On Thu, Feb 27, 2025 at 11:53 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Wed, Feb 19, 2025 at 3:30 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > On Wed, Feb 19, 2025 at 3:27 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > > > On Wed, Feb 19, 2025 at 11:27:50AM +0100, Bartosz Golaszewski wrote: > > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > > > > > Since commit 9d846b1aebbe ("gpiolib: check the return value of > > > > gpio_chip::get_direction()") we check the return value of the > > > > get_direction() callback as per its API contract. This driver returns > > > > -EINVAL if the pin in question is set to one of the alternative > > > > (non-GPIO) functions. This isn't really an error that should be > > > > communicated to GPIOLIB so default to returning the "safe" value of > > > > INPUT in this case. The GPIO subsystem does not have the notion of > > > > "unknown" direction. > > > > > > I see this was already tested for these specific boards. I've also > > > found that Avenger96 is failing with bisect pointing to the same commit > > > this is fixing: > > > > > > https://lava.sirena.org.uk/scheduler/job/1126314 > > > > > > as is the Libretech Potato: > > > > > > https://lava.sirena.org.uk/scheduler/job/1126285 > > > > > > neither of which produce any output before dying, they'll not be fixed > > > by this change. Seems like an audit of the drivers might be in order? > > > > Right. I don't know if they return EINVAL or some other error so let > > me prepare a change that will not bail-out but simply warn on > > get_direction() errors in gpiochip_add_data() instead. > > > > This patch can still go upstream IMO. > > I'm fine to apply it, maybe as non-urgent fix at this point? (for -next) > Yes, the offending changes in gpiolib.c were dropped so this can go in the non-urgent way. > Do you want to send a non-RFC/RFT version or should I just apply it? > You can take it as is. It got tested and reviewed, so the tags served their purpose. :) Bart