Thanks for the info. So does it make more sense to add the new
functionality as part of the EEPROM
driver(drivers/eeprom/spi_xx25xx.c) or under the MTD(drivers/mtd/??).
I assume anything added should be under the EEPROM folder, but I'm a
little confused as to what the difference is between the MTD folder
and the EEPROM folder. It seems that both folders have support for the
at24xx and at25xx series of chips, so it's not obvious which one is
better. I was planning to add it to the drivers/eeprom/spi_xx25xx.c.
-Robert Middleton
On Fri, Nov 3, 2023 at 8:17 PM Gregory Nutt wrote:
>
>
> On 11/3/2023 4:02 PM, Robert Middleton wrote:
> > Hi,
> >
> > I am working on a project that will need to be able to read/write the
> > ID page of an EEPROM(currently a M95M02 SPI device from ST). From the
> > code that I have seen, it seems that this chip is already supported,
> > but there is no code to read/write the device ID page. I'm looking to
> > add support, but I have some questions:
> >
> > 1. There are currently no IOCTLs defined for EEPROM devices, should I
> > add a new IOCTL base or add an extra one to the MTD IOCTLs?
> See below
> > 2. The default IOCTL for the EEPROM returns -ENOTTY which seems weird,
> > should that be something else?
>
> ENOTTY is correct. See https://en.wikipedia.org/wiki/Not_a_typewriter
> or
> https://cwiki.apache.org/confluence/display/NUTTX/ENOTTY+ioctl%28%29+Return+Value
>
> This confuses a lot of people and there are numerous stack overflow
> questions like yours.
>
> > 3. Since you could read/write the ID page, should this really be
> > implemented as an IOCTL? I would assume that the functions would need
> > to be more like the read/write syscalls where you pass in a buffer and
> > the length(assuming you don't want to read or write the entire page).
> > Would it make sense to make another node in /dev to access this page?
>
> This is related logic for the AT24 EEPROM. That part has an extended
> memory region that holds configuration data like that factory
> initialized MAC address of the SAMv71-Xult board.
> See/boards/arm/samv7/samv71-xult/src/sam_ethernet.c:
>
>/* Configure the AT24 to access the extended memory region */
>
>ret = at24->ioctl(at24, MTDIOC_EXTENDED, 1);
>
> That is not exactly the same functionality, but is, I think sufficiently
> related to justify using IOCTLs.
>
> NOTE: That only uses the IOCTL to switch modes of EEPROM. Normal reads
> and writes are then used to access the extended range:
>
>/* Read the MAC address */
>
>nread = at24->read(at24, AT24XX_MACADDR_OFFSET, 6, mac);
>
> Using IOCTLs for reads and writes would be awkward.
>
> Optionally, you could treat the control memory as a separate partition,
> registering the ID page like it were a different device.
>
> Notice that the AT24 does use an MTD IOCTL. I don't know if we want to
> proliferate that naming or not? It would good to re-use it if the
> semantics of the name would permit you to re-use it.
