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

[Khristine Andreea Barbulescu]

On 5/11/2026 11:48 AM, Linus Walleij wrote:
> On Fri, May 8, 2026 at 11:07 AM Khristine Andreea Barbulescu
> <khristineandreea.barbulescu at oss.nxp.com> wrote:
> 
>> 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.
> 
> I don't see the problem with that?
> 
>> A conversion would require stronger separation between
>> GPIO and pinctrl, leaving mux restoration entirely
>> to the pinctrl subsystem.
> 
> Why is that so? Sorry I don't get the problem here.
> 
> The pinmux operations have these callbacks:
> 
> static const struct pinmux_ops s32_pmx_ops = {
> (...)
>         .gpio_request_enable = s32_pmx_gpio_request_enable,
>         .gpio_disable_free = s32_pmx_gpio_disable_free,
>         .gpio_set_direction = s32_pmx_gpio_set_direction,
> };
> 
> So to me it looks like the pinctrl subsystem is *already*
> handling all the muxing of GPIO lines in these
> callbacks?
> 
>> Would it be reasonable to keep the current approach for now
>> and revisit gpio-regmap later if needed?
> 
> I'd prefer that you look into it now while you already
> have all the information at hand and fresh in your mind.
> 
> You can forward my comments to your project lead
> / JIRA instance and say it's Linus' fault you have to spend
> more time on this right now.
> 
> Yours,
> Linus Walleij

Hi Linus,

The new version (v10) has been updated to use gpio-regmap, with a virtual
regmap bridge dispatching GPIO accesses to the underlying SIUL2 register
blocks.
 
I am not fully convinced this is the cleanest model, though.
SIUL2 does not expose GPIO as one regular register space: direction is in
MSCR, input values are read from PGPDI, and output values are written through
PGPDO. These are backed by separate regmaps in the driver, while gpio-regmap
expects a single regmap.
 
So the current path becomes:
  gpio-regmap -> virtual regmap -> MSCR/PGPDI/PGPDO regmap
 
The version was updated this way so we can review the approach on top of the
current code. If this is still the preferred direction, it can be polished
further. Otherwise, I think direct gpio_chip callbacks using the existing regmap
helpers might be a simpler fit for this hardware.
 
What do you think would be the preferred direction for the next revision?

Best regards,
Khristine