On 08/10/21 12:02PM, Mika Westerberg wrote: > Hi, > > On Thu, Oct 07, 2021 at 11:30:31PM +0530, Pratyush Yadav wrote: > > > Probably but I would not call these "problems" - it is how the > > > controller is designed. This one is meant only for SPI-NOR flash access, > > > typically used by the BIOS. It is by no means general purpose SPI > > > controller (as you can see from the datasheet). The BIOS does need the > > > full SPI stack, it just issues these simple commands and let's the > > > controller figure out what actually needs to be done. > > > > The problem is not the controller itself. It is perfectly fine piece to > > have a controller like this IMO. The problem is how do we make it fit > > into the SPI MEM model, which seems to be designed for general purpose > > controllers only. This problem is shared with this and the Cadence xSPI > > controller. > > Fully agree. IMHO trying to shoehorn driver like this into a generic SPI > subsystem does not make much sense to me. These things can only talk to > SPI-NOR chips, nothing else. > > Do you have any suggestions how to solve this "problem" so we can move > forward with the drivers? No, I unfortunately don't. But I suppose the same problem existed with the old driver as well. It ignored nor->read_opcode, etc. and did its own thing, so at least I don't expect things to get much worse with the SPI MEM model. -- Regards, Pratyush Yadav Texas Instruments Inc.