linux-kernel - Re: [PATCH V3 2/4] dt-bindings: mmc: controller: Add max-sd-hs-frequency property

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: <9e345e90-58e6-4755-a0af-8e0b4ccd5d44@quicinc.com>
Date: Fri, 20 Jun 2025 14:37:56 +0530
From: Sarthak Garg <quic_sartgarg@...cinc.com>
To: 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 V3 2/4] dt-bindings: mmc: controller: Add
 max-sd-hs-frequency property



On 6/18/2025 2:38 PM, Krzysztof Kozlowski wrote:
> On 18/06/2025 10:38, Sarthak Garg wrote:
>>
>>
>> On 6/18/2025 1:13 PM, Krzysztof Kozlowski wrote:
>>> On 18/06/2025 09:28, Sarthak Garg wrote:
>>>> Introduce a new optional device tree property `max-sd-hs-frequency` to
>>>> limit the maximum frequency (in Hz) used for SD cards operating in
>>>> High-Speed (HS) mode.
>>>>
>>>> This property is useful for platforms with vendor-specific hardware
>>>> constraints, such as the presence of a level shifter that cannot
>>>> reliably support the default 50 MHz HS frequency. It allows the host
>>>> driver to cap the HS mode frequency accordingly.
>>>>
>>>> Signed-off-by: Sarthak Garg <quic_sartgarg@...cinc.com>
>>>> ---
>>>>    .../devicetree/bindings/mmc/mmc-controller-common.yaml | 10 ++++++++++
>>>>    1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>>>> index 9a7235439759..1976f5f8c401 100644
>>>> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>>>> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>>>> @@ -93,6 +93,16 @@ properties:
>>>>        minimum: 400000
>>>>        maximum: 384000000
>>>>    
>>>> +  max-sd-hs-frequency:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>> +    description: |
>>>> +      Maximum frequency (in Hz) to be used for SD cards operating in
>>>> +      High-Speed (HS) mode. This is useful for platforms with vendor-specific
>>>> +      limitations, such as the presence of a level shifter that cannot support
>>>> +      the default 50 MHz HS frequency or other.
>>>> +    minimum: 400000
>>>> +    maximum: 50000000
>>>
>>> This might be fine, but your DTS suggests clearly this is SoC compatible
>>> deducible, which I already said at v1.
>>>
>>> So now you send v3 which is the same as v1, so you get the same comments.
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Introducing this flag no longer becomes SoC compatible because as per
>> discussions in V2 patchset with Ulf and Konrad this new property can be
>> used by any vendor who wants to limit the HS mode frequency due to any
>> reason. Thats why moved to this generic approach again in V3 as compared
>> to compatible based approach in V2.
> 
> The are no arguments provided in favor, so my review from v1 stays. You
> get the same comments.
> 
> Best regards,
> Krzysztof

@Ulf, @Konrad — since you previously supported the idea of a generic 
property for HS frequency limitation, could you please share your 
thoughts on whether this still seems like a valid approach?

Best regards,
Sarthak