On 20/10/21 11:41AM, Boris Brezillon wrote: > On Wed, 13 Oct 2021 14:44:31 +0300 > Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > > The preferred way to implement SPI-NOR controller drivers is through SPI > > subsubsystem utilizing the SPI MEM core functions. This converts the > > Intel SPI flash controller driver over the SPI MEM by moving the driver > > from SPI-NOR subsystem to SPI subsystem and in one go make it use the > > SPI MEM functions. The driver name will be changed from intel-spi to > > spi-intel to match the convention used in the SPI subsystem. > > > > I skimmed over the driver changes, and I'm skeptical about this "let's > convert all spi-nor controller drivers into spi-mem drivers even if > they don't fit the spi-mem model" strategy. Clearly, the intel > controller is much more limited than any other spi-mem controller (I > mean feature-wise not perf-wise of course). The fact that you have to > check the opcode to decide whether the operation is supported or not, > or the way you deduce when to issue an erase vs a regular read/write is > kind of hack-ish. Not saying we shouldn't support this case in spi-mem, > but it should at least be done in a more controlled way. Maybe with an > explicit array of supported spi_mem operations, and driver specific > hooks for each of these operations so anything falling outside is > clearly identified and rejected (we have this sort of things in the raw > NAND framework). I am curious about how we can solve this. Any pointers to functions/drivers in raw NAND framework that follow this model? [...] -- Regards, Pratyush Yadav Texas Instruments Inc.