[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <031ca485-4320-4754-a5bc-21f01abb54dc@gmx.net>
Date: Wed, 19 Feb 2025 16:46:45 +0100
From: Stefan Wahren <wahrenst@....net>
To: Bartosz Golaszewski <brgl@...ev.pl>,
Linus Walleij <linus.walleij@...aro.org>,
Florian Fainelli <florian.fainelli@...adcom.com>, Ray Jui
<rjui@...adcom.com>, Scott Branden <sbranden@...adcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>, Liao Chen <liaochen4@...wei.com>,
Chen-Yu Tsai <wens@...e.org>, Mark Brown <broonie@...nel.org>,
Marek Szyprowski <m.szyprowski@...sung.com>
Cc: linux-gpio@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [RFC/RFT PATCH] pinctrl: bcm2835: don't -EINVAL on alternate
funcs from get_direction()
Am 19.02.25 um 11:27 schrieb Bartosz Golaszewski:
> From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
>
> 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.
>
> Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()")
> Reported-by: Mark Brown <broonie@...nel.org>
> Closes: https://lore.kernel.org/all/Z7VFB1nST6lbmBIo@finisterre.sirena.org.uk/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Reviewed-by: Stefan Wahren <wahrenst@....net>
Thanks
Powered by blists - more mailing lists