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]
Date:   Wed, 17 May 2023 10:26:07 +0200
From:   Börge Strümpfel <boerge.struempfel@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     bstruempfel@...ratronik.de, andy.shevchenko@...il.com,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        linux-spi@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 1/4] spi: dt-bindings: Introduce spi-mosi-idle-low flag

Thank you for your feedback

Am Mo., 15. Mai 2023 um 02:34 Uhr schrieb Mark Brown <broonie@...nel.org>:
>
> On Fri, May 12, 2023 at 08:54:19AM +0200, Börge Strümpfel wrote:
> > Am Fr., 12. Mai 2023 um 05:30 Uhr schrieb Mark Brown <broonie@...nel.org>:
>
> > > If this is always required for a given device (which I'd expect to be
> > > the case) why configure it through DT?  I know we've got some legacy
> > > stuff like that but not all legacy DT choices were good and no need to
> > > continue the pattern.
>
> > Yes this will always be the case for specific spi-device, spi-controller
> > combinations. Just to make sure, that I understand your suggestion
> > correctly: You propose to check from the specific spi-device-driver, if
> > the spi-controller supports this particular mode-bit, and then set it if
> > it does and thereby loose the need for the DT entry completely?
>
> Yes, we shouldn't need DT here.  Though the device should just be
> setting this unconditionally if it's always required.

I agree with you, that we should not need DT here. I will remove the
dt-binding in the next patch version.

However I am not so sure about setting it unconditionally, since this
is dependent on the spi-controller. Not all spi-controller show this
behavior, that they use a high mosi line in idle mode and have the
ability to change this. As far as I know, another common behavior
is that the mosi just keeps the last state which it transmitted. In this
case, devices like Neopixel would still work without this mode bit.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ