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: <20240112100347.548298e9@erd003.prtnl>
Date: Fri, 12 Jan 2024 10:03:47 +0100
From: David Jander <david@...tonic.nl>
To: Mark Brown <broonie@...nel.org>
Cc: David Lechner <dlechner@...libre.com>, 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>, 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 Mark, David,

Thanks for CC'ing me. Been reading the discussion so far.

On Thu, 11 Jan 2024 21:49:53 +0000
Mark Brown <broonie@...nel.org> wrote:

> On Thu, Jan 11, 2024 at 03:32:54PM -0600, David Lechner wrote:
> > On Thu, Jan 11, 2024 at 2:54 PM David Lechner <dlechner@...libre.com> wrote:  
> 
> > > > (CCed) a while back when he was doing all the work he did on optimising
> > > > the core for uncontended uses, the thinking there was to have a
> > > > spi_prepare_message() (or similar) API that drivers could call and then
> > > > reuse the same transfer repeatedly, and even without any interface for
> > > > client drivers it's likely that we'd be able to take advantage of it in
> > > > the core for multi-transfer messages.  I'd be surprised if there weren't
> > > > wins when the message goes over the DMA copybreak size.  A much wider
> > > > range of hardware would be able to do this bit, for example David's case
> > > > was a Raspberry Pi using the DMA controller to write into the SPI  
> 
> > For those, following along, it looks like the RPi business was
> > actually a 2013 discussion with Martin Sperl [2]. Both this and [1]
> > discuss proposed spi_prepare_message() APIs.  
> 
> > [2]: https://lore.kernel.org/linux-spi/CACRpkdb4mn_Hxg=3tuBu89n6eyJ082EETkwtNbzZDFZYTHbVVg@mail.gmail.com/T/#u  
> 
> Oh, yes - sorry, I'd misremembered which optimisation effort it was
> associated with.  Apologies.

Yes. It was Martin Sperl who proposed this on a Rpi. I mentioned something
similar toward the end of my 2nd email reply in that thread [1]. That might
have triggered the confusion.
As for my interests, I am all for devising ways to make the SPI subsystem more
suitable for optimized high-performance use-cases. In that regard, I think
re-usable messages (spi_prepare_message()) can be useful. More capable
hardware can enable very powerful use-cases for SPI, and it would be cool if
the spi subsystem had the needed infrastructure to support those. As for
hardware-triggers, I still need to wrap my head around how to have a
universally usable API that works nice for the first use-case that comes along
and also doesn't screw up the next use-case that might follow. Keep me posted.

[1] https://lore.kernel.org/linux-spi/20220513144645.2d16475c@erd992/

Best regards,

-- 
David Jander
Protonic Holland.