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: <13ea5fd7-b28b-b6c0-752f-a7d4b4677298@oss.qualcomm.com>
Date: Mon, 24 Nov 2025 15:10:42 +0530
From: Viken Dadhaniya <viken.dadhaniya@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>, konradybcio@...nel.org,
        robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, konrad.dybcio@....qualcomm.com,
        dmitry.baryshkov@...aro.org, mukesh.savaliya@....qualcomm.com
Subject: Re: [PATCH 1/1] arm64: dts: qcom: talos: Drop opp-shared from QUP OPP
 table



On 11/21/2025 5:33 PM, Dmitry Baryshkov wrote:
> On Fri, Nov 21, 2025 at 03:37:21PM +0530, Viken Dadhaniya wrote:
>>
>>
>> On 11/12/2025 1:25 AM, Bjorn Andersson wrote:
>>> On Tue, Nov 11, 2025 at 10:33:50PM +0530, Viken Dadhaniya wrote:
>>>> QUP devices are currently marked with opp-shared in their OPP table,
>>>> causing the kernel to treat them as part of a shared OPP domain. This
>>>> leads to the qcom_geni_serial driver failing to probe with error
>>>> -EBUSY (-16).
>>>>
>>>> Remove the opp-shared property to ensure the OPP framework treats the
>>>> QUP OPP table as device-specific, allowing the serial driver to probe
>>>> successfully
>>>>
>>>> Fixes: f6746dc9e379 ("arm64: dts: qcom: qcs615: Add QUPv3 configuration")
>>>
>>> This was merged 11 months ago, and Yu Zhang added bluetooth support 3
>>> months ago. What changed to break the QUP users? I think it's reasonable
>>> to use this "Fixes", but we should document - at least on the mailing
>>> list, where the regression happened.
>>>
>>> Regards,
>>> Bjorn
>>
>> I’ve checked the older Linux versions and found that this issue started occurring after the following change:
>> https://lore.kernel.org/linux-devicetree/20250630064338.2487409-1-viken.dadhaniya@oss.qualcomm.com/
> 
> Hmm, but it's your patch. How was it tested?

For this patch, I had verified only the I²C instance and compared it against other SoCs (like sc7280.dtsi). But missed to validate all other instances from  SPI/Serial.
I realized now and will make sure to test all possible nodes in future changes to avoid such gap.

> 
>>
>>>
>>>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@....qualcomm.com>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/talos.dtsi | 1 -
>>>>  1 file changed, 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
>>>> index eb6f69be4a82..ed89d2d509d5 100644
>>>> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
>>>> @@ -536,7 +536,6 @@ cdsp_smp2p_in: slave-kernel {
>>>>  
>>>>  	qup_opp_table: opp-table-qup {
>>>>  		compatible = "operating-points-v2";
>>>> -		opp-shared;
>>>>  
>>>>  		opp-75000000 {
>>>>  			opp-hz = /bits/ 64 <75000000>;
>>>> -- 
>>>> 2.34.1
>>>>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ