Hi, removing Uwe from CC as this address bounces. Am Freitag, 21. Juni 2024, 09:09:56 CEST schrieb Michael Walle: > On Fri Jun 21, 2024 at 8:49 AM CEST, Alexander Stein wrote: > > Hi everyone, > > > > sorry for being late to the party. I just noticed this discussion while > > reading [1]. > > > > Am Dienstag, 4. Juni 2024, 09:42:31 CEST schrieb Michael Walle: > > > These devices are more like an AT25 compatible EEPROM instead of > > > flashes. Like an EEPROM the user doesn't need to explicitly erase the > > > memory, nor are there sectors or pages. Thus, instead of the SPI-NOR > > > (flash) driver, one should instead use the at25 EEPROM driver. > > > > > > Signed-off-by: Michael Walle <mwalle@xxxxxxxxxx> > > > Cc: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> > > > Cc: Thorsten Scherer <t.scherer@xxxxxxxxxxxx> > > > Cc: Marek Vasut <marex@xxxxxxx> > > > Cc: Imre Kaloz <kaloz@xxxxxxxxxxx> > > > Cc: Andrew Lunn <andrew@xxxxxxx> > > > Cc: Flavio Suligoi <f.suligoi@xxxxxxx> > > > --- > > > The referenced binding only supports the true AT25 compatible EEPROMs > > > where you have to specify additional properties like size and page size > > > or cypress FRAM devices where all the properties are discovered by the > > > driver. I don't have the actual hardware, therefore I can't work on a > > > proper driver and binding. But I really want to deprecate the use of > > > these EEPROM like devices in SPI-NOR. So as a first step, mark the > > > devices in the DT bindings as deprecated. > > > > > > There are three in-tree users of this. I hope I've CCed all the relevant > > > people. With the switch to the at25 driver also comes a user-space > > > facing change: there is no more MTD device. Instead there is an "eeprom" > > > file in /sys now, just like for every other EEPROM. > > > > > > Marek already expressed, that the sps1 dts can likely be removed > > > altogether. I'd like to hear from the other board DTS maintainers if > > > they seem some problems moving to the EEPROM interface - or maybe that > > > device isn't used at all anyway. So in the end, we can hopefully move > > > all the users over to the at25 driver. > > > > So instead of spi-nor you want to use at25 for this MRAM devices? > > Yes. > > > AFAICS at25 is a spi only driver, but spi-nor is a spi-mem driver. So I am > > wondering if at25 driver is capable of using QSPI hosts. > > spi-mem support could be added to the at25 driver. But probably > mainly because there are SPI controllers out there which only have > an interface to attach memory (like the FlexSPI from NXP). Yes, FlexSPI is my current area of interest. > > Everspin EMxxLXB devices are capable of running in xSPI modes. > > Regarding QSPI (DSPI/OSPI as well) I assumed spi-nor is a given, but maybe > > I am completely wrong here. Maybe someone could clarify this. > > These newer devices should also support the erase command, right? So > they can be a "real" flash. If they support SFDP, the would even be > supported out of the box. The mentioned everspin devices are much > older and behaves more like an EEPROM instead of a flash. I see this is about older devices, I got misled by the subject. The new devices EMxxLX devices do not support SFDP. There are erase commands, but unless you want to set sectors/whole chip to a defined state, this seems unneeded, so SPI_NOR_NO_ERASE would be sensible. I'm wondering if the comment in [1] is still applicable unconditionally, as there still is a use-case for spi-nor on flexspi. Best regards, Alexander [1] https://lore.kernel.org/linux-kernel/D0C9NCOMI27O.2VW2U3FNFTSPK@xxxxxxxxxx/ -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider http://www.tq-group.com/
