linux-kernel - Re: [PATCH v3 4/6] spi: spi-axi-spi-engine: Add support for MOSI idle configuration

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: <20240609101128.4a003446@jic23-huawei>
Date: Sun, 9 Jun 2024 10:11:28 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Marcelo Schmitt <marcelo.schmitt1@...il.com>
Cc: Nuno Sá <noname.nuno@...il.com>, David Lechner
 <dlechner@...libre.com>, Marcelo Schmitt <marcelo.schmitt@...log.com>,
 broonie@...nel.org, lars@...afoo.de, Michael.Hennerich@...log.com,
 robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
 nuno.sa@...log.com, linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
 linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/6] spi: spi-axi-spi-engine: Add support for MOSI
 idle configuration

On Fri, 7 Jun 2024 11:40:23 -0300
Marcelo Schmitt <marcelo.schmitt1@...il.com> wrote:

> On 06/07, Nuno Sá wrote:
> > On Thu, 2024-06-06 at 18:31 -0300, Marcelo Schmitt wrote:
> > 
> > ...
> >   
> > > 
> > > 
> > > 
> > > When is a driver version check needed?
> > > Yes, older versions of SPI-Engine won't support this, but the patch set should
> > > cause no regression. Even if loading the current ad4000 driver with
> > > older SPI-Engine HDL and driver, the ADC driver would get a warn (or error?)
> > > and do what's possible without MOSI idle feature (probably only be able to do
> > > reg access) or fail probing.
> > >   
> > 
> > Maybe I'm missing something but with the patchset we unconditionally set
> > SPI_MOSI_IDLE_HIGH. So if we load an hdl which does not support it things will
> > apparently be ok but it won't actually work, right? If I'm right we should have  
> Yes, that's correct.
> 
> > a bit in a RO config_register telling us that the feature is being supported or
> > not. That way we only set the mode bit if we do support it...  
> 
> Ok, understood. Will do it for v4.
If you don't have such a mode bit, you will need to add a property to the
dt-binding. Or a suitable compatible.

Nasty, so fingers crossed you do have a capability flag to check!

Jonathan

> 
> Thanks,
> Marcelo
> 
> > 
> > - Nuno Sá
> > 
> >