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>

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

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

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