[PATCH] ARM: dts: aspeed: anacapa: Add eeprom device node

[PATCH] ARM: dts: aspeed: anacapa: Add eeprom device node

[Colin Huang]

eeprom address changed (0x50 to 0x51) in DCSCM rev D
To support previous rev (B/C) and rev D,
add eeprom device node for DCSCM rev D.

Signed-off-by: Colin Huang <u8813345@gmail.com>
---
DCSCM rev D changed the eeprom address from 0x50 t0 0x51
To support previous rev(B/C) and rev D.
add new eeprom node for devscm rev d.
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
index 2cb7bd128d24..680108b00664 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -586,6 +586,11 @@ eeprom@50 {
 		reg = <0x50>;
 	};
 
+	eeprom@51 {
+		compatible = "atmel,24c128";
+		reg = <0x51>;
+	};
+
 	// BSM FRU
 	eeprom@56 {
 		compatible = "atmel,24c64";

---
base-commit: 710dbb13377c80a6e39ef049a517665841e3221e
change-id: 20260302-add-new-eeprom-node-78a20a7c4893

Best regards,
-- 
Colin Huang <u8813345@gmail.com>

Re: [PATCH] ARM: dts: aspeed: anacapa: Add eeprom device node

[Andrew Jeffery]

On Mon, 2026-03-02 at 12:20 +0800, Colin Huang wrote:
> eeprom address changed (0x50 to 0x51) in DCSCM rev D
> To support previous rev (B/C) and rev D,
> add eeprom device node for DCSCM rev D.
> 
> Signed-off-by: Colin Huang <u8813345@gmail.com>
> ---
> DCSCM rev D changed the eeprom address from 0x50 t0 0x51
> To support previous rev(B/C) and rev D.
> add new eeprom node for devscm rev d.

I feel different hardware revisions may deserved different devicetrees.
What are the trade-offs that lead you to avoiding that?

Why is it better to cause driver bind errors on both revisions?

Andrew

Re: [PATCH] ARM: dts: aspeed: anacapa: Add eeprom device node

[Colin Huang]

Hi Andrew,

Thanks for the feedback.

In our case the only functional difference between DCSCM rev B/C and
rev D is the EEPROM I²C address change (0x50 → 0x51).
Other than this, the hardware is identical and all device-tree
described components share the same wiring and behaviour.

Maintaining two separate devicetrees for a single‑byte address shift
doesn’t scale well for us. Only side effect of listing both EEPROM
nodes is that the non‑matching node produces a harmless driver bind
error in dmesg. It does not affect functionality on either revision —
the correct node always binds, and the unused one simply fails probe
and is ignored by the driver. From a system behaviour standpoint both
board revisions operate normally.

So the trade‑off we chose is:

  * One DT shared across all revisions → low maintenance cost, one
source of truth.
  * A benign bind failure on the unused EEPROM → visible in logs but
functionally harmless.

If more hardware differences appear in later revisions, separating the
devicetrees would make sense. But given the current situation, keeping
a unified DT is the most maintainable choice.

Thanks,
Colin

Andrew Jeffery <andrew@codeconstruct.com.au> 於 2026年3月5日週四 上午8:12寫道：
>
> On Mon, 2026-03-02 at 12:20 +0800, Colin Huang wrote:
> > eeprom address changed (0x50 to 0x51) in DCSCM rev D
> > To support previous rev (B/C) and rev D,
> > add eeprom device node for DCSCM rev D.
> >
> > Signed-off-by: Colin Huang <u8813345@gmail.com>
> > ---
> > DCSCM rev D changed the eeprom address from 0x50 t0 0x51
> > To support previous rev(B/C) and rev D.
> > add new eeprom node for devscm rev d.
>
> I feel different hardware revisions may deserved different devicetrees.
> What are the trade-offs that lead you to avoiding that?
>
> Why is it better to cause driver bind errors on both revisions?
>
> Andrew

Re: [PATCH] ARM: dts: aspeed: anacapa: Add eeprom device node

[Andrew Jeffery]

On Fri, 2026-03-06 at 14:06 +0800, Colin Huang wrote:
> Hi Andrew,
> 
> Thanks for the feedback.
> 
> In our case the only functional difference between DCSCM rev B/C and
> rev D is the EEPROM I²C address change (0x50 → 0x51).
> Other than this, the hardware is identical and all device-tree
> described components share the same wiring and behaviour.
> 
> Maintaining two separate devicetrees for a single‑byte address shift
> doesn’t scale well for us. 

I disagree that there's a problem of scale. The kernel's dts files are
processed with the C pre-processor - you can #include one file from
another. .dtsi files work this way, and as a related example, we
maintain two devicetrees for the AST2600 EVB where -A1 had some minor
differences in the regulator configuration:

 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts?h=v7.0-rc5
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb-a1.dts?h=v7.0-rc5

See also my response to Kevin Tung earlier:

https://lore.kernel.org/all/d7794f74b26bbc1ee0a70e39c5671acc018f80eb.camel@codeconstruct.com.au/

Andrew