On Wed, Feb 19, 2025 at 3:30 PM Bartosz Golaszewski [off-list ref] wrote:

On Wed, Feb 19, 2025 at 3:27 PM Mark Brown [off-list ref] wrote:

quoted

On Wed, Feb 19, 2025 at 11:27:50AM +0100, Bartosz Golaszewski wrote:

quoted

From: Bartosz Golaszewski <redacted>

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)

Do you want to send a non-RFC/RFT version or should I just apply it?

Yours,
Linus Walleij