| Message ID | 20240701-b4-v6-10-topic-usbc-tcpci-v1-0-3fd5f4a193cc@pengutronix.de |
|---|---|
| Headers | show |
| Series | AT24 EEPROM MTD Support | expand |
On 7/1/24 4:53 PM, Marco Felsch wrote: > Provide a simple helper to make it easy to detect an master mtd device. > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> > --- > include/linux/mtd/mtd.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h > index 8d10d9d2e830..bf3fc2ea7230 100644 > --- a/include/linux/mtd/mtd.h > +++ b/include/linux/mtd/mtd.h > @@ -408,6 +408,11 @@ static inline struct mtd_info *mtd_get_master(struct mtd_info *mtd) > return mtd; > } > > +static inline bool mtd_is_master(struct mtd_info *mtd) > +{ > + return mtd->parent ? false : true; Perhaps: return !mtd->parent; [...] MBR, Sergey
On 7/1/24 2:53 PM, Marco Felsch wrote: > EEPROMs can become quite large nowadays (>=64K). Exposing such devices > as single device isn't always sufficient. There may be partitions which > require different access permissions. Also write access always need to > to verify the offset. > > Port the current misc/eeprom/at24.c driver to the MTD framework since > EEPROMs are memory-technology devices and the framework already supports I was under the impression that MTD devices are tightly coupled by erase blocks. But then we see MTD_NO_ERASE, so what are MTD devices after all? > partitioning. This allow using of-paritions like we do for SPI-NOR > devices already:
On 24-07-01, Sergei Shtylyov wrote: > On 7/1/24 4:53 PM, Marco Felsch wrote: > > > Provide a simple helper to make it easy to detect an master mtd device. > > > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> > > --- > > include/linux/mtd/mtd.h | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h > > index 8d10d9d2e830..bf3fc2ea7230 100644 > > --- a/include/linux/mtd/mtd.h > > +++ b/include/linux/mtd/mtd.h > > @@ -408,6 +408,11 @@ static inline struct mtd_info *mtd_get_master(struct mtd_info *mtd) > > return mtd; > > } > > > > +static inline bool mtd_is_master(struct mtd_info *mtd) > > +{ > > + return mtd->parent ? false : true; > > Perhaps: > > return !mtd->parent; Sure, if you prefer this style rather I will change it. Regards, Marco
On Mon, Jul 1, 2024 at 3:54 PM Marco Felsch <m.felsch@pengutronix.de> wrote: > > All kernel users are shifted to the new MTD_EEPROM_AT24 Kconfig symbol > so we can drop the old one. > Nope, with this series arm64 still selects the old symbol. Bart
Hi, On 24-07-02, Bartosz Golaszewski wrote: > On Mon, Jul 1, 2024 at 3:54 PM Marco Felsch <m.felsch@pengutronix.de> wrote: > > > > All kernel users are shifted to the new MTD_EEPROM_AT24 Kconfig symbol > > so we can drop the old one. > > > > Nope, with this series arm64 still selects the old symbol. sry. I must have forgotten to add the arm64 hunk :/ I also noticed one powerpc config which still select the old symbol. I will fix this in v2. Thank you, Marco > > Bart >
On Mon, Jul 01 2024, Tudor Ambarus wrote: > On 7/1/24 2:53 PM, Marco Felsch wrote: >> EEPROMs can become quite large nowadays (>=64K). Exposing such devices >> as single device isn't always sufficient. There may be partitions which >> require different access permissions. Also write access always need to >> to verify the offset. >> >> Port the current misc/eeprom/at24.c driver to the MTD framework since >> EEPROMs are memory-technology devices and the framework already supports > > I was under the impression that MTD devices are tightly coupled by erase > blocks. But then we see MTD_NO_ERASE, so what are MTD devices after all? I was curious as well so I did some digging. The Kconfig help says: Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices [...] The FAQ on the MTD documentation [0] says: Unix traditionally only knew block devices and character devices. Character devices were things like keyboards or mice, that you could read current data from, but couldn't be seek-ed and didn't have a size. Block devices had a fixed size and could be seek-ed. They also happened to be organized in blocks of multiple bytes, usually 512. Flash doesn't match the description of either block or character devices. They behave similar to block device, but have differences. For example, block devices don't distinguish between write and erase operations. Therefore, a special device type to match flash characteristics was created: MTD. So MTD is neither a block nor a char device. There are translations to use them, as if they were. But those translations are nowhere near the original, just like translated Chinese poems. And in the section below, it lists some properties of an MTD device: - Consists of eraseblocks. - Eraseblocks are larger (typically 128KiB). - Maintains 3 main operations: read from eraseblock, write to eraseblock, and erase eraseblock. - Bad eraseblocks are not hidden and should be dealt with in software. - Eraseblocks wear-out and become bad and unusable after about 10^3 (for MLC NAND) - 10^5 (NOR, SLC NAND) erase cycles. This does support the assumption you had about MTD devices being tightly coupled with erase block. It also makes it quite clear that an EEPROM is not MTD -- since EEPROMs are byte-erasable. Of course, the existence of MTD_NO_ERASE nullifies a lot of these points. So it seems the subsystem has evolved. MTD_NO_ERASE was added by 92cbfdcc3661d ("[MTD] replace MTD_RAM with MTD_GENERIC_TYPE") in 2006, but this commit only adds the flag. The functionality of "not requiring an explicit erase" for RAM devices has existed since the start of the git history at least. I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting adding EEPROMs to MTD [1]. The main purpose would have been unifying the EEPROM drivers under a single interface. I am not sure what came of it though, since I can't find any patches that followed up with the proposal. Overall, I'd say that while originally MTD was written with flash devices with erase blocks in mind, the subsystem seems to have evolved with time to include other types of devices. I don't see anything obviously wrong with adding EEPROMs to the type of devices in MTD as well. It doesn't seem to be too invasive to the subsystem (I do see some dubious code when skimming through the patches, but nothing unfixable). And the EEPROM drivers can get a common interface. The other option would be to create a separate subsystem for EEPROMs, but perhaps that would just lead to a bunch of code being duplicated. I'd like to hear if somebody thinks otherwise, and sees reasons to _not_ do this. [0] http://www.linux-mtd.infradead.org/faq/general.html [1] https://lore.kernel.org/linux-mtd/20130705201118.GM2959@lukather/
On Tue, Jul 02, 2024 at 03:41:52PM GMT, Pratyush Yadav wrote: > On Mon, Jul 01 2024, Tudor Ambarus wrote: > > > On 7/1/24 2:53 PM, Marco Felsch wrote: > >> EEPROMs can become quite large nowadays (>=64K). Exposing such devices > >> as single device isn't always sufficient. There may be partitions which > >> require different access permissions. Also write access always need to > >> to verify the offset. > >> > >> Port the current misc/eeprom/at24.c driver to the MTD framework since > >> EEPROMs are memory-technology devices and the framework already supports > > > > I was under the impression that MTD devices are tightly coupled by erase > > blocks. But then we see MTD_NO_ERASE, so what are MTD devices after all? > > I was curious as well so I did some digging. > > The Kconfig help says: > > Memory Technology Devices are flash, RAM and similar chips, often > used for solid state file systems on embedded devices [...] > > The FAQ on the MTD documentation [0] says: > > Unix traditionally only knew block devices and character devices. > Character devices were things like keyboards or mice, that you could > read current data from, but couldn't be seek-ed and didn't have a size. > Block devices had a fixed size and could be seek-ed. They also happened > to be organized in blocks of multiple bytes, usually 512. > > Flash doesn't match the description of either block or character > devices. They behave similar to block device, but have differences. For > example, block devices don't distinguish between write and erase > operations. Therefore, a special device type to match flash > characteristics was created: MTD. > > So MTD is neither a block nor a char device. There are translations to > use them, as if they were. But those translations are nowhere near the > original, just like translated Chinese poems. > > And in the section below, it lists some properties of an MTD device: > > - Consists of eraseblocks. > - Eraseblocks are larger (typically 128KiB). > - Maintains 3 main operations: read from eraseblock, write to > eraseblock, and erase eraseblock. > - Bad eraseblocks are not hidden and should be dealt with in > software. > - Eraseblocks wear-out and become bad and unusable after about 10^3 > (for MLC NAND) - 10^5 (NOR, SLC NAND) erase cycles. > > This does support the assumption you had about MTD devices being tightly > coupled with erase block. It also makes it quite clear that an EEPROM is > not MTD -- since EEPROMs are byte-erasable. > > Of course, the existence of MTD_NO_ERASE nullifies a lot of > these points. So it seems the subsystem has evolved. MTD_NO_ERASE was > added by 92cbfdcc3661d ("[MTD] replace MTD_RAM with MTD_GENERIC_TYPE") > in 2006, but this commit only adds the flag. The functionality of "not > requiring an explicit erase" for RAM devices has existed since the start > of the git history at least. > > I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting adding > EEPROMs to MTD [1]. The main purpose would have been unifying the EEPROM > drivers under a single interface. I am not sure what came of it though, > since I can't find any patches that followed up with the proposal. That discussion led to drivers/nvmem after I started to work on some early prototype, and Srinivas took over that work. Maxime
On Tue, Jul 02 2024, Maxime Ripard wrote: > On Tue, Jul 02, 2024 at 03:41:52PM GMT, Pratyush Yadav wrote: >> On Mon, Jul 01 2024, Tudor Ambarus wrote: >> >> > On 7/1/24 2:53 PM, Marco Felsch wrote: >> >> EEPROMs can become quite large nowadays (>=64K). Exposing such devices >> >> as single device isn't always sufficient. There may be partitions which >> >> require different access permissions. Also write access always need to >> >> to verify the offset. >> >> >> >> Port the current misc/eeprom/at24.c driver to the MTD framework since >> >> EEPROMs are memory-technology devices and the framework already supports >> > >> > I was under the impression that MTD devices are tightly coupled by erase >> > blocks. But then we see MTD_NO_ERASE, so what are MTD devices after all? >> >> I was curious as well so I did some digging. >> [...] >> >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting adding >> EEPROMs to MTD [1]. The main purpose would have been unifying the EEPROM >> drivers under a single interface. I am not sure what came of it though, >> since I can't find any patches that followed up with the proposal. > > That discussion led to drivers/nvmem after I started to work on > some early prototype, and Srinivas took over that work. So would you say it is better for EEPROM drivers to use nvmem instead of moving under MTD?
On Tue, Jul 02, 2024 at 04:15:20PM GMT, Pratyush Yadav wrote: > On Tue, Jul 02 2024, Maxime Ripard wrote: > > > On Tue, Jul 02, 2024 at 03:41:52PM GMT, Pratyush Yadav wrote: > >> On Mon, Jul 01 2024, Tudor Ambarus wrote: > >> > >> > On 7/1/24 2:53 PM, Marco Felsch wrote: > >> >> EEPROMs can become quite large nowadays (>=64K). Exposing such devices > >> >> as single device isn't always sufficient. There may be partitions which > >> >> require different access permissions. Also write access always need to > >> >> to verify the offset. > >> >> > >> >> Port the current misc/eeprom/at24.c driver to the MTD framework since > >> >> EEPROMs are memory-technology devices and the framework already supports > >> > > >> > I was under the impression that MTD devices are tightly coupled by erase > >> > blocks. But then we see MTD_NO_ERASE, so what are MTD devices after all? > >> > >> I was curious as well so I did some digging. > >> > [...] > >> > >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting adding > >> EEPROMs to MTD [1]. The main purpose would have been unifying the EEPROM > >> drivers under a single interface. I am not sure what came of it though, > >> since I can't find any patches that followed up with the proposal. > > > > That discussion led to drivers/nvmem after I started to work on > > some early prototype, and Srinivas took over that work. > > So would you say it is better for EEPROM drivers to use nvmem instead of > moving under MTD? I thought so at the time, but that was more than 10y ago, and I have followed neither nvmem nor MTD since so I don't really have an opinion there. It looks like drivers/misc/eeprom/at24.c has support for nvmem though, and MTD can be used as an nvmem provider too, so it's not clear to me why we would want to create yet another variant. But again, you shouldn't really ask me in the first place :) I'm sure Miquel, Srinivas, and surely others, are much more relevant to answer that question. Maxime
This series adds the intial support to handle EEPROMs via the MTD layer as well. This allow the user-space to have separate paritions since EEPROMs can become quite large nowadays. With this patchset applied EEPROMs can be accessed via: - legacy 'eeprom' device - nvmem device - mtd device(s) The patchset targets only the AT24 (I2C) EEPROMs since I have no access to AT25 (SPI) EEPROMs nor to one of the other misc/eeprom/* devices. Note: I'm not familiar with Kconfig symbol migration so I don't know if the last patch is required at the moment. Please be notified that the list of recipients is quite large due to the defconfig changes. Regards, Marco Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> --- Marco Felsch (9): mtd: core: add nvmem_write support mtd: add mtd_is_master helper mtd: add support to handle EEPROM devices mtd: devices: add AT24 eeprom support ARM: defconfig: convert to MTD_EEPROM_AT24 powerpc: convert to MTD_EEPROM_AT24 MIPS: configs: convert to MTD_EEPROM_AT24 LoongArch: convert to MTD_EEPROM_AT24 eeprom: at24: remove deprecated Kconfig symbol MAINTAINERS | 2 +- arch/arm/configs/aspeed_g4_defconfig | 2 +- arch/arm/configs/aspeed_g5_defconfig | 2 +- arch/arm/configs/at91_dt_defconfig | 2 +- arch/arm/configs/axm55xx_defconfig | 2 +- arch/arm/configs/davinci_all_defconfig | 2 +- arch/arm/configs/imx_v4_v5_defconfig | 2 +- arch/arm/configs/imx_v6_v7_defconfig | 2 +- arch/arm/configs/ixp4xx_defconfig | 2 +- arch/arm/configs/keystone_defconfig | 2 +- arch/arm/configs/lpc18xx_defconfig | 2 +- arch/arm/configs/lpc32xx_defconfig | 2 +- arch/arm/configs/multi_v5_defconfig | 2 +- arch/arm/configs/multi_v7_defconfig | 2 +- arch/arm/configs/mvebu_v5_defconfig | 2 +- arch/arm/configs/mvebu_v7_defconfig | 2 +- arch/arm/configs/mxs_defconfig | 2 +- arch/arm/configs/omap2plus_defconfig | 2 +- arch/arm/configs/pxa_defconfig | 2 +- arch/arm/configs/s3c6400_defconfig | 2 +- arch/arm/configs/sama5_defconfig | 2 +- arch/arm/configs/sama7_defconfig | 2 +- arch/arm/configs/shmobile_defconfig | 2 +- arch/arm/configs/socfpga_defconfig | 2 +- arch/arm/configs/tegra_defconfig | 2 +- arch/arm/configs/wpcm450_defconfig | 2 +- arch/loongarch/configs/loongson3_defconfig | 2 +- arch/mips/configs/cavium_octeon_defconfig | 2 +- arch/mips/configs/db1xxx_defconfig | 2 +- arch/powerpc/configs/44x/warp_defconfig | 2 +- arch/powerpc/configs/mpc512x_defconfig | 2 +- arch/powerpc/configs/mpc5200_defconfig | 2 +- arch/powerpc/configs/ppc6xx_defconfig | 2 +- arch/powerpc/configs/skiroot_defconfig | 2 +- drivers/misc/eeprom/Kconfig | 31 ------- drivers/misc/eeprom/Makefile | 1 - drivers/mtd/devices/Kconfig | 31 +++++++ drivers/mtd/devices/Makefile | 1 + drivers/{misc/eeprom => mtd/devices}/at24.c | 122 +++++++++++++++------------- drivers/mtd/mtdcore.c | 49 ++++++++++- include/linux/mtd/mtd.h | 5 ++ include/uapi/mtd/mtd-abi.h | 2 + 42 files changed, 187 insertions(+), 123 deletions(-) --- base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0 change-id: 20240701-b4-v6-10-topic-usbc-tcpci-c4bc9bcce604 Best regards,