On Wed, Feb 19, 2025 at 9:38 AM Marek Szyprowski m.szyprowski@samsung.com wrote:
Hi Bartosz,
On 10.02.2025 11:51, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski bartosz.golaszewski@linaro.org
As per the API contract - gpio_chip::get_direction() may fail and return a negative error number. However, we treat it as if it always returned 0 or 1. Check the return value of the callback and propagate the error number up the stack.
This change breaks bcm2835 pincontrol/gpio driver (and probably others) in next-20250218. The problem is that some gpio lines are initially configured as alternate function (i.e. uart) and .get_direction returns -EINVAL for them, what in turn causes the whole gpio chip fail to register. Here is the log with WARN_ON() added to line drivers/pinctrl/bcm/pinctrl-bcm2835.c:350 from Raspberry Pi 4B:
Any suggestions how to fix this issue? Should we add GPIO_LINE_DIRECTION_UNKNOWN?
That would be quite an intrusive change and not something for the middle of the release cycle. I think we need to revert to the previous behavior for this particular use-case: check ret for EINVAL and assume it means input as it's the "safe" setting. Now the question is - can this only happen during the chip registration or should we filter out EINVAL at each gpiod_get_direction() call?
Bart