On 5 March 2018 at 21:35, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Mon, Mar 05, 2018 at 08:07:46PM +0000, Sasha Levin wrote: >> On Mon, Mar 05, 2018 at 10:23:10AM +0000, Mark Brown wrote: >> >On Sat, Mar 03, 2018 at 10:27:56PM +0000, Sasha Levin wrote: > >> >> The bcm63xx SPI controller does not allow manual control of the CS >> >> lines and will toggle it automatically before and after sending data, >> >> so we are limited to messages that fit in the FIFO buffer. Since the CS >> >> lines aren't available as GPIOs either, we will need to make slave >> >> drivers aware of this limitation so they can handle them accordingly. > >> >This seems really aggressive for stable... > >> Why so? > > 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. m25p80 supports max_transfer_size since 4,9, and max_message_size since 4.11 with commit 9e276de6a367cde07c1a63522152985d4e5cca8b. So that one would need to be backported as well for the max_message_size being actually meaningful. tinydrm-helpers also observes max_transfers_size since 4.11 with commit 9f69eb5c36a644571cca6b2f8dc5f6a7cba04a8b where it was added, but since this is a larger commit and not just a "bugfix" one, this doesn't seem like a candidate for backporting. Regards Jonas