[PATCH v9 6/7] pinctrl: s32cc: implement GPIO functionality

[Khristine Andreea Barbulescu]

On 5/5/2026 3:46 PM, Linus Walleij wrote:
> [You don't often get email from linusw at kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Khristine,
> 
> thanks for your patch!
> 
> On Mon, May 4, 2026 at 3:12 PM Khristine Andreea Barbulescu
> <khristineandreea.barbulescu at oss.nxp.com> wrote:
> 
>> From: Andrei Stefanescu <andrei.stefanescu at oss.nxp.com>
>>
>> Add basic GPIO functionality (request, free, get, set) for
>> the existing pinctrl SIUL2 driver since the hardware for
>> pinctrl&GPIO is tightly coupled.
>>
>> The updated SIUL2 block groups pinctrl, GPIO data access
>> and interrupt control within the same hardware unit.
>> The SIUL2 driver is therefore structured as a monolithic
>> pinctrl/GPIO driver.
>>
>> This change came as a result of upstream review in the
>> following series:
>> https://lore.kernel.org/linux-gpio/20260120115923.3463866-4-khristineandreea.barbulescu@oss.nxp.com/T/#m543c9edbdde74bdc68b6a2364e8b975356c33043
>>
>> Support both SIUL2 DT layouts:
>> - legacy pinctrl-only binding
>> - extended pinctrl/GPIO/irqchip binding
>>
>> Also, remove pinmux_ops which are no longer needed.
>>
>> Signed-off-by: Andrei Stefanescu <andrei.stefanescu at oss.nxp.com>
>> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu at oss.nxp.com>
> 
> Same comment about GPIO_REGMAP here.
> 
> Maybe this has been brought up before so it's just sigh rolleyes,
> but my memory is short.
> 
> Of course gpio regmap conversions can be done later, after this,
> but the problem with such things is that they tend to end up on
> the back burner and never actually get done then.
> 
> Yours,
> Linus Walleij


Hi Linus,

Thank you for the suggestion!

I think the gpio-regmap model could fit the SIUL2 PGPDO/PGPDI
data path, so the get/set operations could potentially be
refactored in that direction as a follow-up.

However, I don't think the current driver is a good fit for
a full gpio-regmap conversion. Direction and GPIO mux are
handled through MSCR/pinctrl state (IBE/OBE/SSS), and the GPIO
logic spans multiple register regions across two SIUL2 instances.

A conversion would require stronger separation between
GPIO and pinctrl, leaving mux restoration entirely
to the pinctrl subsystem.

Would it be reasonable to keep the current approach for now
and revisit gpio-regmap later if needed?

Best regards,
Khristine