Hi, On 18/02/20 12:42 pm, Behme Dirk (CM/ESO2) wrote: > Hi Vignesh, > > On 18.02.2020 05:00, Vignesh Raghavendra wrote: >> Hi Sergei >> [...] >> >> Looking around, there seems to be more than one SPI controllers, apart >> from Renesas, which also support SPI NOR and HyperFlash protocol within >> a single IP block. E.g.: Cadence xSPI controller [1]. Therefore, we need >> a generic framework to support these kind of controllers. >> >> One way would be to extend spi_mem_op to support above template along >> with a new field to distinguish SPI NOR vs HyperFlash protocol. HyperBus >> core can then register a spi_device and use spi-mem ops to talk to >> controller driver. >> So, I suggest making Renesas RPC-IF backend a full fledged spi-mem >> driver (instead of driver/memory) and use extended spi_mem_op to support >> HyperFlash. > > > From Renesas Hyperflash user point of view, I wonder if a two step > approach would be possible and acceptable, here? > > Being a user of the Renesas Hyperflash, I want a driver for that. And, > of course, I want it "now" ;) > > So I wonder if it would be a valid option to have a functioning Renesas > Hypeflash driver, first. And in a second step abstract that in a more > generic way to support additional controllers. While in parallel having > a functional driver for the Renesas people, already. > AFAICS, the backend driver is not merged and is still in RFC phase. Therefore I don't see any benefit of two step approach here. Besides you'll have to throw away this new driver (hyperbus/rpc-if.c) entirely later on. How difficult is it to rewrite backend to be spi-mem driver? There is already has a spi_mem_ops frontend implementation, so I don't see much of an issue. Extending hyperbus core to use spi-mem should also straight forward Would involve moving this patch into core file. > Is the support for [1] a more or less theoretical one, at the moment? Or > are there users of that which need support "now", too? > Its not theoretical, I do see patches for xSPI controller here: https://patchwork.kernel.org/cover/11354193/ So, its best to sort this out now so as to avoid possible backward compatibility issues (especially with DT bindings) Regards Vignesh ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/