Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23  1:54 UTC (permalink / raw)
  To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Vinod Koul, Neil Armstrong, Mark Brown,
	Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin, Andrew Lunn,
	Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
	Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
  Cc: netdev, linux-kernel, linux-phy, linux-spi, linux-leds,
	linux-fpga, driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-0-b72eb22a1215@gmail.com>

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/net/phy/mdio_bus_provider.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/mdio_bus_provider.c b/drivers/net/phy/mdio_bus_provider.c
index 041576eba47a..ed3cd9a37c67 100644
--- a/drivers/net/phy/mdio_bus_provider.c
+++ b/drivers/net/phy/mdio_bus_provider.c
@@ -21,6 +21,7 @@
 #include <linux/mii.h>
 #include <linux/mm.h>
 #include <linux/netdevice.h>
+#include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/of_mdio.h>
 #include <linux/phy.h>
@@ -754,7 +755,8 @@ struct mii_bus *of_mdio_find_bus(struct device_node *mdio_bus_np)
 	if (!mdio_bus_np)
 		return NULL;
 
-	d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
+	d = class_find_device_by_fwnode(&mdio_bus_class,
+					of_fwnode_handle(mdio_bus_np));
 	return d ? to_mii_bus(d) : NULL;
 }
 EXPORT_SYMBOL(of_mdio_find_bus);

-- 
2.53.0.959.g497ff81fa9-goog


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH 06/10] mux: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23  1:54 UTC (permalink / raw)
  To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Vinod Koul, Neil Armstrong, Mark Brown,
	Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin, Andrew Lunn,
	Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
	Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
  Cc: netdev, linux-kernel, linux-phy, linux-spi, linux-leds,
	linux-fpga, driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-0-b72eb22a1215@gmail.com>

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/mux/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index 23538de2c91b..774d4cc67cc1 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -521,7 +521,7 @@ static struct mux_chip *of_find_mux_chip_by_node(struct device_node *np)
 {
 	struct device *dev;
 
-	dev = class_find_device_by_of_node(&mux_class, np);
+	dev = class_find_device_by_fwnode(&mux_class, of_fwnode_handle(np));
 
 	return dev ? to_mux_chip(dev) : NULL;
 }

-- 
2.53.0.959.g497ff81fa9-goog


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH 05/10] leds: led-class: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23  1:54 UTC (permalink / raw)
  To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Vinod Koul, Neil Armstrong, Mark Brown,
	Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin, Andrew Lunn,
	Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
	Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
  Cc: netdev, linux-kernel, linux-phy, linux-spi, linux-leds,
	linux-fpga, driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-0-b72eb22a1215@gmail.com>

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/leds/led-class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index d34a19453560..8d7ec9ccb173 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -273,7 +273,7 @@ static struct led_classdev *of_led_get(struct device_node *np, int index,
 	if (!led_node)
 		return ERR_PTR(-ENOENT);
 
-	led_dev = class_find_device_by_of_node(&leds_class, led_node);
+	led_dev = class_find_device_by_fwnode(&leds_class, of_fwnode_handle(led_node));
 	of_node_put(led_node);
 
 	return led_module_get(led_dev);

-- 
2.53.0.959.g497ff81fa9-goog


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23  1:54 UTC (permalink / raw)
  To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Vinod Koul, Neil Armstrong, Mark Brown,
	Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin, Andrew Lunn,
	Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
	Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
  Cc: netdev, linux-kernel, linux-phy, linux-spi, linux-leds,
	linux-fpga, driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-0-b72eb22a1215@gmail.com>

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/regulator/of_regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index c0cc6cc0afd8..43ec0845c940 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -637,7 +637,7 @@ static struct regulator_dev *of_find_regulator_by_node(struct device_node *np)
 {
 	struct device *dev;
 
-	dev = class_find_device_by_of_node(&regulator_class, np);
+	dev = class_find_device_by_fwnode(&regulator_class, of_fwnode_handle(np));
 
 	return dev ? dev_to_rdev(dev) : NULL;
 }

-- 
2.53.0.959.g497ff81fa9-goog


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH 03/10] spi: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23  1:54 UTC (permalink / raw)
  To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Vinod Koul, Neil Armstrong, Mark Brown,
	Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin, Andrew Lunn,
	Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
	Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
  Cc: netdev, linux-kernel, linux-phy, linux-spi, linux-leds,
	linux-fpga, driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-0-b72eb22a1215@gmail.com>

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/spi/spi.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index bf1df365f795..071a9ffdb59d 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -21,6 +21,7 @@
 #include <linux/kthread.h>
 #include <linux/mod_devicetable.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
 #include <linux/percpu.h>
@@ -4948,11 +4949,12 @@ EXPORT_SYMBOL_GPL(spi_write_then_read);
 /* The spi controllers are not using spi_bus, so we find it with another way */
 struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
 {
+	struct fwnode_handle *fwnode = of_fwnode_handle(node);
 	struct device *dev;
 
-	dev = class_find_device_by_of_node(&spi_controller_class, node);
+	dev = class_find_device_by_fwnode(&spi_controller_class, fwnode);
 	if (!dev && IS_ENABLED(CONFIG_SPI_SLAVE))
-		dev = class_find_device_by_of_node(&spi_target_class, node);
+		dev = class_find_device_by_fwnode(&spi_target_class, fwnode);
 	if (!dev)
 		return NULL;
 

-- 
2.53.0.959.g497ff81fa9-goog


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH 02/10] phy: core: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23  1:54 UTC (permalink / raw)
  To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Vinod Koul, Neil Armstrong, Mark Brown,
	Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin, Andrew Lunn,
	Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
	Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
  Cc: netdev, linux-kernel, linux-phy, linux-spi, linux-leds,
	linux-fpga, driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-0-b72eb22a1215@gmail.com>

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/phy/phy-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 21aaf2f76e53..57bce6b63a31 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -761,7 +761,8 @@ struct phy *of_phy_simple_xlate(struct device *dev,
 {
 	struct device *target_dev;
 
-	target_dev = class_find_device_by_of_node(&phy_class, args->np);
+	target_dev = class_find_device_by_fwnode(&phy_class,
+						 of_fwnode_handle(args->np));
 	if (!target_dev)
 		return ERR_PTR(-ENODEV);
 

-- 
2.53.0.959.g497ff81fa9-goog


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH net-next 01/10] net: wan: framer: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23  1:54 UTC (permalink / raw)
  To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Vinod Koul, Neil Armstrong, Mark Brown,
	Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin, Andrew Lunn,
	Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
	Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
  Cc: netdev, linux-kernel, linux-phy, linux-spi, linux-leds,
	linux-fpga, driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-0-b72eb22a1215@gmail.com>

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/net/wan/framer/framer-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wan/framer/framer-core.c b/drivers/net/wan/framer/framer-core.c
index d779b03a9e1b..77ef1bfd476c 100644
--- a/drivers/net/wan/framer/framer-core.c
+++ b/drivers/net/wan/framer/framer-core.c
@@ -745,7 +745,7 @@ struct framer *framer_provider_simple_of_xlate(struct device *dev,
 {
 	struct device *target_dev;
 
-	target_dev = class_find_device_by_of_node(&framer_class, args->np);
+	target_dev = class_find_device_by_fwnode(&framer_class, of_fwnode_handle(args->np));
 	if (!target_dev)
 		return ERR_PTR(-ENODEV);
 

-- 
2.53.0.959.g497ff81fa9-goog


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH 00/10] Remove class_find_device_by_of_node in favor of finding by firmware node
From: Dmitry Torokhov @ 2026-03-23  1:54 UTC (permalink / raw)
  To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Vinod Koul, Neil Armstrong, Mark Brown,
	Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin, Andrew Lunn,
	Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
	Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
  Cc: netdev, linux-kernel, linux-phy, linux-spi, linux-leds,
	linux-fpga, driver-core

Firmware nodes are generalization of OF device nodes and generic APIs
should offer only fwnode variants instead of providing firmware-specific
handlers.

This series switches all users of class_find_device_by_of_node() to
class_find_device_by_fwnode() and removes the OF variant.

I believe this can be applied through individual subsystems and then the
last patch can go into the driver core.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Dmitry Torokhov (10):
      net: wan: framer: switch to using class_find_device_by_fwnode()
      phy: core: switch to using class_find_device_by_fwnode()
      spi: switch to using class_find_device_by_fwnode()
      regulator: of: switch to using class_find_device_by_fwnode()
      leds: led-class: switch to using class_find_device_by_fwnode()
      mux: switch to using class_find_device_by_fwnode()
      net: phy: switch to using class_find_device_by_fwnode()
      fpga: bridge: switch to using class_find_device_by_fwnode()
      fpga: manager: switch to using class_find_device_by_fwnode()
      driver core: class: remove class_find_device_by_of_node()

 drivers/fpga/fpga-bridge.c           |  4 +++-
 drivers/fpga/fpga-mgr.c              |  3 ++-
 drivers/leds/led-class.c             |  2 +-
 drivers/mux/core.c                   |  2 +-
 drivers/net/phy/mdio_bus_provider.c  |  4 +++-
 drivers/net/wan/framer/framer-core.c |  2 +-
 drivers/phy/phy-core.c               |  3 ++-
 drivers/regulator/of_regulator.c     |  2 +-
 drivers/spi/spi.c                    |  6 ++++--
 include/linux/device/class.h         | 12 ------------
 10 files changed, 18 insertions(+), 22 deletions(-)
---
base-commit: 785f0eb2f85decbe7c1ef9ae922931f0194ffc2e
change-id: 20260220-remove-device-find-by-of-node-077784fa109c

Thanks.

-- 
Dmitry


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: kernel test robot @ 2026-03-22 23:31 UTC (permalink / raw)
  To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
  Cc: llvm, oe-kbuild-all, Bryan O'Donoghue, Vladimir Zapolskiy,
	linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <20260315-x1e-csi2-phy-v4-2-90c09203888d@linaro.org>

Hi Bryan,

kernel test robot noticed the following build errors:

[auto build test ERROR on c824345288d11e269ce41b36c105715bc2286050]

url:    https://github.com/intel-lab-lkp/linux/commits/Bryan-O-Donoghue/dt-bindings-phy-qcom-Add-CSI2-C-PHY-DPHY-schema/20260316-081353
base:   c824345288d11e269ce41b36c105715bc2286050
patch link:    https://lore.kernel.org/r/20260315-x1e-csi2-phy-v4-2-90c09203888d%40linaro.org
patch subject: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
config: riscv-allyesconfig (https://download.01.org/0day-ci/archive/20260323/202603230713.5uOUC5EI-lkp@intel.com/config)
compiler: clang version 16.0.6 (https://github.com/llvm/llvm-project 7cbf1a2591520c2491aa35339f227775f4d3adf6)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603230713.5uOUC5EI-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603230713.5uOUC5EI-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c:360:13: error: initializer element is not a compile-time constant
           .opp_clk = x1e_clks[2],
                      ^~~~~~~~~~~
   1 error generated.


vim +360 drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c

   347	
   348	const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_4nm_x1e = {
   349		.ops = &phy_qcom_mipi_csi2_ops_3ph_1_0,
   350		.reg_info = {
   351			.init_seq = lane_regs_x1e80100,
   352			.lane_array_size = ARRAY_SIZE(lane_regs_x1e80100),
   353			.common_regs_offset = 0x1000,
   354			.generation = GEN2,
   355		},
   356		.supply_names = (const char **)x1e_supplies,
   357		.num_supplies = ARRAY_SIZE(x1e_supplies),
   358		.clk_names = (const char **)x1e_clks,
   359		.num_clk = ARRAY_SIZE(x1e_clks),
 > 360		.opp_clk = x1e_clks[2],

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v2 2/2] iio: inkern: Use namespaced exports
From: Dmitry Torokhov @ 2026-03-22 22:26 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Romain Gantois, MyungJoo Ham, Chanwoo Choi, Guenter Roeck,
	Peter Rosin, David Lechner, Nuno Sá, Andy Shevchenko,
	Lars-Peter Clausen, Michael Hennerich, Mariel Tinaco, Kevin Tsai,
	Linus Walleij, Eugen Hristev, Vinod Koul, Kishon Vijay Abraham I,
	Sebastian Reichel, Chen-Yu Tsai, Hans de Goede,
	Support Opensource, Paul Cercueil, Iskren Chernev,
	Krzysztof Kozlowski, Marek Szyprowski, Matheus Castello,
	Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
	Casey Connolly, Pali Rohár, Orson Zhai, Baolin Wang,
	Chunyan Zhang, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
	Daniel Lezcano, Zhang Rui, Lukasz Luba, Claudiu Beznea,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	Sylwester Nawrocki, Olivier Moysan, Arnaud Pouliquen,
	Maxime Coquelin, Alexandre Torgue, Thomas Petazzoni, linux-kernel,
	linux-hwmon, linux-iio, linux-input, linux-phy, linux-pm,
	linux-mips, linux-mediatek, linux-arm-msm, linux-sound,
	linux-stm32, Sebastian Reichel, Andy Shevchenko
In-Reply-To: <20260322122529.62093f12@jic23-huawei>

On Sun, Mar 22, 2026 at 12:25:29PM +0000, Jonathan Cameron wrote:
> On Sun, 11 Jan 2026 17:02:22 +0000
> Jonathan Cameron <jic23@kernel.org> wrote:
> 
> > On Tue, 09 Dec 2025 09:25:56 +0100
> > Romain Gantois <romain.gantois@bootlin.com> wrote:
> > 
> > > Use namespaced exports for IIO consumer API functions.
> > > 
> > > This will make it easier to manage the IIO export surface. Consumer drivers
> > > will only be provided access to a specific set of functions, thereby
> > > restricting usage of internal IIO functions by other parts of the kernel.
> > > 
> > > This change cannot be split into several parts without breaking
> > > bisectability, thus all of the affected drivers are modified at once.
> > > 
> > > Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for power-supply
> > > Acked-by: Guenter Roeck <linux@roeck-us.net>
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > > Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>  
> > Ideally looking for a couple more Acks.
> > 
> > If any of the maintainers of other trees who haven't already replied
> > have time for a quick glance that would be great.  I'll spin an
> > immutable branch but I'm not really expecting any non trivial
> > conflicts unless there is a new user in flight that I've forgotten
> > about.
> 
> At this stage, given I'm still waiting on replies from a couple of
> subsystem maintainers, I'm thinking we'll do this next cycle and I'll
> provide an immutable branch based on rc1 for anyone to grab if they
> run into merge conflicts in linux-next.

Sorry, I just acked the input bits in the patch, but in general I feel
these kind of mechanical changes in consumers do not require an ack and
you can just go an apply such changes.

Thanks.

-- 
Dmitry

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v2 2/2] iio: inkern: Use namespaced exports
From: Dmitry Torokhov @ 2026-03-22 22:24 UTC (permalink / raw)
  To: Romain Gantois
  Cc: MyungJoo Ham, Chanwoo Choi, Guenter Roeck, Peter Rosin,
	Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
	Lars-Peter Clausen, Michael Hennerich, Mariel Tinaco, Kevin Tsai,
	Linus Walleij, Eugen Hristev, Vinod Koul, Kishon Vijay Abraham I,
	Sebastian Reichel, Chen-Yu Tsai, Hans de Goede,
	Support Opensource, Paul Cercueil, Iskren Chernev,
	Krzysztof Kozlowski, Marek Szyprowski, Matheus Castello,
	Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
	Casey Connolly, Pali Rohár, Orson Zhai, Baolin Wang,
	Chunyan Zhang, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
	Daniel Lezcano, Zhang Rui, Lukasz Luba, Claudiu Beznea,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	Sylwester Nawrocki, Olivier Moysan, Arnaud Pouliquen,
	Maxime Coquelin, Alexandre Torgue, Thomas Petazzoni, linux-kernel,
	linux-hwmon, linux-iio, linux-input, linux-phy, linux-pm,
	linux-mips, linux-mediatek, linux-arm-msm, linux-sound,
	linux-stm32, Sebastian Reichel, Andy Shevchenko
In-Reply-To: <20251209-iio-inkern-use-namespaced-exports-v2-2-9799a33c4b7f@bootlin.com>

On Tue, Dec 09, 2025 at 09:25:56AM +0100, Romain Gantois wrote:
> Use namespaced exports for IIO consumer API functions.
> 
> This will make it easier to manage the IIO export surface. Consumer drivers
> will only be provided access to a specific set of functions, thereby
> restricting usage of internal IIO functions by other parts of the kernel.
> 
> This change cannot be split into several parts without breaking
> bisectability, thus all of the affected drivers are modified at once.
> 
> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for power-supply
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>

For input:

Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Thanks.

-- 
Dmitry

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: kernel test robot @ 2026-03-22 16:44 UTC (permalink / raw)
  To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
  Cc: oe-kbuild-all, Bryan O'Donoghue, Vladimir Zapolskiy,
	linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <20260315-x1e-csi2-phy-v4-2-90c09203888d@linaro.org>

Hi Bryan,

kernel test robot noticed the following build warnings:

[auto build test WARNING on c824345288d11e269ce41b36c105715bc2286050]

url:    https://github.com/intel-lab-lkp/linux/commits/Bryan-O-Donoghue/dt-bindings-phy-qcom-Add-CSI2-C-PHY-DPHY-schema/20260316-081353
base:   c824345288d11e269ce41b36c105715bc2286050
patch link:    https://lore.kernel.org/r/20260315-x1e-csi2-phy-v4-2-90c09203888d%40linaro.org
patch subject: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
config: arc-allyesconfig (https://download.01.org/0day-ci/archive/20260323/202603230048.ZxbvVL5L-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603230048.ZxbvVL5L-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603230048.ZxbvVL5L-lkp@intel.com/

All warnings (new ones prefixed by >>):

   drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c: In function 'phy_qcom_mipi_csi2_power_off':
>> drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c:153:13: warning: unused variable 'i' [-Wunused-variable]
     153 |         int i;
         |             ^


vim +/i +153 drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c

   149	
   150	static int phy_qcom_mipi_csi2_power_off(struct phy *phy)
   151	{
   152		struct mipi_csi2phy_device *csi2phy = phy_get_drvdata(phy);
 > 153		int i;
   154	
   155		for (int i = 0; i < csi2phy->num_pds; i++)
   156			dev_pm_genpd_set_performance_state(csi2phy->pds[i], 0);
   157	
   158		clk_bulk_disable_unprepare(csi2phy->soc_cfg->num_clk,
   159					   csi2phy->clks);
   160		regulator_bulk_disable(csi2phy->soc_cfg->num_supplies,
   161				       csi2phy->supplies);
   162	
   163		return 0;
   164	}
   165	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v3 6/6] gpu: drm: mediatek: ovl: add specific entry for mt8167
From: Chun-Kuang Hu @ 2026-03-22 13:39 UTC (permalink / raw)
  To: Luca Leonardo Scorcia
  Cc: linux-mediatek, Val Packett, AngeloGioacchino Del Regno,
	Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
	Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
	linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <5f880f1334aa93184afee3e36132ca42628821fb.1771863641.git.l.scorcia@gmail.com>

Hi, Luca:

Luca Leonardo Scorcia <l.scorcia@gmail.com> 於 2026年2月23日週一 下午4:26寫道:
>
> From: Val Packett <val@packett.cool>
>
> While this configuration is otherwise identical to mt8173, according
> to Android kernel sources, this SoC does need smi_id_en.

Applied to mediatek-drm-next [1], thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index e0236353d499..97a899e4bd99 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -671,6 +671,16 @@ static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
>         .num_formats = ARRAY_SIZE(mt8173_formats),
>  };
>
> +static const struct mtk_disp_ovl_data mt8167_ovl_driver_data = {
> +       .addr = DISP_REG_OVL_ADDR_MT8173,
> +       .gmc_bits = 8,
> +       .layer_nr = 4,
> +       .fmt_rgb565_is_0 = true,
> +       .smi_id_en = true,
> +       .formats = mt8173_formats,
> +       .num_formats = ARRAY_SIZE(mt8173_formats),
> +};
> +
>  static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
>         .addr = DISP_REG_OVL_ADDR_MT8173,
>         .gmc_bits = 8,
> @@ -742,6 +752,8 @@ static const struct mtk_disp_ovl_data mt8195_ovl_driver_data = {
>  static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
>         { .compatible = "mediatek,mt2701-disp-ovl",
>           .data = &mt2701_ovl_driver_data},
> +       { .compatible = "mediatek,mt8167-disp-ovl",
> +         .data = &mt8167_ovl_driver_data},
>         { .compatible = "mediatek,mt8173-disp-ovl",
>           .data = &mt8173_ovl_driver_data},
>         { .compatible = "mediatek,mt8183-disp-ovl",
> --
> 2.43.0
>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v3 3/6] dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
From: Chun-Kuang Hu @ 2026-03-22 13:30 UTC (permalink / raw)
  To: Luca Leonardo Scorcia
  Cc: linux-mediatek, AngeloGioacchino Del Regno, Krzysztof Kozlowski,
	Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
	Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
	Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
	linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <92530e0a31eca1feb822f5c5fd4ac894937dd6c7.1771863641.git.l.scorcia@gmail.com>

Hi, Luca:

Luca Leonardo Scorcia <l.scorcia@gmail.com> 於 2026年2月23日週一 下午4:26寫道:
>
> Add support for the MediaTek mt8167 SoC: the DSI PHY found
> in this chip is fully compatible with the one found in the mt2701 SoC.

Applied to mediatek-drm-next [1], thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> index acdbce937b0a..c6d0bbdbe0e2 100644
> --- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> @@ -23,6 +23,7 @@ properties:
>        - items:
>            - enum:
>                - mediatek,mt7623-mipi-tx
> +              - mediatek,mt8167-mipi-tx
>            - const: mediatek,mt2701-mipi-tx
>        - items:
>            - enum:
> --
> 2.43.0
>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v3 2/6] dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
From: Chun-Kuang Hu @ 2026-03-22 13:19 UTC (permalink / raw)
  To: Luca Leonardo Scorcia
  Cc: linux-mediatek, Krzysztof Kozlowski, AngeloGioacchino Del Regno,
	Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
	Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
	Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
	linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <66eafae30f9fe00b469e79d385c1ddd24d209475.1771863641.git.l.scorcia@gmail.com>

Hi, Luca:

Luca Leonardo Scorcia <l.scorcia@gmail.com> 於 2026年2月23日週一 下午4:26寫道:
>
> Add compatibles for various display-related blocks of MediaTek mt8167.

Applied to mediatek-drm-next [1], thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  .../devicetree/bindings/display/mediatek/mediatek,aal.yaml    | 1 +
>  .../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml  | 4 +++-
>  .../devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 +
>  .../devicetree/bindings/display/mediatek/mediatek,gamma.yaml  | 1 +
>  .../devicetree/bindings/display/mediatek/mediatek,ovl.yaml    | 1 +
>  .../devicetree/bindings/display/mediatek/mediatek,rdma.yaml   | 1 +
>  .../devicetree/bindings/display/mediatek/mediatek,wdma.yaml   | 4 +++-
>  7 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index daf90ebb39bf..4bbea72b292a 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -33,6 +33,7 @@ properties:
>            - enum:
>                - mediatek,mt2712-disp-aal
>                - mediatek,mt6795-disp-aal
> +              - mediatek,mt8167-disp-aal
>            - const: mediatek,mt8173-disp-aal
>        - items:
>            - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> index fca8e7bb0cbc..5c5068128d0c 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> @@ -25,7 +25,9 @@ properties:
>            - mediatek,mt8183-disp-ccorr
>            - mediatek,mt8192-disp-ccorr
>        - items:
> -          - const: mediatek,mt8365-disp-ccorr
> +          - enum:
> +              - mediatek,mt8167-disp-ccorr
> +              - mediatek,mt8365-disp-ccorr
>            - const: mediatek,mt8183-disp-ccorr
>        - items:
>            - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> index abaf27916d13..891c95be15b9 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> @@ -26,6 +26,7 @@ properties:
>            - mediatek,mt8183-disp-dither
>        - items:
>            - enum:
> +              - mediatek,mt8167-disp-dither
>                - mediatek,mt8186-disp-dither
>                - mediatek,mt8188-disp-dither
>                - mediatek,mt8192-disp-dither
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
> index 48542dc7e784..ec1054bb06d4 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
> @@ -28,6 +28,7 @@ properties:
>        - items:
>            - enum:
>                - mediatek,mt6795-disp-gamma
> +              - mediatek,mt8167-disp-gamma
>            - const: mediatek,mt8173-disp-gamma
>        - items:
>            - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
> index 4f110635afb6..679f731f0f15 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
> @@ -23,6 +23,7 @@ properties:
>      oneOf:
>        - enum:
>            - mediatek,mt2701-disp-ovl
> +          - mediatek,mt8167-disp-ovl
>            - mediatek,mt8173-disp-ovl
>            - mediatek,mt8183-disp-ovl
>            - mediatek,mt8192-disp-ovl
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
> index 878f676b581f..cb187a95c11e 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
> @@ -36,6 +36,7 @@ properties:
>            - enum:
>                - mediatek,mt7623-disp-rdma
>                - mediatek,mt2712-disp-rdma
> +              - mediatek,mt8167-disp-rdma
>            - const: mediatek,mt2701-disp-rdma
>        - items:
>            - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
> index a3a2b71a4523..816841a96133 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
> @@ -24,7 +24,9 @@ properties:
>        - enum:
>            - mediatek,mt8173-disp-wdma
>        - items:
> -          - const: mediatek,mt6795-disp-wdma
> +          - enum:
> +              - mediatek,mt6795-disp-wdma
> +              - mediatek,mt8167-disp-wdma
>            - const: mediatek,mt8173-disp-wdma
>
>    reg:
> --
> 2.43.0
>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v2 2/2] iio: inkern: Use namespaced exports
From: Jonathan Cameron @ 2026-03-22 12:25 UTC (permalink / raw)
  To: Romain Gantois
  Cc: MyungJoo Ham, Chanwoo Choi, Guenter Roeck, Peter Rosin,
	David Lechner, Nuno Sá, Andy Shevchenko, Lars-Peter Clausen,
	Michael Hennerich, Mariel Tinaco, Kevin Tsai, Linus Walleij,
	Dmitry Torokhov, Eugen Hristev, Vinod Koul,
	Kishon Vijay Abraham I, Sebastian Reichel, Chen-Yu Tsai,
	Hans de Goede, Support Opensource, Paul Cercueil, Iskren Chernev,
	Krzysztof Kozlowski, Marek Szyprowski, Matheus Castello,
	Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
	Casey Connolly, Pali Rohár, Orson Zhai, Baolin Wang,
	Chunyan Zhang, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
	Daniel Lezcano, Zhang Rui, Lukasz Luba, Claudiu Beznea,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	Sylwester Nawrocki, Olivier Moysan, Arnaud Pouliquen,
	Maxime Coquelin, Alexandre Torgue, Thomas Petazzoni, linux-kernel,
	linux-hwmon, linux-iio, linux-input, linux-phy, linux-pm,
	linux-mips, linux-mediatek, linux-arm-msm, linux-sound,
	linux-stm32, Sebastian Reichel, Andy Shevchenko
In-Reply-To: <20260111170222.43aee69a@jic23-huawei>

On Sun, 11 Jan 2026 17:02:22 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Tue, 09 Dec 2025 09:25:56 +0100
> Romain Gantois <romain.gantois@bootlin.com> wrote:
> 
> > Use namespaced exports for IIO consumer API functions.
> > 
> > This will make it easier to manage the IIO export surface. Consumer drivers
> > will only be provided access to a specific set of functions, thereby
> > restricting usage of internal IIO functions by other parts of the kernel.
> > 
> > This change cannot be split into several parts without breaking
> > bisectability, thus all of the affected drivers are modified at once.
> > 
> > Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for power-supply
> > Acked-by: Guenter Roeck <linux@roeck-us.net>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>  
> Ideally looking for a couple more Acks.
> 
> If any of the maintainers of other trees who haven't already replied
> have time for a quick glance that would be great.  I'll spin an
> immutable branch but I'm not really expecting any non trivial
> conflicts unless there is a new user in flight that I've forgotten
> about.

At this stage, given I'm still waiting on replies from a couple of
subsystem maintainers, I'm thinking we'll do this next cycle and I'll
provide an immutable branch based on rc1 for anyone to grab if they
run into merge conflicts in linux-next.

Thanks,

Jonathan

> 
> Jonathan
> 
> > ---
> >  drivers/extcon/extcon-adc-jack.c                |  1 +
> >  drivers/hwmon/iio_hwmon.c                       |  1 +
> >  drivers/hwmon/ntc_thermistor.c                  |  1 +
> >  drivers/iio/adc/envelope-detector.c             |  1 +
> >  drivers/iio/afe/iio-rescale.c                   |  1 +
> >  drivers/iio/buffer/industrialio-buffer-cb.c     |  1 +
> >  drivers/iio/buffer/industrialio-hw-consumer.c   |  1 +
> >  drivers/iio/dac/ad8460.c                        |  1 +
> >  drivers/iio/dac/dpot-dac.c                      |  1 +
> >  drivers/iio/inkern.c                            | 54 ++++++++++++-------------
> >  drivers/iio/light/cm3605.c                      |  1 +
> >  drivers/iio/light/gp2ap002.c                    |  1 +
> >  drivers/iio/multiplexer/iio-mux.c               |  1 +
> >  drivers/iio/potentiostat/lmp91000.c             |  1 +
> >  drivers/input/joystick/adc-joystick.c           |  1 +
> >  drivers/input/keyboard/adc-keys.c               |  1 +
> >  drivers/input/touchscreen/colibri-vf50-ts.c     |  1 +
> >  drivers/input/touchscreen/resistive-adc-touch.c |  1 +
> >  drivers/phy/motorola/phy-cpcap-usb.c            |  1 +
> >  drivers/power/supply/ab8500_btemp.c             |  1 +
> >  drivers/power/supply/ab8500_charger.c           |  1 +
> >  drivers/power/supply/ab8500_fg.c                |  1 +
> >  drivers/power/supply/axp20x_ac_power.c          |  1 +
> >  drivers/power/supply/axp20x_battery.c           |  1 +
> >  drivers/power/supply/axp20x_usb_power.c         |  1 +
> >  drivers/power/supply/axp288_fuel_gauge.c        |  1 +
> >  drivers/power/supply/cpcap-battery.c            |  1 +
> >  drivers/power/supply/cpcap-charger.c            |  1 +
> >  drivers/power/supply/da9150-charger.c           |  1 +
> >  drivers/power/supply/generic-adc-battery.c      |  1 +
> >  drivers/power/supply/ingenic-battery.c          |  1 +
> >  drivers/power/supply/intel_dc_ti_battery.c      |  1 +
> >  drivers/power/supply/lego_ev3_battery.c         |  1 +
> >  drivers/power/supply/lp8788-charger.c           |  1 +
> >  drivers/power/supply/max17040_battery.c         |  1 +
> >  drivers/power/supply/mp2629_charger.c           |  1 +
> >  drivers/power/supply/mt6370-charger.c           |  1 +
> >  drivers/power/supply/qcom_smbx.c                |  1 +
> >  drivers/power/supply/rn5t618_power.c            |  1 +
> >  drivers/power/supply/rx51_battery.c             |  1 +
> >  drivers/power/supply/sc27xx_fuel_gauge.c        |  1 +
> >  drivers/power/supply/twl4030_charger.c          |  1 +
> >  drivers/power/supply/twl4030_madc_battery.c     |  1 +
> >  drivers/power/supply/twl6030_charger.c          |  1 +
> >  drivers/thermal/qcom/qcom-spmi-adc-tm5.c        |  1 +
> >  drivers/thermal/qcom/qcom-spmi-temp-alarm.c     |  1 +
> >  drivers/thermal/renesas/rzg3s_thermal.c         |  1 +
> >  drivers/thermal/thermal-generic-adc.c           |  1 +
> >  sound/soc/codecs/audio-iio-aux.c                |  1 +
> >  sound/soc/samsung/aries_wm8994.c                |  1 +
> >  sound/soc/samsung/midas_wm1811.c                |  1 +
> >  sound/soc/stm/stm32_adfsdm.c                    |  1 +
> >  52 files changed, 78 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
> > index 7e3c9f38297b..e735f43dcdeb 100644
> > --- a/drivers/extcon/extcon-adc-jack.c
> > +++ b/drivers/extcon/extcon-adc-jack.c
> > @@ -210,3 +210,4 @@ module_platform_driver(adc_jack_driver);
> >  MODULE_AUTHOR("MyungJoo Ham <myungjoo.ham@samsung.com>");
> >  MODULE_DESCRIPTION("ADC Jack extcon driver");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
> > index e376d4cde5ad..4c7843fbcc50 100644
> > --- a/drivers/hwmon/iio_hwmon.c
> > +++ b/drivers/hwmon/iio_hwmon.c
> > @@ -222,3 +222,4 @@ module_platform_driver(iio_hwmon_driver);
> >  MODULE_AUTHOR("Jonathan Cameron <jic23@kernel.org>");
> >  MODULE_DESCRIPTION("IIO to hwmon driver");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
> > index d21f7266c411..417807fad80b 100644
> > --- a/drivers/hwmon/ntc_thermistor.c
> > +++ b/drivers/hwmon/ntc_thermistor.c
> > @@ -706,3 +706,4 @@ MODULE_DESCRIPTION("NTC Thermistor Driver");
> >  MODULE_AUTHOR("MyungJoo Ham <myungjoo.ham@samsung.com>");
> >  MODULE_LICENSE("GPL");
> >  MODULE_ALIAS("platform:ntc-thermistor");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/adc/envelope-detector.c b/drivers/iio/adc/envelope-detector.c
> > index 5b16fe737659..fea20e7e6cd9 100644
> > --- a/drivers/iio/adc/envelope-detector.c
> > +++ b/drivers/iio/adc/envelope-detector.c
> > @@ -406,3 +406,4 @@ module_platform_driver(envelope_detector_driver);
> >  MODULE_DESCRIPTION("Envelope detector using a DAC and a comparator");
> >  MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c
> > index ecaf59278c6f..d7f55109af3e 100644
> > --- a/drivers/iio/afe/iio-rescale.c
> > +++ b/drivers/iio/afe/iio-rescale.c
> > @@ -609,3 +609,4 @@ module_platform_driver(rescale_driver);
> >  MODULE_DESCRIPTION("IIO rescale driver");
> >  MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/buffer/industrialio-buffer-cb.c b/drivers/iio/buffer/industrialio-buffer-cb.c
> > index 3e27385069ed..608ea9afc15a 100644
> > --- a/drivers/iio/buffer/industrialio-buffer-cb.c
> > +++ b/drivers/iio/buffer/industrialio-buffer-cb.c
> > @@ -153,3 +153,4 @@ EXPORT_SYMBOL_GPL(iio_channel_cb_get_iio_dev);
> >  MODULE_AUTHOR("Jonathan Cameron <jic23@kernel.org>");
> >  MODULE_DESCRIPTION("Industrial I/O callback buffer");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c b/drivers/iio/buffer/industrialio-hw-consumer.c
> > index 526b2a8d725d..d7ff086ed783 100644
> > --- a/drivers/iio/buffer/industrialio-hw-consumer.c
> > +++ b/drivers/iio/buffer/industrialio-hw-consumer.c
> > @@ -211,3 +211,4 @@ EXPORT_SYMBOL_GPL(iio_hw_consumer_disable);
> >  MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
> >  MODULE_DESCRIPTION("Hardware consumer buffer the IIO framework");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/dac/ad8460.c b/drivers/iio/dac/ad8460.c
> > index 6e45686902dd..ad654819ca22 100644
> > --- a/drivers/iio/dac/ad8460.c
> > +++ b/drivers/iio/dac/ad8460.c
> > @@ -955,3 +955,4 @@ MODULE_AUTHOR("Mariel Tinaco <mariel.tinaco@analog.com");
> >  MODULE_DESCRIPTION("AD8460 DAC driver");
> >  MODULE_LICENSE("GPL");
> >  MODULE_IMPORT_NS("IIO_DMAENGINE_BUFFER");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/dac/dpot-dac.c b/drivers/iio/dac/dpot-dac.c
> > index d1b8441051ae..49dbdb7df955 100644
> > --- a/drivers/iio/dac/dpot-dac.c
> > +++ b/drivers/iio/dac/dpot-dac.c
> > @@ -254,3 +254,4 @@ module_platform_driver(dpot_dac_driver);
> >  MODULE_DESCRIPTION("DAC emulation driver using a digital potentiometer");
> >  MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> > index 1e5eb5a41271..c75c3a8d233f 100644
> > --- a/drivers/iio/inkern.c
> > +++ b/drivers/iio/inkern.c
> > @@ -281,7 +281,7 @@ struct iio_channel *fwnode_iio_channel_get_by_name(struct fwnode_handle *fwnode,
> >  
> >  	return ERR_PTR(-ENODEV);
> >  }
> > -EXPORT_SYMBOL_GPL(fwnode_iio_channel_get_by_name);
> > +EXPORT_SYMBOL_NS_GPL(fwnode_iio_channel_get_by_name, "IIO_CONSUMER");
> >  
> >  static struct iio_channel *fwnode_iio_channel_get_all(struct device *dev)
> >  {
> > @@ -386,7 +386,7 @@ struct iio_channel *iio_channel_get(struct device *dev,
> >  
> >  	return iio_channel_get_sys(name, channel_name);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_channel_get);
> > +EXPORT_SYMBOL_NS_GPL(iio_channel_get, "IIO_CONSUMER");
> >  
> >  void iio_channel_release(struct iio_channel *channel)
> >  {
> > @@ -395,7 +395,7 @@ void iio_channel_release(struct iio_channel *channel)
> >  	iio_device_put(channel->indio_dev);
> >  	kfree(channel);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_channel_release);
> > +EXPORT_SYMBOL_NS_GPL(iio_channel_release, "IIO_CONSUMER");
> >  
> >  static void devm_iio_channel_free(void *iio_channel)
> >  {
> > @@ -418,7 +418,7 @@ struct iio_channel *devm_iio_channel_get(struct device *dev,
> >  
> >  	return channel;
> >  }
> > -EXPORT_SYMBOL_GPL(devm_iio_channel_get);
> > +EXPORT_SYMBOL_NS_GPL(devm_iio_channel_get, "IIO_CONSUMER");
> >  
> >  struct iio_channel *devm_fwnode_iio_channel_get_by_name(struct device *dev,
> >  							struct fwnode_handle *fwnode,
> > @@ -437,7 +437,7 @@ struct iio_channel *devm_fwnode_iio_channel_get_by_name(struct device *dev,
> >  
> >  	return channel;
> >  }
> > -EXPORT_SYMBOL_GPL(devm_fwnode_iio_channel_get_by_name);
> > +EXPORT_SYMBOL_NS_GPL(devm_fwnode_iio_channel_get_by_name, "IIO_CONSUMER");
> >  
> >  struct iio_channel *iio_channel_get_all(struct device *dev)
> >  {
> > @@ -506,7 +506,7 @@ struct iio_channel *iio_channel_get_all(struct device *dev)
> >  		iio_device_put(chans[i].indio_dev);
> >  	return ERR_PTR(ret);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_channel_get_all);
> > +EXPORT_SYMBOL_NS_GPL(iio_channel_get_all, "IIO_CONSUMER");
> >  
> >  void iio_channel_release_all(struct iio_channel *channels)
> >  {
> > @@ -518,7 +518,7 @@ void iio_channel_release_all(struct iio_channel *channels)
> >  	}
> >  	kfree(channels);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_channel_release_all);
> > +EXPORT_SYMBOL_NS_GPL(iio_channel_release_all, "IIO_CONSUMER");
> >  
> >  static void devm_iio_channel_free_all(void *iio_channels)
> >  {
> > @@ -541,7 +541,7 @@ struct iio_channel *devm_iio_channel_get_all(struct device *dev)
> >  
> >  	return channels;
> >  }
> > -EXPORT_SYMBOL_GPL(devm_iio_channel_get_all);
> > +EXPORT_SYMBOL_NS_GPL(devm_iio_channel_get_all, "IIO_CONSUMER");
> >  
> >  static int iio_channel_read(struct iio_channel *chan, int *val, int *val2,
> >  			    enum iio_chan_info_enum info)
> > @@ -585,7 +585,7 @@ int iio_read_channel_raw(struct iio_channel *chan, int *val)
> >  
> >  	return iio_channel_read(chan, val, NULL, IIO_CHAN_INFO_RAW);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_channel_raw);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_channel_raw, "IIO_CONSUMER");
> >  
> >  int iio_read_channel_average_raw(struct iio_channel *chan, int *val)
> >  {
> > @@ -597,7 +597,7 @@ int iio_read_channel_average_raw(struct iio_channel *chan, int *val)
> >  
> >  	return iio_channel_read(chan, val, NULL, IIO_CHAN_INFO_AVERAGE_RAW);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_channel_average_raw);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_channel_average_raw, "IIO_CONSUMER");
> >  
> >  int iio_multiply_value(int *result, s64 multiplier,
> >  		       unsigned int type, int val, int val2)
> > @@ -701,7 +701,7 @@ int iio_convert_raw_to_processed(struct iio_channel *chan, int raw,
> >  	return iio_convert_raw_to_processed_unlocked(chan, raw, processed,
> >  						     scale);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_convert_raw_to_processed);
> > +EXPORT_SYMBOL_NS_GPL(iio_convert_raw_to_processed, "IIO_CONSUMER");
> >  
> >  int iio_read_channel_attribute(struct iio_channel *chan, int *val, int *val2,
> >  			       enum iio_chan_info_enum attribute)
> > @@ -714,13 +714,13 @@ int iio_read_channel_attribute(struct iio_channel *chan, int *val, int *val2,
> >  
> >  	return iio_channel_read(chan, val, val2, attribute);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_channel_attribute);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_channel_attribute, "IIO_CONSUMER");
> >  
> >  int iio_read_channel_offset(struct iio_channel *chan, int *val, int *val2)
> >  {
> >  	return iio_read_channel_attribute(chan, val, val2, IIO_CHAN_INFO_OFFSET);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_channel_offset);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_channel_offset, "IIO_CONSUMER");
> >  
> >  int iio_read_channel_processed_scale(struct iio_channel *chan, int *val,
> >  				     unsigned int scale)
> > @@ -748,20 +748,20 @@ int iio_read_channel_processed_scale(struct iio_channel *chan, int *val,
> >  							     scale);
> >  	}
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_channel_processed_scale);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_channel_processed_scale, "IIO_CONSUMER");
> >  
> >  int iio_read_channel_processed(struct iio_channel *chan, int *val)
> >  {
> >  	/* This is just a special case with scale factor 1 */
> >  	return iio_read_channel_processed_scale(chan, val, 1);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_channel_processed);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_channel_processed, "IIO_CONSUMER");
> >  
> >  int iio_read_channel_scale(struct iio_channel *chan, int *val, int *val2)
> >  {
> >  	return iio_read_channel_attribute(chan, val, val2, IIO_CHAN_INFO_SCALE);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_channel_scale);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_channel_scale, "IIO_CONSUMER");
> >  
> >  static int iio_channel_read_avail(struct iio_channel *chan,
> >  				  const int **vals, int *type, int *length,
> > @@ -790,7 +790,7 @@ int iio_read_avail_channel_attribute(struct iio_channel *chan,
> >  
> >  	return iio_channel_read_avail(chan, vals, type, length, attribute);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_avail_channel_attribute);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_avail_channel_attribute, "IIO_CONSUMER");
> >  
> >  int iio_read_avail_channel_raw(struct iio_channel *chan,
> >  			       const int **vals, int *length)
> > @@ -807,7 +807,7 @@ int iio_read_avail_channel_raw(struct iio_channel *chan,
> >  
> >  	return ret;
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_avail_channel_raw);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_avail_channel_raw, "IIO_CONSUMER");
> >  
> >  static int iio_channel_read_max(struct iio_channel *chan,
> >  				int *val, int *val2, int *type,
> > @@ -863,7 +863,7 @@ int iio_read_max_channel_raw(struct iio_channel *chan, int *val)
> >  
> >  	return iio_channel_read_max(chan, val, NULL, &type, IIO_CHAN_INFO_RAW);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_max_channel_raw);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_max_channel_raw, "IIO_CONSUMER");
> >  
> >  static int iio_channel_read_min(struct iio_channel *chan,
> >  				int *val, int *val2, int *type,
> > @@ -919,7 +919,7 @@ int iio_read_min_channel_raw(struct iio_channel *chan, int *val)
> >  
> >  	return iio_channel_read_min(chan, val, NULL, &type, IIO_CHAN_INFO_RAW);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_min_channel_raw);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_min_channel_raw, "IIO_CONSUMER");
> >  
> >  int iio_get_channel_type(struct iio_channel *chan, enum iio_chan_type *type)
> >  {
> > @@ -933,7 +933,7 @@ int iio_get_channel_type(struct iio_channel *chan, enum iio_chan_type *type)
> >  
> >  	return 0;
> >  }
> > -EXPORT_SYMBOL_GPL(iio_get_channel_type);
> > +EXPORT_SYMBOL_NS_GPL(iio_get_channel_type, "IIO_CONSUMER");
> >  
> >  static int iio_channel_write(struct iio_channel *chan, int val, int val2,
> >  			     enum iio_chan_info_enum info)
> > @@ -957,13 +957,13 @@ int iio_write_channel_attribute(struct iio_channel *chan, int val, int val2,
> >  
> >  	return iio_channel_write(chan, val, val2, attribute);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_write_channel_attribute);
> > +EXPORT_SYMBOL_NS_GPL(iio_write_channel_attribute, "IIO_CONSUMER");
> >  
> >  int iio_write_channel_raw(struct iio_channel *chan, int val)
> >  {
> >  	return iio_write_channel_attribute(chan, val, 0, IIO_CHAN_INFO_RAW);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_write_channel_raw);
> > +EXPORT_SYMBOL_NS_GPL(iio_write_channel_raw, "IIO_CONSUMER");
> >  
> >  unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
> >  {
> > @@ -978,7 +978,7 @@ unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
> >  
> >  	return i;
> >  }
> > -EXPORT_SYMBOL_GPL(iio_get_channel_ext_info_count);
> > +EXPORT_SYMBOL_NS_GPL(iio_get_channel_ext_info_count, "IIO_CONSUMER");
> >  
> >  static const struct iio_chan_spec_ext_info *
> >  iio_lookup_ext_info(const struct iio_channel *chan, const char *attr)
> > @@ -1013,7 +1013,7 @@ ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
> >  	return ext_info->read(chan->indio_dev, ext_info->private,
> >  			      chan->channel, buf);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_channel_ext_info);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_channel_ext_info, "IIO_CONSUMER");
> >  
> >  ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
> >  				   const char *buf, size_t len)
> > @@ -1027,7 +1027,7 @@ ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
> >  	return ext_info->write(chan->indio_dev, ext_info->private,
> >  			       chan->channel, buf, len);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_write_channel_ext_info);
> > +EXPORT_SYMBOL_NS_GPL(iio_write_channel_ext_info, "IIO_CONSUMER");
> >  
> >  ssize_t iio_read_channel_label(struct iio_channel *chan, char *buf)
> >  {
> > @@ -1038,4 +1038,4 @@ ssize_t iio_read_channel_label(struct iio_channel *chan, char *buf)
> >  
> >  	return do_iio_read_channel_label(chan->indio_dev, chan->channel, buf);
> >  }
> > -EXPORT_SYMBOL_GPL(iio_read_channel_label);
> > +EXPORT_SYMBOL_NS_GPL(iio_read_channel_label, "IIO_CONSUMER");
> > diff --git a/drivers/iio/light/cm3605.c b/drivers/iio/light/cm3605.c
> > index 0c17378e27d1..1bd11292d005 100644
> > --- a/drivers/iio/light/cm3605.c
> > +++ b/drivers/iio/light/cm3605.c
> > @@ -325,3 +325,4 @@ module_platform_driver(cm3605_driver);
> >  MODULE_AUTHOR("Linus Walleij <linus.walleij@linaro.org>");
> >  MODULE_DESCRIPTION("CM3605 ambient light and proximity sensor driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/light/gp2ap002.c b/drivers/iio/light/gp2ap002.c
> > index a0d8a58f2704..04b1f6eade0e 100644
> > --- a/drivers/iio/light/gp2ap002.c
> > +++ b/drivers/iio/light/gp2ap002.c
> > @@ -717,3 +717,4 @@ module_i2c_driver(gp2ap002_driver);
> >  MODULE_AUTHOR("Linus Walleij <linus.walleij@linaro.org>");
> >  MODULE_DESCRIPTION("GP2AP002 ambient light and proximity sensor driver");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/multiplexer/iio-mux.c b/drivers/iio/multiplexer/iio-mux.c
> > index b742ca9a99d1..e193913f5af7 100644
> > --- a/drivers/iio/multiplexer/iio-mux.c
> > +++ b/drivers/iio/multiplexer/iio-mux.c
> > @@ -464,3 +464,4 @@ module_platform_driver(mux_driver);
> >  MODULE_DESCRIPTION("IIO multiplexer driver");
> >  MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/iio/potentiostat/lmp91000.c b/drivers/iio/potentiostat/lmp91000.c
> > index eccc2a34358f..7d993f2acda4 100644
> > --- a/drivers/iio/potentiostat/lmp91000.c
> > +++ b/drivers/iio/potentiostat/lmp91000.c
> > @@ -423,3 +423,4 @@ module_i2c_driver(lmp91000_driver);
> >  MODULE_AUTHOR("Matt Ranostay <matt.ranostay@konsulko.com>");
> >  MODULE_DESCRIPTION("LMP91000 digital potentiostat");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/input/joystick/adc-joystick.c b/drivers/input/joystick/adc-joystick.c
> > index ff44f9978b71..4fa42f88bcfa 100644
> > --- a/drivers/input/joystick/adc-joystick.c
> > +++ b/drivers/input/joystick/adc-joystick.c
> > @@ -329,3 +329,4 @@ module_platform_driver(adc_joystick_driver);
> >  MODULE_DESCRIPTION("Input driver for joysticks connected over ADC");
> >  MODULE_AUTHOR("Artur Rojek <contact@artur-rojek.eu>");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
> > index f1753207429d..d687459a0c80 100644
> > --- a/drivers/input/keyboard/adc-keys.c
> > +++ b/drivers/input/keyboard/adc-keys.c
> > @@ -202,3 +202,4 @@ module_platform_driver(adc_keys_driver);
> >  MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni@free-electrons.com>");
> >  MODULE_DESCRIPTION("Input driver for resistor ladder connected on ADC");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c b/drivers/input/touchscreen/colibri-vf50-ts.c
> > index 98d5b2ba63fb..89c4d7b2b89e 100644
> > --- a/drivers/input/touchscreen/colibri-vf50-ts.c
> > +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
> > @@ -372,3 +372,4 @@ module_platform_driver(vf50_touch_driver);
> >  MODULE_AUTHOR("Sanchayan Maity");
> >  MODULE_DESCRIPTION("Colibri VF50 Touchscreen driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/input/touchscreen/resistive-adc-touch.c b/drivers/input/touchscreen/resistive-adc-touch.c
> > index 7e761ec73273..2fefd652864c 100644
> > --- a/drivers/input/touchscreen/resistive-adc-touch.c
> > +++ b/drivers/input/touchscreen/resistive-adc-touch.c
> > @@ -301,3 +301,4 @@ module_platform_driver(grts_driver);
> >  MODULE_AUTHOR("Eugen Hristev <eugen.hristev@microchip.com>");
> >  MODULE_DESCRIPTION("Generic ADC Resistive Touch Driver");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/phy/motorola/phy-cpcap-usb.c b/drivers/phy/motorola/phy-cpcap-usb.c
> > index 7cb020dd3423..9591672b0511 100644
> > --- a/drivers/phy/motorola/phy-cpcap-usb.c
> > +++ b/drivers/phy/motorola/phy-cpcap-usb.c
> > @@ -717,3 +717,4 @@ MODULE_ALIAS("platform:cpcap_usb");
> >  MODULE_AUTHOR("Tony Lindgren <tony@atomide.com>");
> >  MODULE_DESCRIPTION("CPCAP usb phy driver");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/ab8500_btemp.c b/drivers/power/supply/ab8500_btemp.c
> > index e5202a7b6209..36b0c52a4b8b 100644
> > --- a/drivers/power/supply/ab8500_btemp.c
> > +++ b/drivers/power/supply/ab8500_btemp.c
> > @@ -829,3 +829,4 @@ MODULE_LICENSE("GPL v2");
> >  MODULE_AUTHOR("Johan Palsson, Karl Komierowski, Arun R Murthy");
> >  MODULE_ALIAS("platform:ab8500-btemp");
> >  MODULE_DESCRIPTION("AB8500 battery temperature driver");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/ab8500_charger.c b/drivers/power/supply/ab8500_charger.c
> > index 5f4537766e5b..6e49d1b28254 100644
> > --- a/drivers/power/supply/ab8500_charger.c
> > +++ b/drivers/power/supply/ab8500_charger.c
> > @@ -3751,3 +3751,4 @@ MODULE_LICENSE("GPL v2");
> >  MODULE_AUTHOR("Johan Palsson, Karl Komierowski, Arun R Murthy");
> >  MODULE_ALIAS("platform:ab8500-charger");
> >  MODULE_DESCRIPTION("AB8500 charger management driver");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/ab8500_fg.c b/drivers/power/supply/ab8500_fg.c
> > index 9dd99722667a..5fa559f796aa 100644
> > --- a/drivers/power/supply/ab8500_fg.c
> > +++ b/drivers/power/supply/ab8500_fg.c
> > @@ -3252,3 +3252,4 @@ MODULE_LICENSE("GPL v2");
> >  MODULE_AUTHOR("Johan Palsson, Karl Komierowski");
> >  MODULE_ALIAS("platform:ab8500-fg");
> >  MODULE_DESCRIPTION("AB8500 Fuel Gauge driver");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/axp20x_ac_power.c b/drivers/power/supply/axp20x_ac_power.c
> > index 5f6ea416fa30..e9049d6229df 100644
> > --- a/drivers/power/supply/axp20x_ac_power.c
> > +++ b/drivers/power/supply/axp20x_ac_power.c
> > @@ -421,3 +421,4 @@ module_platform_driver(axp20x_ac_power_driver);
> >  MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
> >  MODULE_DESCRIPTION("AXP20X and AXP22X PMICs' AC power supply driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
> > index 50ca8e110085..ee8701a6e907 100644
> > --- a/drivers/power/supply/axp20x_battery.c
> > +++ b/drivers/power/supply/axp20x_battery.c
> > @@ -1155,3 +1155,4 @@ module_platform_driver(axp20x_batt_driver);
> >  MODULE_DESCRIPTION("Battery power supply driver for AXP20X and AXP22X PMICs");
> >  MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
> > index e75d1e377ac1..599adcf84968 100644
> > --- a/drivers/power/supply/axp20x_usb_power.c
> > +++ b/drivers/power/supply/axp20x_usb_power.c
> > @@ -1080,3 +1080,4 @@ module_platform_driver(axp20x_usb_power_driver);
> >  MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
> >  MODULE_DESCRIPTION("AXP20x PMIC USB power supply status driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/axp288_fuel_gauge.c b/drivers/power/supply/axp288_fuel_gauge.c
> > index a3d71fc72064..c6897dd808fc 100644
> > --- a/drivers/power/supply/axp288_fuel_gauge.c
> > +++ b/drivers/power/supply/axp288_fuel_gauge.c
> > @@ -817,3 +817,4 @@ MODULE_AUTHOR("Ramakrishna Pallala <ramakrishna.pallala@intel.com>");
> >  MODULE_AUTHOR("Todd Brandt <todd.e.brandt@linux.intel.com>");
> >  MODULE_DESCRIPTION("Xpower AXP288 Fuel Gauge Driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/cpcap-battery.c b/drivers/power/supply/cpcap-battery.c
> > index 8106d1edcbc2..542c3c70e3cb 100644
> > --- a/drivers/power/supply/cpcap-battery.c
> > +++ b/drivers/power/supply/cpcap-battery.c
> > @@ -1176,3 +1176,4 @@ module_platform_driver(cpcap_battery_driver);
> >  MODULE_LICENSE("GPL v2");
> >  MODULE_AUTHOR("Tony Lindgren <tony@atomide.com>");
> >  MODULE_DESCRIPTION("CPCAP PMIC Battery Driver");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/cpcap-charger.c b/drivers/power/supply/cpcap-charger.c
> > index d0c3008db534..89bc0fc3c9f8 100644
> > --- a/drivers/power/supply/cpcap-charger.c
> > +++ b/drivers/power/supply/cpcap-charger.c
> > @@ -977,3 +977,4 @@ MODULE_AUTHOR("Tony Lindgren <tony@atomide.com>");
> >  MODULE_DESCRIPTION("CPCAP Battery Charger Interface driver");
> >  MODULE_LICENSE("GPL v2");
> >  MODULE_ALIAS("platform:cpcap-charger");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/da9150-charger.c b/drivers/power/supply/da9150-charger.c
> > index 27f36ef5b88d..58449df6068c 100644
> > --- a/drivers/power/supply/da9150-charger.c
> > +++ b/drivers/power/supply/da9150-charger.c
> > @@ -644,3 +644,4 @@ module_platform_driver(da9150_charger_driver);
> >  MODULE_DESCRIPTION("Charger Driver for DA9150");
> >  MODULE_AUTHOR("Adam Thomson <Adam.Thomson.Opensource@diasemi.com>");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c
> > index f5f2566b3a32..d18c8ee40405 100644
> > --- a/drivers/power/supply/generic-adc-battery.c
> > +++ b/drivers/power/supply/generic-adc-battery.c
> > @@ -298,3 +298,4 @@ module_platform_driver(gab_driver);
> >  MODULE_AUTHOR("anish kumar <yesanishhere@gmail.com>");
> >  MODULE_DESCRIPTION("generic battery driver using IIO");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/ingenic-battery.c b/drivers/power/supply/ingenic-battery.c
> > index b111c7ce2be3..5be269f17bff 100644
> > --- a/drivers/power/supply/ingenic-battery.c
> > +++ b/drivers/power/supply/ingenic-battery.c
> > @@ -190,3 +190,4 @@ module_platform_driver(ingenic_battery_driver);
> >  MODULE_DESCRIPTION("Battery driver for Ingenic JZ47xx SoCs");
> >  MODULE_AUTHOR("Artur Rojek <contact@artur-rojek.eu>");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/intel_dc_ti_battery.c b/drivers/power/supply/intel_dc_ti_battery.c
> > index 56b0c92e9d28..1a16ded563bc 100644
> > --- a/drivers/power/supply/intel_dc_ti_battery.c
> > +++ b/drivers/power/supply/intel_dc_ti_battery.c
> > @@ -387,3 +387,4 @@ MODULE_ALIAS("platform:" DEV_NAME);
> >  MODULE_AUTHOR("Hans de Goede <hansg@kernel.org>");
> >  MODULE_DESCRIPTION("Intel Dollar Cove (TI) battery driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/lego_ev3_battery.c b/drivers/power/supply/lego_ev3_battery.c
> > index 28454de05761..414816662b06 100644
> > --- a/drivers/power/supply/lego_ev3_battery.c
> > +++ b/drivers/power/supply/lego_ev3_battery.c
> > @@ -231,3 +231,4 @@ module_platform_driver(lego_ev3_battery_driver);
> >  MODULE_LICENSE("GPL");
> >  MODULE_AUTHOR("David Lechner <david@lechnology.com>");
> >  MODULE_DESCRIPTION("LEGO MINDSTORMS EV3 Battery Driver");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/lp8788-charger.c b/drivers/power/supply/lp8788-charger.c
> > index f0a680c155c4..8c6ec98362d0 100644
> > --- a/drivers/power/supply/lp8788-charger.c
> > +++ b/drivers/power/supply/lp8788-charger.c
> > @@ -727,3 +727,4 @@ MODULE_DESCRIPTION("TI LP8788 Charger Driver");
> >  MODULE_AUTHOR("Milo Kim");
> >  MODULE_LICENSE("GPL");
> >  MODULE_ALIAS("platform:lp8788-charger");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c
> > index c1640bc6accd..1fe658bfecc1 100644
> > --- a/drivers/power/supply/max17040_battery.c
> > +++ b/drivers/power/supply/max17040_battery.c
> > @@ -635,3 +635,4 @@ module_i2c_driver(max17040_i2c_driver);
> >  MODULE_AUTHOR("Minkyu Kang <mk7.kang@samsung.com>");
> >  MODULE_DESCRIPTION("MAX17040 Fuel Gauge");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/mp2629_charger.c b/drivers/power/supply/mp2629_charger.c
> > index d281c1059629..ed49f9a04c8c 100644
> > --- a/drivers/power/supply/mp2629_charger.c
> > +++ b/drivers/power/supply/mp2629_charger.c
> > @@ -660,3 +660,4 @@ module_platform_driver(mp2629_charger_driver);
> >  MODULE_AUTHOR("Saravanan Sekar <sravanhome@gmail.com>");
> >  MODULE_DESCRIPTION("MP2629 Charger driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/mt6370-charger.c b/drivers/power/supply/mt6370-charger.c
> > index e6db961d5818..2d02fdf37d70 100644
> > --- a/drivers/power/supply/mt6370-charger.c
> > +++ b/drivers/power/supply/mt6370-charger.c
> > @@ -941,3 +941,4 @@ module_platform_driver(mt6370_chg_driver);
> >  MODULE_AUTHOR("ChiaEn Wu <chiaen_wu@richtek.com>");
> >  MODULE_DESCRIPTION("MediaTek MT6370 Charger Driver");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/qcom_smbx.c b/drivers/power/supply/qcom_smbx.c
> > index b1cb925581ec..63b88754155c 100644
> > --- a/drivers/power/supply/qcom_smbx.c
> > +++ b/drivers/power/supply/qcom_smbx.c
> > @@ -1050,3 +1050,4 @@ module_platform_driver(qcom_spmi_smb);
> >  MODULE_AUTHOR("Casey Connolly <casey.connolly@linaro.org>");
> >  MODULE_DESCRIPTION("Qualcomm SMB2 Charger Driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/rn5t618_power.c b/drivers/power/supply/rn5t618_power.c
> > index 40dec55a9f73..a3f30e390c11 100644
> > --- a/drivers/power/supply/rn5t618_power.c
> > +++ b/drivers/power/supply/rn5t618_power.c
> > @@ -821,3 +821,4 @@ module_platform_driver(rn5t618_power_driver);
> >  MODULE_ALIAS("platform:rn5t618-power");
> >  MODULE_DESCRIPTION("Power supply driver for RICOH RN5T618");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/rx51_battery.c b/drivers/power/supply/rx51_battery.c
> > index b0220ec2d926..57266921dc8e 100644
> > --- a/drivers/power/supply/rx51_battery.c
> > +++ b/drivers/power/supply/rx51_battery.c
> > @@ -246,3 +246,4 @@ MODULE_ALIAS("platform:rx51-battery");
> >  MODULE_AUTHOR("Pali Rohár <pali@kernel.org>");
> >  MODULE_DESCRIPTION("Nokia RX-51 battery driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c b/drivers/power/supply/sc27xx_fuel_gauge.c
> > index a7ed9de8a289..1719ec4173e6 100644
> > --- a/drivers/power/supply/sc27xx_fuel_gauge.c
> > +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
> > @@ -1350,3 +1350,4 @@ module_platform_driver(sc27xx_fgu_driver);
> >  
> >  MODULE_DESCRIPTION("Spreadtrum SC27XX PMICs Fual Gauge Unit Driver");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/twl4030_charger.c b/drivers/power/supply/twl4030_charger.c
> > index 04216b2bfb6c..151f7b24e9b9 100644
> > --- a/drivers/power/supply/twl4030_charger.c
> > +++ b/drivers/power/supply/twl4030_charger.c
> > @@ -1144,3 +1144,4 @@ MODULE_AUTHOR("Gražvydas Ignotas");
> >  MODULE_DESCRIPTION("TWL4030 Battery Charger Interface driver");
> >  MODULE_LICENSE("GPL");
> >  MODULE_ALIAS("platform:twl4030_bci");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/twl4030_madc_battery.c b/drivers/power/supply/twl4030_madc_battery.c
> > index 3935162e350b..9b3785d1643c 100644
> > --- a/drivers/power/supply/twl4030_madc_battery.c
> > +++ b/drivers/power/supply/twl4030_madc_battery.c
> > @@ -237,3 +237,4 @@ MODULE_LICENSE("GPL");
> >  MODULE_AUTHOR("Lukas Märdian <lukas@goldelico.com>");
> >  MODULE_DESCRIPTION("twl4030_madc battery driver");
> >  MODULE_ALIAS("platform:twl4030_madc_battery");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/power/supply/twl6030_charger.c b/drivers/power/supply/twl6030_charger.c
> > index b4ec26ff257c..82911a811f4e 100644
> > --- a/drivers/power/supply/twl6030_charger.c
> > +++ b/drivers/power/supply/twl6030_charger.c
> > @@ -579,3 +579,4 @@ module_platform_driver(twl6030_charger_driver);
> >  
> >  MODULE_DESCRIPTION("TWL6030 Battery Charger Interface driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
> > index d7f2e6ca92c2..bb6222c8cc5f 100644
> > --- a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
> > +++ b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
> > @@ -1069,3 +1069,4 @@ module_platform_driver(adc_tm5_driver);
> >  
> >  MODULE_DESCRIPTION("SPMI PMIC Thermal Monitor ADC driver");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
> > index f39ca0ddd17b..fb003ca96454 100644
> > --- a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
> > +++ b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
> > @@ -904,3 +904,4 @@ module_platform_driver(qpnp_tm_driver);
> >  MODULE_ALIAS("platform:spmi-temp-alarm");
> >  MODULE_DESCRIPTION("QPNP PMIC Temperature Alarm driver");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/thermal/renesas/rzg3s_thermal.c b/drivers/thermal/renesas/rzg3s_thermal.c
> > index e25e36c99a88..7ced8f76a0ec 100644
> > --- a/drivers/thermal/renesas/rzg3s_thermal.c
> > +++ b/drivers/thermal/renesas/rzg3s_thermal.c
> > @@ -270,3 +270,4 @@ module_platform_driver(rzg3s_thermal_driver);
> >  MODULE_DESCRIPTION("Renesas RZ/G3S Thermal Sensor Unit Driver");
> >  MODULE_AUTHOR("Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/drivers/thermal/thermal-generic-adc.c b/drivers/thermal/thermal-generic-adc.c
> > index 7c844589b153..cfdb8e674dd2 100644
> > --- a/drivers/thermal/thermal-generic-adc.c
> > +++ b/drivers/thermal/thermal-generic-adc.c
> > @@ -228,3 +228,4 @@ module_platform_driver(gadc_thermal_driver);
> >  MODULE_AUTHOR("Laxman Dewangan <ldewangan@nvidia.com>");
> >  MODULE_DESCRIPTION("Generic ADC thermal driver using IIO framework with DT");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/sound/soc/codecs/audio-iio-aux.c b/sound/soc/codecs/audio-iio-aux.c
> > index 588e48044c13..864a5a676495 100644
> > --- a/sound/soc/codecs/audio-iio-aux.c
> > +++ b/sound/soc/codecs/audio-iio-aux.c
> > @@ -312,3 +312,4 @@ module_platform_driver(audio_iio_aux_driver);
> >  MODULE_AUTHOR("Herve Codina <herve.codina@bootlin.com>");
> >  MODULE_DESCRIPTION("IIO ALSA SoC aux driver");
> >  MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/sound/soc/samsung/aries_wm8994.c b/sound/soc/samsung/aries_wm8994.c
> > index 3723329b266d..b6f0f3c0d393 100644
> > --- a/sound/soc/samsung/aries_wm8994.c
> > +++ b/sound/soc/samsung/aries_wm8994.c
> > @@ -700,3 +700,4 @@ module_platform_driver(aries_audio_driver);
> >  MODULE_DESCRIPTION("ALSA SoC ARIES WM8994");
> >  MODULE_LICENSE("GPL");
> >  MODULE_ALIAS("platform:aries-audio-wm8994");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/sound/soc/samsung/midas_wm1811.c b/sound/soc/samsung/midas_wm1811.c
> > index 239e958b88d3..12c4962f901d 100644
> > --- a/sound/soc/samsung/midas_wm1811.c
> > +++ b/sound/soc/samsung/midas_wm1811.c
> > @@ -773,3 +773,4 @@ module_platform_driver(midas_driver);
> >  MODULE_AUTHOR("Simon Shields <simon@lineageos.org>");
> >  MODULE_DESCRIPTION("ASoC support for Midas");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> > diff --git a/sound/soc/stm/stm32_adfsdm.c b/sound/soc/stm/stm32_adfsdm.c
> > index c914d1c46850..dabcd2759187 100644
> > --- a/sound/soc/stm/stm32_adfsdm.c
> > +++ b/sound/soc/stm/stm32_adfsdm.c
> > @@ -407,3 +407,4 @@ MODULE_DESCRIPTION("stm32 DFSDM DAI driver");
> >  MODULE_AUTHOR("Arnaud Pouliquen <arnaud.pouliquen@st.com>");
> >  MODULE_LICENSE("GPL v2");
> >  MODULE_ALIAS("platform:" STM32_ADFSDM_DRV_NAME);
> > +MODULE_IMPORT_NS("IIO_CONSUMER");
> >   
> 
> 


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 1/3] phy: lynx-28g: use timeouts when waiting for lane halt and reset
From: Andrew Lunn @ 2026-03-21 15:48 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-phy, netdev, Ioana Ciornei, Vinod Koul, Neil Armstrong,
	Josua Mayer, linux-kernel
In-Reply-To: <20260321011451.1557091-2-vladimir.oltean@nxp.com>

On Sat, Mar 21, 2026 at 03:14:49AM +0200, Vladimir Oltean wrote:
> There are various circumstances in which a lane halt, or a lane reset,
> will fail to complete. If this happens, it will hang the kernel, which
> only implements a busy loop with no timeout.
> 
> The circumstances in which this will happen are all bugs in nature:
> - if we try to power off a powered off lane
> - if we try to power off a lane that uses a PLL locked onto the wrong
>   refclk frequency (wrong RCW, but SoC boots anyway)
> 
> Actually, unbounded loops in the kernel are a bad practice, so let's use
> read_poll_timeout() with a custom function that reads both LNaTRSTCTL
> (lane transmit control register) and LNaRRSTCTL (lane receive control
> register) and returns true when the request is done in both directions.
> 
> The HLT_REQ bit has to clear, whereas the RST_DONE bit has to get set.
> 
> Any time such an error happens, it is catastrophic and there is no point
> in trying to propagate it to our callers:
> - if lynx_28g_set_mode() -> lynx_28g_power_on() times out, we have
>   already reconfigured the lane, but returning an error would tell the
>   caller that we didn't
> - if lynx_28g_power_off() times out, again not much for the consumer to
>   do to help get out of this situation - the phy_power_off() call is
>   probably made from a context that the consumer can't cancel, or it is
>   making it to return to a known state from a previous failure.
> 
> So just print an error if timeouts happen and let the driver control
> flow continue. The entire point is just to not let the kernel freeze.
> 
> Suggested-by: Josua Mayer <josua@solid-run.com>
> Link: https://lore.kernel.org/lkml/d0c8bbf8-a0c5-469f-a148-de2235948c0f@solid-run.com/
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* [PATCH phy-fixes] phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access
From: Gabor Juhos @ 2026-03-21 14:42 UTC (permalink / raw)
  To: Miquel Raynal, Vinod Koul, Neil Armstrong, Igal Liberman,
	Kishon Vijay Abraham I
  Cc: linux-phy, linux-kernel, Gabor Juhos

The mvebu_a3700_utmi_phy_power_off() function tries to modify the
USB2_PHY_CTRL register by using the IO address of the PHY IP block along
with the readl/writel IO accessors. However, the register exist in the
USB miscellaneous register space, and as such it must be accessed via
regmap like it is done in the mvebu_a3700_utmi_phy_power_on() function.

Change the code to use regmap_update_bits() for modífying the register
to fix this.

Fixes: cc8b7a0ae866 ("phy: add A3700 UTMI PHY driver")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
---
 drivers/phy/marvell/phy-mvebu-a3700-utmi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-a3700-utmi.c b/drivers/phy/marvell/phy-mvebu-a3700-utmi.c
index 04f4fb4bed7024c933190bbd9353615d54ac172c..f882bc57649c77343c3cb9c5111db82812993c3e 100644
--- a/drivers/phy/marvell/phy-mvebu-a3700-utmi.c
+++ b/drivers/phy/marvell/phy-mvebu-a3700-utmi.c
@@ -168,9 +168,8 @@ static int mvebu_a3700_utmi_phy_power_off(struct phy *phy)
 	u32 reg;
 
 	/* Disable PHY pull-up and enable USB2 suspend */
-	reg = readl(utmi->regs + USB2_PHY_CTRL(usb32));
-	reg &= ~(RB_USB2PHY_PU | RB_USB2PHY_SUSPM(usb32));
-	writel(reg, utmi->regs + USB2_PHY_CTRL(usb32));
+	regmap_update_bits(utmi->usb_misc, USB2_PHY_CTRL(usb32),
+			   RB_USB2PHY_PU | RB_USB2PHY_SUSPM(usb32), 0);
 
 	/* Power down OTG module */
 	if (usb32) {

---
base-commit: 81af9e40e2e4e1aa95f09fb34811760be6742c58
change-id: 20260321-a3700-utmi-fix-usb2_phy_ctrl-access-759ad1d7c935

Best regards,
-- 
Gabor Juhos <j4g8y7@gmail.com>


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH phy-next 3/3] phy: lynx-28g: implement phy_exit() operation
From: Vladimir Oltean @ 2026-03-21  1:14 UTC (permalink / raw)
  To: linux-phy
  Cc: netdev, Ioana Ciornei, Vinod Koul, Neil Armstrong, Josua Mayer,
	linux-kernel
In-Reply-To: <20260321011451.1557091-1-vladimir.oltean@nxp.com>

On Layerscape, some Lynx SerDes consumers go through the PHY framework
(we call these 'managed' for the sake of this discussion; they are some
Ethernet lanes), and some consumers don't go through the PHY framework
(we call these 'unmanaged'; they are some unconverted Ethernet lanes,
plus all SATA and PCIe controllers).

A lane is initially unmanaged, and becomes managed when phy_init() is
called on it. Similarly, it becomes unmanaged again when phy_exit() is
called.

Managed lanes are supposed to have power management through
phy_power_on() and phy_power_off().

The lynx-28g SerDes driver, when it probes, probes on all lanes, but
needs to be careful to keep the unmanaged lanes powered on, because
those might be in use by consumers unaware that they need to call
phy_init() and phy_power_on(). This also applies after phy_exit() is
called - no guarantee is made about how the port may be used
afterwards - may be DPDK, may be something else which is unaware of
the PHY framework.

Given this state table:

 State  | Consumer calls phy_exit()? | Provider implements phy_exit()?
 -------+----------------------------+--------------------------------
 (a)    | no                         | no
 (b)    | no                         | yes
 (c)    | yes                        | no
 (d)    | yes                        | yes

we are currently in state (a). This has the problem that when the
consumer fails to probe with -EPROBE_DEFER or is otherwise unbound,
the phy->init_count remains elevated and the lane never returns to the
unmanaged state (temporarily or not) as it should. Furthermore, the
second and subsequent phy_init() consumer calls are never passed on to
the provider driver.

We solve the above problem by implementing phy_exit() in the consumer,
and that moves us to state (c). But this creates the problem that a
balanced set of phy_init() and phy_exit() calls from the consumer will
effectively result in multiple lynx_28g_init() calls as seen by the
SerDes and nothing else - as the optional phy_ops :: exit() is not
implemented. But that actually doesn't work - the 28G Lynx SerDes can't
power down a lane which is already powered down; that call sequence
would time out and fail.

So actually we want to be in state (d), where both the provider and the
consumer implement phy_exit(). But we can only do that safely through
intermediary state (b), where the provider implements it first. This
effectively behaves just like (a), except it offers a safe migration
path for the consumer to call phy_exit() as mandated by the Generic PHY
API.

Extra development notes: ignoring the lynx_28g_power_on() error in
lynx_28g_exit() is a deliberate decision. The consumer can't deal with a
teardown path that is not error-free. Ignoring the error is not silent:
lynx_28g_power_on() -> lynx_28g_lane_reset() will print on failure.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Previously submitted as part of larger set:
https://lore.kernel.org/linux-phy/20260114152111.625350-9-vladimir.oltean@nxp.com/

Changes:
- Stop propagating lynx_28g_power_on() error code to lynx_28g_exit().
- Add more detailed explanation in commit message
---
 drivers/phy/freescale/phy-fsl-lynx-28g.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
index b056951506dc..dd54d82a1e1f 100644
--- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
+++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
@@ -1113,8 +1113,25 @@ static int lynx_28g_init(struct phy *phy)
 	return 0;
 }
 
+static int lynx_28g_exit(struct phy *phy)
+{
+	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
+
+	/* The lane returns to the state where it isn't managed by the
+	 * consumer, so we must treat is as if it isn't initialized, and
+	 * always powered on.
+	 */
+	lane->init = false;
+	lane->powered_up = false;
+
+	lynx_28g_power_on(phy);
+
+	return 0;
+}
+
 static const struct phy_ops lynx_28g_ops = {
 	.init		= lynx_28g_init,
+	.exit		= lynx_28g_exit,
 	.power_on	= lynx_28g_power_on,
 	.power_off	= lynx_28g_power_off,
 	.set_mode	= lynx_28g_set_mode,
-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH phy-next 2/3] phy: lynx-28g: truly power the lanes up or down
From: Vladimir Oltean @ 2026-03-21  1:14 UTC (permalink / raw)
  To: linux-phy
  Cc: netdev, Ioana Ciornei, Vinod Koul, Neil Armstrong, Josua Mayer,
	linux-kernel
In-Reply-To: <20260321011451.1557091-1-vladimir.oltean@nxp.com>

The current procedure for power_off() and power_on() is the same as the
one used for major lane reconfiguration, aka halting. But this is
incorrect.

One would expect that a powered off lane causes the CDR (clock and data
recovery) loop of the link partner to lose lock onto its RX stream
(which suggests there are no longer any bit transitions => the channel
is inactive). However, it can be observed that this does not take place
(the CDR lock is still there), which means that a halted lane is not
powered off.

Implement the procedure mentioned in the block guide for powering down
a lane, and then back on. This means:

- lynx_28g_power_off() currently emits a HLT_REQ and waits for it to
  clear. Rename it to lynx_28g_lane_halt() and keep using it for
  lynx_28g_set_mode().
- lynx_28g_power_on() currently emits a RST_REQ and waits for it to
  clear. This is the reset procedure - rename it to
  lynx_28g_lane_reset(), and keep using it for lynx_28g_set_mode().

The "real" lynx_28g_power_off() should emit a STP_REQ and wait for it to
clear. And the "real" lynx_28g_power_on() should clear the DIS bit and
then perform a lane reset. Hook these methods to the phy_ops ::
power_off() and power_on() instead.

As opposed to lynx_28g_power_off() which is also directly hooked to the
PHY API, lynx_28g_lane_halt() isn't; just to lynx_28g_set_mode(), and
the call is being made in a state where we haven't yet made any change
to the lane. So it does make some limited amount of sense to code this
up such that if it fails, we make an attempt to reset the lane anyway
and let the consumer know that phy_set_mode_ext() failed.

Sort the field definitions in LNaTRSTCTL and LNaRRSTCTL in descending
order, and add new definitions for STP_REQ and DIS, previously unused.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Previously submitted as part of larger set:
https://lore.kernel.org/linux-phy/20260114152111.625350-8-vladimir.oltean@nxp.com/

Changes:
- stop propagating read_poll_timeout() error code to the new
  lynx_28g_power_off() implementation, for the same reason as the
  previous patch.
- do propagate the read_poll_timeout() error code to
  lynx_28g_lane_halt(), and make an attempt to reset the lane.
- more detailed explanation in commit message
---
 drivers/phy/freescale/phy-fsl-lynx-28g.c | 103 +++++++++++++++++++----
 1 file changed, 85 insertions(+), 18 deletions(-)

diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
index 3debf4131e0f..b056951506dc 100644
--- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
+++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
@@ -70,9 +70,11 @@
 
 /* Lane a Tx Reset Control Register */
 #define LNaTRSTCTL(lane)			(0x800 + (lane) * 0x100 + 0x20)
-#define LNaTRSTCTL_HLT_REQ			BIT(27)
-#define LNaTRSTCTL_RST_DONE			BIT(30)
 #define LNaTRSTCTL_RST_REQ			BIT(31)
+#define LNaTRSTCTL_RST_DONE			BIT(30)
+#define LNaTRSTCTL_HLT_REQ			BIT(27)
+#define LNaTRSTCTL_STP_REQ			BIT(26)
+#define LNaTRSTCTL_DIS				BIT(24)
 
 /* Lane a Tx General Control Register */
 #define LNaTGCR0(lane)				(0x800 + (lane) * 0x100 + 0x24)
@@ -98,9 +100,11 @@
 
 /* Lane a Rx Reset Control Register */
 #define LNaRRSTCTL(lane)			(0x800 + (lane) * 0x100 + 0x40)
-#define LNaRRSTCTL_HLT_REQ			BIT(27)
-#define LNaRRSTCTL_RST_DONE			BIT(30)
 #define LNaRRSTCTL_RST_REQ			BIT(31)
+#define LNaRRSTCTL_RST_DONE			BIT(30)
+#define LNaRRSTCTL_HLT_REQ			BIT(27)
+#define LNaRRSTCTL_STP_REQ			BIT(26)
+#define LNaRRSTCTL_DIS				BIT(24)
 #define LNaRRSTCTL_CDR_LOCK			BIT(12)
 
 /* Lane a Rx General Control Register */
@@ -255,6 +259,9 @@
 #define LYNX_28G_LANE_RESET_SLEEP_US		100
 #define LYNX_28G_LANE_RESET_TIMEOUT_US		1000000
 
+#define LYNX_28G_LANE_STOP_SLEEP_US		100
+#define LYNX_28G_LANE_STOP_TIMEOUT_US		1000000
+
 enum lynx_28g_eq_type {
 	EQ_TYPE_NO_EQ = 0,
 	EQ_TYPE_2TAP = 1,
@@ -615,6 +622,15 @@ static bool lynx_28g_lane_halt_done(struct lynx_28g_lane *lane)
 	       !(rrstctl & LNaRRSTCTL_HLT_REQ);
 }
 
+static bool lynx_28g_lane_stop_done(struct lynx_28g_lane *lane)
+{
+	u32 trstctl = lynx_28g_lane_read(lane, LNaTRSTCTL);
+	u32 rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
+
+	return !(trstctl & LNaTRSTCTL_STP_REQ) &&
+	       !(rrstctl & LNaRRSTCTL_STP_REQ);
+}
+
 static bool lynx_28g_lane_reset_done(struct lynx_28g_lane *lane)
 {
 	u32 trstctl = lynx_28g_lane_read(lane, LNaTRSTCTL);
@@ -624,15 +640,13 @@ static bool lynx_28g_lane_reset_done(struct lynx_28g_lane *lane)
 	       (rrstctl & LNaRRSTCTL_RST_DONE);
 }
 
-static int lynx_28g_power_off(struct phy *phy)
+/* Halting puts the lane in a mode in which it can be reconfigured */
+static int lynx_28g_lane_halt(struct phy *phy)
 {
 	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
 	bool done;
 	int err;
 
-	if (!lane->powered_up)
-		return 0;
-
 	/* Issue a halt request */
 	lynx_28g_lane_rmw(lane, LNaTRSTCTL, LNaTRSTCTL_HLT_REQ,
 			  LNaTRSTCTL_HLT_REQ);
@@ -649,20 +663,15 @@ static int lynx_28g_power_off(struct phy *phy)
 			'A' + lane->id, ERR_PTR(err));
 	}
 
-	lane->powered_up = false;
-
-	return 0;
+	return err;
 }
 
-static int lynx_28g_power_on(struct phy *phy)
+static int lynx_28g_lane_reset(struct phy *phy)
 {
 	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
 	bool done;
 	int err;
 
-	if (lane->powered_up)
-		return 0;
-
 	/* Issue a reset request on the lane */
 	lynx_28g_lane_rmw(lane, LNaTRSTCTL, LNaTRSTCTL_RST_REQ,
 			  LNaTRSTCTL_RST_REQ);
@@ -679,6 +688,61 @@ static int lynx_28g_power_on(struct phy *phy)
 			'A' + lane->id, ERR_PTR(err));
 	}
 
+	return err;
+}
+
+static int lynx_28g_power_off(struct phy *phy)
+{
+	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
+	bool done;
+	int err;
+
+	if (!lane->powered_up)
+		return 0;
+
+	/* Issue a stop request */
+	lynx_28g_lane_rmw(lane, LNaTRSTCTL, LNaTRSTCTL_STP_REQ,
+			  LNaTRSTCTL_STP_REQ);
+	lynx_28g_lane_rmw(lane, LNaRRSTCTL, LNaRRSTCTL_STP_REQ,
+			  LNaRRSTCTL_STP_REQ);
+
+	/* Wait until the stop process is complete */
+	err = read_poll_timeout(lynx_28g_lane_stop_done, done, done,
+				LYNX_28G_LANE_STOP_SLEEP_US,
+				LYNX_28G_LANE_STOP_TIMEOUT_US,
+				false, lane);
+	if (err) {
+		dev_err(&phy->dev, "Lane %c stop failed: %pe\n",
+			'A' + lane->id, ERR_PTR(err));
+	}
+
+	/* Power down the RX and TX portions of the lane */
+	lynx_28g_lane_rmw(lane, LNaRRSTCTL, LNaRRSTCTL_DIS,
+			  LNaRRSTCTL_DIS);
+	lynx_28g_lane_rmw(lane, LNaTRSTCTL, LNaTRSTCTL_DIS,
+			  LNaTRSTCTL_DIS);
+
+	lane->powered_up = false;
+
+	return 0;
+}
+
+static int lynx_28g_power_on(struct phy *phy)
+{
+	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
+	int err;
+
+	if (lane->powered_up)
+		return 0;
+
+	/* Power up the RX and TX portions of the lane */
+	lynx_28g_lane_rmw(lane, LNaRRSTCTL, 0, LNaRRSTCTL_DIS);
+	lynx_28g_lane_rmw(lane, LNaTRSTCTL, 0, LNaTRSTCTL_DIS);
+
+	err = lynx_28g_lane_reset(phy);
+	if (err)
+		return err;
+
 	lane->powered_up = true;
 
 	return 0;
@@ -992,8 +1056,11 @@ static int lynx_28g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
 	/* If the lane is powered up, put the lane into the halt state while
 	 * the reconfiguration is being done.
 	 */
-	if (powered_up)
-		lynx_28g_power_off(phy);
+	if (powered_up) {
+		err = lynx_28g_lane_halt(phy);
+		if (err)
+			goto out;
+	}
 
 	err = lynx_28g_lane_disable_pcvt(lane, lane->mode);
 	if (err)
@@ -1007,7 +1074,7 @@ static int lynx_28g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
 
 out:
 	if (powered_up)
-		lynx_28g_power_on(phy);
+		lynx_28g_lane_reset(phy);
 
 	return err;
 }
-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH phy-next 1/3] phy: lynx-28g: use timeouts when waiting for lane halt and reset
From: Vladimir Oltean @ 2026-03-21  1:14 UTC (permalink / raw)
  To: linux-phy
  Cc: netdev, Ioana Ciornei, Vinod Koul, Neil Armstrong, Josua Mayer,
	linux-kernel
In-Reply-To: <20260321011451.1557091-1-vladimir.oltean@nxp.com>

There are various circumstances in which a lane halt, or a lane reset,
will fail to complete. If this happens, it will hang the kernel, which
only implements a busy loop with no timeout.

The circumstances in which this will happen are all bugs in nature:
- if we try to power off a powered off lane
- if we try to power off a lane that uses a PLL locked onto the wrong
  refclk frequency (wrong RCW, but SoC boots anyway)

Actually, unbounded loops in the kernel are a bad practice, so let's use
read_poll_timeout() with a custom function that reads both LNaTRSTCTL
(lane transmit control register) and LNaRRSTCTL (lane receive control
register) and returns true when the request is done in both directions.

The HLT_REQ bit has to clear, whereas the RST_DONE bit has to get set.

Any time such an error happens, it is catastrophic and there is no point
in trying to propagate it to our callers:
- if lynx_28g_set_mode() -> lynx_28g_power_on() times out, we have
  already reconfigured the lane, but returning an error would tell the
  caller that we didn't
- if lynx_28g_power_off() times out, again not much for the consumer to
  do to help get out of this situation - the phy_power_off() call is
  probably made from a context that the consumer can't cancel, or it is
  making it to return to a known state from a previous failure.

So just print an error if timeouts happen and let the driver control
flow continue. The entire point is just to not let the kernel freeze.

Suggested-by: Josua Mayer <josua@solid-run.com>
Link: https://lore.kernel.org/lkml/d0c8bbf8-a0c5-469f-a148-de2235948c0f@solid-run.com/
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Previously submitted as part of larger set:
https://lore.kernel.org/linux-phy/20260114152111.625350-7-vladimir.oltean@nxp.com/

Changes:
- Stop propagating the read_poll_timeout() errors to callers
- Adjust commit message to explain that decision
---
 drivers/phy/freescale/phy-fsl-lynx-28g.c | 72 ++++++++++++++++++------
 1 file changed, 56 insertions(+), 16 deletions(-)

diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
index 2b0fd95ba62f..3debf4131e0f 100644
--- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
+++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
@@ -249,6 +249,12 @@
 
 #define CR(x)					((x) * 4)
 
+#define LYNX_28G_LANE_HALT_SLEEP_US		100
+#define LYNX_28G_LANE_HALT_TIMEOUT_US		1000000
+
+#define LYNX_28G_LANE_RESET_SLEEP_US		100
+#define LYNX_28G_LANE_RESET_TIMEOUT_US		1000000
+
 enum lynx_28g_eq_type {
 	EQ_TYPE_NO_EQ = 0,
 	EQ_TYPE_2TAP = 1,
@@ -600,10 +606,29 @@ static void lynx_28g_lane_set_pll(struct lynx_28g_lane *lane,
 	}
 }
 
+static bool lynx_28g_lane_halt_done(struct lynx_28g_lane *lane)
+{
+	u32 trstctl = lynx_28g_lane_read(lane, LNaTRSTCTL);
+	u32 rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
+
+	return !(trstctl & LNaTRSTCTL_HLT_REQ) &&
+	       !(rrstctl & LNaRRSTCTL_HLT_REQ);
+}
+
+static bool lynx_28g_lane_reset_done(struct lynx_28g_lane *lane)
+{
+	u32 trstctl = lynx_28g_lane_read(lane, LNaTRSTCTL);
+	u32 rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
+
+	return (trstctl & LNaTRSTCTL_RST_DONE) &&
+	       (rrstctl & LNaRRSTCTL_RST_DONE);
+}
+
 static int lynx_28g_power_off(struct phy *phy)
 {
 	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
-	u32 trstctl, rrstctl;
+	bool done;
+	int err;
 
 	if (!lane->powered_up)
 		return 0;
@@ -615,11 +640,14 @@ static int lynx_28g_power_off(struct phy *phy)
 			  LNaRRSTCTL_HLT_REQ);
 
 	/* Wait until the halting process is complete */
-	do {
-		trstctl = lynx_28g_lane_read(lane, LNaTRSTCTL);
-		rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
-	} while ((trstctl & LNaTRSTCTL_HLT_REQ) ||
-		 (rrstctl & LNaRRSTCTL_HLT_REQ));
+	err = read_poll_timeout(lynx_28g_lane_halt_done, done, done,
+				LYNX_28G_LANE_HALT_SLEEP_US,
+				LYNX_28G_LANE_HALT_TIMEOUT_US,
+				false, lane);
+	if (err) {
+		dev_err(&phy->dev, "Lane %c halt failed: %pe\n",
+			'A' + lane->id, ERR_PTR(err));
+	}
 
 	lane->powered_up = false;
 
@@ -629,7 +657,8 @@ static int lynx_28g_power_off(struct phy *phy)
 static int lynx_28g_power_on(struct phy *phy)
 {
 	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
-	u32 trstctl, rrstctl;
+	bool done;
+	int err;
 
 	if (lane->powered_up)
 		return 0;
@@ -641,11 +670,14 @@ static int lynx_28g_power_on(struct phy *phy)
 			  LNaRRSTCTL_RST_REQ);
 
 	/* Wait until the reset sequence is completed */
-	do {
-		trstctl = lynx_28g_lane_read(lane, LNaTRSTCTL);
-		rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
-	} while (!(trstctl & LNaTRSTCTL_RST_DONE) ||
-		 !(rrstctl & LNaRRSTCTL_RST_DONE));
+	err = read_poll_timeout(lynx_28g_lane_reset_done, done, done,
+				LYNX_28G_LANE_RESET_SLEEP_US,
+				LYNX_28G_LANE_RESET_TIMEOUT_US,
+				false, lane);
+	if (err) {
+		dev_err(&phy->dev, "Lane %c reset failed: %pe\n",
+			'A' + lane->id, ERR_PTR(err));
+	}
 
 	lane->powered_up = true;
 
@@ -1065,7 +1097,7 @@ static void lynx_28g_cdr_lock_check(struct work_struct *work)
 	struct lynx_28g_priv *priv = work_to_lynx(work);
 	struct lynx_28g_lane *lane;
 	u32 rrstctl;
-	int i;
+	int err, i;
 
 	for (i = 0; i < LYNX_28G_NUM_LANE; i++) {
 		lane = &priv->lane[i];
@@ -1081,9 +1113,17 @@ static void lynx_28g_cdr_lock_check(struct work_struct *work)
 		if (!(rrstctl & LNaRRSTCTL_CDR_LOCK)) {
 			lynx_28g_lane_rmw(lane, LNaRRSTCTL, LNaRRSTCTL_RST_REQ,
 					  LNaRRSTCTL_RST_REQ);
-			do {
-				rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
-			} while (!(rrstctl & LNaRRSTCTL_RST_DONE));
+
+			err = read_poll_timeout(lynx_28g_lane_read, rrstctl,
+						!!(rrstctl & LNaRRSTCTL_RST_DONE),
+						LYNX_28G_LANE_RESET_SLEEP_US,
+						LYNX_28G_LANE_RESET_TIMEOUT_US,
+						false, lane, LNaRRSTCTL);
+			if (err) {
+				dev_warn_once(&lane->phy->dev,
+					      "Lane %c receiver reset failed: %pe\n",
+					      'A' + lane->id, ERR_PTR(err));
+			}
 		}
 
 		mutex_unlock(&lane->phy->mutex);
-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH phy-next 0/3] Lynx 28G: better init(), exit(), power_on(), power_off()
From: Vladimir Oltean @ 2026-03-21  1:14 UTC (permalink / raw)
  To: linux-phy
  Cc: netdev, Ioana Ciornei, Vinod Koul, Neil Armstrong, Josua Mayer,
	linux-kernel

This is a set of 3 improvements to the 28G Lynx SerDes driver as found
on NXP Layerscape:
- avoid kernel hangs if lane resets/halts fail due to other bugs
- actually have phy_power_down() cut power from lanes, not just halt them
- allow consumers to call phy_exit(), to balance the phy->init_count

Especially change 3 will allow further development of the dpaa2-eth
consumer. To permit phy_exit() and other patches in net-next to be
submitted in this development cycle without functionally breaking
networking, please apply this change on top of v7.0-rc1 and provide
it as a stable tag to be pulled in netdev.

Vladimir Oltean (3):
  phy: lynx-28g: use timeouts when waiting for lane halt and reset
  phy: lynx-28g: truly power the lanes up or down
  phy: lynx-28g: implement phy_exit() operation

 drivers/phy/freescale/phy-fsl-lynx-28g.c | 190 +++++++++++++++++++----
 1 file changed, 157 insertions(+), 33 deletions(-)

-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 6/7] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
From: kernel test robot @ 2026-03-20 19:06 UTC (permalink / raw)
  To: Nora Schiffer, Andrew Lunn, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Nishanth Menon, Vignesh Raghavendra,
	Tero Kristo
  Cc: llvm, oe-kbuild-all, netdev, Siddharth Vadapalli, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux,
	Nora Schiffer
In-Reply-To: <4cc3dd9fab460d35215c8f97496b9ae16c5bcb22.1773751309.git.nora.schiffer@ew.tq-group.com>

Hi Nora,

kernel test robot noticed the following build errors:

[auto build test ERROR on robh/for-next]
[also build test ERROR on net-next/main net/main linus/master v7.0-rc4 next-20260319]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Nora-Schiffer/dt-bindings-phy-ti-phy-j721e-wiz-Add-ti-j722s-wiz-10g-compatible/20260320-033344
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/4cc3dd9fab460d35215c8f97496b9ae16c5bcb22.1773751309.git.nora.schiffer%40ew.tq-group.com
patch subject: [PATCH 6/7] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
config: arm64-allmodconfig (https://download.01.org/0day-ci/archive/20260321/202603210254.ABl6TQWc-lkp@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260321/202603210254.ABl6TQWc-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603210254.ABl6TQWc-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/net/ethernet/ti/am65-cpsw-nuss.c:762:9: warning: cast to smaller integer type 'enum am65_cpsw_tx_buf_type' from 'void *' [-Wvoid-pointer-to-enum-cast]
     762 |         return (enum am65_cpsw_tx_buf_type)k3_cppi_desc_pool_desc_info(tx_chn->desc_pool,
         |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     763 |                                                                        desc_idx);
         |                                                                        ~~~~~~~~~
>> drivers/net/ethernet/ti/am65-cpsw-nuss.c:3470:47: error: use of undeclared identifier 'AM64_CPSW_QUIRK_CUT_THRU'
    3470 |         .quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ | AM64_CPSW_QUIRK_CUT_THRU,
         |                                                      ^
   1 warning and 1 error generated.


vim +/AM64_CPSW_QUIRK_CUT_THRU +3470 drivers/net/ethernet/ti/am65-cpsw-nuss.c

  3468	
  3469	static const struct am65_cpsw_pdata j722s_cpswxg_pdata = {
> 3470		.quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ | AM64_CPSW_QUIRK_CUT_THRU,
  3471		.ale_dev_id = "am64-cpswxg",
  3472		.fdqring_mode = K3_RINGACC_RING_MODE_RING,
  3473		.extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
  3474	};
  3475	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 6/7] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
From: kernel test robot @ 2026-03-20 14:23 UTC (permalink / raw)
  To: Nora Schiffer, Andrew Lunn, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Nishanth Menon, Vignesh Raghavendra,
	Tero Kristo
  Cc: oe-kbuild-all, netdev, Siddharth Vadapalli, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux,
	Nora Schiffer
In-Reply-To: <4cc3dd9fab460d35215c8f97496b9ae16c5bcb22.1773751309.git.nora.schiffer@ew.tq-group.com>

Hi Nora,

kernel test robot noticed the following build errors:

[auto build test ERROR on robh/for-next]
[also build test ERROR on net-next/main net/main linus/master v7.0-rc4 next-20260319]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Nora-Schiffer/dt-bindings-phy-ti-phy-j721e-wiz-Add-ti-j722s-wiz-10g-compatible/20260320-033344
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/4cc3dd9fab460d35215c8f97496b9ae16c5bcb22.1773751309.git.nora.schiffer%40ew.tq-group.com
patch subject: [PATCH 6/7] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20260320/202603202224.XkGRjqgx-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260320/202603202224.XkGRjqgx-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603202224.XkGRjqgx-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/net/ethernet/ti/am65-cpsw-nuss.c:3470:54: error: 'AM64_CPSW_QUIRK_CUT_THRU' undeclared here (not in a function)
    3470 |         .quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ | AM64_CPSW_QUIRK_CUT_THRU,
         |                                                      ^~~~~~~~~~~~~~~~~~~~~~~~


vim +/AM64_CPSW_QUIRK_CUT_THRU +3470 drivers/net/ethernet/ti/am65-cpsw-nuss.c

  3468	
  3469	static const struct am65_cpsw_pdata j722s_cpswxg_pdata = {
> 3470		.quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ | AM64_CPSW_QUIRK_CUT_THRU,
  3471		.ale_dev_id = "am64-cpswxg",
  3472		.fdqring_mode = K3_RINGACC_RING_MODE_RING,
  3473		.extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
  3474	};
  3475	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-03-20  9:56 UTC (permalink / raw)
  To: Vladimir Zapolskiy, Bryan O'Donoghue, Dmitry Baryshkov,
	Neil Armstrong
  Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
	linux-media, devicetree, linux-kernel
In-Reply-To: <5b23408d-c996-4785-8294-233d79168a1b@linaro.org>

On 20/03/2026 00:37, Vladimir Zapolskiy wrote:
> On 3/19/26 17:18, Bryan O'Donoghue wrote:
>> On 19/03/2026 14:56, Vladimir Zapolskiy wrote:
>>>> There's no reason to remove that from CAMSS - it would be an ABI break
>>>> in user-space anyway.
>>> If technically CAMSS CSIPHY could be excluded from the list of CAMSS media
>>> subdevices, then for the sake of simplification it should be done for all
>>> supported platforms in advance, such a change will be independent from this
>>> particular phy series, and vice versa, this CAMSS only driver change will
>>> prepare a ground for media-less CAMSS CSIPHY device drivers, hence it shall
>>> precede this particular CAMSS CSIPHY series.
>>>
>>> For backward compatibility with userspace a noop stub will be good enough,
>>> it's not an issue at all.
>> The standalone PHY driver doesn't require removing the CSIPHY media
>> entity from CAMSS. They serve different purposes and coexist - its
>> important to have a NOP from user-space perspective for legacy and
>> indeed for new implementations.
>>
> There should be no two CAMSS CSIPHY device (or subdevice) drivers, where
> one chop of CAMSS CSIPHY device driver remains to sit under media, and
> another one is under phy subsystem, since it's a further degradation from
> the current already pretty awful state of the CAMSS driver, but at least
> CSIPHY is not scattered over different subsystems today.
> 
> It might be fine to move device driver parts related to CAMSS CSIPHY
> driver from media subsystem to phy subsystem, however if only a partial
> transition is planned, and CSIPHY device support is split into two device
> (sub-)drivers, then it merely exposes a quite severe design flaw.

It's not two drivers for the same device. It's two layers:

- The media entity in CAMSS is a pipeline routing abstraction.
   It validates formats and connects pads. It does not program
   CSIPHY hardware directly.

- The PHY driver programs the hardware — registers, clocks,
   regulators, power domains.

This is the same layering as rkisp1 (media pipeline) +
phy-rockchip-inno-csidphy (electrical config). The ISP's media
entities and the standalone PHY coexist in different subsystems
without conflict.

No CSIPHY functionality is duplicated across subsystems. This segmenting 
of concepts and functionality isn't even unique. We see this constantly 
with USB (where the MAC lives in drivers/usb/ and the electricals in 
drivers/phy/) and Display/DSI.


> It looks like it's still undecided, if CAMSS CSIPHY IP is a phy or media
> device, it can not be both at the same time.

We are maintaining the existing user-space setup which presents a 
msm_csiphyX v4l2-media device, whilst moving the PHY component out into 
drivers/phy where it belongs - completely transparently to user-space. 
So we already have a dependency in user-space which needs to be maintained.

The concrete hardware benefits, as I alluded to Neil, are:

- Per-PHY voltage rails
- Per-PHY power domains
- Per-PHY operating points (OPPs)

Those are real-world hardware fixes which "just work" as a result of 
dedicated device nodes and a driver specifically written to relieve the 
technical debt we've been accruing with the existing model, for years.

Having been educated - brought to the realisation on OPPS, Power-domains 
and yes voltage rails it is amazing to me this whole legacy system 
hasn't exploded before now but, its certainly way past time to fix it.

We should proceed with moving init sequences, voltages, PDs and OPPs to 
drivers/phy.

I'm happy to have a debate about the status of the PHY media device 
after, however I have to say I'm skeptical about removing the media 
device - something we could do whether the init sequences live in 
drivers/media/qcom/camss or in drivers/phy BTW - I'm skeptical about 
removing that v4l2 node specifically because we've had it in user-space 
for a long time and I do therefore think that constitutes an ABI.

As I've said already though `rm -rf /dev/v4l2-subdev::msm_csiphy*" is 
basically an entirely separate debate.

---
bod

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox