This series is an RFC for adding port-mapped I/O (PMIO) support to
gpio-mmio.

This v2 comes with all suggestions done by Linux Walleij in the
initial review [1].

For keeping compatibility with gpio_generic_chip, a new _config struct
was added instead of extending gpio_generic_chip_config. Using such new
_config struct, called gpio_generic_chip_port_config, requires a new API
function gpio_generic_chip_port_init() to access to that new structure.

Besides, structure gpio_chip_reg has been transformed to union. It reflects
better that MMIO and PMIO chips will only use one of them, saving memory
as well.

I'm still sending this as RFC but I don't know if I should send this as a
regular PATCH series.

[1] https://lore.kernel.org/linux-gpio/20260407184805.807328-1-dev-josejavier.rodriguez@duagon.com

---
Changes in v2:
    - Move struct gpio_chip_reg to union gpio_chip_reg.
    - Add a new gpio-mmio API function to init PMIO generic chips.

Jose Javier Rodriguez Barbarin (3):
  gpio: mmio: convert accessors to generic register descriptors
  gpio: mmio: add port-mapped read/write callbacks
  gpio: mmio: add port-mapped support for gpio_generic_chip

 drivers/gpio/gpio-mmio.c     | 330 ++++++++++++++++++++++++-----------
 include/linux/gpio/generic.h |  78 ++++++++-
 2 files changed, 300 insertions(+), 108 deletions(-)

-- 
2.53.0

On Mon, Apr 13, 2026 at 12:24 PM Jose Javier Rodriguez Barbarin
<dev-josejavier.rodriguez@duagon.com> wrote:

> This series is an RFC for adding port-mapped I/O (PMIO) support to
> gpio-mmio.
>
> This v2 comes with all suggestions done by Linux Walleij in the
> initial review [1].

That name! ;)

> For keeping compatibility with gpio_generic_chip, a new _config struct
> was added instead of extending gpio_generic_chip_config. Using such new
> _config struct, called gpio_generic_chip_port_config, requires a new API
> function gpio_generic_chip_port_init() to access to that new structure.
>
> Besides, structure gpio_chip_reg has been transformed to union. It reflects
> better that MMIO and PMIO chips will only use one of them, saving memory
> as well.
>
> I'm still sending this as RFC but I don't know if I should send this as a
> regular PATCH series.

I think we will usually only merge infrastructure if there is also a
consumer/user of it going in at the same time so these patches will
need to be prepended to a driver patch.

Yours,
Linus Walleij

On Wed, Apr 22, 2026 at 06:44:37PM +0200, Linus Walleij wrote:
> On Mon, Apr 13, 2026 at 12:24 PM Jose Javier Rodriguez Barbarin
> <dev-josejavier.rodriguez@duagon.com> wrote:
>
> > This series is an RFC for adding port-mapped I/O (PMIO) support to
> > gpio-mmio.
> >
> > This v2 comes with all suggestions done by Linux Walleij in the
> > initial review [1].
>
> That name! ;)

Oh, I'm so sorry. :'(

>
> > For keeping compatibility with gpio_generic_chip, a new _config struct
> > was added instead of extending gpio_generic_chip_config. Using such new
> > _config struct, called gpio_generic_chip_port_config, requires a new API
> > function gpio_generic_chip_port_init() to access to that new structure.
> >
> > Besides, structure gpio_chip_reg has been transformed to union. It reflects
> > better that MMIO and PMIO chips will only use one of them, saving memory
> > as well.
> >
> > I'm still sending this as RFC but I don't know if I should send this as a
> > regular PATCH series.
>
> I think we will usually only merge infrastructure if there is also a
> consumer/user of it going in at the same time so these patches will
> need to be prepended to a driver patch.

Thank you so much. So, as far as I understand, my patches will be applied
once one or more drivers use those changes, isn't it?

All this started because I tried to provide I/O port support to gpio-menz127
however to apply those changes I have to add other changes on drivers/mcb
first. I'm currently working on it.

I'm aware there are still few I/O port-mapped I/O drivers so I would like
to continue with the TODO "task", trying to move those drivers to use this.

>
> Yours,
> Linus Walleij

Regards,

Javier R.

On Thu, Apr 23, 2026 at 5:14 PM Jose Javier Rodriguez Barbarin
<dev-josejavier.rodriguez@duagon.com> wrote:

> > I think we will usually only merge infrastructure if there is also a
> > consumer/user of it going in at the same time so these patches will
> > need to be prepended to a driver patch.
>
> Thank you so much. So, as far as I understand, my patches will be applied
> once one or more drivers use those changes, isn't it?

Yeah just put some driver patch last in the series so we see "OK it's
being used, looks good" and we (Bart) will merge it.

Yours,
Linus Walleij

On Thu, Apr 23, 2026 at 5:14 PM Jose Javier Rodriguez Barbarin
<dev-josejavier.rodriguez@duagon.com> wrote:
>
> >
> > I think we will usually only merge infrastructure if there is also a
> > consumer/user of it going in at the same time so these patches will
> > need to be prepended to a driver patch.
>
> Thank you so much. So, as far as I understand, my patches will be applied
> once one or more drivers use those changes, isn't it?
>

More precisely: we can consider picking it up once you post a patch
that uses it proving that it's worth having it upstream.

> All this started because I tried to provide I/O port support to gpio-menz127
> however to apply those changes I have to add other changes on drivers/mcb
> first. I'm currently working on it.
>
> I'm aware there are still few I/O port-mapped I/O drivers so I would like
> to continue with the TODO "task", trying to move those drivers to use this.
>

Bart

On Wed, Apr 22, 2026 at 6:44 PM Linus Walleij <linusw@kernel.org> wrote:
>
> On Mon, Apr 13, 2026 at 12:24 PM Jose Javier Rodriguez Barbarin
> <dev-josejavier.rodriguez@duagon.com> wrote:
>
> > This series is an RFC for adding port-mapped I/O (PMIO) support to
> > gpio-mmio.
> >
> > This v2 comes with all suggestions done by Linux Walleij in the
> > initial review [1].
>
> That name! ;)
>
> > For keeping compatibility with gpio_generic_chip, a new _config struct
> > was added instead of extending gpio_generic_chip_config. Using such new
> > _config struct, called gpio_generic_chip_port_config, requires a new API
> > function gpio_generic_chip_port_init() to access to that new structure.
> >
> > Besides, structure gpio_chip_reg has been transformed to union. It reflects
> > better that MMIO and PMIO chips will only use one of them, saving memory
> > as well.
> >
> > I'm still sending this as RFC but I don't know if I should send this as a
> > regular PATCH series.
>
> I think we will usually only merge infrastructure if there is also a
> consumer/user of it going in at the same time so these patches will
> need to be prepended to a driver patch.
>

Agreed. If the driver in question is not targetting drivers/gpio/, I
can provide an immutable branch with these patches.

Bart