pinctrl-scmi: Support for pin-only mode when groups are unavailable

pinctrl-scmi: Support for pin-only mode when groups are unavailable

[Ciprian Marian Costea]

Hello,


I’m currently exploring a solution to improve the 'pinctrl-scmi' [1] 
driver so it can better support SCMI platforms that only provide 
individual pin control. At the moment, the driver handles only 
group-based operations, which means platforms without pin groups run 
into limitations.

According to the SCMI v4.0 specification (section 3.11.2.8), both 
group-based and per-pin control modes should be supported. However, on 
pin-only platforms, the current implementation cannot enumerate groups, 
configure pinmux, or assign functions per pin. This results in probe 
failures and '-EINVAL' errors when trying to configure non-existent groups.

I haven’t seen any work in this area yet, but if nothing is in progress, 
I’d like to propose an approach that keeps compatibility with the 
existing Linux pinctrl framework while adding per-pin support. The idea 
is to detect whether the platform supports groups or pins-only during 
probe, and when groups are missing, create virtual groups from the DT 
pin specifications. This would allow us to reuse the existing 
group-based logic while enabling per-pin muxing.

For example, a DTS node could look like this:

uart_pins: uart-pins {
     pins = <10 11>;      /* SCMI pin IDs */
     functions = <2 3>;   /* Per-pin function IDs: UART_TX, UART_RX */
};

or:

uart_pins: uart-pins {
     pins = <10 11>;      /* SCMI pin IDs */
     function = <2>;      /* Same function for all pins */
};

To make this work, the driver would need to:
   - Detect capabilities during probe (groups vs pins-only). Can be 
implemented via 'pinctrl_ops->count_get()'.
   - Create virtual groups when groups are unsupported.
   - Add per-pin mux/config operations by introducing a 'pin_mux_set()' 
callback in the SCMI core, since currently only group-based 'mux_set' is 
implemented.

I’d really appreciate your thoughts on whether this direction makes 
sense and if there’s anything I should consider before starting.
Thanks a lot for your time and guidance!

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/pinctrl-scmi.c

Best Regards,
Ciprian Costea

Re: pinctrl-scmi: Support for pin-only mode when groups are unavailable

[Cristian Marussi]

On Thu, Oct 16, 2025 at 07:05:21PM +0300, Ciprian Marian Costea wrote:
> Hello,
> 

[CC: <linus.walleij@linaro.org>]

Hi Ciprian,

I will have a better look at this in the coming days ...

...but I think, in the meantime, better if we CC also the PINCTRL
Maintainer Linus Walleij that helped us reviewing also this driver from the
PINCTRL subsystem perspective....

> 
> I’m currently exploring a solution to improve the 'pinctrl-scmi' [1] driver
> so it can better support SCMI platforms that only provide individual pin
> control. At the moment, the driver handles only group-based operations,
> which means platforms without pin groups run into limitations.

...ok

> 
> According to the SCMI v4.0 specification (section 3.11.2.8), both
> group-based and per-pin control modes should be supported. However, on
> pin-only platforms, the current implementation cannot enumerate groups,
> configure pinmux, or assign functions per pin. This results in probe
> failures and '-EINVAL' errors when trying to configure non-existent groups.
> 

...indeed

> I haven’t seen any work in this area yet, but if nothing is in progress, I’d
> like to propose an approach that keeps compatibility with the existing Linux
> pinctrl framework while adding per-pin support. The idea is to detect

...nothing planned or requested as of now that I know...so feel free to propose
your improvements...becasue it is easier to discuss in front of a series :P

Cheers,
Cristian

> whether the platform supports groups or pins-only during probe, and when
> groups are missing, create virtual groups from the DT pin specifications.
> This would allow us to reuse the existing group-based logic while enabling
> per-pin muxing.
> 
> For example, a DTS node could look like this:
> 
> uart_pins: uart-pins {
>     pins = <10 11>;      /* SCMI pin IDs */
>     functions = <2 3>;   /* Per-pin function IDs: UART_TX, UART_RX */
> };
> 
> or:
> 
> uart_pins: uart-pins {
>     pins = <10 11>;      /* SCMI pin IDs */
>     function = <2>;      /* Same function for all pins */
> };
> 
> To make this work, the driver would need to:
>   - Detect capabilities during probe (groups vs pins-only). Can be
> implemented via 'pinctrl_ops->count_get()'.
>   - Create virtual groups when groups are unsupported.
>   - Add per-pin mux/config operations by introducing a 'pin_mux_set()'
> callback in the SCMI core, since currently only group-based 'mux_set' is
> implemented.
> 
> I’d really appreciate your thoughts on whether this direction makes sense
> and if there’s anything I should consider before starting.
> Thanks a lot for your time and guidance!
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/pinctrl-scmi.c
> 
> Best Regards,
> Ciprian Costea

Re: pinctrl-scmi: Support for pin-only mode when groups are unavailable

[Ciprian Marian Costea]

On 10/16/2025 8:36 PM, Cristian Marussi wrote:
> On Thu, Oct 16, 2025 at 07:05:21PM +0300, Ciprian Marian Costea wrote:
>> Hello,
>>

Hello Cristian,

Thank you for your valuable feedback.
I will work on and send a patchset for this proposed support.

Best Regards,
Ciprian

> 
> [CC: <linus.walleij@linaro.org>]
> 
> Hi Ciprian,
> 
> I will have a better look at this in the coming days ...
> 
> ...but I think, in the meantime, better if we CC also the PINCTRL
> Maintainer Linus Walleij that helped us reviewing also this driver from the
> PINCTRL subsystem perspective....
> 
>>
>> I’m currently exploring a solution to improve the 'pinctrl-scmi' [1] driver
>> so it can better support SCMI platforms that only provide individual pin
>> control. At the moment, the driver handles only group-based operations,
>> which means platforms without pin groups run into limitations.
> 
> ...ok
> 
>>
>> According to the SCMI v4.0 specification (section 3.11.2.8), both
>> group-based and per-pin control modes should be supported. However, on
>> pin-only platforms, the current implementation cannot enumerate groups,
>> configure pinmux, or assign functions per pin. This results in probe
>> failures and '-EINVAL' errors when trying to configure non-existent groups.
>>
> 
> ...indeed
> 
>> I haven’t seen any work in this area yet, but if nothing is in progress, I’d
>> like to propose an approach that keeps compatibility with the existing Linux
>> pinctrl framework while adding per-pin support. The idea is to detect
> 
> ...nothing planned or requested as of now that I know...so feel free to propose
> your improvements...becasue it is easier to discuss in front of a series :P
> 
> Cheers,
> Cristian
> 
>> whether the platform supports groups or pins-only during probe, and when
>> groups are missing, create virtual groups from the DT pin specifications.
>> This would allow us to reuse the existing group-based logic while enabling
>> per-pin muxing.
>>
>> For example, a DTS node could look like this:
>>
>> uart_pins: uart-pins {
>>      pins = <10 11>;      /* SCMI pin IDs */
>>      functions = <2 3>;   /* Per-pin function IDs: UART_TX, UART_RX */
>> };
>>
>> or:
>>
>> uart_pins: uart-pins {
>>      pins = <10 11>;      /* SCMI pin IDs */
>>      function = <2>;      /* Same function for all pins */
>> };
>>
>> To make this work, the driver would need to:
>>    - Detect capabilities during probe (groups vs pins-only). Can be
>> implemented via 'pinctrl_ops->count_get()'.
>>    - Create virtual groups when groups are unsupported.
>>    - Add per-pin mux/config operations by introducing a 'pin_mux_set()'
>> callback in the SCMI core, since currently only group-based 'mux_set' is
>> implemented.
>>
>> I’d really appreciate your thoughts on whether this direction makes sense
>> and if there’s anything I should consider before starting.
>> Thanks a lot for your time and guidance!
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/pinctrl-scmi.c
>>
>> Best Regards,
>> Ciprian Costea

Re: pinctrl-scmi: Support for pin-only mode when groups are unavailable

[Linus Walleij]

On Thu, Oct 16, 2025 at 7:37 PM Cristian Marussi
<cristian.marussi@arm.com> wrote:
> On Thu, Oct 16, 2025 at 07:05:21PM +0300, Ciprian Marian Costea wrote:

> > I’m currently exploring a solution to improve the 'pinctrl-scmi' [1] driver
> > so it can better support SCMI platforms that only provide individual pin
> > control. At the moment, the driver handles only group-based operations,
> > which means platforms without pin groups run into limitations.
> >
> > According to the SCMI v4.0 specification (section 3.11.2.8), both
> > group-based and per-pin control modes should be supported. However, on
> > pin-only platforms, the current implementation cannot enumerate groups,
> > configure pinmux, or assign functions per pin. This results in probe
> > failures and '-EINVAL' errors when trying to configure non-existent groups.

First: it is usually not true that no grouping exist. They are usually
there in the hardware, it is just that the fact that the programming
reference document document a register for each pin and you just
cannot see the forest because of all the trees (pins) literally.

I.e. just because pins *can* be controlled individually, this does
not mean that it is a good idea for the SCMI-back firmware
to *expose* them as individually controlled.

Example:

Pins 0, 1, 2, 3

Function uart0:
Poke 0x3 into register A to turn pin 0 into UART RX
Poke 0x3 into register A+4 to turn pin 1 into UART TX
Poke 0x3 into register A+8 to turn pin 2 into UART RTS
Poke 0x3 into register A+12 to turn pin 3 into UART CTS

Some people will see "4 pins with individual controls"

Some people will see "4 pins in a group exposing a UART
with RX, TX, RTS, CTS" and create a group of these
4 pins called uart0_grp = { 0, 1, 2, 3 }

Now, often RTS and CTS isn't used, so maybe these
need their own group and the intended use is more like
uart0_rx_tx = {0, 1}
uart0_rts_cts = {2, 3}

Now the usual complaint from the software engineer
implementing a FW driver or Linux kernel driver is
"I don't know what use cases and groups are appropriate".

But this complaint is coming from the same company,
the same legal body, that produced the whole SoC.

And this is not to act as a coherent company.

This is overall a clear symptom of throw-over-the-wall
engineering.
https://en.wikipedia.org/wiki/Traditional_engineering

So I would take a step back and talk to some hardware
engineers about this before proceeding. The SCMI
exposure of groups and functions look like they do for
a reason: per-pin muxing is use sometimes by hobbyists
and consultants to SoC companies who have no direct
insight to the hardware and cannot really communicate
with HW engineers.

But for a *firmware* we certainly expect the people writing
that to have talked to the engineer who designed the
grouping inherent in the hardware. At least try hard.

Then there is the last resort which I would think twice
before implementing:

What the Qualcomm driver does is to create a group
for every single pin, e.g.

gpio0_grp = {0}
gpio1_grp = {1}
....

Yours,
Linus Walleij