On Wed, Jun 03, 2026 at 01:55:25PM +0100, Jonathan Cameron wrote: > On Wed, 3 Jun 2026 13:26:43 +0100 > Rodrigo Alencar <[email protected]> wrote: > > On 26/06/02 10:14PM, Andy Shevchenko wrote: > > > On Tue, Jun 02, 2026 at 05:33:56PM +0100, Rodrigo Alencar via B4 Relay > > > wrote: > > > > > > > Use of local SPI bus data to manage a collection of SPI transfers and > > > > flush them to the SPI platform driver with the sync() operation. This > > > > allows for faster handling of multiple channel DAC writes, avoiding > > > > kernel > > > > overhead per spi_sync() call, which will be helpful when enabling > > > > triggered buffer support. > > > > > > Why spi_message_alloc() can't be used instead of manual handling? > > > (Seems no current users, so you even can modify it for your needs.) > > > > I need to manually call spi_message_add_tail() to append messages. > > I suppose that such function is a bit weird and no wonder why it > > is not being used. struct spi_message_with_transfers might need > > to be properly declared so that users can populate the transfer > > array without manually moving pointers or having to redefine the type. > > > Agreed it would be significant surgery. Perhaps worth it as a follow up > if you can find a couple of drivers open coding the equivalent. > > Otherwise perhaps send a patch removing spi_message_alloc()
My experience with removing of dead code in SPI is that Mark is reluctant doing that. Maybe if somebody tries that it will work this time. -- With Best Regards, Andy Shevchenko
