linux-kernel - Re: [PATCH 01/13] spi: add core support for controllers with offload capabilities

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: <0c0b1954825dc174cab48060e96ddadadc18aefd.camel@gmail.com>
Date: Thu, 11 Jan 2024 09:49:08 +0100
From: Nuno Sá <noname.nuno@...il.com>
To: David Lechner <dlechner@...libre.com>, Mark Brown <broonie@...nel.org>, 
 Jonathan Cameron <jic23@...nel.org>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley
 <conor+dt@...nel.org>,  Michael Hennerich <michael.hennerich@...log.com>,
 Nuno Sá <nuno.sa@...log.com>, Frank Rowand
 <frowand.list@...il.com>
Cc: Thierry Reding <thierry.reding@...il.com>, Uwe
 Kleine-König <u.kleine-koenig@...gutronix.de>, Jonathan
 Corbet <corbet@....net>,  linux-spi@...r.kernel.org,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org, 
 linux-doc@...r.kernel.org, linux-pwm@...r.kernel.org, 
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/13] spi: add core support for controllers with
 offload capabilities

Hi David,


On Wed, 2024-01-10 at 13:49 -0600, David Lechner wrote:
> This adds a feature for specialized SPI controllers that can record
> a series of SPI transfers, including tx data, cs assertions, delays,
> etc. and then play them back using a hardware trigger without CPU
> intervention.
> 
> The intended use case for this is with the AXI SPI Engine to capture
> data from ADCs at high rates (MSPS) with a stable sample period.
> 
> Most of the implementation is controller-specific and will be handled by
> drivers that implement the offload_ops callbacks. The API follows a
> prepare/enable pattern that should be familiar to users of the clk
> subsystem.
> 
> Consumers of this API will make calls similar to this:
> 
>     /* in probe() */
>     offload = spi_offload_get(spi, 0);
>     ...
> 
On top of what Mark already stated, and as we already discussed offline, I
personally don't like this provider - consumer interface for the offload. The
first thing is that this is taking into account the possibility of having
multiple offload cores. While the FGPA core was designed with that in mind, we
don't really have any design using multiple offloads in one spi engine (always
one). Hence this is all pretty much untested.

If we want to already have this support, my feeling is that we should have a
simple integer dt property for the peripheral devices (similar to cs). When a
device is being created/added, the spi core would parse this property and get
it's offload index. The point is that this would all be transparent for spi
devices drivers that would only have to call the SPI API's and the core would
make sure the right index is passed to the controller.

But honestly, IMO, I would just keep things simple for now and assume one core
per engine.

I would probably also prefer to see all the new interfaces part of the
spi_controller struct directly...

- Nuno Sá