On Wed, Nov 16, 2022 at 11:21:37AM +0100, Thierry Reding wrote: > On Mon, Nov 14, 2022 at 03:29:43PM -0500, Brian Masney wrote: > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > > index 11fb7ec883e9..8bec66008869 100644 > > --- a/drivers/gpio/gpiolib.c > > +++ b/drivers/gpio/gpiolib.c > > @@ -678,7 +678,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data, > > * Assign fwnode depending on the result of the previous calls, > > * if none of them succeed, assign it to the parent's one. > > */ > > - gdev->dev.fwnode = dev_fwnode(&gdev->dev) ?: fwnode; > > + gc->fwnode = gdev->dev.fwnode = dev_fwnode(&gdev->dev) ?: fwnode; > > This doesn't look right to me. Looking at the documentation of > gc->fwnode and how it is used, the purpose of this is to allow > explicitly overriding the fwnode that the GPIO chip will use. > > So really this should not be used beyond the initial registration > in gpiochip_add_data_with_key(). If the above patch fixes anything, > then I suspect somebody is using gc->fwnode outside of this > registration. > > Looking at gpiolib, the only remaining place that seems to do this is > the gpio-reserved-ranges handling code, in which case, the below on top > of my initial patch might fix that. That might explain why MSM is still > seeing issues. That is correct. The Thinkpad x13s laptop uses the driver drivers/pinctrl/qcom/pinctrl-sc8280xp.c and arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts defines a gpio-reserved-ranges property. The SA8540p automotive board has the same SoC, however the DTS we are using doesn't use the gpio-reserved-ranges property, and why only your original patch fixed the issue for this board. I think my patch should be removed from the GPIO tree if Thierry's two patches work for everyone. Brian
