Two different power monitor devices, using different drivers, reuse
I2C addresses 0x40 and 0x45 on bus 10 across Yosemite5 board variants.
Defining these devices statically in the DTS can lead to incorrect
driver binding on newer boards when the wrong device is instantiated.
Therefore, remove 10-0040 and 10-0045 device nodes, and let the driver
selection is instead handled in user space by the OpenBMC Entity
Manager based on the actual board configuration.
Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
index 7991e9360847532cff9aad4ad4ed57d4c30668a0..45b8ac2e8c65a4f672e64571631b7f6944f26213 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
@@ -674,20 +674,6 @@ gpio-expander@22 {
"PWRGD_P3V3_AUX","ALERT_TEMP";
};
- power-sensor@40 {
- compatible = "ti,ina233";
- reg = <0x40>;
- shunt-resistor = <2000>;
- ti,maximum-expected-current-microamp = <32768000>;
- };
-
- power-sensor@45 {
- compatible = "ti,ina233";
- reg = <0x45>;
- shunt-resistor = <2000>;
- ti,maximum-expected-current-microamp = <32768000>;
- };
-
adc@48 {
compatible = "ti,ads7830";
reg = <0x48>;
--
2.53.0Hi Kevin, Sorry for the patchy replies so far, but this series bothers me and other priorities keep bumping it down the list. On Mon, 2026-02-23 at 19:17 +0800, Kevin Tung wrote: > Two different power monitor devices, using different drivers, reuse > I2C addresses 0x40 and 0x45 on bus 10 across Yosemite5 board variants. > Defining these devices statically in the DTS can lead to incorrect > driver binding on newer boards when the wrong device is instantiated. There are effective methods of maintaining devicetrees for variants. Why are we choosing to remove information about the platform rather than use existing techniques to properly describe them? > > Therefore, remove 10-0040 and 10-0045 device nodes, and let the driver > selection is instead handled in user space by the OpenBMC Entity > Manager based on the actual board configuration. As a separate problem to the one above, while you may run OpenBMC on this platform, I'd rather keep the description abstract. We can finish the sentence at "... is instead handled in user space" and remove the rest. Andrew
On Tue, Mar 3, 2026 at 6:41 PM Andrew Jeffery <andrew@codeconstruct.com.au> wrote: > > Hi Kevin, > > Sorry for the patchy replies so far, but this series bothers me and > other priorities keep bumping it down the list. > > On Mon, 2026-02-23 at 19:17 +0800, Kevin Tung wrote: > > Two different power monitor devices, using different drivers, reuse > > I2C addresses 0x40 and 0x45 on bus 10 across Yosemite5 board variants. > > Defining these devices statically in the DTS can lead to incorrect > > driver binding on newer boards when the wrong device is instantiated. > > There are effective methods of maintaining devicetrees for variants. > Why are we choosing to remove information about the platform rather > than use existing techniques to properly describe them? > Hi Andrew, This is due to hardware design changes during earlier development stages, and the fix is expected to remain stable as the design has matured. Could you guide me on the best way to maintain devicetrees for variants? Thank you :) > > > > Therefore, remove 10-0040 and 10-0045 device nodes, and let the driver > > selection is instead handled in user space by the OpenBMC Entity > > Manager based on the actual board configuration. > > As a separate problem to the one above, while you may run OpenBMC on > this platform, I'd rather keep the description abstract. We can finish > the sentence at "... is instead handled in user space" and remove the > rest. > Noted. Thanks. Kevin, BR
Hi Kevin, Sorry for the delay. On Mon, 2026-03-09 at 11:41 -0700, Kevin Tung wrote: > On Tue, Mar 3, 2026 at 6:41 PM Andrew Jeffery > <andrew@codeconstruct.com.au> wrote: > > > > Hi Kevin, > > > > Sorry for the patchy replies so far, but this series bothers me and > > other priorities keep bumping it down the list. > > > > On Mon, 2026-02-23 at 19:17 +0800, Kevin Tung wrote: > > > Two different power monitor devices, using different drivers, reuse > > > I2C addresses 0x40 and 0x45 on bus 10 across Yosemite5 board variants. > > > Defining these devices statically in the DTS can lead to incorrect > > > driver binding on newer boards when the wrong device is instantiated. > > > > There are effective methods of maintaining devicetrees for variants. > > Why are we choosing to remove information about the platform rather > > than use existing techniques to properly describe them? > > > Hi Andrew, > > This is due to hardware design changes during earlier development > stages, and the fix is expected to remain stable as the design has > matured. > Could you guide me on the best way to maintain devicetrees for > variants? Thank you :) My expectation is your platforms move through several design phases prior to (mass?) production. My suspicion is that you have sent a devicetree for the pre-production design phases, and you're trying to evolve that one devicetree to match the design for whatever current phase you're in. So, ideally: Send a devicetree only for the finalised design. Don't send devicetrees for pre-production designs. If you feel you can't do that for some reason, an alternative is to have a separate .dts file for each phase in the design process. This may sound tedious but it doesn't have to be a burden to maintain. For instance, you can use one or more .dtsi files to describe the common components and relationships for your platform. These .dtsi files are then #included into .dts files as usual. Often .dtsi files are used to isolate different hardware scopes (SoC vs board, for instance), but we're not limited to that, we can use them for the purpose outlined above too. If there are only (very) minor differences, there's also the option of #including another .dts file. From there you can adjust properties or even delete nodes where it makes sense. For example, we maintain a .dts file for the latest revision of the AST2600-EVB, but we also have a separate .dts for the A1 revision with a different regulator setup: - 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 Any of these are better options than this current approach of trying to justify incompatible changes against unclear design boundaries. Andrew
On Thu, Mar 26, 2026 at 2:07 PM Andrew Jeffery <andrew@codeconstruct.com.au> wrote: > > Hi Kevin, > > Sorry for the delay. > > On Mon, 2026-03-09 at 11:41 -0700, Kevin Tung wrote: > > On Tue, Mar 3, 2026 at 6:41 PM Andrew Jeffery > > <andrew@codeconstruct.com.au> wrote: > > > > > > Hi Kevin, > > > > > > Sorry for the patchy replies so far, but this series bothers me and > > > other priorities keep bumping it down the list. > > > > > > On Mon, 2026-02-23 at 19:17 +0800, Kevin Tung wrote: > > > > Two different power monitor devices, using different drivers, reuse > > > > I2C addresses 0x40 and 0x45 on bus 10 across Yosemite5 board variants. > > > > Defining these devices statically in the DTS can lead to incorrect > > > > driver binding on newer boards when the wrong device is instantiated. > > > > > > There are effective methods of maintaining devicetrees for variants. > > > Why are we choosing to remove information about the platform rather > > > than use existing techniques to properly describe them? > > > > > Hi Andrew, > > > > This is due to hardware design changes during earlier development > > stages, and the fix is expected to remain stable as the design has > > matured. > > Could you guide me on the best way to maintain devicetrees for > > variants? Thank you :) > > My expectation is your platforms move through several design phases > prior to (mass?) production. My suspicion is that you have sent a > devicetree for the pre-production design phases, and you're trying to > evolve that one devicetree to match the design for whatever current > phase you're in. > > So, ideally: Send a devicetree only for the finalised design. Don't > send devicetrees for pre-production designs. > > If you feel you can't do that for some reason, an alternative is to > have a separate .dts file for each phase in the design process. > > This may sound tedious but it doesn't have to be a burden to maintain. > > For instance, you can use one or more .dtsi files to describe the > common components and relationships for your platform. These .dtsi > files are then #included into .dts files as usual. Often .dtsi files > are used to isolate different hardware scopes (SoC vs board, for > instance), but we're not limited to that, we can use them for the > purpose outlined above too. > > If there are only (very) minor differences, there's also the option of > #including another .dts file. From there you can adjust properties or > even delete nodes where it makes sense. For example, we maintain a .dts > file for the latest revision of the AST2600-EVB, but we also have a > separate .dts for the A1 revision with a different regulator setup: > > - 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 > > Any of these are better options than this current approach of trying to > justify incompatible changes against unclear design boundaries. > > Andrew Hi Andrew, Thank you for the guidance. We will submit devicetree changes for the finalized design and ensure they align with the hardware to maintain stability and avoid incompatible changes. Kevin
© 2016 - 2026 Red Hat, Inc.