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: <faa93bb8-ebc2-4f95-84ca-a61b80188e20@collabora.com>
Date: Thu, 3 Oct 2024 10:52:25 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Pablo Sun <pablo.sun@...iatek.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v3 3/6] dt-bindings: nvmem: mediatek: efuse: Reuse
 mt8186-efuse in mt8188

Il 03/10/24 10:13, Krzysztof Kozlowski ha scritto:
> On Wed, Oct 02, 2024 at 09:42:32AM +0200, AngeloGioacchino Del Regno wrote:
>> Il 02/10/24 08:11, Krzysztof Kozlowski ha scritto:
>>> On Wed, Oct 02, 2024 at 10:21:35AM +0800, Pablo Sun wrote:
>>>> mt8188 has the same GPU speed binning efuse field just
>>>> like mt8186, which requires post-processing to convert to the
>>>> bit field format specified by OPP table.
>>>>
>>>> Add the binding for the compatible list:
>>>>     "mediatek,mt8188-efuse", "mediatek,mt8186-efuse"
>>>> so mt8188 uses the same conversion.
>>>>
>>>> Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>>>> Signed-off-by: Pablo Sun <pablo.sun@...iatek.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml | 4 ++++
>>>>    1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
>>>> index 32b8c1eb4e80..70815a3329bf 100644
>>>> --- a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
>>>> +++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
>>>> @@ -39,6 +39,10 @@ properties:
>>>>                  - mediatek,mt8195-efuse
>>>>                  - mediatek,mt8516-efuse
>>>>              - const: mediatek,efuse
>>>> +      - items:
>>>> +          - enum:
>>>> +              - mediatek,mt8188-efuse
>>>> +          - const: mediatek,mt8186-efuse
>>>
>>> And this is not compatible with generic one? This is confusing. Why are
>>> you adding generic fallbacks if they are not valid?
>>>
>>
>> It was my suggestion to start dropping the usage of the generic "mediatek,efuse"
>> fallback, as I've seen multiple times feedback saying to not use generic fallbacks.
>>
>> Was that wrong?
> 
> No, just nothing provided the background that such change is
> intentional. Please mention in commit msg that the preferred way from
> now on is not using the generic fallback.  Maybe even add it to the
> binding itself as comment, so people won't grow the enum with fallback.
> 

Cool. Thanks for the explanation, krzk.

Pablo, can you please add a comment in the binding saying that no more entries
shall be added to the generic fallback set?

Having a comment there, instead of just into the commit message, would be (imo)
better... as then, anyone trying to add new compatibles will be more likely to
read that.

Cheers,
Angelo


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ