Re: [PATCH] ARM: dts: aspeed: yosemite4: Remove Floating Falls board nodes

[Eric Yang]

Hi Andrew,

Thanks for the review.

On Fri, 2026-11-06 at 15:46 +1030, Andrew Jeffery wrote:
> So the expander and EEPROM are on a pluggable board?

Yes, they are on the Floating Falls board, which is a separate board
that would connect to the Sentinel Dome through a connector. That
connector is not populated on any Sentinel Dome currently in use.

> Which "stage" does the devicetree currently represent?

The Yosemite 4 hardware itself is not going to change any more, and
this is its only devicetree. The Floating Falls board is not part of
that hardware: no system currently in use has it. This patch therefore
only makes the devicetree describe the hardware as it is, by removing
the nodes for a board that is not there.

> Have you seen this discussion:

>From what I read in that thread, your concern is that a devicetree
that is changed to follow the current design phase no longer says which
hardware it describes, so changes to it become incompatible changes
against a boundary that is unclear. You suggested:

- sending only the finalised design
- a separate .dts per phase, with the common parts in .dtsi files
- for small differences, a .dts that includes another .dts and adjusts
  properties or deletes nodes

Did I understand your concern correctly, or is the number of changes to
a devicetree also part of it?

I would also like to ask for your advice on how we handle future
platforms during their pre-production design phases.

In our case the firmware is built from the devicetree of the latest
stage only, and the devicetree and the userspace usually change
together, so we would like to send each change as we make it. Even
within one stage, the devicetree can need changes because of new
requirements or problems found. A platform can also have several SKUs
that are developed separately and can be at different stages. We build
all SKUs of a platform into one firmware image with a single
devicetree, so a devicetree per SKU would mean an image per SKU for us.

Of your three suggestions, the second looks the most workable for us.
Sending only the finalised design would leave the devicetree we build
our firmware from out of upstream until the design is final, which we
would like to avoid. The include approach looks suited to small
differences, but the differences between stages on our platforms can
include:

- a device moving to a different I2C bus
- GPIO line names changing
- devices being added or removed

My understanding is that your per-phase suggestion could work for us in
the following way:

- The top-level .dts keeps the platform's current name, and our
  firmware is built from it.
- Parts that do not change between stages or SKUs go into a common
  .dtsi.
- For each SKU, the top-level .dts also includes a .dtsi for the stage
  that SKU is currently at.
- Each change is sent as a DTS patch against the file for the SKU and
  stage it applies to, or against the common .dtsi if it applies to all
  of them.
- When a SKU moves to its next stage, DTS patches add the next stage's
  .dtsi and switch the top-level .dts to include it. The previous
  stage's .dtsi can be removed in a later patch, or kept if you prefer.

For example, with two SKUs at different stages:

  platform.dts            (top-level, keeps the platform's name)
    includes platform-common.dtsi
    includes platform-sku1-stage2.dtsi
    includes platform-sku2-stage1.dtsi

and after SKU 2 moves to its next stage:

  platform.dts
    includes platform-common.dtsi
    includes platform-sku1-stage2.dtsi
    includes platform-sku2-stage2.dtsi   (added)

Is that correct and acceptable to you, or would you recommend something
different? I would appreciate your advice.

Also, when two SKUs have different devices at the same address on the
same bus, the devicetree cannot describe both. I would appreciate your
advice here too: is removing such devices from the devicetree and
creating them in userspace the only way, is there another way, or
should this be avoided at the hardware design stage?

> This kind of verification isn't terribly useful?

In v2 I will leave that paragraph out and reword the commit message to
say that the board is not in any system currently in use and its
connector is not populated.

Thank you for your time and for sharing your perspective on this,
Eric