Hi Jones & Augus: thanks for your explanations.
Most controllers just take an OPCODE and pass it on to the controller and have done with it. The issue that you're attempting to rectify is that the m25p80 expects every controller to be an SPI controller registered to the SPI framework, but as we both know that's not always practical as the SPI framework doesn't allow all configuration information to be passed back to the controller driver. Our issue is not the same. We are required to send entire 'message sequences', to the controller rather than just opcodes. The JEDEC message sequence can be seen below. Bear in mind that this is also one of the more simple message sequences. Some of them even vary depending on which chip is present.
Frankly speaking, my quadspi driver's code is just like Jones's code. Yes, a big "switch".
The opcode is just like an index to trigger the proper operation. That's why i add this hook @->read_reg(). (the hook acts as the ioctl) If we do not use this hooks, we should add more hooks such as @->read_id, @->read_sr, @->read_cr... That's make the interface not graceful enough. I read the your patch implementing the read_id: http://lists.infradead.org/pipermail/linux-mtd/2013-November/050221.html it's more readable. But i think Jones's stfsm_read_reg() is workable too. If you do not like the read_reg() hook, do you have any better idea? thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
