The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO
@ 2026-08-14 11:01 Oleksij Rempel
  2026-08-14 11:46 ` Alvin Šipraga
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Oleksij Rempel @ 2026-08-14 11:01 UTC (permalink / raw)
  To: Linus Walleij, Luiz Angelo Daros de Luca, Andrew Lunn,
	Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni
  Cc: Ahmad Fatoum, stable, Oleksij Rempel, kernel, linux-kernel,
	Alvin Šipraga, netdev

From: Ahmad Fatoum <a.fatoum@pengutronix.de>

rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
the probe path, which may sleep and is not timing-critical.  When the
reset GPIO is provided by a sleeping controller such as an I2C I/O
expander, gpiod_set_value() warns:

  WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61
  Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT)
  Workqueue: events_unbound deferred_probe_work_func
  pc : gpiod_set_value+0x44/0x80
  lr : rtl83xx_probe+0x1d8/0x3a0
  Call trace:
   gpiod_set_value+0x44/0x80 (P)
   rtl83xx_probe+0x1d8/0x3a0
   realtek_mdio_probe+0x24/0xa0
   mdio_probe+0x38/0x78
   really_probe+0xc4/0x3e0
   __driver_probe_device+0x15c/0x1b8
   driver_probe_device+0xb4/0x120
   __device_attach_driver+0xb8/0x1a0
   bus_for_each_drv+0x88/0xf0
   __device_attach+0xa0/0x1d8
   device_initial_probe+0x54/0x68
   bus_probe_device+0x38/0xa0
   deferred_probe_work_func+0xb8/0x120
   process_one_work+0x184/0x4e8
   worker_thread+0x188/0x308
   kthread+0x130/0x150
   ret_from_fork+0x10/0x20

Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
be used without triggering the warning.

The reset GPIO has been driven with the non-sleeping gpiod_set_value()
since the driver was added in v4.19.  The call has since been refactored
across several files - from realtek-smi.c / realtek-mdio.c into the common
rtl83xx.c module and then into the rtl83xx_reset_assert() and
rtl83xx_reset_deassert() helpers (both in v6.9).  This patch therefore
applies as-is only to kernels that carry those helpers (v6.9+); older
stable kernels need the same gpiod_set_value_cansleep() conversion at the
corresponding open-coded call sites.

Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver")
Cc: <stable@vger.kernel.org> # 6.9.x
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
 drivers/net/dsa/realtek/rtl83xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/realtek/rtl83xx.c b/drivers/net/dsa/realtek/rtl83xx.c
index 09fd64880232..8121ec12fd8b 100644
--- a/drivers/net/dsa/realtek/rtl83xx.c
+++ b/drivers/net/dsa/realtek/rtl83xx.c
@@ -334,7 +334,7 @@ void rtl83xx_reset_assert(struct realtek_priv *priv)
 			 "Failed to assert the switch reset control: %pe\n",
 			 ERR_PTR(ret));
 
-	gpiod_set_value(priv->reset, true);
+	gpiod_set_value_cansleep(priv->reset, true);
 }
 
 void rtl83xx_reset_deassert(struct realtek_priv *priv)
@@ -347,7 +347,7 @@ void rtl83xx_reset_deassert(struct realtek_priv *priv)
 			 "Failed to deassert the switch reset control: %pe\n",
 			 ERR_PTR(ret));
 
-	gpiod_set_value(priv->reset, false);
+	gpiod_set_value_cansleep(priv->reset, false);
 }
 
 /**
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO
  2026-08-14 11:01 [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO Oleksij Rempel
@ 2026-08-14 11:46 ` Alvin Šipraga
  2026-08-14 14:09 ` Andrew Lunn
  2026-08-14 20:06 ` Linus Walleij
  2 siblings, 0 replies; 5+ messages in thread
From: Alvin Šipraga @ 2026-08-14 11:46 UTC (permalink / raw)
  To: Oleksij Rempel
  Cc: Linus Walleij, Luiz Angelo Daros de Luca, Andrew Lunn,
	Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Ahmad Fatoum, stable, kernel, linux-kernel, netdev

On Fri, Aug 14, 2026 at 01:01:02PM +0200, Oleksij Rempel wrote:
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> 
> rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
> the probe path, which may sleep and is not timing-critical.  When the
> reset GPIO is provided by a sleeping controller such as an I2C I/O
> expander, gpiod_set_value() warns:
> 
>   WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61
>   Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT)
>   Workqueue: events_unbound deferred_probe_work_func
>   pc : gpiod_set_value+0x44/0x80
>   lr : rtl83xx_probe+0x1d8/0x3a0
>   Call trace:
>    gpiod_set_value+0x44/0x80 (P)
>    rtl83xx_probe+0x1d8/0x3a0
>    realtek_mdio_probe+0x24/0xa0
>    mdio_probe+0x38/0x78
>    really_probe+0xc4/0x3e0
>    __driver_probe_device+0x15c/0x1b8
>    driver_probe_device+0xb4/0x120
>    __device_attach_driver+0xb8/0x1a0
>    bus_for_each_drv+0x88/0xf0
>    __device_attach+0xa0/0x1d8
>    device_initial_probe+0x54/0x68
>    bus_probe_device+0x38/0xa0
>    deferred_probe_work_func+0xb8/0x120
>    process_one_work+0x184/0x4e8
>    worker_thread+0x188/0x308
>    kthread+0x130/0x150
>    ret_from_fork+0x10/0x20
> 
> Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
> be used without triggering the warning.
> 
> The reset GPIO has been driven with the non-sleeping gpiod_set_value()
> since the driver was added in v4.19.  The call has since been refactored
> across several files - from realtek-smi.c / realtek-mdio.c into the common
> rtl83xx.c module and then into the rtl83xx_reset_assert() and
> rtl83xx_reset_deassert() helpers (both in v6.9).  This patch therefore
> applies as-is only to kernels that carry those helpers (v6.9+); older
> stable kernels need the same gpiod_set_value_cansleep() conversion at the
> corresponding open-coded call sites.
> 
> Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver")
> Cc: <stable@vger.kernel.org> # 6.9.x
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
>  drivers/net/dsa/realtek/rtl83xx.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Alvin Šipraga <alvin.sipraga@analog.com>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO
  2026-08-14 11:01 [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO Oleksij Rempel
  2026-08-14 11:46 ` Alvin Šipraga
@ 2026-08-14 14:09 ` Andrew Lunn
  2026-08-14 17:00   ` Jakub Kicinski
  2026-08-14 20:06 ` Linus Walleij
  2 siblings, 1 reply; 5+ messages in thread
From: Andrew Lunn @ 2026-08-14 14:09 UTC (permalink / raw)
  To: Oleksij Rempel
  Cc: Linus Walleij, Luiz Angelo Daros de Luca, Vladimir Oltean,
	David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Ahmad Fatoum, stable, kernel, linux-kernel, Alvin Šipraga,
	netdev

On Fri, Aug 14, 2026 at 01:01:02PM +0200, Oleksij Rempel wrote:
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> 
> rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
> the probe path, which may sleep and is not timing-critical.  When the
> reset GPIO is provided by a sleeping controller such as an I2C I/O
> expander, gpiod_set_value() warns:
> 
> Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
> be used without triggering the warning.
> 
> The reset GPIO has been driven with the non-sleeping gpiod_set_value()
> since the driver was added in v4.19.  The call has since been refactored
> across several files - from realtek-smi.c / realtek-mdio.c into the common
> rtl83xx.c module and then into the rtl83xx_reset_assert() and
> rtl83xx_reset_deassert() helpers (both in v6.9).  This patch therefore
> applies as-is only to kernels that carry those helpers (v6.9+); older
> stable kernels need the same gpiod_set_value_cansleep() conversion at the
> corresponding open-coded call sites.

This is one of those fuzzy cases. It never worked, so this is not a
regression. Nobody has needed it up until now. So it probably should
be considered a new feature, and merged via net-next.

   Andrew

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO
  2026-08-14 14:09 ` Andrew Lunn
@ 2026-08-14 17:00   ` Jakub Kicinski
  0 siblings, 0 replies; 5+ messages in thread
From: Jakub Kicinski @ 2026-08-14 17:00 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Oleksij Rempel, Linus Walleij, Luiz Angelo Daros de Luca,
	Vladimir Oltean, David S. Miller, Eric Dumazet, Paolo Abeni,
	Ahmad Fatoum, stable, kernel, linux-kernel, Alvin Šipraga,
	netdev

On Fri, 14 Aug 2026 16:09:04 +0200 Andrew Lunn wrote:
> On Fri, Aug 14, 2026 at 01:01:02PM +0200, Oleksij Rempel wrote:
> > From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> > 
> > rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
> > the probe path, which may sleep and is not timing-critical.  When the
> > reset GPIO is provided by a sleeping controller such as an I2C I/O
> > expander, gpiod_set_value() warns:
> > 
> > Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
> > be used without triggering the warning.
> > 
> > The reset GPIO has been driven with the non-sleeping gpiod_set_value()
> > since the driver was added in v4.19.  The call has since been refactored
> > across several files - from realtek-smi.c / realtek-mdio.c into the common
> > rtl83xx.c module and then into the rtl83xx_reset_assert() and
> > rtl83xx_reset_deassert() helpers (both in v6.9).  This patch therefore
> > applies as-is only to kernels that carry those helpers (v6.9+); older
> > stable kernels need the same gpiod_set_value_cansleep() conversion at the
> > corresponding open-coded call sites.  
> 
> This is one of those fuzzy cases. It never worked, so this is not a
> regression. Nobody has needed it up until now. So it probably should
> be considered a new feature, and merged via net-next.

Sounds like it's a false positive, but it's a WARN, so if it hits on
real platforms -- I think it's a real fix?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO
  2026-08-14 11:01 [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO Oleksij Rempel
  2026-08-14 11:46 ` Alvin Šipraga
  2026-08-14 14:09 ` Andrew Lunn
@ 2026-08-14 20:06 ` Linus Walleij
  2 siblings, 0 replies; 5+ messages in thread
From: Linus Walleij @ 2026-08-14 20:06 UTC (permalink / raw)
  To: Oleksij Rempel
  Cc: Luiz Angelo Daros de Luca, Andrew Lunn, Vladimir Oltean,
	David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Ahmad Fatoum, stable, kernel, linux-kernel, Alvin Šipraga,
	netdev

On Fri, Aug 14, 2026 at 1:01 PM Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>
> rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
> the probe path, which may sleep and is not timing-critical.  When the
> reset GPIO is provided by a sleeping controller such as an I2C I/O
> expander, gpiod_set_value() warns:
>
>   WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61
>   Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT)
>   Workqueue: events_unbound deferred_probe_work_func
>   pc : gpiod_set_value+0x44/0x80
>   lr : rtl83xx_probe+0x1d8/0x3a0
>   Call trace:
>    gpiod_set_value+0x44/0x80 (P)
>    rtl83xx_probe+0x1d8/0x3a0
>    realtek_mdio_probe+0x24/0xa0
>    mdio_probe+0x38/0x78
>    really_probe+0xc4/0x3e0
>    __driver_probe_device+0x15c/0x1b8
>    driver_probe_device+0xb4/0x120
>    __device_attach_driver+0xb8/0x1a0
>    bus_for_each_drv+0x88/0xf0
>    __device_attach+0xa0/0x1d8
>    device_initial_probe+0x54/0x68
>    bus_probe_device+0x38/0xa0
>    deferred_probe_work_func+0xb8/0x120
>    process_one_work+0x184/0x4e8
>    worker_thread+0x188/0x308
>    kthread+0x130/0x150
>    ret_from_fork+0x10/0x20
>
> Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
> be used without triggering the warning.
>
> The reset GPIO has been driven with the non-sleeping gpiod_set_value()
> since the driver was added in v4.19.  The call has since been refactored
> across several files - from realtek-smi.c / realtek-mdio.c into the common
> rtl83xx.c module and then into the rtl83xx_reset_assert() and
> rtl83xx_reset_deassert() helpers (both in v6.9).  This patch therefore
> applies as-is only to kernels that carry those helpers (v6.9+); older
> stable kernels need the same gpiod_set_value_cansleep() conversion at the
> corresponding open-coded call sites.
>
> Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver")
> Cc: <stable@vger.kernel.org> # 6.9.x
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>

Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-08-14 20:06 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-14 11:01 [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO Oleksij Rempel
2026-08-14 11:46 ` Alvin Šipraga
2026-08-14 14:09 ` Andrew Lunn
2026-08-14 17:00   ` Jakub Kicinski
2026-08-14 20:06 ` Linus Walleij

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