linux-kernel - Re: [PATCH V4 4/4] arm64: dts: qcom: sm8550: Remove SDR104/SDR50 broken capabilities

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: <a1252539-d35f-443b-9e0a-3316f9ff932a@quicinc.com>
Date: Wed, 20 Aug 2025 12:49:48 +0530
From: Sarthak Garg <quic_sartgarg@...cinc.com>
To: Neil Armstrong <neil.armstrong@...aro.org>,
        Konrad Dybcio
	<konrad.dybcio@....qualcomm.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        "Ulf
 Hansson" <ulf.hansson@...aro.org>, Rob Herring <robh@...nel.org>,
        "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        "Bjorn
 Andersson" <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>
CC: <linux-mmc@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <quic_cang@...cinc.com>, <quic_nguyenb@...cinc.com>,
        <quic_rampraka@...cinc.com>, <quic_pragalla@...cinc.com>,
        <quic_sayalil@...cinc.com>, <quic_nitirawa@...cinc.com>,
        <quic_bhaskarv@...cinc.com>, <kernel@....qualcomm.com>
Subject: Re: [PATCH V4 4/4] arm64: dts: qcom: sm8550: Remove SDR104/SDR50
 broken capabilities



On 8/19/2025 7:00 PM, Neil Armstrong wrote:
> On 14/08/2025 09:15, Sarthak Garg wrote:
>>
>>
>> On 8/13/2025 5:37 PM, Konrad Dybcio wrote:
>>> On 8/13/25 1:56 PM, Krzysztof Kozlowski wrote:
>>>> On 13/08/2025 13:21, Konrad Dybcio wrote:
>>>>> On 8/13/25 1:08 PM, Sarthak Garg wrote:
>>>>>>
>>>>>>
>>>>>> On 8/5/2025 2:55 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 05/08/2025 11:19, Sarthak Garg wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/1/2025 2:32 PM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 01/08/2025 10:45, Sarthak Garg wrote:
>>>>>>>>>> The kernel now handles level shifter limitations affecting SD 
>>>>>>>>>> card
>>>>>>>>>> modes, making it unnecessary to explicitly disable SDR104 and 
>>>>>>>>>> SDR50
>>>>>>>>>> capabilities in the device tree.
>>>>>>>>>>
>>>>>>>>>> However, due to board-specific hardware constraints 
>>>>>>>>>> particularly related
>>>>>>>>>> to level shifter in this case the maximum frequency for SD 
>>>>>>>>>> High-Speed
>>>>>>>>>> (HS) mode must be limited to 37.5 MHz to ensure reliable 
>>>>>>>>>> operation of SD
>>>>>>>>>> card in HS mode. This is achieved using the 
>>>>>>>>>> max-sd-hs-frequency property
>>>>>>>>>> in the board DTS.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Sarthak Garg <quic_sartgarg@...cinc.com>
>>>>>>>>>> ---
>>>>>>>>>>     
>>>>>>>>>> arch/arm64/boot/dts/qcom/sm8550-hdk.dts                     | 1 +
>>>>>>>>>>     
>>>>>>>>>> arch/arm64/boot/dts/qcom/sm8550-mtp.dts                     | 1 +
>>>>>>>>>>     
>>>>>>>>>> arch/arm64/boot/dts/qcom/sm8550-sony-xperia-yodo-pdx234.dts | 1 +
>>>>>>>>>>     
>>>>>>>>>> arch/arm64/boot/dts/qcom/sm8550.dtsi                        | 
>>>>>>>>>> 3 ---
>>>>>>>>>>     4 files changed, 3 insertions(+), 3 deletions(-)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This will break MMC for all of the users and nothing in commit 
>>>>>>>>> msg or
>>>>>>>>> cover letter explains that or mentions merging strategy.
>>>>>>>>>
>>>>>>>>> Exactly this case is covered by your internal guideline, no? 
>>>>>>>>> Please read it.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Krzysztof
>>>>>>>>
>>>>>>>> Just to make sure I’m addressing the right concern — are you 
>>>>>>>> primarily
>>>>>>>> worried about the introduction of the max-sd-hs-frequency 
>>>>>>>> property in
>>>>>>>> the board DTS files, or about the removal of the sdhci-caps-mask
>>>>>>>> from the common sm8550.dtsi?
>>>>>>>
>>>>>>>
>>>>>>> Apply this patch and test MMC. Does it work? No. Was it working? 
>>>>>>> Yes.
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Krzysztof
>>>>>>
>>>>>>
>>>>>> You're absolutely right to raise the concern about potential 
>>>>>> breakage.
>>>>>> After conducting additional testing across multiple boards, I’ve 
>>>>>> confirmed that the removal of SDR104/SDR50 broken capabilities 
>>>>>> does indeed affect V1 SM8550 devices.
>>>>>
>>>>> v1 is a prototype revision, please forget it exists, we most 
>>>>> definitely
>>>>> do not support it upstream
>>>>
>>>>
>>>> You should double check. SM8450 (not v1!) needed it, so either it was
>>>> copied to SM8550 (v2!) by mistake or was also needed.
>>>
>>> I believe that the speed capabilities are indeed restricted on 
>>> 8550-final
>>> and that's why this patchset exists in the first place
>>>
>>> Konrad
>>
>> Hi Krzysztof, Konrad,
>>
>> Konrad is right — this patch series addresses limitations seen on
>> SM8550-final silicon.
>>
>> SDR50 mode: The tuning support introduced in this series helps ensure
>> reliable operation.
>> SDR104 mode: limitations are resolved in SM8550 v2.
> 
> I guess the state is the same for SM8650, it also requires the 
> max-sd-hs-frequency.
> 
> I guess all boards with a level-shifter on board would need such 
> limitation,
> including most of the HDK boards (SM8450 included)
> 
> Neil
>

Yes, that makes sense Neil — all boards with a level-shifter on board
would likely need this limitation, including SM8450, SM8550, and SM8650.

>>
>> But still to avoid regressions, *I’ll like to retain sdhci-caps-mask in
>> sm8550.dtsi for now and revisit its removal for future targets after
>> thorough validation and testing from the beginning.*
>>
>> Konrad suggested placing max-sd-hs-frequency in the SoC dtsi.
>> Krzysztof, could you please share your thoughts on this approach?
>>
>> Best regards,
>> Sarthak Garg
>