linux-kernel - Re: [PATCH 05/10] dt-bindings: interconnect: Add sm8350, sc8280xp and generic OSM L3 compatibles

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: <910c152d-5e1a-4667-2f0a-a1524f51958c@linaro.org>
Date:   Thu, 3 Nov 2022 11:56:20 -0400
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Bjorn Andersson <andersson@...nel.org>
Cc:     Bjorn Andersson <quic_bjorande@...cinc.com>,
        Georgi Djakov <djakov@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Sibi Sankar <quic_sibis@...cinc.com>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Mike Tipton <quic_mdtipton@...cinc.com>,
        Johan Hovold <johan+linaro@...nel.org>,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 05/10] dt-bindings: interconnect: Add sm8350, sc8280xp and
 generic OSM L3 compatibles

On 03/11/2022 11:46, Bjorn Andersson wrote:
> On Thu, Nov 03, 2022 at 08:25:17AM -0400, Krzysztof Kozlowski wrote:
>> On 02/11/2022 23:44, Bjorn Andersson wrote:
>>> On Fri, Oct 28, 2022 at 06:12:29PM -0400, Krzysztof Kozlowski wrote:
>>>> On 27/10/2022 23:41, Bjorn Andersson wrote:
>>>>> Add EPSS L3 compatibles for sm8350 and sc8280xp, but while at it also
>>>>> introduce generic compatible for both qcom,osm-l3 and qcom,epss-l3.
>>>>>
>>>>> Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
>>>>> ---
>>>>>  .../bindings/interconnect/qcom,osm-l3.yaml    | 22 +++++++++++++------
>>>>>  1 file changed, 15 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
>>>>> index bf538c0c5a81..ae0995341a78 100644
>>>>> --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
>>>>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
>>>>> @@ -16,13 +16,21 @@ description:
>>>>>  
>>>>>  properties:
>>>>>    compatible:
>>>>> -    enum:
>>>>> -      - qcom,sc7180-osm-l3
>>>>> -      - qcom,sc7280-epss-l3
>>>>> -      - qcom,sc8180x-osm-l3
>>>>> -      - qcom,sdm845-osm-l3
>>>>> -      - qcom,sm8150-osm-l3
>>>>> -      - qcom,sm8250-epss-l3
>>>>> +    oneOf:
>>>>> +      items:
>>>>
>>>> oneOf expects a list, so this should be "    - items"
>>>>
>>>
>>> Ahh, thanks. Must have missed running the dt_binding_check on this one.
>>>
>>>>> +        - enum:
>>>>> +            - qcom,sc7180-osm-l3
>>>>> +            - qcom,sc8180x-osm-l3
>>>>> +            - qcom,sdm845-osm-l3
>>>>> +            - qcom,sm8150-osm-l3
>>>>> +        - const: qcom,osm-l3
>>>>
>>>> The concept is good, but are you sure all SoCs will be compatible with
>>>> generic osm-l3?
>>>
>>> Per the current implementation yes, worst case if one or more of them isn't the
>>> more specific compatible can be used to alter the behavior of that platform.
>>>
>>>> Why not using dedicated compatible of one soc, e.g. the
>>>> oldest here? We already did like that for BWMON, DMA and few others.
>>>>
>>>
>>> Because if we say compatible = "qcom,sc8180x-osm-l3", "qcom,sdm845-osm-l3" and
>>> there is a quirk needed for "qcom,sdm845-osm-l3" we're forced to add a "special
>>> case" every other *-osm-l3 in the driver.
>>>
>>> This way we can have a generic implementation for the qcom,osm-l3 and if we
>>> realize that we need to quirk something for the oldest platform, we can do so
>>> without affecting the others.
>>
>> True. This also means we do not really know which one is the generic
>> implementation :)
>>
> 
> There currently is an implementation without platform specific quirks, I
> call that the generic implementation and suggest that we refer to that
> using "qcom,osm-l3".>
> If we instead were to use sdm845 as the generic compatible, and there
> turns out to be a need for a quirk for this platform, you:
> 
> 1) no longer have a generic implementation, but 4 platform-specific
>    implementations

It's okay because there is no such thing anymore as "generic
implementation". If this happened, your generic compatible is not
specific enough. It does not represent any specific hardware.

Adding generic compatibles just to make driver binding easier, is a bit
in contrast with DT which should focus on hardware description.

> 
> 2) have 3 platforms claiming to be compatible with the quirked (now
>    specialized) implementation, which they clearly aren't anymore

Yes, that's the problem and this is why I mentioned that we do not know
the generic implementation. If we knew that sdm845 is the generic, we
would not expect specific quirks for it.

If you cannot make sdm845 generic because of unknown quirk, then you
just do not know which one is generic implementation and that compatible
is not specific enough... Or it is specific only to current Linux driver.

> Therefor I favor using generic names for generic compatibles.

They make driver development easier but they hide the real match between
hardware and compatible.

Best regards,
Krzysztof