On 6 March 2018 at 15:20, Mark Brown broonie@kernel.org wrote:

On Tue, Mar 06, 2018 at 02:42:43PM +0100, Jonas Gorski wrote:

...

On 5 March 2018 at 21:35, Mark Brown broonie@kernel.org wrote:

...

...

It's exposing more capability information but it's in the "how did this ever work without the fix" range, and I'd worry that this might cause us to do something like start exercising handling code in client drivers that had never been tested. Not that I can immediately see any client drivers in mainline that actually pay attention... :/

...

I would assume that most spi client drivers use short messages, so they aren't affected unless the max message size is really short. m25p80 on the other hand will do arbitrarily large transfers/reads, so there it was supported first.

There's a bunch of SPI drivers that do firmware downloads which I'd expect to be affected, the limit the device has is tiny so it's relatively easy to bump into it. It's very rare for devices to be so limited so unfortunately client drivers don't generally check though.

Well, at least for bcm63xx it's very rare to have something other than a flash chip, a (broadcom) ethernet switch management interface, or a SLIC/SLAC attached to the SPI controller. And AFAICT of these three only the flash chip uses large SPI transfers. Furthermore, unless you have a development board, you won't be able to attach anything different to it. So the chance to bump into the limits with other drivers is rather low.

I would assume that this is true for most systems with a limited SPI controller. I would hope that most board designers are sensible enough to not add devices that won't work ;-)

Regards Jonas