linux-kernel - Re: [PATCH v3 1/3] dt-bindings: mmc: Add support for rk3576 dw-mshc

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20e1c51c-0231-40de-919e-664df906a724@kernel.org>
Date: Fri, 16 Aug 2024 10:23:40 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Heiko Stübner <heiko@...ech.de>,
 linux-kernel@...r.kernel.org, Detlev Casanova <detlev.casanova@...labora.com>
Cc: Ulf Hansson <ulf.hansson@...aro.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Jaehoon Chung <jh80.chung@...sung.com>,
 linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 kernel@...labora.com
Subject: Re: [PATCH v3 1/3] dt-bindings: mmc: Add support for rk3576 dw-mshc

On 16/08/2024 09:45, Heiko Stübner wrote:
> Am Freitag, 16. August 2024, 08:52:04 CEST schrieb Krzysztof Kozlowski:
>> On 15/08/2024 15:49, Heiko Stübner wrote:
>>> Am Donnerstag, 15. August 2024, 00:34:00 CEST schrieb Detlev Casanova:
>>>> Add the compatible string for rockchip,rk3576-dw-mshc and add support
>>>> for the rockchip,v2-tuning flag, a new feature of this core.
>>>>
>>>> Signed-off-by: Detlev Casanova <detlev.casanova@...labora.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
>>>> index 211cd0b0bc5f3..0543cdb51c657 100644
>>>> --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
>>>> +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
>>>> @@ -39,6 +39,7 @@ properties:
>>>>                - rockchip,rk3368-dw-mshc
>>>>                - rockchip,rk3399-dw-mshc
>>>>                - rockchip,rk3568-dw-mshc
>>>> +              - rockchip,rk3576-dw-mshc
>>>>                - rockchip,rk3588-dw-mshc
>>>>                - rockchip,rv1108-dw-mshc
>>>>                - rockchip,rv1126-dw-mshc
>>>
>>> this would mark the rk3576-dw-mshc as being the "same" as the
>>
>> Not the same, but compatible.
>>
>>> core rk3288 variant. rk3288 was the first controller introducing the
>>> clock tuning for higher speeds. with the clocks being part of the CRU.
>>>
>>> As we can see in later patches, this rk3576 though changes that
>>> setup with moving the tunable clock configurations into the controller
>>> itself.
>>>
>>> So please don't claim to be compatible to the 3288, but instead start
>>> a new block for this new set of controllers:
>>
>> The question is can new device work with old compatible (without new
>> features)?
> 
> the rk3288 and following have their clock phase tuning for hs-modes in
> the main soc's clock controller. Hence you have the "ciu-drive" and
> "ciu-sample" clocks [0].
> 
> On the rk3576 (and probably following) those clock phase settings moved
> inside the mmc controller itself. So there are no external phase clocks
> anymore.
> 
> So right now we have two types in the binding, the rk2928 type [1],
> used on the old rk3066 and rk3188 socs, that did not support mmc hs-modes
> and the rk3288-type which introduced phase tuning via clocks from the
> main clock controller.
> 
> The rk3576 now switches to having phase tuning in the mmc controller
> itself. So throwing that on unmodified code for the rk3288 will get you
> degraded functionality, because the tuning won't work because there are
> no "ciu-drive" and "ciu-sample" anymore .

One could still argue that rest of programming model is the same, thus
"degraded" mode counts as compatibility, but I do not insist on that.

> 
> 
> And with that separate compatible we could also "tighten" the binding
> a bit to make those additional clocks more explicit for the rk3288 type.
This you can, and actually should, do with existing binding. Maybe just
a bit more tricky/complicated code.

Anyway, fine with both compatibility-approaches.

Best regards,
Krzysztof