Re: [RFC PATCH] pinctrl: sunxi: convert to GPIO_GENERIC

[Andre Przywara <andre.przywara@arm.com>]

Hi Bartosz, Linus,

so I wanted to come back to this, posting a A733 v2, with this patch 
included, and was wondering what the consensus on this matter would be?

...

On 3/16/26 09:57, Bartosz Golaszewski wrote:
> On Sun, 15 Mar 2026 01:42:05 +0100, Andre Przywara
> <andre.przywara@arm.com> said:
>> On Sat, 14 Mar 2026 13:14:25 +0800
>> Icenowy Zheng <uwu@icenowy.me> wrote:
>>
>>> 在 2026-03-13五的 01:06 +0100，Andre Przywara写道：
>>>> Allwinner SoCs combine pinmuxing and GPIO control in one device/MMIO
>>>> register frame. So far we were instantiating one GPIO chip per
>>>> pinctrl
>>>> device, which covers multiple banks of up to 32 GPIO pins per bank.
>>>> The
>>>> GPIO numbers were set to match the absolute pin numbers, even across
>>>> the
>>>> typically two instances of the pinctrl device.
>>>>
>>>> Convert the GPIO part of the sunxi pinctrl over to use the
>>>> gpio_generic
>>>> framework. This alone allows to remove some sunxi specific code,
>>>> which
>>>> is replaced with the existing generic code. This will become even
>>>> more
>>>> useful with the upcoming A733 support, which adds set and clear
>>>> registers for the output.
>>>> As a side effect this also changes the GPIO device and number
>>>> allocation: Each bank is now represented by its own gpio_chip, with
>>>> only
>>>> as many pins as there are actually implemented. The numbering is left
>>>> up
>>>
>>> Ah, is this a userspace API break?

So to summarise: yes, the user visible number in /sys/class/gpio would 
change. For a start, there would be up to a dozen gpiochip's now, 
instead of the just two before. But at the moment they are somewhat 
inconsistently named: the current labels are just <addr>.pinctrl, you 
would need to know that 300b000 is the primary controller. This is of 
course SoC specific, and DOES differ between generations of Allwinner 
chips. With this patch we get the bank number appended to the label, so 
it becomes something like: 300b000.pinctrl-PD, which is grep-able even.

As for users being affected by this change: that's hard to say, there 
seem to be a lot of silent users there (not being visible in mainline 
discussions), also a lot of people using these boards in a very embedded 
way. My hunch is that still quite some people use the sysfs interface, 
because it's so convenient to use from the shell, and many compile their 
own kernels. At the same time I am sure those people could adapt to any 
new scheme.

>> Was that ever a guaranteed user space API? Or just something
>> that everyone relied on because it was always the same (until it
>> wasn't)? Similar to /dev/mmcblk0 being the SD card?


>> And ignoring the ill-fated old-style sysfs interface for now, how does
>> this work with libgpiod? Would it still use the absolute pin numbers?
>>
>> I mean looking at that warning about the forced GPIO numbering we
>> get, using base = -1 seems to be the recommended way?
>>
> 
> My view is this: for libgpiod, there are no absolute GPIO numbers and the
> ordering of GPIO chip character devices is not guaranteed.
> 
> For sysfs: userspace may rightfully expect the global numbering to stay the
> same. I don't like it but this is the kernel policy.

Does it matter anyhow that this interface is deprecated, and even hidden 
behind CONFIG_EXPERT?

> Here however, there's another thing: the fact that a single GPIO chips is now
> split into several. I don't mind it but if someone complains, it would have
> to be reverted.

Who would care, and are there other effects outside of the sysfs 
numbering? I mean we always had two GPIO chips before (because of two 
instances of pinctrl IP in most Allwinner SoCs), one with one or two 
banks, one with up to 11. Now it's at least consistently one bank per 
chip, without gaps.

So personally I am leaning towards doing the change: most users can 
typically adapt - or they don't care because they don't update their 
kernels (beyond stable revisions). And to address the naming 
ambiguities, we could push for more gpio-line-names. That would make 
finding a GPIO much safer and easier, and works either way.

But if this patch's ABI breakage is a showstopper, I would need to know, 
so that I can rebase the A733 pinctrl patches without this one being the 
first patch in the series.

Cheers,
Andre