Hi Linus,

Am Freitag, 16. Oktober 2026, 11:07:48 Mitteleuropäische Sommerzeit schrieb 
Linus Walleij:
> I don't believe that the hardware block inside the SoC actually
> has a single inverted direction bit. Prove it 😀
> 
> This sounds much more like someone using open drain to drive
> the line high when setting it to input mode and has hacked
> their way around that behaviour instead of just asking the
> GPIOlib core to do the right thing:
> 
> gpios = <&gpio 0 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;

I read up a bit on open drain configurations and I can't rule out your theory, 
but I think it is unlikely. The following is from memory of my testing two 
months ago or so:

On all GPIOs of my zx29 board except GPIO 24, direction=1 means output, 
direction=0 means input.

For GPIO 24, if I set direction=1 and use the pull-up or pull-down, I can read 
back the bias state via the GPIO input register. The GPIO output register is 
ignored. So it is behaving very input-y. Bias on this gpio defaults to no 
bias. Both pull-down (reads 0) and pull-up (reads 1) work that way.

With direction=0, the gpio output gets read back on the gpio input regardless 
of bias. I.e. the GPIO overpowers the bias as it should for output.

The GPIO in question is used to keep the device enabled when running on 
battery. ZTE's code calls it "PSHOLD". My best guess is that they wired it up 
in that way so that the default hardware state, direction=0, value=0, drives 
it low and shuts off the device unless the software takes action to keep the 
device powered. The practical outcome is that the user has to hold the power 
button for ~1 second until ZTE's U-Boot sets direction=0, value=1 to keep the 
device running.

Do you have any other ideas I could try?

I do need GPIO 27 or so for the SPI display D/C pin, which sits in the same 
byte, so I can't just declare GPIO 24 with a "dirin" reg.

> It does sounds a bit like churn if we remove a driver from the kernel
> and then add it back after some years...
> 
> However if this is using GENERIC_GPIO (regmap is something else)
> this is a better base.
> 
> I think it's easy for an LLM to port over the IRQ support from the
> old driver to this new one, given the code is already there and
> this way keep the best of both worlds?

You probably mean GPIO_GENERIC, which afaiu is implemented in gpio-mmio.c. 
That's what I am actually using (I guess I confused this with gpio-regmap in 
my previous email). But my hardware (unlike Navid's) has no GPIO IRQs.

(The SoC kinda has GPIO IRQs, but those are handled via pinmux. A few lines 
can be connected to the GIC, bypassing GPIO entirely)