[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 at 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 at 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