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:

quoted

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.