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: <836d6ead-6620-4bc7-8dc1-d9220e7c83dc@quicinc.com>
Date: Thu, 24 Jul 2025 17:18:27 +0530
From: Sarthak Garg <quic_sartgarg@...cinc.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
        Konrad Dybcio
	<konrad.dybcio@....qualcomm.com>,
        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 7/1/2025 3:00 PM, Krzysztof Kozlowski wrote:
> On 01/07/2025 11:04, Konrad Dybcio wrote:
>>>>>>
>>>>>> Looking at the docs, a number of platforms have various limitations
>>>>>> with regards to frequency at specific speed-modes, some of which seem
>>>>>> to be handled implicitly by rounding in the clock framework's
>>>>>> round/set_rate().
>>>>>>
>>>>>> I can very easily imagine there are either boards or platforms in the
>>>>>> wild, where the speed must be limited for various reasons, maybe some
>>>>>> of them currently don't advertise it (like sm8550 on next/master) to
>>>>>> hide that
>>>>>
>>>>> But there are no such now. The only argument (fact) provided in this
>>>>> patchset is: this is issue specific to SM8550 SoC, not the board. See
>>>>> last patch. Therefore this is compatible-deducible and this makes
>>>>> property without any upstream user.
>>>>
>>>> When one appears, we will have to carry code to repeat what the property
>>>> does, based on a specific compatible.. And all OS implementations will
>>>> have to do the same, instead of parsing the explicit information
>>>
>>> Adding new property in such case will be trivial and simple, unlike
>>> having to maintain unused ABI.
>>>
>>> And it will be unused, because last patch DTS should be rejected on that
>>> basis: adding redundant properties which are already defined by the
>>> compatible.
>>
>> Got some more fresh information.. This apparently *does* vary across
>> boards, as there is a recommended hardware workaround to this rate
>> limitation (requiring an external clock source, which is up to the
>> OEM to implement or not)
> 
> 
> This should be clearly explained in commit msg and the DTS patch
> re-written because it seems it is not a property of the SoC.
> 
> I mean, really, that last patch here makes entire discussion pointless,
> because till it is in the patchset is a proof this is a SoC level property.
> 
> Best regards,
> Krzysztof


Sure I'll update the commit message clearly mentioning it as board 
specific and update the DTS patch and have these changes in board 
specific dts files (for e.g sm8550-mtp.dts).

As rightly stated above this configuration will vary across boards as well.

Regards,
Sarthak