It's strongly recommended for GPIO drivers to always implement the
.get_direction() callback - even for fixed-direction controllers.

GPIO core will even emit a warning if the callback is missing, when
users try to read the direction of a pin.

Implement .get_direction() for gpio-davinci.

Reported-by: Michael Walle <mwalle@kernel.org>
Closes: https://lore.kernel.org/all/DFJAFK3DTBOZ.3G2P3A5IH34GF@kernel.org/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
I sent v1 too fast and forgot to Cc Keerthy. Sorry for the noise.

Changes in v2:
- use unsigned int instead of unsigned
- Cc davinci-gpio maintainer

 drivers/gpio/gpio-davinci.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 538f27209ce7..97780f27ce5b 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -6,6 +6,7 @@
  * Copyright (c) 2007, MontaVista Software, Inc. <source@mvista.com>
  */
 
+#include <linux/cleanup.h>
 #include <linux/gpio/driver.h>
 #include <linux/errno.h>
 #include <linux/kernel.h>
@@ -109,6 +110,22 @@ davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 	return __davinci_direction(chip, offset, true, value);
 }
 
+static int davinci_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+	struct davinci_gpio_controller *d = gpiochip_get_data(chip);
+	struct davinci_gpio_regs __iomem *g;
+	u32 mask = __gpio_mask(offset), val;
+	int bank = offset / 32;
+
+	g = d->regs[bank];
+
+	guard(spinlock_irqsave)(&d->lock);
+
+	val = readl_relaxed(&g->dir);
+
+	return (val & mask) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT;
+}
+
 /*
  * Read the pin's value (works even if it's set up as output);
  * returns zero/nonzero.
@@ -203,6 +220,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
 	chips->chip.get = davinci_gpio_get;
 	chips->chip.direction_output = davinci_direction_out;
 	chips->chip.set = davinci_gpio_set;
+	chips->chip.get_direction = davinci_get_direction;
 
 	chips->chip.ngpio = ngpio;
 	chips->chip.base = -1;
-- 
2.47.3

On Fri, 09 Jan 2026 14:08:32 +0100, Bartosz Golaszewski wrote:
> It's strongly recommended for GPIO drivers to always implement the
> .get_direction() callback - even for fixed-direction controllers.
> 
> GPIO core will even emit a warning if the callback is missing, when
> users try to read the direction of a pin.
> 
> Implement .get_direction() for gpio-davinci.
> 
> [...]

Applied, thanks!

[1/1] gpio: davinci: implement .get_direction()
      commit: c18790018799155e58d5a11c6697f9c398bf8b60

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

On Fri, Jan 9, 2026 at 2:08 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:

> It's strongly recommended for GPIO drivers to always implement the
> .get_direction() callback - even for fixed-direction controllers.
>
> GPIO core will even emit a warning if the callback is missing, when
> users try to read the direction of a pin.
>
> Implement .get_direction() for gpio-davinci.
>
> Reported-by: Michael Walle <mwalle@kernel.org>
> Closes: https://lore.kernel.org/all/DFJAFK3DTBOZ.3G2P3A5IH34GF@kernel.org/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij

Hi,

On Fri Jan 9, 2026 at 2:08 PM CET, Bartosz Golaszewski wrote:
> It's strongly recommended for GPIO drivers to always implement the
> .get_direction() callback - even for fixed-direction controllers.
>
> GPIO core will even emit a warning if the callback is missing, when
> users try to read the direction of a pin.
>
> Implement .get_direction() for gpio-davinci.

I must be blind! I didn't see the direction register and I assumed
that the direction is fixed and only known by the pinctrl (as on k3
SoCs, you have to hardcode the directions of GPIOs in the device
tree.

Thanks for taking care.

> Reported-by: Michael Walle <mwalle@kernel.org>
> Closes: https://lore.kernel.org/all/DFJAFK3DTBOZ.3G2P3A5IH34GF@kernel.org/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

This will need a

Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support")

Otherwise the sa67 board will be broken with the defconfig (or any
config enabled ARCH_QCOM).

Tested-by: Michael Walle <mwalle@kernel.org> # on sa67

-michael

On Fri, Jan 9, 2026 at 3:12 PM Michael Walle <mwalle@kernel.org> wrote:
>
> Hi,
>
> On Fri Jan 9, 2026 at 2:08 PM CET, Bartosz Golaszewski wrote:
> > It's strongly recommended for GPIO drivers to always implement the
> > .get_direction() callback - even for fixed-direction controllers.
> >
> > GPIO core will even emit a warning if the callback is missing, when
> > users try to read the direction of a pin.
> >
> > Implement .get_direction() for gpio-davinci.
>
> I must be blind! I didn't see the direction register and I assumed
> that the direction is fixed and only known by the pinctrl (as on k3
> SoCs, you have to hardcode the directions of GPIOs in the device
> tree.
>
> Thanks for taking care.
>
> > Reported-by: Michael Walle <mwalle@kernel.org>
> > Closes: https://lore.kernel.org/all/DFJAFK3DTBOZ.3G2P3A5IH34GF@kernel.org/
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
> This will need a
>
> Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support")
>
> Otherwise the sa67 board will be broken with the defconfig (or any
> config enabled ARCH_QCOM).
>

Can you confirm, you're still seeing the issue with:

    https://lore.kernel.org/all/20260108-gpio-shared-false-positive-v1-1-5dbf8d1b2f7d@oss.qualcomm.com/

?

Bartosz

> Tested-by: Michael Walle <mwalle@kernel.org> # on sa67
>
> -michael

>> This will need a
>>
>> Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support")
>>
>> Otherwise the sa67 board will be broken with the defconfig (or any
>> config enabled ARCH_QCOM).
>>
>
> Can you confirm, you're still seeing the issue with:
>
>     https://lore.kernel.org/all/20260108-gpio-shared-false-positive-v1-1-5dbf8d1b2f7d@oss.qualcomm.com/

Yes, latest next, with that patch applied, still causes the same
issue. I don't think it's a false positive as the same gpio is used
as enable for two different regulators :)

-michael

On Fri, Jan 9, 2026 at 3:48 PM Michael Walle <mwalle@kernel.org> wrote:
>
> >> This will need a
> >>
> >> Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support")
> >>
> >> Otherwise the sa67 board will be broken with the defconfig (or any
> >> config enabled ARCH_QCOM).
> >>
> >
> > Can you confirm, you're still seeing the issue with:
> >
> >     https://lore.kernel.org/all/20260108-gpio-shared-false-positive-v1-1-5dbf8d1b2f7d@oss.qualcomm.com/
>
> Yes, latest next, with that patch applied, still causes the same
> issue. I don't think it's a false positive as the same gpio is used
> as enable for two different regulators :)
>

Yes, I responded under the other thread. Let's add Fixes: and use this
as the solution?

Bart

On Fri Jan 9, 2026 at 3:51 PM CET, Bartosz Golaszewski wrote:
> On Fri, Jan 9, 2026 at 3:48 PM Michael Walle <mwalle@kernel.org> wrote:
>>
>> >> This will need a
>> >>
>> >> Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support")
>> >>
>> >> Otherwise the sa67 board will be broken with the defconfig (or any
>> >> config enabled ARCH_QCOM).
>> >>
>> >
>> > Can you confirm, you're still seeing the issue with:
>> >
>> >     https://lore.kernel.org/all/20260108-gpio-shared-false-positive-v1-1-5dbf8d1b2f7d@oss.qualcomm.com/
>>
>> Yes, latest next, with that patch applied, still causes the same
>> issue. I don't think it's a false positive as the same gpio is used
>> as enable for two different regulators :)
>>
>
> Yes, I responded under the other thread. Let's add Fixes: and use this
> as the solution?

Was just about to reply to the other thread, but lets keep it here:

Yes please, that will work for me.

Thanks,
-michael