linux-kernel - Re: [PATCH v2 2/2] spi: npcm-pspi: Add NPCM845 peripheral SPI support

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: <CAP6Zq1iRowFv4qg=AqdVmBRRx5p4-5AaC1G-aZs=2LnOAOELXA@mail.gmail.com>
Date:   Sun, 24 Jul 2022 11:44:29 +0300
From:   Tomer Maimon <tmaimon77@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Avi Fishman <avifishman70@...il.com>,
        Tali Perry <tali.perry1@...il.com>,
        Joel Stanley <joel@....id.au>,
        Patrick Venture <venture@...gle.com>,
        Nancy Yuen <yuenn@...gle.com>,
        Benjamin Fair <benjaminfair@...gle.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        OpenBMC Maillist <openbmc@...ts.ozlabs.org>,
        linux-spi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] spi: npcm-pspi: Add NPCM845 peripheral SPI support

Hi Mark and Krzysztof,

Thanks for your reply,

On Fri, 22 Jul 2022 at 21:57, Mark Brown <broonie@...nel.org> wrote:
>
> On Fri, Jul 22, 2022 at 08:47:24PM +0200, Krzysztof Kozlowski wrote:
> > On 22/07/2022 20:43, Mark Brown wrote:
>
> > > ...with a fallback list required by the bindings so the driver actually
> > > binds.  Note that bindings are currently not in YAML format so there'd
> > > be even less enforcement of that than normal, and as they're currently
> > > written the bindings don't require fallback.
>
> > Yes, the bindings document should be rephrased but we were living like
> > that for few years. :)
>
> The binding document as it stands only has one compatible, there's no
> existing problem with it other than the YAML conversion.  If we're
> adding something new that requires a fallback we should be explicit
> about that rather than have something that's actively misleading where
> previously things were clear.  I don't mind if we add the compatible to
> the driver or document the requirement for the fallback but we should do
> one of the two.

is V2 good enough? adding the compatible to the driver and the document?
Or should we use fallback?
If fallback is choosen, can you explain how I should do it?

Best regards,

Tomer