linux-kernel - Re: [PATCH v5 2/2] dt-bindings: fpga: add binding doc for ecp5-spi fpga mgr

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: <20220729163347.irqqqcvh2biliqg2@x260>
Date:   Fri, 29 Jul 2022 19:33:47 +0300
From:   Ivan Bornyakov <i.bornyakov@...rotek.ru>
To:     Daniel Glöckner <dg@...ix.com>
Cc:     mdf@...nel.org, hao.wu@...el.com, yilun.xu@...el.com,
        trix@...hat.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, linux-fpga@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        system@...rotek.ru,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v5 2/2] dt-bindings: fpga: add binding doc for ecp5-spi
 fpga mgr

On Fri, Jul 29, 2022 at 11:01:24AM +0200, Daniel Glöckner wrote:
> Hi,
> 
> On Tue, Jul 19, 2022 at 02:23:35PM +0300, Ivan Bornyakov wrote:
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - lattice,ecp5-fpga-mgr
> 
> Since this driver uses the same interface as the existing
> drivers/fpga/machxo2-spi.c driver, wouldn't it be advisable to use a
> similar compatible id, i.e. lattice,ecp5-slave-spi?
> 

To quote Krzysztof Kozlowski from v1 review:
 > Do not encode interface name in compatible so no "spi"

See https://lore.kernel.org/linux-fpga/044a9736-a4ec-c250-7755-c80a5bcbe38b@linaro.org/

> > +required:
> > +  - compatible
> > +  - reg
> > +  - program-gpios
> > +  - init-gpios
> > +  - done-gpios
> 
> I think some of the GPIOs can be made optional by reading the status
> register or using the refresh command, assuming the slave spi interface
> stayed enabled after previous programming and we are not dealing with
> several chained FPGAs. But that can of course be left as an exercise for
> other developers.

I would prefer the latter.