platform: mellanox: Fix a resource leak in an error handling path in mlxplat_probe()
Message ID | 8bd0a7944f0f4f1342333eaf8d92d8e9d5623110.1696141233.git.christophe.jaillet@wanadoo.fr |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp852770vqb; Sun, 1 Oct 2023 05:46:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFEOKpSlroO0GvRge5685Z9fz9cuka13yCM627tKHq4ckznejNwHLoabATC+3EA2EqtNTD9 X-Received: by 2002:a17:902:a417:b0:1c3:323f:f531 with SMTP id p23-20020a170902a41700b001c3323ff531mr8833991plq.20.1696164403999; Sun, 01 Oct 2023 05:46:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696164403; cv=none; d=google.com; s=arc-20160816; b=swgIdgbbBdeAOUWHR5CIRSz+gIJUtwJGzRmWadiTUggJ/Z5bp3hY/Obk3dxdgioHSZ QXqgtX1l+cNmijpSBQ6uwBnqUVD0E8a46KG0reu7rQEcjQq4cS3PgCCyvCJEUpxxtjcA F0hxmrbapMN4WSZnoTi6k01+C2X71GTPZs8Ig3p7N0R9jAmiqFQbSj7XkJt3s6mrZ8ZC XBkMh3icqN036rfIWaNe1xxoVDa7yWawy5Dlw1Mf3BI67bXbYT34zgIaLK6x7TVtS5Ra IMKXXTBpJZWWPbLMiaf5PgW9IiRPy9UBnsIrn1WuNKd4RkJI7X6RR0KR6H9phZrNx1cc ynaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=8VNyDNwvUj63WBSAVLx12j5A3luCQB3hSbdx06sW9dw=; fh=ixSk4EDXqh/rAEYbMwPuMh6jxCozel+m6Wv5O9qcuJE=; b=PnP0UtO9khhSRSXjcfeLpU7rHiFhs8mtEws/56gwMbxCdoIo2pgJ6z8y2Y/1QtonPN 7kotUVCjKI9T0ziBNsrd+jIIEpDp6W2RoaNp2WTwVYbEFCyPAgahZbqo7o79g31/1Mb1 wrYMQLWg4u08kZWNTpZ/InMACnkkSXpMymcHP2MgCzpDkEemZBSzc9BYoG7FEEFwzTev BQyzsiaMioFhSKndkfHzBCrw/uTVyMJstx3jSOoa7vCXrS0LFt/JZeDhfhsqPFOjcERX o3QZUw+w5IlDNRY3qUMqTxgJwhcV/nCCQO0eYx1roykqv3urxLO5cdA+GnYpczrBFCU5 ST3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=mZm6LI0q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wanadoo.fr Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id lb7-20020a170902fa4700b001c60d1da0d9si18327658plb.243.2023.10.01.05.46.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Oct 2023 05:46:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=mZm6LI0q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wanadoo.fr Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 15234826C4DA; Sat, 30 Sep 2023 23:21:07 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234356AbjJAGVD (ORCPT <rfc822;pwkd43@gmail.com> + 18 others); Sun, 1 Oct 2023 02:21:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234293AbjJAGVA (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 1 Oct 2023 02:21:00 -0400 Received: from smtp.smtpout.orange.fr (smtp-16.smtpout.orange.fr [80.12.242.16]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FE36DA for <linux-kernel@vger.kernel.org>; Sat, 30 Sep 2023 23:20:56 -0700 (PDT) Received: from pop-os.home ([86.243.2.178]) by smtp.orange.fr with ESMTPA id mpoyqui9X615Bmpozqjj2L; Sun, 01 Oct 2023 08:20:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr; s=t20230301; t=1696141254; bh=8VNyDNwvUj63WBSAVLx12j5A3luCQB3hSbdx06sW9dw=; h=From:To:Cc:Subject:Date; b=mZm6LI0qG50vdg0Uro8unjFDDj9mH+yKMAUMUQ2ocIobQyTbRkztvejkhx/9rI3jz Hl+ODEgwKZFYvl2X6ERvzj7iv6gsRXKfwqvRnDZw62N5+E+DI3QJp0tunDcRjQoYFO BRzMlDyHaol3lIdT0vaFhd6689GkUMYJa55fCjYYRB8Swp0U96eOtqnpaZJb77WxAL VZ/fJgqABRSSxmUCSls5JP5lA12rFNbDMJfl0/1I6f/28qBUjGUSWKKjpcuZXr95Vw esFvOZH7PFjQ8dgbdYYUjcbkFIZUDtrr6GszNWIzglg7UzEtixuwXls4uoB1WipZWT Mzl7W0rvq7JXQ== X-ME-Helo: pop-os.home X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Sun, 01 Oct 2023 08:20:54 +0200 X-ME-IP: 86.243.2.178 From: Christophe JAILLET <christophe.jaillet@wanadoo.fr> To: Vadim Pasternak <vadimp@nvidia.com>, Hans de Goede <hdegoede@redhat.com>, =?utf-8?q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>, Mark Gross <markgross@kernel.org>, Michael Shych <michaelsh@nvidia.com> Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Christophe JAILLET <christophe.jaillet@wanadoo.fr>, platform-driver-x86@vger.kernel.org Subject: [PATCH] platform: mellanox: Fix a resource leak in an error handling path in mlxplat_probe() Date: Sun, 1 Oct 2023 08:20:51 +0200 Message-Id: <8bd0a7944f0f4f1342333eaf8d92d8e9d5623110.1696141233.git.christophe.jaillet@wanadoo.fr> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Sat, 30 Sep 2023 23:21:07 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778557285788679951 X-GMAIL-MSGID: 1778557285788679951 |
Series |
platform: mellanox: Fix a resource leak in an error handling path in mlxplat_probe()
|
|
Commit Message
Christophe JAILLET
Oct. 1, 2023, 6:20 a.m. UTC
If an error occurs after a successful mlxplat_i2c_main_init(),
mlxplat_i2c_main_exit() should be called to free some resources.
Add the missing call, as already done in the remove function.
Fixes: 158cd8320776 ("platform: mellanox: Split logic in init and exit flow")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This patch is based on comparison between functions called in the remove
function and the error handling path of the probe.
For some reason, the way the code is written and function names are
puzzling to me. So Review with care!
---
drivers/platform/x86/mlx-platform.c | 1 +
1 file changed, 1 insertion(+)
Comments
On Sun, 1 Oct 2023, Christophe JAILLET wrote: > If an error occurs after a successful mlxplat_i2c_main_init(), > mlxplat_i2c_main_exit() should be called to free some resources. > > Add the missing call, as already done in the remove function. > > Fixes: 158cd8320776 ("platform: mellanox: Split logic in init and exit flow") > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > --- > This patch is based on comparison between functions called in the remove > function and the error handling path of the probe. > > For some reason, the way the code is written and function names are > puzzling to me. Indeed, pre/post are mixed up for init/exit variants which makes everything very confusing and the call to mlxplat_post_init() is buried deep into the call chain. These would seem better names for the init/deinit with proper pairing: - ..._logicdev_init/deinit for FPGA/CPLD init. - ..._mainbus_init/deinit - perhaps the rest could be just ..._platdevs_reg/unreg Those alone would make it much easier to follow. In addition, - mlxplat_i2c_mux_complition_notify() looks just useless call chain level and should be removed (it also has a typo in its name). - Maybe ..._platdev_reg() (currently mlxplat_post_init()) should be called directly from mainbus_init() or even from .probe() and not from the mux topo init. > So Review with care! It does not look complete as also mlxplat_i2c_main_init() lacks rollback it should do it mlxplat_i2c_mux_topology_init() failed. Since currently mlxplat_i2c_main_init() is what ultimately calls mlxplat_post_init() deep down in the call chain (unless the call to it gets moved out from there), it would be appropriate for mlxplat_i2c_main_exit() to do/call the cleanup. And neither .probe() nor .remove() should call mlxplat_pre_exit() directly in that case. So two alternative ways forward for the fix before all the renaming: 1) Move mlxplat_post_init() call out of its current place into .probe() and make the rollback path there to match that. 2) Do cleanup properly in mlxplat_i2c_main_init() and mlxplat_i2c_main_exit(). I'd prefer 1) because it's much simpler to follow the init logic when the init components are not hidden deep into the call chain.
Hi Ilpo, Thank you very much for review. > -----Original Message----- > From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> > Sent: Tuesday, 3 October 2023 15:06 > To: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > Cc: Vadim Pasternak <vadimp@nvidia.com>; Hans de Goede > <hdegoede@redhat.com>; Mark Gross <markgross@kernel.org>; Michael > Shych <michaelsh@nvidia.com>; LKML <linux-kernel@vger.kernel.org>; kernel- > janitors@vger.kernel.org; platform-driver-x86@vger.kernel.org > Subject: Re: [PATCH] platform: mellanox: Fix a resource leak in an error > handling path in mlxplat_probe() > > On Sun, 1 Oct 2023, Christophe JAILLET wrote: > > > If an error occurs after a successful mlxplat_i2c_main_init(), > > mlxplat_i2c_main_exit() should be called to free some resources. > > > > Add the missing call, as already done in the remove function. > > > > Fixes: 158cd8320776 ("platform: mellanox: Split logic in init and exit > > flow") > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > --- > > This patch is based on comparison between functions called in the > > remove function and the error handling path of the probe. > > > > For some reason, the way the code is written and function names are > > puzzling to me. > > Indeed, pre/post are mixed up for init/exit variants which makes everything > very confusing and the call to mlxplat_post_init() is buried deep into the call > chain. > > These would seem better names for the init/deinit with proper pairing: > > - ..._logicdev_init/deinit for FPGA/CPLD init. > - ..._mainbus_init/deinit > - perhaps the rest could be just ..._platdevs_reg/unreg > > Those alone would make it much easier to follow. > > In addition, > - mlxplat_i2c_mux_complition_notify() looks just useless call chain level > and should be removed (it also has a typo in its name). > - Maybe ..._platdev_reg() (currently mlxplat_post_init()) should be called > directly from mainbus_init() or even from .probe() and not from the > mux topo init. > > > So Review with care! > > It does not look complete as also mlxplat_i2c_main_init() lacks rollback it > should do it mlxplat_i2c_mux_topology_init() failed. > > Since currently mlxplat_i2c_main_init() is what ultimately calls > mlxplat_post_init() deep down in the call chain (unless the call to it gets moved > out from there), it would be appropriate for > mlxplat_i2c_main_exit() to do/call the cleanup. And neither .probe() nor > .remove() should call mlxplat_pre_exit() directly in that case. > > So two alternative ways forward for the fix before all the renaming: > > 1) Move mlxplat_post_init() call out of its current place into .probe() > and make the rollback path there to match that. > 2) Do cleanup properly in mlxplat_i2c_main_init() and > mlxplat_i2c_main_exit(). > > I'd prefer 1) because it's much simpler to follow the init logic when the init > components are not hidden deep into the call chain. > I would prefer to keep mlxplat_i2c_mux_complition_notify() as separate function. I am going to use it as a callback. I suggest I'll prepare the next patches: 1. As a bugfix, fix provided by Christophe and additional cleanup in mlxplat_i2c_main_init(): @@ -6514,6 +6514,10 @@ static int mlxplat_i2c_main_init(struct mlxplat_priv *priv) return 0; fail_mlxplat_i2c_mux_topology_init: + if (priv->pdev_i2c) { + platform_device_unregister(priv->pdev_i2c); + priv->pdev_i2c = NULL; + } fail_platform_i2c_register: fail_mlxplat_mlxcpld_verify_bus_topology: return err; @@ -6598,6 +6602,7 @@ static int mlxplat_probe(struct platform_device *pdev) fail_register_reboot_notifier: fail_regcache_sync: mlxplat_pre_exit(priv); + mlxplat_i2c_main_exit(priv); fail_mlxplat_i2c_main_init: fail_regmap_write: 2. Move mlxplat_pre_exit() inside mlxplat_i2c_main_exit() 3. Fix of ' complition' misspelling: s/mlxplat_i2c_main_complition_notify/ mlxplat_i2c_main_completion_notify 4. Renaming: mlxplat_pre_init()/mlxplat_post_exit() to mlxplat_logicdev_init()/mlxplat_logicdev_exit() mlxplat_i2c_main_init()/mlxplat_i2c_main_exit() keep as is. mlxplat_post_init()/mlxplat_pre_exit() to mlxplat_platdevs_init()/mlxplat_platdevs_exit() What do you think? Thanks, Vadim. > -- > i. > > > > --- > > drivers/platform/x86/mlx-platform.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/platform/x86/mlx-platform.c > b/drivers/platform/x86/mlx-platform.c > > index 3d96dbf79a72..64701b63336e 100644 > > --- a/drivers/platform/x86/mlx-platform.c > > +++ b/drivers/platform/x86/mlx-platform.c > > @@ -6598,6 +6598,7 @@ static int mlxplat_probe(struct platform_device > *pdev) > > fail_register_reboot_notifier: > > fail_regcache_sync: > > mlxplat_pre_exit(priv); > > + mlxplat_i2c_main_exit(priv); > > fail_mlxplat_i2c_main_init: > > fail_regmap_write: > > fail_alloc: > >
On Tue, 3 Oct 2023, Vadim Pasternak wrote: > Hi Ilpo, > Thank you very much for review. > > > -----Original Message----- > > From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> > > Sent: Tuesday, 3 October 2023 15:06 > > To: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > Cc: Vadim Pasternak <vadimp@nvidia.com>; Hans de Goede > > <hdegoede@redhat.com>; Mark Gross <markgross@kernel.org>; Michael > > Shych <michaelsh@nvidia.com>; LKML <linux-kernel@vger.kernel.org>; kernel- > > janitors@vger.kernel.org; platform-driver-x86@vger.kernel.org > > Subject: Re: [PATCH] platform: mellanox: Fix a resource leak in an error > > handling path in mlxplat_probe() > > > > On Sun, 1 Oct 2023, Christophe JAILLET wrote: > > > > > If an error occurs after a successful mlxplat_i2c_main_init(), > > > mlxplat_i2c_main_exit() should be called to free some resources. > > > > > > Add the missing call, as already done in the remove function. > > > > > > Fixes: 158cd8320776 ("platform: mellanox: Split logic in init and exit > > > flow") > > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > > --- > > > This patch is based on comparison between functions called in the > > > remove function and the error handling path of the probe. > > > > > > For some reason, the way the code is written and function names are > > > puzzling to me. > > > > Indeed, pre/post are mixed up for init/exit variants which makes everything > > very confusing and the call to mlxplat_post_init() is buried deep into the call > > chain. > > > > These would seem better names for the init/deinit with proper pairing: > > > > - ..._logicdev_init/deinit for FPGA/CPLD init. > > - ..._mainbus_init/deinit > > - perhaps the rest could be just ..._platdevs_reg/unreg > > > > Those alone would make it much easier to follow. > > > > In addition, > > - mlxplat_i2c_mux_complition_notify() looks just useless call chain level > > and should be removed (it also has a typo in its name). > > - Maybe ..._platdev_reg() (currently mlxplat_post_init()) should be called > > directly from mainbus_init() or even from .probe() and not from the > > mux topo init. > > > > > So Review with care! > > > > It does not look complete as also mlxplat_i2c_main_init() lacks rollback it > > should do it mlxplat_i2c_mux_topology_init() failed. > > > > Since currently mlxplat_i2c_main_init() is what ultimately calls > > mlxplat_post_init() deep down in the call chain (unless the call to it gets moved > > out from there), it would be appropriate for > > mlxplat_i2c_main_exit() to do/call the cleanup. And neither .probe() nor > > .remove() should call mlxplat_pre_exit() directly in that case. > > > > So two alternative ways forward for the fix before all the renaming: > > > > 1) Move mlxplat_post_init() call out of its current place into .probe() > > and make the rollback path there to match that. > > 2) Do cleanup properly in mlxplat_i2c_main_init() and > > mlxplat_i2c_main_exit(). > > > > I'd prefer 1) because it's much simpler to follow the init logic when the init > > components are not hidden deep into the call chain. > > > > I would prefer to keep mlxplat_i2c_mux_complition_notify() as separate > function. I am going to use it as a callback. It's okay for it to remain as long as the init/deinit pairs properly in the end. > I suggest I'll prepare the next patches: > > 1. > As a bugfix, fix provided by Christophe and additional cleanup in > mlxplat_i2c_main_init(): > > @@ -6514,6 +6514,10 @@ static int mlxplat_i2c_main_init(struct mlxplat_priv *priv) > return 0; > > fail_mlxplat_i2c_mux_topology_init: > + if (priv->pdev_i2c) { > + platform_device_unregister(priv->pdev_i2c); > + priv->pdev_i2c = NULL; > + } > fail_platform_i2c_register: > fail_mlxplat_mlxcpld_verify_bus_topology: > return err; > @@ -6598,6 +6602,7 @@ static int mlxplat_probe(struct platform_device *pdev) > fail_register_reboot_notifier: > fail_regcache_sync: > mlxplat_pre_exit(priv); > + mlxplat_i2c_main_exit(priv); > fail_mlxplat_i2c_main_init: > fail_regmap_write: > > 2. > Move mlxplat_pre_exit() inside mlxplat_i2c_main_exit() This can be and should be combined with step 1 (where .probe()'s rollback and .remove() would call it and not mlxplat_pre_exit() at all). It already makes the pairing okay on the logic level so only name pairing needs to be done after that. You can do separate patch both with Fixes tags since these are kinda independent issues. These 1+2 are what I suggested in 2). > 3. > Fix of ' complition' misspelling: > s/mlxplat_i2c_main_complition_notify/ mlxplat_i2c_main_completion_notify > > 4. > > Renaming: > mlxplat_pre_init()/mlxplat_post_exit() to > mlxplat_logicdev_init()/mlxplat_logicdev_exit() > > mlxplat_i2c_main_init()/mlxplat_i2c_main_exit() keep as is. > > mlxplat_post_init()/mlxplat_pre_exit() to > mlxplat_platdevs_init()/mlxplat_platdevs_exit() > > What do you think? Yes to 3 & 4.
> -----Original Message----- > From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> > Sent: Wednesday, 4 October 2023 11:52 > To: Vadim Pasternak <vadimp@nvidia.com> > Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>; Hans de Goede > <hdegoede@redhat.com>; Mark Gross <markgross@kernel.org>; Michael > Shych <michaelsh@nvidia.com>; LKML <linux-kernel@vger.kernel.org>; kernel- > janitors@vger.kernel.org; platform-driver-x86@vger.kernel.org > Subject: RE: [PATCH] platform: mellanox: Fix a resource leak in an error > handling path in mlxplat_probe() > > On Tue, 3 Oct 2023, Vadim Pasternak wrote: > > > Hi Ilpo, > > Thank you very much for review. > > > > > -----Original Message----- > > > From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> > > > Sent: Tuesday, 3 October 2023 15:06 > > > To: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > > Cc: Vadim Pasternak <vadimp@nvidia.com>; Hans de Goede > > > <hdegoede@redhat.com>; Mark Gross <markgross@kernel.org>; Michael > > > Shych <michaelsh@nvidia.com>; LKML <linux-kernel@vger.kernel.org>; > > > kernel- janitors@vger.kernel.org; > > > platform-driver-x86@vger.kernel.org > > > Subject: Re: [PATCH] platform: mellanox: Fix a resource leak in an > > > error handling path in mlxplat_probe() > > > > > > On Sun, 1 Oct 2023, Christophe JAILLET wrote: > > > > > > > If an error occurs after a successful mlxplat_i2c_main_init(), > > > > mlxplat_i2c_main_exit() should be called to free some resources. > > > > > > > > Add the missing call, as already done in the remove function. > > > > > > > > Fixes: 158cd8320776 ("platform: mellanox: Split logic in init and > > > > exit > > > > flow") > > > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > > > --- > > > > This patch is based on comparison between functions called in the > > > > remove function and the error handling path of the probe. > > > > > > > > For some reason, the way the code is written and function names > > > > are puzzling to me. > > > > > > Indeed, pre/post are mixed up for init/exit variants which makes > > > everything very confusing and the call to mlxplat_post_init() is > > > buried deep into the call chain. > > > > > > These would seem better names for the init/deinit with proper pairing: > > > > > > - ..._logicdev_init/deinit for FPGA/CPLD init. > > > - ..._mainbus_init/deinit > > > - perhaps the rest could be just ..._platdevs_reg/unreg > > > > > > Those alone would make it much easier to follow. > > > > > > In addition, > > > - mlxplat_i2c_mux_complition_notify() looks just useless call chain level > > > and should be removed (it also has a typo in its name). > > > - Maybe ..._platdev_reg() (currently mlxplat_post_init()) should be called > > > directly from mainbus_init() or even from .probe() and not from the > > > mux topo init. > > > > > > > So Review with care! > > > > > > It does not look complete as also mlxplat_i2c_main_init() lacks > > > rollback it should do it mlxplat_i2c_mux_topology_init() failed. > > > > > > Since currently mlxplat_i2c_main_init() is what ultimately calls > > > mlxplat_post_init() deep down in the call chain (unless the call to > > > it gets moved out from there), it would be appropriate for > > > mlxplat_i2c_main_exit() to do/call the cleanup. And neither > > > .probe() nor > > > .remove() should call mlxplat_pre_exit() directly in that case. > > > > > > So two alternative ways forward for the fix before all the renaming: > > > > > > 1) Move mlxplat_post_init() call out of its current place into .probe() > > > and make the rollback path there to match that. > > > 2) Do cleanup properly in mlxplat_i2c_main_init() and > > > mlxplat_i2c_main_exit(). > > > > > > I'd prefer 1) because it's much simpler to follow the init logic > > > when the init components are not hidden deep into the call chain. > > > > > > > I would prefer to keep mlxplat_i2c_mux_complition_notify() as separate > > function. I am going to use it as a callback. > > It's okay for it to remain as long as the init/deinit pairs properly in the end. > > > I suggest I'll prepare the next patches: > > > > 1. > > As a bugfix, fix provided by Christophe and additional cleanup in > > mlxplat_i2c_main_init(): > > > > @@ -6514,6 +6514,10 @@ static int mlxplat_i2c_main_init(struct > mlxplat_priv *priv) > > return 0; > > > > fail_mlxplat_i2c_mux_topology_init: > > + if (priv->pdev_i2c) { > > + platform_device_unregister(priv->pdev_i2c); > > + priv->pdev_i2c = NULL; > > + } > > fail_platform_i2c_register: > > fail_mlxplat_mlxcpld_verify_bus_topology: > > return err; > > @@ -6598,6 +6602,7 @@ static int mlxplat_probe(struct platform_device > > *pdev) > > fail_register_reboot_notifier: > > fail_regcache_sync: > > mlxplat_pre_exit(priv); > > + mlxplat_i2c_main_exit(priv); > > fail_mlxplat_i2c_main_init: > > fail_regmap_write: > > > > 2. > > Move mlxplat_pre_exit() inside mlxplat_i2c_main_exit() > > This can be and should be combined with step 1 (where .probe()'s rollback > and .remove() would call it and not mlxplat_pre_exit() at all). It already makes > the pairing okay on the logic level so only name pairing needs to be done after > that. > > You can do separate patch both with Fixes tags since these are kinda > independent issues. > > These 1+2 are what I suggested in 2). > > > 3. > > Fix of ' complition' misspelling: > > s/mlxplat_i2c_main_complition_notify/ > > mlxplat_i2c_main_completion_notify > > > > 4. > > > > Renaming: > > mlxplat_pre_init()/mlxplat_post_exit() to > > mlxplat_logicdev_init()/mlxplat_logicdev_exit() > > > > mlxplat_i2c_main_init()/mlxplat_i2c_main_exit() keep as is. > > > > mlxplat_post_init()/mlxplat_pre_exit() to > > mlxplat_platdevs_init()/mlxplat_platdevs_exit() > > > > What do you think? > > Yes to 3 & 4. Hi Ilpo, Thank you very much for your inputs. I sent one bugfix and two amendment patches. I just wanted to note, that in case of some comments for these patches, I'll be able to make modifications only after 15 October. Thanks, Vadim. > > > -- > i.
diff --git a/drivers/platform/x86/mlx-platform.c b/drivers/platform/x86/mlx-platform.c index 3d96dbf79a72..64701b63336e 100644 --- a/drivers/platform/x86/mlx-platform.c +++ b/drivers/platform/x86/mlx-platform.c @@ -6598,6 +6598,7 @@ static int mlxplat_probe(struct platform_device *pdev) fail_register_reboot_notifier: fail_regcache_sync: mlxplat_pre_exit(priv); + mlxplat_i2c_main_exit(priv); fail_mlxplat_i2c_main_init: fail_regmap_write: fail_alloc: