[PATCH v5 0/8] Revise Meta Yosemite5 devicetree

[PATCH v5 0/8] Revise Meta Yosemite5 devicetree

[Kevin Tung]

Summary:
Revise linux device tree entry related to Meta (Facebook) Yosemite5.

Changes in v5:
- Fix host0-ready and add POST end GPIO
- Expand PDB and HSC abbreviations in commit messages
- Use IPMB consistently in subject and description
- Rewrite "Correct power monitor shunt resistor commit" in imperative mood
- Link to v4: https://lore.kernel.org/r/20260130-yv5_revise_dts-v4-0-4d924455f3a7@gmail.com

Changes in v4:
- Add PDB IO expander device node
- Add GPIO to bypass OCP debug card commands
- Expand commit message explaining the shunt resistor correction
- Link to v3: https://lore.kernel.org/r/20251219-yv5_revise_dts-v3-0-ca1d5a382013@gmail.com

Changes in v3:
- Correct power monitor shunt resistor
- Revert the previous SGPIO P0_I3C_APML_ALERT_L renaming change
- Add new SGPIO line names and rename signal
- Retitle Update sensor configuration for more clarity
- Link to v2: https://lore.kernel.org/r/20251120-yv5_revise_dts-v2-0-4d7de701c5be@gmail.com

Changes in v2:
- Add ipmb node for OCP debug card
- Link to v1: https://lore.kernel.org/r/20251118-yv5_revise_dts-v1-0-fcd6b44b4497@gmail.com

Changes in v1:
- Increase i2c4/i2c12 bus speed to 400 kHz
- Update sensor configuration
- Rename sgpio P0_I3C_APML_ALERT_L

Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>
---
Kevin Tung (8):
      ARM: dts: aspeed: yosemite5: Increase i2c4/i2c12 bus speed to 400 kHz
      ARM: dts: aspeed: yosemite5: Remove ambiguous power monitor DTS nodes
      ARM: dts: aspeed: yosemite5: Add new SGPIO line names and rename signal
      ARM: dts: aspeed: yosemite5: Add IPMB node for OCP debug card
      ARM: dts: aspeed: yosemite5: Correct power monitor shunt resistor
      ARM: dts: aspeed: yosemite5: Add power distribution board IO expanders
      ARM: dts: aspeed: yosemite5: Add debug card bypass GPIO
      ARM: dts: aspeed: yosemite5: Fix host0-ready and add POST end GPIO

 .../dts/aspeed/aspeed-bmc-facebook-yosemite5.dts   | 117 +++++++++++++++------
 1 file changed, 87 insertions(+), 30 deletions(-)
---
base-commit: 5d1d2ebbfe226540c630e9998374e16dad2779e4
change-id: 20251118-yv5_revise_dts-12e10edd95d6

Best regards,
-- 
Kevin Tung <kevin.tung.openbmc@gmail.com>

[PATCH v5 1/8] ARM: dts: aspeed: yosemite5: Increase i2c4/i2c12 bus speed to 400 kHz

[Kevin Tung]

Configure i2c4 and i2c12 to operate at 400 kHz instead of 100 kHz.
This update aligns the bus settings with the hardware capabilities
and improves MCTP communication performance.

Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts | 2 ++
 1 file changed, 2 insertions(+)

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 2486981f3d6bd36f3fe780b21e834b85242f8aa9..7991e9360847532cff9aad4ad4ed57d4c30668a0 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
@@ -231,6 +231,7 @@ sbtsi@4c {
 &i2c4 {
 	multi-master;
 	mctp-controller;
+	clock-frequency = <400000>;
 	status = "okay";
 
 	mctp@10 {
@@ -782,6 +783,7 @@ adc@4b {
 &i2c12 {
 	multi-master;
 	mctp-controller;
+	clock-frequency = <400000>;
 	status = "okay";
 
 	mctp@10 {

-- 
2.53.0

[PATCH v5 2/8] ARM: dts: aspeed: yosemite5: Remove ambiguous power monitor DTS nodes

[Kevin Tung]

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.0

[PATCH v5 3/8] ARM: dts: aspeed: yosemite5: Add new SGPIO line names and rename signal

[Kevin Tung]

Add new SGPIO line names for user space monitoring and event logging.

Also rename PADDLE_BD_IOEXP_INT to ALERT_IRQ_PMBUS_PWR2_N to match
hardware naming. The original PADDLE_BD_IOEXP_INT is unused, so this
change does not affect current system functionality.

Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>
---
 .../dts/aspeed/aspeed-bmc-facebook-yosemite5.dts   | 31 ++++++++++++++++++----
 1 file changed, 26 insertions(+), 5 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 45b8ac2e8c65a4f672e64571631b7f6944f26213..983aebc394d9159c7e3db2e7c39e963f7b64c855 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
@@ -978,7 +978,7 @@ &sgpiom0 {
 	"E1S_0_BD_IOEXP","",
 	"E1S_1_BD_IOEXP","",
 	/*bit88-bit95*/
-	"PADDLE_BD_IOEXP_INT","",
+	"ALERT_IRQ_PMBUS_PWR2_N","",
 	"FM_BOARD_REV_ID0","",
 	"FM_BOARD_REV_ID1","",
 	"FM_BOARD_REV_ID2","",
@@ -991,16 +991,37 @@ &sgpiom0 {
 	"PRSNT_BOOT_N_FF","",
 	"PRSNT_MCIO1A_N_FF","",
 	"NIC_PRSNT_N","",
-	"","",
+	"FM_CPU_BMC_RST_N","",
 	"","",
 	"","",
 	"","",
 	/*bit104-bit111*/
-	"","","","","","","","","","","","","","","","",
+	"MASTER_PWR_EN","",
+	"MASTER_PWR2_EN","",
+	"PRSNT_MCIO0A_E1S0_N","",
+	"","",
+	"PRSNT_MCIO0A_E1S1_N","",
+	"","",
+	"","",
+	"Fault","",
 	/*bit112-bit119*/
-	"","","","","","","","","","","","","","","","",
+	"FM_CPLD_RSVD_MCIO0A_SB1","",
+	"FM_CPLD_RSVD_MCIO0A_SB2","",
+	"","",
+	"","",
+	"","",
+	"","",
+	"","",
+	"","",
 	/*bit120-bit127*/
-	"","","","","","","","","","","","","","","","";
+	"","",
+	"","",
+	"","",
+	"","",
+	"","",
+	"","",
+	"","",
+	"","";
 	status = "okay";
 };
 

-- 
2.53.0

[PATCH v5 4/8] ARM: dts: aspeed: yosemite5: Add IPMB node for OCP debug card

[Kevin Tung]

Add the device tree node to enable the IPMB interface used by
the OCP debug card.

Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts | 7 +++++++
 1 file changed, 7 insertions(+)

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 983aebc394d9159c7e3db2e7c39e963f7b64c855..84d3731b17f7c7c87338672bbcc859de2b89b722 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
@@ -365,7 +365,14 @@ i2c6mux0ch3: i2c@3 {
 
 /* SCM CPLD I2C */
 &i2c7 {
+	multi-master;
 	status = "okay";
+
+	ipmb@10 {
+		compatible = "ipmb-dev";
+		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+		i2c-protocol;
+	};
 };
 
 &i2c8 {

-- 
2.53.0

[PATCH v5 5/8] ARM: dts: aspeed: yosemite5: Correct power monitor shunt resistor

[Kevin Tung]

Correct the shunt resistor values for the power monitor devices in the
Yosemite5 devicetree.

The values originally defined in the DTS do not match the resistor
values populated on the production board. The discrepancy was caused by
using outdated pre-production hardware documentation during the initial
DTS development. As a result, the power and current readings calculated
by the driver were inaccurate.

Update the DTS to reflect the actual resistor values present on the
board so that the reported power and current measurements are correct.

Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 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 84d3731b17f7c7c87338672bbcc859de2b89b722..524597a81365ef10cd03b67d35eeb88a965cbe0a 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
@@ -415,7 +415,7 @@ power-sensor@42 {
 	power-monitor@43 {
 		compatible = "lltc,ltc4287";
 		reg = <0x43>;
-		shunt-resistor-micro-ohms = <250>;
+		shunt-resistor-micro-ohms = <100>;
 	};
 
 	power-sensor@44 {
@@ -461,25 +461,25 @@ eeprom@57 {
 	power-monitor@58 {
 		compatible = "renesas,isl28022";
 		reg = <0x58>;
-		shunt-resistor-micro-ohms = <1000>;
+		shunt-resistor-micro-ohms = <10000>;
 	};
 
 	power-monitor@59 {
 		compatible = "renesas,isl28022";
 		reg = <0x59>;
-		shunt-resistor-micro-ohms = <1000>;
+		shunt-resistor-micro-ohms = <10000>;
 	};
 
 	power-monitor@5a {
 		compatible = "renesas,isl28022";
 		reg = <0x5a>;
-		shunt-resistor-micro-ohms = <1000>;
+		shunt-resistor-micro-ohms = <10000>;
 	};
 
 	power-monitor@5b {
 		compatible = "renesas,isl28022";
 		reg = <0x5b>;
-		shunt-resistor-micro-ohms = <1000>;
+		shunt-resistor-micro-ohms = <10000>;
 	};
 
 	psu@5c {
@@ -723,13 +723,13 @@ gpio-expander@21 {
 	power-sensor@40 {
 		compatible = "ti,ina230";
 		reg = <0x40>;
-		shunt-resistor = <2000>;
+		shunt-resistor = <1000>;
 	};
 
 	power-sensor@41 {
 		compatible = "ti,ina230";
 		reg = <0x41>;
-		shunt-resistor = <2000>;
+		shunt-resistor = <1000>;
 	};
 
 	power-sensor@42 {

-- 
2.53.0

[PATCH v5 6/8] ARM: dts: aspeed: yosemite5: Add power distribution board IO expanders

[Kevin Tung]

Add device tree nodes for the two IO expanders on the power
distribution board (PDB) in Yosemite5.

The updated hardware design introduces these IO expanders to support
fan presence detection, hot swap controller (HSC) fault monitoring,
and PDB CPLD update status monitoring.

Connect the IO expander interrupt to SGPIO92. This pin was previously
named ALERT_PADDLE2_SMB_N and was unused by the system. Repurpose and
rename it to FM_IOE_ALT_N to reflect its function as the PDB IO
expander interrupt.

Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>
---
 .../dts/aspeed/aspeed-bmc-facebook-yosemite5.dts   | 42 +++++++++++++++++++++-
 1 file changed, 41 insertions(+), 1 deletion(-)

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 524597a81365ef10cd03b67d35eeb88a965cbe0a..30fb41fdaeb7a2276cdfe98654696a16cf1de5fc 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
@@ -389,6 +389,46 @@ adc@1d {
 		ti,mode = /bits/ 8 <1>;
 	};
 
+	/* PDB IOEXP0 */
+	pdb_io_expander0: gpio-expander@24 {
+		compatible = "nxp,pca9555";
+		reg = <0x24>;
+		interrupt-parent = <&sgpiom0>;
+		interrupts = <92 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names =
+			"FM_P52V_AUX_FLT_N","FM_P12V_AUX_ALERT_N",
+			"FM_SLOT1_HSC_FAULT","FM_SLOT2_HSC_FAULT",
+			"FM_SLOT3_HSC_FAULT","FM_SLOT4_HSC_FAULT",
+			"FM_SLOT5_HSC_FAULT","FM_SLOT6_HSC_FAULT",
+			"PRSNT_FAN0","PRSNT_FAN1",
+			"PRSNT_FAN2","PRSNT_FAN3",
+			"","",
+			"","INT_SLOT";
+	};
+
+	/* PDB IOEXP1 */
+	gpio-expander@25 {
+		compatible = "nxp,pca9555";
+		reg = <0x25>;
+		interrupt-parent = <&pdb_io_expander0>;
+		interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names =
+			"SLOT1_CM_UPDATE","SLOT2_CM_UPDATE",
+			"SLOT3_CM_UPDATE","SLOT4_CM_UPDATE",
+			"SLOT5_CM_UPDATE","SLOT6_CM_UPDATE",
+			"","",
+			"","",
+			"","",
+			"","",
+			"","";
+	};
+
 	power-sensor@40 {
 		compatible = "ti,ina238";
 		reg = <0x40>;
@@ -937,7 +977,7 @@ &sgpiom0 {
 	"ALERT_OC_PADDLE2_N","",
 	"ALERT_OC_PWR2_N","",
 	"ALERT_OC_PWR11_N","",
-	"ALERT_PADDLE2_SMB_N","",
+	"FM_IOE_ALT_N","",
 	"ALERT_PWR14_SB2_LEAK_DETECT_N","",
 	/*bit48-bit55*/
 	"ALERT_PWR14_SB3_LEAK_DETECT_N","",

-- 
2.53.0

[PATCH v5 7/8] ARM: dts: aspeed: yosemite5: Add debug card bypass GPIO

[Kevin Tung]

On Yv5, the SCM CPLD bypass OCP debug card commands to the BMC.
These commands share the same I2C bus used by the BMC to access the
SCM CPLD for firmware updates, which can cause bus conflicts.

To avoid this, the SCM CPLD provides a bypass control GPIO connected
to GPIOO7. When asserted by the BMC, this GPIO isolates debug card
commands and prevents conflicts during SCM CPLD access.

Add the DEBUG_CARD_BYPASS GPIO to support this behavior.

Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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 30fb41fdaeb7a2276cdfe98654696a16cf1de5fc..f590ec6e00c48afe4ade1fb98011780ac0570e7c 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
@@ -166,7 +166,8 @@ &gpio0 {
 			"led-postcode-3","led-postcode-4","led-postcode-5",
 			"led-postcode-6","led-postcode-7",
 	/*O0-O7*/	"RUN_POWER_PG","PWR_BRAKE","CHASSIS_AC_LOSS","BSM_PRSNT_N",
-			"PSU_SMB_ALERT","FM_TPM_PRSNT_0_N","PSU_FW_UPDATING_N","",
+			"PSU_SMB_ALERT","FM_TPM_PRSNT_0_N",
+			"PSU_FW_UPDATING_N","DEBUG_CARD_BYPASS",
 	/*P0-P7*/	"PWR_BTN_BMC_N","IPEX_CABLE_PRSNT","ID_RST_BTN_BMC_N",
 			"RST_BMC_RSTBTN_OUT_N","BMC_PWR_LED","RUN_POWER_EN","SHDN_FORCE","",
 	/*Q0-Q7*/	"IRQ_PCH_TPM_SPI_LV3_N","USB_OC0_REAR_N","UART_MUX_SEL",

-- 
2.53.0

[PATCH v5 8/8] ARM: dts: aspeed: yosemite5: Fix host0-ready and add POST end GPIO

[Kevin Tung]

Rename the unused PWRGD_CPU_PWROK_2 line to host0-ready and move the
previous host0-ready GPIO to FM_BIOS_POST_CMPLT_N.

The "host0-ready" line name is used by OpenBMC phosphor-state-manager
to determine whether the host firmware is running. The previous DTS
incorrectly mapped host0-ready to the POST end signal, causing
incorrect host firmware detection.

Map host0-ready to the correct power-good signal and use
FM_BIOS_POST_CMPLT_N as the POST end indicator.

Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 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 f590ec6e00c48afe4ade1fb98011780ac0570e7c..beb971eadbe53b5d9fa49252a41bf7484a8e32da 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
@@ -929,8 +929,8 @@ &sgpiom0 {
 	/*bit0-bit7*/
 	"PWRGD_CPU_PWROK","SGPIO_RSTBTN_OUT",
 	"PWRGD_CPU_PWROK_1","SGPIO_BMC_READY",
-	"PWRGD_CPU_PWROK_2","IBB_BMC_SRST",
-	"host0-ready","FM_I3C_SPD_AH_SEL_R",
+	"host0-ready","IBB_BMC_SRST",
+	"FM_BIOS_POST_CMPLT_N","FM_I3C_SPD_AH_SEL_R",
 	"PCIe_HP_BOOT","FM_I3C_SPD_IP_SEL_R",
 	"PCIe_HP_DATA","FM_JTAG_BMC_MUX_S0_R",
 	"PCIe_HP_NIC","FM_JTAG_BMC_MUX_S1_R",

-- 
2.53.0

Re: [PATCH v5 3/8] ARM: dts: aspeed: yosemite5: Add new SGPIO line names and rename signal

[Andrew Jeffery]

On Mon, 2026-02-23 at 19:17 +0800, Kevin Tung wrote:
> Add new SGPIO line names for user space monitoring and event logging.
> 
> Also rename PADDLE_BD_IOEXP_INT to ALERT_IRQ_PMBUS_PWR2_N to match
> hardware naming. The original PADDLE_BD_IOEXP_INT is unused, so this
> change does not affect current system functionality.

Why are these two problems being solved in the one patch?

https://docs.kernel.org/process/submitting-patches.html#split-changes

Essentially, your use of "Also" is a bit of a red flag here.

However, on the specifics, why was the PADDLE_BD_IOEXP_INT hardware
naming wrong to begin with? What changed?

Broadly, it feels a lot like you're revising platform designs, then
trying to make the one devicetree fit the current design, and are not
explicitly communicating that this is what you're doing.

If that _is_ what you're doing, then we can come up with much better
schemes to handle it that aren't a constant stream of compatibility
breaks.

I need you to engage with this concern.

From inspection, I only find patches 1, 4 and 7 of this series to be
something I'd consider applying without further discussion.

Andrew

Re: [PATCH v5 2/8] ARM: dts: aspeed: yosemite5: Remove ambiguous power monitor DTS nodes

[Andrew Jeffery]

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?

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

Re: [PATCH v5 3/8] ARM: dts: aspeed: yosemite5: Add new SGPIO line names and rename signal

[Kevin Tung]

On Tue, Mar 3, 2026 at 6:41 PM Andrew Jeffery
<andrew@codeconstruct.com.au> wrote:
>
> On Mon, 2026-02-23 at 19:17 +0800, Kevin Tung wrote:
> > Add new SGPIO line names for user space monitoring and event logging.
> >
> > Also rename PADDLE_BD_IOEXP_INT to ALERT_IRQ_PMBUS_PWR2_N to match
> > hardware naming. The original PADDLE_BD_IOEXP_INT is unused, so this
> > change does not affect current system functionality.
>
> Why are these two problems being solved in the one patch?
>
> https://docs.kernel.org/process/submitting-patches.html#split-changes
>
> Essentially, your use of "Also" is a bit of a red flag here.
>
Hi Andew, sorry for addressing two issues in a single patch. I will
split them into two separate patches.

> However, on the specifics, why was the PADDLE_BD_IOEXP_INT hardware
> naming wrong to begin with? What changed?
>
Originally the signal was named PADDLE_BD_IOEXP_INT by the hardware team,
but the name did not clearly reflect its actual function. After
discussion with the EE team,
it was renamed to ALERT_IRQ_PMBUS_PWR2_N to better match its use as
the PMBus PWR2 alert interrupt in the system.

> Broadly, it feels a lot like you're revising platform designs, then
> trying to make the one devicetree fit the current design, and are not
> explicitly communicating that this is what you're doing.
>
> If that _is_ what you're doing, then we can come up with much better
> schemes to handle it that aren't a constant stream of compatibility
> breaks.
>
> I need you to engage with this concern.
>
Thanks for your feedback. I realize there may be a lack of knowledge
on my side regarding the best practices here.
Could you kindly guide me on how we might implement a better approach
that avoids a constant stream of compatibility breaks?
I’d like to ensure we handle this correctly and align with the
expected workflow.

> From inspection, I only find patches 1, 4 and 7 of this series to be
> something I'd consider applying without further discussion.
>
Got it. Should I split patches 1, 4, and 7 into a separate series?
This would keep the current series shorter by excluding items that
don’t require further discussion.

Kevin
BR

Re: [PATCH v5 2/8] ARM: dts: aspeed: yosemite5: Remove ambiguous power monitor DTS nodes

[Kevin Tung]

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

Re: [PATCH v5 2/8] ARM: dts: aspeed: yosemite5: Remove ambiguous power monitor DTS nodes

[Andrew Jeffery]

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

Re: [PATCH v5 3/8] ARM: dts: aspeed: yosemite5: Add new SGPIO line names and rename signal

[Andrew Jeffery]

Hi Kevin,

On Mon, 2026-03-09 at 11:34 -0700, Kevin Tung wrote:
> > Broadly, it feels a lot like you're revising platform designs, then
> > trying to make the one devicetree fit the current design, and are not
> > explicitly communicating that this is what you're doing.
> > 
> > If that _is_ what you're doing, then we can come up with much better
> > schemes to handle it that aren't a constant stream of compatibility
> > breaks.
> > 
> > I need you to engage with this concern.
> > 
> Thanks for your feedback. I realize there may be a lack of knowledge
> on my side regarding the best practices here.
> Could you kindly guide me on how we might implement a better approach
> that avoids a constant stream of compatibility breaks?
> I’d like to ensure we handle this correctly and align with the
> expected workflow.

Sure, see the reply I just sent here:

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

> 
> > From inspection, I only find patches 1, 4 and 7 of this series to be
> > something I'd consider applying without further discussion.
> > 
> Got it. Should I split patches 1, 4, and 7 into a separate series?
> This would keep the current series shorter by excluding items that
> don’t require further discussion.
> 

I am okay with that, so long as it makes sense in the context of the
discussion linked above.

Andrew