On 6 August 2015 at 13:23, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote: > >> However, I am familiar m25p80.c and as I understand it the controller >> is basically supposed to implement m25p80.c in hardware when this flag >> is set. > > But what in concrete terms is that supposed to mean? It's currently > just an essentially undocumented flag on a message rather than something > operating at the level of a flash chip. That's pretty much where > Russell's comments come from. > >> If I was using m25p80.c to talk to anything but an actual flash chip >> it would get me quite worried. > > Sure, but at the end of the day it's just emitting standard SPI messages > which don't know anything about flash. If those messages are a sensible > interface here then why bother with the flag, we can just pattern match > on the format of the message. If that doesn't work then probably this > isn't a great interface and a separate, application specific interface > makes more sense. The messages are sensible interface for communicating with a device that interprets a particular part of the mesasge as address and another particular part of the message as command and sends same amount of junk before reply as the flash chip would. If your device happens to send reply immediately part of it is trashed. If it happens to interpret address differently the data ends up in random part of your memory. So no, that is not something you can autodetect. At the end of the day you have valid SPI messages but the m25p80 layer adds interpretation to those messages which may not always give correct result. On the other hand, if you ever get to m25p80 or spi-nor you can assume any message you send goes to a flash chip and insist that the controller uses the flash-specific interface. If there is possibility of connecting different kind of devices to multiple chipselects on the same master then you probably want to select this option per message or per slave. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
