| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20250407145546.270683-11-herve.codina@bootlin.com>
Date: Mon, 7 Apr 2025 16:55:39 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Danilo Krummrich <dakr@...nel.org>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Andi Shyti <andi.shyti@...nel.org>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
Peter Rosin <peda@...ntia.se>,
Derek Kiernan <derek.kiernan@....com>,
Dragan Cvetic <dragan.cvetic@....com>,
Arnd Bergmann <arnd@...db.de>,
Herve Codina <herve.codina@...tlin.com>,
Rob Herring <robh@...nel.org>,
Saravana Kannan <saravanak@...gle.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Mark Brown <broonie@...nel.org>,
Len Brown <lenb@...nel.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Daniel Scally <djrscally@...il.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: Wolfram Sang <wsa@...nel.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
linux-kernel@...r.kernel.org,
imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org,
linux-clk@...r.kernel.org,
linux-i2c@...r.kernel.org,
devicetree@...r.kernel.org,
linux-pci@...r.kernel.org,
linux-spi@...r.kernel.org,
linux-acpi@...r.kernel.org,
Allan Nielsen <allan.nielsen@...rochip.com>,
Horatiu Vultur <horatiu.vultur@...rochip.com>,
Steen Hegelund <steen.hegelund@...rochip.com>,
Luca Ceresoli <luca.ceresoli@...tlin.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: [PATCH 10/16] i2c: mux: Create missing devlink between mux and adapter supplier
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 dev 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 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 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 supplier of the adapter a mux is connected to,
rely on the newly introduced i2c_adapter_get_supplier() and create the
missing devlink between the i2c mux device and the supplier 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.
Signed-off-by: Herve Codina <herve.codina@...tlin.com>
---
drivers/i2c/i2c-mux.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index d8bdb3b40acf..84ffd58e4d6d 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -271,7 +271,9 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
u32 force_nr, u32 chan_id)
{
struct i2c_adapter *parent = muxc->parent;
+ struct device *parent_supplier;
struct i2c_mux_priv *priv;
+ struct device_link *dl;
char symlink_name[20];
int ret;
@@ -378,6 +380,24 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
ACPI_COMPANION(muxc->dev),
chan_id);
+ /*
+ * There is no relationship set between the mux dev and the 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 device (supplier) which handles
+ * the i2c mux upstream adapter.
+ */
+ parent_supplier = i2c_get_adapter_supplier(parent);
+ dl = device_link_add(muxc->dev, parent_supplier, DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!dl) {
+ dev_err(muxc->dev, "failed to create device link to %s\n",
+ dev_name(parent_supplier));
+ put_device(parent_supplier);
+ ret = -EINVAL;
+ goto err_free_priv;
+ }
+ put_device(parent_supplier);
+
if (force_nr) {
priv->adap.nr = force_nr;
ret = i2c_add_numbered_adapter(&priv->adap);
--
2.49.0
Powered by blists - more mailing lists