linux-kernel - Re: [PATCH v5 04/15] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings

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: <4ff85493-665a-ee58-07d3-80178c49223b@linaro.org>
Date:   Tue, 21 Jun 2022 09:00:36 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Serge Semin <fancer.lancer@...il.com>
Cc:     Brad Larson <brad@...sando.io>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mmc@...r.kernel.org, adrian.hunter@...el.com,
        alcooperx@...il.com, andy.shevchenko@...il.com, arnd@...db.de,
        blarson@....com, brijeshkumar.singh@....com,
        catalin.marinas@....com, gsomlo@...il.com, gerg@...ux-m68k.org,
        krzysztof.kozlowski+dt@...aro.org, lee.jones@...aro.org,
        broonie@...nel.org, yamada.masahiro@...ionext.com,
        p.zabel@...gutronix.de, piotrs@...ence.com, p.yadav@...com,
        rdunlap@...radead.org, robh+dt@...nel.org, samuel@...lland.org,
        suravee.suthikulpanit@....com, thomas.lendacky@....com,
        ulf.hansson@...aro.org, will@...nel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v5 04/15] dt-bindings: spi: dw: Add AMD Pensando Elba SoC
 SPI Controller bindings

On 20/06/2022 22:04, Serge Semin wrote:
> On Mon, Jun 20, 2022 at 09:46:25PM +0200, Krzysztof Kozlowski wrote:
>> On 20/06/2022 21:30, Serge Semin wrote:
>>> On Mon, Jun 13, 2022 at 12:56:47PM -0700, Brad Larson wrote:
>>>> From: Brad Larson <blarson@....com>
>>>>
>>>> The AMD Pensando Elba SoC has integrated the DW APB SPI Controller
>>>>
>>>> Signed-off-by: Brad Larson <blarson@....com>
>>>> ---
>>>>  Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>>>> index e25d44c218f2..2a55b947cffc 100644
>>>> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>>>> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>>>> @@ -73,6 +73,8 @@ properties:
>>>>                - renesas,r9a06g032-spi # RZ/N1D
>>>>                - renesas,r9a06g033-spi # RZ/N1S
>>>>            - const: renesas,rzn1-spi   # RZ/N1
>>>
>>>> +      - description: AMD Pensando Elba SoC SPI Controller
>>>> +        const: amd,pensando-elba-spi
>>>
>>> Not enough. The driver requires to have a phandle reference to the
>>> Pensando System Controller. So the property like
>>> "amd,pensando-elba-syscon" is also needed to be added to the DT schema
>>> otherwise should the dt-schema tool correctly handle the
>>> "unevaluatedProperties: false" setting (Rob says it isn't fully
>>> supported at the moment), the dtbs_check procedure will fail on your
>>> dts evaluation.
>>
> 
>> The property was here before, now removed, so I assume it was also
>> removed from the driver and DTS. Isn't that the case?
> 
> Ah, the property has been indeed removed. The driver now searches for
> the system controller by the next compatible string:
> "amd,pensando-elba-syscon" using the
> syscon_regmap_lookup_by_compatible() method. My mistake. Sorry for the
> noise.
> 
> * Though personally I'd prefer to have a property with the phandle
> reference in order to signify the connection between the system controller
> and the SPI-controller. Otherwise the implicit DT bindings like having
> the "amd,pensando-elba-syscon"-compatible syscon gets to be
> hidden behind the DT scene. But seeing we have already got the Microsemi
> platform with such semantic, I can't insist on fixing this.

I agree entirely, this should be explicit syscon-type property. Looking
up for compatibles:
 - creates hidden (not expressed via bindings) dependency between nodes,
 - is not portable and several people struggled with it later and needed
backward-compatible code (many examples, let's just give recent one: [1])


[1]
https://lore.kernel.org/all/20220619151225.209029-10-tmaimon77@gmail.com/


Best regards,
Krzysztof