Re: [PATCH v2 1/2] dt-bindings: pinctrl: document the Eliza Top Level Mode Multiplexer

[Konrad Dybcio]

On 1/29/26 1:42 PM, Abel Vesa wrote:
> On 26-01-29 13:04:23, Konrad Dybcio wrote:
>> On 1/29/26 12:12 PM, Abel Vesa wrote:
>>> On 26-01-29 11:45:59, Konrad Dybcio wrote:
>>>> On 1/29/26 11:41 AM, Abel Vesa wrote:
>>>>> On 26-01-29 11:34:07, Konrad Dybcio wrote:
>>>>>> On 1/28/26 6:22 PM, Abel Vesa wrote:
>>>>>>> On 26-01-28 12:38:32, Krzysztof Kozlowski wrote:
>>>>>>>> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote:
>>>>>>>>> Document the Top Level Mode Multiplexer on the Eliza Platform.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Abel Vesa <abel.vesa@xxxxxxxxxxxxxxxx>
>>>>>>>>> ---
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>>> +
>>>>>>>>> +  gpio-line-names:
>>>>>>>>> +    maxItems: 185
>>>>>>>>
>>>>>>>> 186, your first GPIO is 0 and last is 185.
>>>>>>>
>>>>>>> Actually it is 0 through 184. The 185 is ufs reset.
>>>>>>
>>>>>> The UFS reset also happens to be a GPIO..
>>>>>
>>>>> So the gpio-line-names should include the ufs reset,
>>>>> but the pattern not.
>>>>
>>>> Why not?
>>>
>>> ufs reset cannot be configured as gpio, so why would it be part of the
>>> pattern?
>>
>> It's certainly registered as a GPIO, as all users of UFSHC refer to it
> 
> Well, technically yes, SW-wise. But it definitely doesn't have the same
> configuration fields in HW. Anyway, that is not the point here.
> 
> The point is the pattern has dedicated enum for ufs_reset and gpio185 is
> not even part of the gpio groups anyway. [1]

So, is the current behavior such that in case I wanted to set some
properties on the ufs pin, the description would be:

foo-state {
	pins = "ufs_reset";
};

?

TBF we don't have any such ones, possibly because whatever the
bootloader had configured has always seemed to work well enough..

In that case, I agree that this pattern should not include the pin.
I'm however a little surprised to see that would be the case, since
we end up consuming this pin as a numbered GPIO via reset-gpios.

> Also, are you saying that all older platforms (sm8[3-7]50, at least) are effectively
> wrong since they do exactly the thing I described ? :-)
> 
>>
>>> For the same reason, it cannot be part of the gpio-line-names either.
>>
>> Since it's registered as a GPIO, why not?
> 
> If what I'm saying above is true, you can't configure gpio185, so AFAICT you
> won't be able to name it either. Or am I wrong ?

I think the truth is more nuanced:

The UFS_RESET is a GPIO in the sense of pinctrl-msm, as it has a ctl_reg
and an io_reg. It's not capable of receiving interrupts and it seems to
be output-only.

It does not have a "gpio" pinmux function (func0 is named "ufs_reset" intead),
but that's just human-facing naming, so whatever.

It can be toggled and is consumed by its number, through the gpios/xxx-pins
property.

Running cat /sys/kernel/debug/gpios on x1e80100, where ngpios and gpio-ranges
includes that pin though, I could not see it listed. I don't really know why.
That's where I'd expect to see the name given by gpio-line-names.

Now, I would also strongly expect that this pin would be only ever used for
UFS reset, making the name override unnecessary but we've all seen things..

Konrad