Message-ID: <mafs0ikxnykpr.fsf@kernel.org>
Date: Tue, 02 Jul 2024 15:41:52 +0200
From: Pratyush Yadav <pratyush@...nel.org>
To: Tudor Ambarus <tudor.ambarus@...aro.org>
Cc: Marco Felsch <m.felsch@...gutronix.de>,  Miquel Raynal
 <miquel.raynal@...tlin.com>,  Richard Weinberger <richard@....at>,
  Vignesh Raghavendra <vigneshr@...com>,  Arnd Bergmann <arnd@...db.de>,
  Greg Kroah-Hartman <gregkh@...uxfoundation.org>,  Bartosz Golaszewski
 <brgl@...ev.pl>,  Russell King <linux@...linux.org.uk>,  Joel Stanley
 <joel@....id.au>,  Andrew Jeffery <andrew@...econstruct.com.au>,  Nicolas
 Ferre <nicolas.ferre@...rochip.com>,  Alexandre Belloni
 <alexandre.belloni@...tlin.com>,  Claudiu Beznea
 <claudiu.beznea@...on.dev>,  Shawn Guo <shawnguo@...nel.org>,  Sascha
 Hauer <s.hauer@...gutronix.de>,  Pengutronix Kernel Team
 <kernel@...gutronix.de>,  Fabio Estevam <festevam@...il.com>,  Vladimir
 Zapolskiy <vz@...ia.com>,  Andrew Lunn <andrew@...n.ch>,  Gregory Clement
 <gregory.clement@...tlin.com>,  Sebastian Hesselbarth
 <sebastian.hesselbarth@...il.com>,  Tony Lindgren <tony@...mide.com>,
  Geert Uytterhoeven <geert+renesas@...der.be>,  Magnus Damm
 <magnus.damm@...il.com>,  Dinh Nguyen <dinguyen@...nel.org>,  Thierry
 Reding <thierry.reding@...il.com>,  Jonathan Hunter
 <jonathanh@...dia.com>,  Jonathan Neuschäfer
 <j.neuschaefer@....net>,
  Michael Ellerman <mpe@...erman.id.au>,  Nicholas Piggin
 <npiggin@...il.com>,  Christophe Leroy <christophe.leroy@...roup.eu>,
  "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,  Thomas Bogendoerfer
 <tsbogend@...ha.franken.de>,  Huacai Chen <chenhuacai@...nel.org>,  WANG
 Xuerui <kernel@...0n.name>,  linux-mtd@...ts.infradead.org,
  linux-kernel@...r.kernel.org,  linux-i2c@...r.kernel.org,
  linux-arm-kernel@...ts.infradead.org,  linux-aspeed@...ts.ozlabs.org,
  imx@...ts.linux.dev,  linux-omap@...r.kernel.org,
  linux-renesas-soc@...r.kernel.org,  linux-tegra@...r.kernel.org,
  openbmc@...ts.ozlabs.org,  linuxppc-dev@...ts.ozlabs.org,
  linux-mips@...r.kernel.org,  loongarch@...ts.linux.dev,  Maxime Ripard
 <mripard@...nel.org>
Subject: Re: [PATCH 4/9] mtd: devices: add AT24 eeprom support

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/

-- 
Regards,
Pratyush Yadav

Powered by blists - more mailing lists