Hi Mark, On Thu, May 20, 2021 at 02:56:15PM +0100, Mark Brown wrote: > On Thu, May 20, 2021 at 04:50:31PM +0300, Vladimir Oltean wrote: > > > Only that certain SPI controllers, such as the spi-sc18is602 I2C-to-SPI > > bridge, cannot keep the chip select asserted for that long. > > The spi_max_transfer_size() and spi_max_message_size() functions are how > > the controller can impose its hardware limitations upon the SPI > > peripheral driver. > > You should respect both, frankly I don't see any advantage to using > cs_change for something like this - just do a bunch of async SPI > transfers and you'll get the same effect in terms of being able to keep > the queue for the controller primed with more robust support since it's > not stressing edge cases. cs_change is more for doing things that are > just very non-standard. Sorry, I don't really understand your comment: in which way would it be more robust for my use case to use spi_async()? The cs_change logic was already there prior to this patch, I am just reiterating how it works. Given the way in which it works (which I think is correct), the most natural way to limit the buffer length is to look for the max transfer len.