[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a94eb00-3a1a-4806-a739-0adc8e6f05c6@oss.qualcomm.com>
Date: Wed, 7 Jan 2026 10:22:02 +0530
From: Viken Dadhaniya <viken.dadhaniya@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>
Cc: 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, mukesh.savaliya@....qualcomm.com
Subject: Re: [PATCH 1/1] arm64: dts: qcom: talos: Drop opp-shared from QUP OPP
table
Hi Bjorn,
Just a quick reminder to pick this change if there are no other open items.
Please let me know if you need any additional details.
Thanks
Viken.
On 12/17/2025 9:20 PM, 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.
> 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
>>>>>>
>>>
Powered by blists - more mailing lists