Messages in this thread | | | Date | Mon, 7 May 2018 10:34:49 +0200 | From | Boris Brezillon <> | Subject | Re: [PATCH] spi-nor: Add support for Atmel Dataflash memories |
| |
Hi Nicolas,
On Mon, 7 May 2018 10:23:56 +0200 Nicolas Ferre <nicolas.ferre@microchip.com> wrote:
> On 04/05/2018 at 20:38, Boris Brezillon wrote: > > Hi Radu, > > > > Sorry for the late reply. > > > > On Wed, 28 Feb 2018 13:55:01 +0200 > > Radu Pirea <radu.pirea@microchip.com> wrote: > > > >> This patch add support in spi-nor for allmost all dataflash memories > >> supported by old mtd_dataflash driver. > > > > Those devices clearly use a different instruction set, so I don't think > > they fit in this framework. Can you tell us why you want to move > > dataflash support to the SPI NOR framework. I think I know why, but I'd > > like to get your version. My guess is that some people want to connect > > dataflash chips to the Atmel QSPI controller, and it's not supported > > right now because the Atmel QSPI controller implements the SPI-NOR > > interface and not the generic SPI one, thus preventing anything that > > is not a SPI NOR from being connected to this controller. > > > > If I'm right, then the solution is to convert the QSPI driver to the > > spi-mem interface [1] and move it to drivers/spi/. > > No, I we didn't think about this. Dataflash is not so popular those days > and we don't want to revive it anyway. Our QSPI driver has already a lot > of things to handle in QSPI-related topics to not mix it with oldies ;-) > > The rationale behind this work is to get rid of the very old dataflash > standalone driver and benefit from the whole spi-nor infrastructure like > cache coherency management and DMA handling (which were broken in the > old dataflash driver in recent kernels).
Still don't think that's a good move, especially since those flashes are using a completely different instruction set and are not exactly behaving like SPI NORs. If we need some of the spi-nor logic to help handle dataflash chips in a more efficient/safe way, then those bits should be exposed as helpers at the MTD level instead of turning spi-nor into a Frankenstein framework.
Regards,
Boris
| |