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] [thread-next>] [day] [month] [year] [list]
Message-ID: <6244680d-f6c3-4aba-8e12-61093e51f76c@oss.qualcomm.com>
Date: Thu, 29 Jan 2026 13:04:23 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Abel Vesa <abel.vesa@....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 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

> For the same reason, it cannot be part of the gpio-line-names either.

Since it's registered as a GPIO, why not?

Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ