Re: [PATCH net v1 1/1] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO
Jakub Kicinski <[email protected]>
| Newsgroups | org.kernel.vger.stable,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> > > > > 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?