On Wed, Feb 19, 2025 at 9:38 AM Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > > Hi Bartosz, > > On 10.02.2025 11:51, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > 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