linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Andi Shyti <andi.shyti@kernel.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Peter Rosin <peda@axentia.se>,
	Derek Kiernan <derek.kiernan@amd.com>,
	Dragan Cvetic <dragan.cvetic@amd.com>,
	Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Mark Brown <broonie@kernel.org>, Len Brown <lenb@kernel.org>,
	Daniel Scally <djrscally@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Wolfram Sang <wsa@kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	linux-kernel@vger.kernel.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-acpi@vger.kernel.org,
	Allan Nielsen <allan.nielsen@microchip.com>,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	Steen Hegelund <steen.hegelund@microchip.com>,
	Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v2 16/26] i2c: mux: Create missing devlink between mux and adapter physical device
Date: Mon, 19 May 2025 16:39:35 +0200	[thread overview]
Message-ID: <20250519163935.3e47ec04@bootlin.com> (raw)
In-Reply-To: <aB0C05WnKkgslAuT@smile.fi.intel.com>

Hi Andy,

On Thu, 8 May 2025 22:15:31 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Wed, May 07, 2025 at 09:12:58AM +0200, Herve Codina wrote:
> > When removing an i2c controller device handling an i2c bus where an i2c
> > mux is connected to, the removal process hangs and is stuck in the
> > wait_completion() call done in i2c_del_adapter().
> > 
> > The i2c_del_adapter() tries to removed the i2c adapter related to the
> > i2c controller device and the wait_completion() is waiting for the i2c
> > adapter device release. This release is performed when the device is no
> > more used (i.e. refcount reaches zero).
> > 
> > When an i2c mux is involved in an i2c path, the struct dev topology is
> > the following:
> >     +----------------+                +-------------------+
> >     | i2c controller |                |      i2c mux      |
> >     |     device     |                |      device       |
> >     |       ^        |                |                   |
> >     |       |        |                |                   |
> >     |  dev's parent  |                |                   |
> >     |       |        |                |                   |
> >     |   i2c adapter  |                | i2c adapter chanX |
> >     |     device  <---- dev's parent ------  device       |
> >     |   (no driver)  |                |    (no driver)    |
> >     +----------------+                +-------------------+
> > 
> > When an i2c mux device creates an i2c adapter for its downstream
> > channel, a reference is taken to its adapter dev's parent. This parent
> > is the i2c mux upstream adapter device.
> > 
> > No relationship exists between the i2c mux device itself and the i2c
> > controller device (physical device) in order to have the i2c mux device
> > calling i2c_del_adapter() to remove its downtream adapters and so,
> > release references taken to the upstream adapter.
> > 
> > This consumer/supplier relationship is typically a devlink relationship.
> > 
> > Also, i2c muxes can be chained and so, the upstream adapter can be
> > supplied by either an i2c controller device or an other i2c mux device.
> > 
> > In order to get the physical device of the adapter a mux is connected
> > to, rely on the newly introduced i2c_adapter_get_physdev() and create
> > the missing devlink between the i2c mux device and the physical
> > device of the adapter the mux is connected to.
> > 
> > With that done, the i2c mux device is removed before the device
> > handling the upstream i2c adapter (i2c controller device or i2c mux
> > device). All references are released and the i2c_del_adapter() call
> > performed by driver handling the upstream adapter device is not blocking
> > anymore.  
> 
> ...
> 
> > +	/*
> > +	 * There is no relationship set between the mux device and the physical
> > +	 * device handling the parent adapter. Create this missing relationship
> > +	 * in order to remove the i2c mux device (consumer) and so the dowstream
> > +	 * channel adapters before removing the physical device (supplier) which
> > +	 * handles the i2c mux upstream adapter.
> > +	 */
> > +	parent_physdev = i2c_get_adapter_physdev(parent);
> > +	dl = device_link_add(muxc->dev, parent_physdev, DL_FLAG_AUTOREMOVE_CONSUMER);
> > +	if (!dl) {
> > +		dev_err(muxc->dev, "failed to create device link to %s\n",
> > +			dev_name(parent_physdev));
> > +		put_device(parent_physdev);
> > +		ret = -EINVAL;
> > +		goto err_free_priv;
> > +	}
> > +	put_device(parent_physdev);  
> 
> Since you are not checking parent_physdev for NULL, the dev_name() can print a
> "(null)" string. Is this by design?

It is worse than that. If parent_physdev is NULL, dev_name() can crash.

I will fix that and check parent_physdev for NULL in the next iteration.

Best regards,
Hervé


  reply	other threads:[~2025-05-19 17:18 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07  7:12 [PATCH v2 00/26] lan966x pci device: Add support for SFPs Herve Codina
2025-05-07  7:12 ` [PATCH v2 01/26] Revert "treewide: Fix probing of devices in DT overlays" Herve Codina
2025-05-07 11:28   ` Mark Brown
2025-05-07  7:12 ` [PATCH v2 02/26] driver core: Rename get_dev_from_fwnode() wrapper to get_device_from_fwnode() Herve Codina
2025-05-07  7:12 ` [PATCH v2 03/26] of: dynamic: Fix overlayed devices not probing because of fw_devlink Herve Codina
2025-05-07  7:12 ` [PATCH v2 04/26] driver core: Avoid warning when removing a device while its supplier is unbinding Herve Codina
2025-05-07 15:15   ` Andy Shevchenko
2025-05-19 11:35     ` Herve Codina
2025-05-07  7:12 ` [PATCH v2 05/26] bus: simple-pm-bus: Populate child nodes at probe Herve Codina
2025-05-08 14:27   ` Andy Shevchenko
2025-05-19 11:58     ` Herve Codina
2025-05-19 12:06       ` Andy Shevchenko
2025-05-19 14:24         ` Herve Codina
2025-05-16 19:22   ` Rafael J. Wysocki
2025-05-19 12:46     ` Herve Codina
2025-05-07  7:12 ` [PATCH v2 06/26] driver core: fw_devlink: Introduce fw_devlink_set_device() Herve Codina
2025-05-07 15:02   ` Andy Shevchenko
2025-05-19 14:27     ` Herve Codina
2025-05-07  7:12 ` [PATCH v2 07/26] drivers: core: Use fw_devlink_set_device() Herve Codina
2025-05-07  7:12 ` [PATCH v2 08/26] pinctrl: cs42l43: " Herve Codina
2025-05-07 15:06   ` Andy Shevchenko
2025-05-07  7:12 ` [PATCH v2 09/26] cxl/test: Use device_set_node() Herve Codina
2025-05-07 15:10   ` Andy Shevchenko
2025-05-07  7:12 ` [PATCH v2 10/26] cxl/test: Use fw_devlink_set_device() Herve Codina
2025-05-07  7:12 ` [PATCH v2 11/26] PCI: of: " Herve Codina
2025-05-07  7:12 ` [PATCH v2 12/26] PCI: of: Set fwnode device of newly created PCI device nodes Herve Codina
2025-05-08 18:31   ` Andy Shevchenko
2025-05-08 18:35     ` Geert Uytterhoeven
2025-05-07  7:12 ` [PATCH v2 13/26] PCI: of: Remove fwnode_dev_initialized() call for a PCI root bridge node Herve Codina
2025-05-07  7:12 ` [PATCH v2 14/26] i2c: core: Introduce i2c_get_adapter_physdev() Herve Codina
2025-05-07  7:12 ` [PATCH v2 15/26] i2c: mux: Set adapter physical device Herve Codina
2025-05-07  7:12 ` [PATCH v2 16/26] i2c: mux: Create missing devlink between mux and " Herve Codina
2025-05-08 19:15   ` Andy Shevchenko
2025-05-19 14:39     ` Herve Codina [this message]
2025-05-07  7:12 ` [PATCH v2 17/26] of: property: Allow fw_devlink device-tree on x86 when PCI device-tree node creation is enabled Herve Codina
2025-05-08 19:19   ` Andy Shevchenko
2025-05-07  7:13 ` [PATCH v2 18/26] clk: lan966x: Add MCHP_LAN966X_PCI dependency Herve Codina
2025-05-07  7:13 ` [PATCH v2 19/26] i2c: busses: at91: " Herve Codina
2025-05-12 22:32   ` Andi Shyti
2025-05-07  7:13 ` [PATCH v2 20/26] misc: lan966x_pci: Fix dtso nodes ordering Herve Codina
2025-05-07  7:13 ` [PATCH v2 21/26] misc: lan966x_pci: Split dtso in dtsi/dtso Herve Codina
2025-05-07 22:14   ` Andrew Lunn
2025-05-07  7:13 ` [PATCH v2 22/26] misc: lan966x_pci: Rename lan966x_pci.dtso to lan966x_evb_lan9662_nic.dtso Herve Codina
2025-05-07 22:14   ` Andrew Lunn
2025-05-07  7:13 ` [PATCH v2 23/26] misc: lan966x_pci: Introduce board specific data Herve Codina
2025-05-07 22:24   ` Andrew Lunn
2025-05-08  7:13     ` Geert Uytterhoeven
2025-05-29 13:19       ` Rob Herring
2025-05-19 14:44     ` Herve Codina
2025-05-08 19:21   ` Andy Shevchenko
2025-05-19 15:00     ` Herve Codina
2025-05-19 15:44       ` Andy Shevchenko
2025-05-07  7:13 ` [PATCH v2 24/26] misc: lan966x_pci: Add dtsi/dtso nodes in order to support SFPs Herve Codina
2025-05-07  7:13 ` [PATCH v2 25/26] misc: lan966x_pci: Sort the drivers list in Kconfig help Herve Codina
2025-05-07  7:13 ` [PATCH v2 26/26] misc: lan966x_pci: Add drivers needed to support SFPs " Herve Codina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250519163935.3e47ec04@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=allan.nielsen@microchip.com \
    --cc=andi.shyti@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=broonie@kernel.org \
    --cc=dakr@kernel.org \
    --cc=derek.kiernan@amd.com \
    --cc=devicetree@vger.kernel.org \
    --cc=djrscally@gmail.com \
    --cc=dragan.cvetic@amd.com \
    --cc=festevam@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=mturquette@baylibre.com \
    --cc=peda@axentia.se \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=sakari.ailus@linux.intel.com \
    --cc=saravanak@google.com \
    --cc=sboyd@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=steen.hegelund@microchip.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).