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@xxxxxxxxxxxx/ > > 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á
