linux-kernel - Re: [PATCH v2 3/4] arm64: dts: qcom: qcm2290: add LPASS LPI pin controller

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: <DDO45O787X9V.1KOKIB22SVSN7@linaro.org>
Date: Tue, 21 Oct 2025 16:42:57 +0100
From: "Alexey Klimov" <alexey.klimov@...aro.org>
To: "Dmitry Baryshkov" <dmitry.baryshkov@....qualcomm.com>
Cc: "Bjorn Andersson" <andersson@...nel.org>, "Konrad Dybcio"
 <konrad.dybcio@....qualcomm.com>, "Linus Walleij"
 <linus.walleij@...aro.org>, "Rob Herring" <robh@...nel.org>, "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>,
 "Konrad Dybcio" <konradybcio@...nel.org>, "Srinivas Kandagatla"
 <srini@...nel.org>, <linux-arm-msm@...r.kernel.org>,
 <linux-gpio@...r.kernel.org>, <devicetree@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <linux-sound@...r.kernel.org>
Subject: Re: [PATCH v2 3/4] arm64: dts: qcom: qcm2290: add LPASS LPI pin
 controller

On Tue Oct 21, 2025 at 2:03 PM BST, Dmitry Baryshkov wrote:
> On Tue, Oct 21, 2025 at 01:56:09PM +0100, Alexey Klimov wrote:
>> On Fri Oct 17, 2025 at 11:42 PM BST, Bjorn Andersson wrote:
>> > On Fri, Oct 10, 2025 at 01:29:38PM +0100, Alexey Klimov wrote:
>> >> On Tue Oct 7, 2025 at 1:39 PM BST, Konrad Dybcio wrote:
>> >> > On 10/7/25 4:03 AM, Alexey Klimov wrote:
>> >> >> Add the Low Power Audio SubSystem Low Power Island (LPASS LPI) pin
>> >> >> controller device node required for audio subsystem on Qualcomm
>> >> >> QRB2210 RB1. QRB2210 is based on qcm2290 which is based on sm6115.
>> >> >> 
>> >> >> While at this, also add description of lpi_i2s2 pins (active state)
>> >> >> required for audio playback via HDMI/I2S.
>> >> >> 
>> >> >> Cc: Srinivas Kandagatla <srini@...nel.org>
>> >> >> Signed-off-by: Alexey Klimov <alexey.klimov@...aro.org>
>> >> >> ---
>> >> >
>> >> > [...]
>> >> >
>> >> >> +			lpi_i2s2_active: lpi-i2s2-active-state {
>> >> >> +				data-pins {
>> >> >> +					pins = "gpio12";
>> >> >> +					function = "i2s2_data";
>> >> >> +					bias-disable;
>> >> >> +					drive-strength = <8>;
>> >> >> +					output-high;
>> >> >
>> >> > I.. doubt output-high is what you want?
>> >> 
>> >> Why? Or is it because of some in-kernel gpiod?
>> >> 
>> >
>> > What does "output-high" mean for a non-gpio function?
>> 
>> This is not efficient. It will be more useful to go straight to
>> the point.
>
> It is efficient. It makes everybody think about it (and ask the same
> question in future) instead of just depending on maintainers words.

No. Imagine instead of this email you've got smth like this:
"I.. doubt efficient is what you want?"

>> This description of pins was taken from Qualcomm downstream code
>> and the similar patch was applied (see provided URL in the prev email).
>
> And we all know that downstream can be buggy, incomplete, etc.
>
>> Back to your question -- does it matter here if it is gpio or non-gpio
>> function?
>
> It does. The I2S data pin is supposed to be toggled in some way by a
> certain IP core. What would it mean if we program output-high? Will the
> pin still be toggled (by the function) or stay pulled up (because of the
> output being programmed)?

Here the topic was switched/replaced. And the other referenced email
suggests that they don't want to see output property regardless.

Anyway, as it was indicated in my previous email the problem they
were trying to refer to was kinda understood.

Thanks,
Alexey