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: <fd73a142-3b22-407f-8e6d-00f4e1e1c8eb@oss.qualcomm.com>
Date: Mon, 23 Jun 2025 14:31:14 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Sarthak Garg <quic_sartgarg@...cinc.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 6/23/25 2:16 PM, Krzysztof Kozlowski wrote:
> On 23/06/2025 14:08, Konrad Dybcio wrote:
>>>>>
>>>>> This might be fine, but your DTS suggests clearly this is SoC compatible
>>>>> deducible, which I already said at v1.
>>>>
>>>> I don't understand why you're rejecting a common solution to a problem
>>>> that surely exists outside this one specific chip from one specific
>>>> vendor, which may be caused by a multitude of design choices, including
>>>> erratic board (not SoC) electrical design
>>>
>>> No one brought any arguments so far that common solution is needed. The
>>> only argument provided - sm8550 - is showing this is soc design.
>>>
>>> I don't reject common solution. I provided review at v1 to which no one
>>> responded, no one argued, no one provided other arguments.
>>
>> Okay, so the specific problem that causes this observable limitation
>> exists on SM8550 and at least one more platform which is not upstream
>> today. It can be caused by various electrical issues, in our specific
>> case by something internal to the SoC (but external factors may apply
>> too)
>>
>> 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

Konrad