linux-kernel - Re: [PATCH 1/1] arm64: dts: qcom: talos: Drop opp-shared from QUP OPP table

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: <073c34fa-4c19-4905-851d-727722bbf8c2@oss.qualcomm.com>
Date: Mon, 12 Jan 2026 14:17:31 +0530
From: Viken Dadhaniya <viken.dadhaniya@....qualcomm.com>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        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 1/10/2026 1:10 AM, Bjorn Andersson wrote:
> On Wed, Dec 17, 2025 at 09:20:09PM +0530, Viken Dadhaniya wrote:
>> Hi Bjorn and Dmitry,
>>
>> On 11/24/2025 3:10 PM, Viken Dadhaniya wrote:
>>>
>>>
>>> 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.
>>>
>>
>> I hope the above information addresses your question. 
>> The current change has been validated for the SPI, Serial, and I2C drivers,
>> and it is functioning as expected.
> 
> I'm sorry, but above you write "verified only I2C ... But missed to
> validate all other instances" and here you write "validated SPI, Serial,
> and I2C drivers".
> 
> Did you test it or not?
> 
> Or are you saying that you only tested I2C, but have now verified also
> SPI and Serial?
> 
> Regards,
> Bjorn

Hi Bjorn,

Seems there is some confusion, let me clarify:

For the earlier patch which caused regression:
https://lore.kernel.org/linux-devicetree/20250630064338.2487409-1-viken.dadhaniya@oss.qualcomm.com/
I had verified the I²C protocol only and compared it against other SoCs
(such as sc7280.dtsi). Unfortunately, I missed validating the SPI and
Serial instances at that time. I acknowledge this gap and will ensure
comprehensive testing across all relevant nodes in future changes.

For the current patch providing the solution for above issue:
https://lore.kernel.org/all/vmrpdu7fn776vkwrhwvtuwkpsxaco4gt4worl43mpvk73ft67a@cbkg6gmqss5x/
I have validated the SPI, Serial, and I²C drivers, and they are
functioning as expected.

Hope it clarifies, Please let me know if there is anything else needed
from my side.

Regards,
Viken

> 
>> Please let us know if you have any further queries.
>>
>>>>
>>>>>
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>