| 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 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 01, 2024 at 03:53:39PM +0200, Marco Felsch wrote: > 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. FWIW, I think that MTD is *not* the place for EEPROMs. Yeah, we have the driver spread over the kernel for EEPROMs (mostly due to historical reasons and absence an umbrella subsystem for them), but it's not the reason to hack them into something which is not quite suitable. If NVMEM needs to be updated and may cover these cases after all (and do not forget about *small* size EEPROMs that most likely appear on the devices with limited amount of resources!) in a reasonable size and performance, why not?
Hi Andy, On 24-08-23, Andy Shevchenko wrote: > On Mon, Jul 01, 2024 at 03:53:39PM +0200, Marco Felsch wrote: > > 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. > > FWIW, I think that MTD is *not* the place for EEPROMs. > > Yeah, we have the driver spread over the kernel for EEPROMs (mostly due to > historical reasons and absence an umbrella subsystem for them), but it's not > the reason to hack them into something which is not quite suitable. Thank you for you input. There are two things to mention: 1st) I send a RFC patch and asked for feedback and all I got was: looks okay, please send a proper patch [1] which I did. 2nd) I don't see the hacky part in this patchset. Anyway the customer doesn't need the nvmem-partitions anymore and therefore this patchset can be seen as obsolote. Regards, Marco [1] https://lore.kernel.org/lkml/20231201144441.imk7rrjnv2dugo7p@pengutronix.de/T/#m1e0e5778448971b50a883f62bd95622f6422b9a2 > > If NVMEM needs to be updated and may cover these cases after all (and do not > forget about *small* size EEPROMs that most likely appear on the devices with > limited amount of resources!) in a reasonable size and performance, why not? > > -- > With Best Regards, > Andy Shevchenko > > >
On Mon, Aug 26, 2024 at 09:51:10AM +0200, Marco Felsch wrote: > On 24-08-23, Andy Shevchenko wrote: > > On Mon, Jul 01, 2024 at 03:53:39PM +0200, Marco Felsch wrote: > > > 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. > > > > FWIW, I think that MTD is *not* the place for EEPROMs. > > > > Yeah, we have the driver spread over the kernel for EEPROMs (mostly due to > > historical reasons and absence an umbrella subsystem for them), but it's not > > the reason to hack them into something which is not quite suitable. > > Thank you for you input. There are two things to mention: > 1st) I send a RFC patch and asked for feedback and all I got was: looks > okay, please send a proper patch [1] which I did. I was on a long vacation, I haven't had time or even wishes to look at the patches or patch series. Sorry for that. Second point, RFC means "request for comments", here is mine. It's up to the maintainers and you on how to proceed it. > 2nd) I don't see the hacky part in this patchset. I haven't talked about patchset, I have talked about architectural / design point of view. I read the discussion and to me it seems like it solves the issue with a quite big hammer. If you can prove that on embedded systems with limited resources it is not a problem, just mention that in the cover letter. > Anyway the customer doesn't need the nvmem-partitions anymore and > therefore this patchset can be seen as obsolote. > > [1] https://lore.kernel.org/lkml/20231201144441.imk7rrjnv2dugo7p@pengutronix.de/T/#m1e0e5778448971b50a883f62bd95622f6422b9a2 > > > If NVMEM needs to be updated and may cover these cases after all (and do not > > forget about *small* size EEPROMs that most likely appear on the devices with > > limited amount of resources!) in a reasonable size and performance, why not?
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,