On 6 March 2018 at 15:20, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Tue, Mar 06, 2018 at 02:42:43PM +0100, Jonas Gorski wrote: >> On 5 March 2018 at 21:35, Mark Brown <broonie@xxxxxxxxxx> 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