linux-kernel - Re: [PATCH RFC v4 00/15] spi: axi-spi-engine: add offload support

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: <72afe00622075f77b410e9537cca0a7ac5a4cba3.camel@gmail.com>
Date: Thu, 24 Oct 2024 16:12:11 +0200
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@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Nuno Sá <nuno.sa@...log.com>, Uwe
 Kleine-König <ukleinek@...nel.org>
Cc: Michael Hennerich <Michael.Hennerich@...log.com>, Lars-Peter Clausen
	 <lars@...afoo.de>, David Jander <david@...tonic.nl>, Martin Sperl
	 <kernel@...tin.sperl.org>, linux-spi@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-iio@...r.kernel.org, linux-pwm@...r.kernel.org
Subject: Re: [PATCH RFC v4 00/15] spi: axi-spi-engine: add offload support

Hi David,

On Wed, 2024-10-23 at 15:59 -0500, David Lechner wrote:
> In this revision, I ended up changing quite a bit more that I was
> expecting.
> 
> In the DT bindings, I ended up dropping the #spi-offload-cells and
> spi-offload properties. A couple of reasons for this:
> 
> 1. Several people commented that it is odd to have a separate provider/
>    consumer binding for something that already has a parent/child
>    relationship (both on this series and in another unrelated series
>    with io-backends). For now, the only SPI offload provider is the AXI
>    SPI Engine, which is a SPI controller.
> 2. In a discussion unrelated to this series, but related to the idea
>    of SPI offloads [1], it became apparent that the proposed use for
>    the cells to select triggers and tx/rx streams doesn't actually
>    work for that case.
> 3. In offline review, it was suggested that assigning specific offloads
>    to specific peripherals may be too restrictive, e.g. if there are
>    controllers that have pools of identical offloads. This idea of
>    pools of generic offloads has also come up in previous discussions
>    on the mailing list.
> 
> [1]:
> https://lore.kernel.org/linux-iio/e5310b63-9dc4-43af-9fbe-0cc3b604ab8b@baylibre.com/
> 
> So the idea is that if we do end up needing to use DT to assign certain
> resources (triggers, DMA channels, etc.) to specific peripherals, we
> would make a mapping attribute in the controller node rather than using
> phandle cells. But we don't need this yet, so it isn't present in The
> current patches.
> 
> And if we ever end up with a SPI offload provider that is not a SPI
> controller, we can bring back the #spi-offload-cells and
> spi-offload properties.

Well I do like we kind of gave a step back and are more focused in supporting what we
have and know at the moment. And I think (for what I saw so far) things are being
implemented in fairly flexible manner. So yeah, as far as I'm concerned, I liked what
I saw so far. Hopefully everyone can agree on this so we drop the RFC :)

I'll try to look at the remaining patches tomorrow...

- Nuno Sá