On Mon, May 24, 2021 at 04:02:12PM +0300, Vladimir Oltean wrote: > On Mon, May 24, 2021 at 09:35:29AM +0100, Mark Brown wrote: > > This is not the case, spi_message_max_size() is a limit on the size of a > > spi_message. > That is true, although it doesn't mean much, since in the presence of > cs_change, a spi_message has no correspondent in the physical world > (i.e. you can't look at a logic analyzer dump and say "this spi_message > was from this to this point"), and that is the problem really. It may affect how things are implemented by the driver, for example if the driver can send a command stream to the hardware the limit might be due to that command stream. There is no need or expectation for drivers to pattern match what the're being asked to do and parse out something that should be a string of messages from the spi_message they get, it is expected that client drivers should split things up naturally. > Describing the controller's inability to send more than N SPI words with > continuous chip select using spi_message_max_size() is what seems flawed > to me, but it's what we have, and what I've adapted to. I can't entirely parse that but the limit here isn't to do with how long chip select is asserted for.
Attachment:
signature.asc
Description: PGP signature
