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: <5b62d742fa789e9860781b6f5f1fda4f583b0e5b.camel@gmail.com>
Date: Thu, 11 Jan 2024 15:11:32 +0100
From: Nuno Sá <noname.nuno@...il.com>
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

On Thu, 2024-01-11 at 13:33 +0000, Mark Brown wrote:
> On Thu, Jan 11, 2024 at 09:49:08AM +0100, Nuno Sá wrote:
> > On Wed, 2024-01-10 at 13:49 -0600, David Lechner wrote:
> 
> > >     /* 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.
> 
> I tend to agree that we shouldn't be exposing this to SPI device drivers
> however we will want to keep track of if the unit is busy, and designing
> it to cope with multiple offloads does seem like sensible future
> proofing.  There's also the possibility that one engine might be able to

Fair enough. But wouldn't a simple DT integer property (handled by the spi core)
to identify the offload index be easier for SPI device drivers? We could still
have dedicated interfaces for checking if the unit is busy or not... The point
is that we would not need an explicit get() from SPI drivers.

I'm of course assuming that one spi device can only be connected to one engine
which seems reasonable to me.

- Nuno Sá