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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <lqzft4adz56ly5323cpcsdasr4uag6gb2wrtlabynd6mvxayhi@jdrxniqm6qek>
Date: Fri, 30 Jan 2026 10:18:19 +0200
From: Abel Vesa <abel.vesa@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Linus Walleij <linusw@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: pinctrl: document the Eliza Top
 Level Mode Multiplexer

On 26-01-29 15:11:07, Konrad Dybcio wrote:
> 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@....qualcomm.com>
> >>>>>>>>> ---
> >>>>>>
> >>>>>> [...]
> >>>>>>
> >>>>>>>>> +
> >>>>>>>>> +  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.

That's because the pins property uses the name (here "ufs_reset") while
the *-gpios uses the number that goes via driver specific of_xlate.

> 
> > 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.

Just because we treat it as gpio in the driver, doesn't mean it is a gpio.
HW-wise, it is not a gpio. GPIOs have electrical properties (at least) that
this ufs_reset doesn't.

> 
> 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.

Being toggle capable doesn't make it a GPIO. Again, a GPIO is more than that.

> 
> 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.

Yeah. I think it should've listed it. It does on Eliza and Glymur.

> 
> 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..

Anyway, to conclude, pins property does allow you to use it by name beacuse
of the enum entry below.

But the gpio-line-names doesn't make any sense to allow you to override the name.
This part is can be debated, for sure.

I'll respin with these in mind and we can fix this later on, if needed, on all
platforms at once.  

Thanks,
Abel