On Mon, Jun 06, 2016 at 07:34:26PM +0100, Mark Brown wrote: > On Mon, Jun 06, 2016 at 11:28:03AM -0700, Brian Norris wrote: > > On Mon, Jun 06, 2016 at 06:40:03PM +0100, Mark Brown wrote: > > > On Sat, Jun 04, 2016 at 12:22:37AM +0200, Heiner Kallweit wrote: > > > > > I'd like to come back to this discussion. You said best would be to fix > > > > the chip driver. To do this and calculate an appropriate value for > > > > max_transfer_size the chip driver would have to know that the spi_device > > > > is a spi-nor device. > > > > That doesn't make any sense, the controller hardware doesn't magically > > > change based on what is connected to it. > > > I believe Heiner has an (unstated here, but stated elsewhere?) > > assumption that his driver has a maximum *message* size, not *transfer* > > size. So he's explaining how to work around that by implicitly figuring > > out what the message size would be based on a transfer size, I think. > > That still wouldn't explain how this could depend on the connected > device, the message size isn't going to change any more than the > transfer size is. Ah, well I bet Heiner's mostly just testing flash (m25p80) and/or m25p80 is one of the bigger stressors. Anyway, you're definitely correct that Heiner's suggested approach is not good. He's essentially implying his driver should be intuiting the message size / transfer size patterns for arbitrary users. I suppose we really just need to figure out what his actual problem is, so we can address it generically. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html