Re: [PATCH 09/24] gpio: Add ZTE ZX279128S GPIO driver

[Linus Walleij]

On Sun, Oct 11, 2026 at 2:13 PM Stefan Dösinger
<stefandoesinger@xxxxxxxxx> wrote:
> Am Samstag, 10. Oktober 2026, 14:59:47 Mitteleuropäische Sommerzeit schrieben
> Sie:
> > +/*
> > + * Each bank has 16 lines, one bit per line in each register. The registers
> > + * at 0x04-0x10 and 0x28-0x34 control the interrupts, which are not
> > supported + * yet.
> > + */
> > +#define ZX279128S_GPIO_DIR   0x00    /* 1: output */
> > +#define ZX279128S_GPIO_DATA  0x14    /* line level */
> > +#define ZX279128S_GPIO_SET   0x18    /* write 1: drive high */
> > +#define ZX279128S_GPIO_CLEAR 0x1c    /* write 1: drive low */
>
> This looks identical to mine, which itself matches the old zx29 GPIO driver
> with IRQ support etc that was removed in 89d4f98ae90d ("ARM: remove zte  zx
> platform"). This old driver had support for IRQs.
>
> My hardware has the same register layout, but no IRQ support (related
> registers are always 0). So I wasn't planning on reviving the old driver and
> just using regmap-gpio like you do here. If your hardware has indeed working
> GPIO IRQs it would make sense to revive the old driver.

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?

> My hardware has one annoyance: There is one GPIO line (not one block of 16,
> just one single line) that has an inverted direction bit - and this line is
> necessary to run the routers on battery. I don't yet know what the nicest way
> to deal with this is. If we have a good reason to have our own zx gpio driver
> then life would be easier :-)

I don't believe that the hardware block inside the SoC actually
has a single inverted direction bit. Prove it :D

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)>;

Yours,
Linus Walleij