08:50 <mwalle> is there a common practice how to deprecate device support in the kernel? I'd like to get rid of the misuse of the spi-nor for some EEPROM like FRAMs. It's such a maintenance burden. The correct way would be to use the at25 driver for these parts. But then we don't have an /dev/mtdN for these, so it's not the same. Uhm.

08:52 <mwalle> Of all the oddball devices, there is only one device used in device trees: mr25h256

09:25 <arnd> can you give more detail about what would have to change? Are these dts files that are wrongly describing hardware, or some driver that does the wrong thing?

09:27 <geertu> mwalle: Add everspin,mr25h256 to at25_of_match[] and change the configs?

09:43 <mwalle> arnd: devices in question are all the SPI-NOR parts with SPI_NOR_NO_ERASE (CAT25_INFO will set that one automatically). Most of them doesn't support autodetection, like the ones in catalyst.c, they seem to be ancient and there are no users, I'd just remove them

09:44 <mwalle> arnd: but things get complicated with everspin,mr25h256, there are in-tree users in arch/arm. So while you could convert them to the proper driver that is 'compatible = "everspin,mr25h256", "atmel,at25"' it won't behave the same in userspace. I.e. there will be no /dev/mtd for it

09:45 <mwalle> geertu: ^^

09:47 <geertu> mwalle: That's unfortunate, but not uncommon (cfr. e.g. fbdev->drm)

09:47 <mwalle> funny enough there is a mb85rs1mt in our fujitsu.c which already have a proper DT binding for the at25, see Documentation/devicetree/bindings/eeprom/at25.yaml

09:49 <mwalle> geertu: mh, how did that work? sorry i may be too "new" to the kernel development

09:51 <geertu> mwalle: fbdev uses /dev/fb*, drm uses /dev/drm*

09:52 <javierm> mwalle: maybe another option is to add a new SPI_NOR_DEPRECATED Kconfig symbol that's default to 'n' and conditionally add the of_device_id entries for the deprecated devices when enabled?

09:52 <javierm> mwalle: and if after a couple of releases nobody complains, then you could remove ?

09:53 <javierm> mwalle: I see that other subsystems do something like that

09:53 <geertu> mwalle: If you add everspin,mr25h256 to at25_of_match[], but don't remove the entry in the spi-nor driver, things will work fine if people enable either the at25 or spi-nor driver

09:53 <geertu> If they enable both, what they get depends on probe order :-(

09:59 <krzk> geertu: mwalle: you could make driver excluding each other in Kconfig.

10:03 <geertu> krzk: Several of my boards use both at25 and spi-nor. So it would be better to exclude the specific entry in the spi-nor driver using #if !IS_ENABLED(CONFIG_EEPROM_AT25)

10:04 <krzk> geertu: ack, seems better

10:38 <conchuod> Anyone seen RWSEM issues in today's next?

11:17 <mwalle> geertu: krzk: sorry, had lunch break. and after a while I'll just remove it entirely from spi-nor?

11:22 <mwalle> I fail to see deprecation strategy behind it

11:22 <arnd> I also just came back from lunch. mwalle, I think it's best to start by finding out more about how and why each of these got added to spi-nor instead of at25 in the first place.

11:23 <arnd> I see ce56ce7da3159 ("mtd: spi-nor: Add support for Fujitsu MB85RS1MT FRAM") and 8a2644d5f3608 ("mtd: spi-nor: Add support for Cypress cy15x104q") added specific chips not that long ago, so you can ask the authors whether just moving those to at25 would work for them

11:27 <arnd> Most of the catalyst and everspin parts came from drivers/mtd/devices/m25p80.c when spi-nor.c was created

11:33 <mwalle> arnd: it goes back way more

11:33 <mwalle> 5ca11ca7ad950 ("mtd: m25p80: add support for Everspin MR25H256 MRAM chip")

11:33 <mwalle> from marex :)

11:44 <mwalle> arnd: judging from https://community.infineon.com/t5/Knowledge-Base-Articles/F-RAM-Support-under-Linux-KBA223028/ta-p/248959 people are using at least that one as a replacement for flashes. so i guess they expect the mtd layer. sigh

11:57 <mwalle> it seems there are two ways to have support in linux for these "EEPROM-like and flash-like" devices in the kernel. Either through the at25 driver (which just exposes an "eeprom" sysfs binary file") or through spi-nor which sits on top of the mtd layer. And both seem to be in used. even worse, there are bindings for the MB85RS1MT pointing to the at25 driver, but its (also) implemented in spi-nor.

14:08 <arnd> ardb: it looks like https://lore.kernel.org/lkml/CAMj1kXF0AQ9cc64N9kRxV8s1TDTVdAb_4s2P-rriim5DNW_cCA@mail.gmail.com/ is the only remaining patch in my original series of 16 that I had for rmk. I think this is because the conflict you mentioned.

14:09 <arnd> what's the status of your series, would it make sense if you just add my patch to it?

14:09 <ardb> arnd: probably - russell pulled that into this devel-stable branch but didn't push it to -next yet

14:25 <arnd> ardb: I tried merging the devel-stable into my randconfig tree. It looks like at least the patch I mentioned above is no longer needed, so I can just skip resending it. There is one more conflict between one of my patches and your series, which will have to be addressed by removing the extra VFP_bounce() prototype, but otherwise it looks like we are clean now

14:25 <ardb> arnd: good

14:26 <ardb> i hope i didn't introduce any new occurrences?

14:39 <arnd> none that I see so far

17:07 <Xogium> yay new toy to play with ! Somoene offered me the odyssey stm32mp135d from seeed studio ^^

17:07 <Xogium> *someone

17:10 <Xogium> apparently it's got a super nice schematic too, with a good revision history and a cool block diagram