Hi João,
On 2026-09-23T21:40:27, João Loureiro <[email protected]> wrote:
> spi: Introduce initial driver-model support for SPI EEPROMs
>
> U-Boot has driver-model support for EEPROMs on several buses - I2C
> through UCLASS_I2C_EEPROM and 1-Wire through UCLASS_W1_EEPROM - but
> nothing for SPI, even though SPI EEPROMs are common and are usually the
> faster part of the two.
>
> These devices typically hold a board's identity: its serial number, a
> unique device ID and the hardware variant. U-Boot needs that early,
> both to decide which device tree and overlays to load for the variant
> it happens to be running on, and to hand the unique IDs to the system
> it is about to boot. Today a board that wants any of this has to
> open-code raw SPI transfers in board code, which is neither reusable
> nor testable.
>
> Introduce a UCLASS_SPI_EEPROM uclass with read/write/size operations,
> analogous to the I2C EEPROM uclass, along with a driver for AT25-style
> parts. The chip geometry - total size, page size and address width - is
> taken from the device tree as described by the atmel,at25 binding in
> dts/upstream/Bindings/eeprom/at25.yaml, which requires those properties,
> [...]
>
> MAINTAINERS | 7 ++
> configs/sandbox_defconfig | 1 +
> drivers/misc/Kconfig | 15 +++
> drivers/misc/Makefile | 1 +
> drivers/misc/spi_eeprom.c | 267
> +++++++++++++++++++++++++++++++++++++++++
> drivers/misc/spi_eeprom_priv.h | 18 +++
> include/dm/uclass-id.h | 1 +
> include/spi_eeprom.h | 95 +++++++++++++++
> 8 files changed, 405 insertions(+)
> even though SPI EEPROMs are common and are usually the faster part of the two.
Nit: 'the faster of the two'.
> diff --git a/drivers/misc/spi_eeprom.c b/drivers/misc/spi_eeprom.c
> @@ -0,0 +1,267 @@
> + ret = spi_eeprom_read_status(dev, &status);
> + if (ret) {
> + log_err("Failed to read status register: %d\n", ret);
> + return ret;
> + }
> +
> + log_debug("status register: 0x%02x\n", status);
> +
> + return 0;
> +}
Just to check, is this status-register read a deliberate presence
check, or only diagnostic? If diagnostic, a bus glitch or unpopulated
socket will fail probe() and take the whole board down, which seems
strong. If deliberate, please say so in the comment above.
Reviewed-by: Simon Glass <[email protected]>
Regards,
Simon
