[PATCH v3 0/5] ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs

[PATCH v3 0/5] ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs

[Fred Chen]

Update Santabarbara Device Tree to include several GPIO expanders for
NIC, Switch, and system monitoring.

v2 -> v3:
- Reword the system monitoring GPIOs commit message
- Disable power monitor nodes for ICs that now have multiple vendor sources
- Add GPIO line names for the JTAG CPU debug interface
- Add SGPIO line names for MCIO thermal trip monitoring and UFM read-complete
- Add a leak-cable-presence IO expander on the module boards
- Link to v2: https://lore.kernel.org/all/20260421130344.2751662-1-fredchen.openbmc@gmail.com/


v1 -> v2:
- Add system power fault alert and E1S GPIO expander interrupt
- Add switch board SKU IDs and power good monitoring
- Add NIC1-4 power good monitoring, reset control, and fault detection
- Update the commit message
- Link to v1: https://lore.kernel.org/all/20260129073749.3155383-1-fredchen.openbmc@gmail.com/

Fred Chen (5):
  ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs
  ARM: dts: aspeed: santabarbara: Disable power monitor nodes
  ARM: dts: aspeed: santabarbara: Add JTAG GPIO line names
  ARM: dts: aspeed: santabarbara: Add SGPIO line names
  ARM: dts: aspeed: santabarbara: Add leak cable present IO expander

 .../aspeed-bmc-facebook-santabarbara.dts      | 200 +++++++++++++++++-
 1 file changed, 192 insertions(+), 8 deletions(-)

-- 
2.52.0

[PATCH v3 1/5] ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs

[Fred Chen]

Add several GPIO expanders on the switch board for NIC, PEX, and cable
presence monitoring. Due to a design change, ioexp0 (0x20) now
aggregates interrupts from the downstream expanders (0x21-0x27) onto a
single sgpiom0 line, reducing the number of sideband interrupt pins
required.

The new nodes provide:
- NIC1-4 power good monitoring, reset control, and fault detection
- Switch PEX power good signals and hardware SKU/Revision IDs
- Cable presence detection and selection for four SPI flashes
- System power fault alert via SGPIO and E1S GPIO expander interrupt

Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
---
 .../aspeed-bmc-facebook-santabarbara.dts      | 125 +++++++++++++++++-
 1 file changed, 124 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
index 0a3e2e241063..2a822e38f091 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
@@ -616,6 +616,8 @@ gpio@74 {
 				reg = <0x74>;
 				gpio-controller;
 				#gpio-cells = <2>;
+				interrupt-parent = <&sgpiom0>;
+				interrupts = <146 IRQ_TYPE_LEVEL_LOW>;
 				gpio-line-names =
 					"P12V_E1S_ADC_ALERT","BUFF0_100M_LOSB_PLD",
 					"E1S_BP_SKU_ID0","E1S_BP_SKU_ID1",
@@ -1335,6 +1337,112 @@ eeprom@50 {
 &i2c12 {
 	status = "okay";
 
+	ioexp0: gpio@20 {
+		compatible = "nxp,pca9555";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&sgpiom0>;
+		interrupts = <148 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"IOEXP_21h_INT_N","IOEXP_22h_INT_N",
+			"IOEXP_23h_INT_N","IOEXP_24h_INT_N",
+			"IOEXP_25h_INT_N","IOEXP_26h_INT_N",
+			"IOEXP_27h_INT_N","SWB_PWR_FAULT_N",
+			"","","","",
+			"","","","";
+	};
+
+	gpio@21 {
+		compatible = "nxp,pca9555";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&ioexp0>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"PDB_PRSNT_J1_N","PDB_PRSNT_J2_N",
+			"PRSNT_NIC1_N","PRSNT_NIC2_N",
+			"PRSNT_NIC3_N","PRSNT_NIC4_N",
+			"","",
+			"CBL_PRSNT_MCIO_0_N","CBL_PRSNT_MCIO_1_N",
+			"CBL_PRSNT_MCIO_2_N","CBL_PRSNT_MCIO_3_N",
+			"","","","";
+	};
+
+	gpio@22 {
+		compatible = "nxp,pca9555";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&ioexp0>;
+		interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"SWB_PWRGD_P3V3_AUX","SWB_PWRGD_P1V8_PEX",
+			"SWB_PWRGD_P1V8_AUX","SWB_PWRGD_P5V",
+			"SWB_PWRGD_P1V5_PEX","SWB_PWRGD_P1V2_PEX",
+			"SWB_PWRGD_P0V895_PEX","SWB_PWRGD_P0V81_PEX_0",
+			"SWB_PWRGD_P0V81_PEX_1","SWB_PWRGD_P0V81_REFCLK",
+			"SWB_PWRGD_MODULE","",
+			"","","","";
+	};
+
+	gpio@24 {
+		compatible = "nxp,pca9555";
+		reg = <0x24>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&ioexp0>;
+		interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"RST_PERST_NIC1_N","RST_PERST_NIC2_N",
+			"RST_PERST_NIC3_N","RST_PERST_NIC4_N",
+			"RST_PERST_MCIO_0_N","RST_PERST_MCIO_1_N",
+			"RST_PERST_MCIO_2_N","RST_PERST_MCIO_3_N",
+			"FM_P3V3_NIC1_FAULT_N","FM_P3V3_NIC2_FAULT_N",
+			"FM_P3V3_NIC3_FAULT_N","FM_P3V3_NIC4_FAULT_N",
+			"PWRGD_P12V_NIC1","PWRGD_P12V_NIC2",
+			"PWRGD_P12V_NIC3","PWRGD_P12V_NIC4";
+	};
+
+	gpio@25 {
+		compatible = "nxp,pca9555";
+		reg = <0x25>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&ioexp0>;
+		interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"NIC1_MAIN_R_PWR_EN","NIC2_MAIN_R_PWR_EN",
+			"NIC3_MAIN_R_PWR_EN","NIC4_MAIN_R_PWR_EN",
+			"FM_PLD_NIC1_AUX_PWR_EN","FM_PLD_NIC2_AUX_PWR_EN",
+			"FM_PLD_NIC3_AUX_PWR_EN","FM_PLD_NIC4_AUX_PWR_EN",
+			"PWRGD_NIC1","PWRGD_NIC2",
+			"PWRGD_NIC3","PWRGD_NIC4",
+			"PWRGD_P3V3_NIC1","PWRGD_P3V3_NIC2",
+			"PWRGD_P3V3_NIC3","PWRGD_P3V3_NIC4";
+	};
+
+	gpio@26 {
+		compatible = "nxp,pca9555";
+		reg = <0x26>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&ioexp0>;
+		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"SWB_SKU_ID_0","SWB_SKU_ID_1",
+			"SWB_SKU_ID_2","SWB_SKU_ID_3",
+			"SWB_REV_ID_0","SWB_REV_ID_1",
+			"SWB_REV_ID_2","",
+			"RST_PLD_PEX_PERST_N","CPLD_MB_PWR_EN",
+			"RST_PERST_SWB_R_N","SWB_LEAK_DETECT",
+			"PEX_SYS_ERR_FPGA","PRSNT_SWB_LEAK_CABLE_N",
+			"","";
+	};
+
 	gpio@27 {
 		compatible = "nxp,pca9555";
 		reg = <0x27>;
@@ -1349,6 +1457,21 @@ gpio@27 {
 			"SPI_MUX_SEL","","","";
 	};
 
+	gpio@28 {
+		compatible = "nxp,pca9555";
+		reg = <0x28>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names =
+			"SCO_UART_MUX_SEL0","SCO_UART_MUX_SEL1",
+			"SPI_PROG_PL12_SEL","SPI_PROG_PL34_SEL",
+			"","","","",
+			"I3C_HUB_3_MUX_SEL_PLD","",
+			"SPI_PROG_PL12_EN_N","SPI_PROG_PL34_EN_N",
+			"SCO1_SPI_SEL","SCO2_SPI_SEL",
+			"SCO3_SPI_SEL","SCO4_SPI_SEL";
+	};
+
 	// SWB FRU
 	eeprom@52 {
 		compatible = "atmel,24c64";
@@ -1776,7 +1899,7 @@ &sgpiom0 {
 	"MB_SKU_ID_1","PASSWORD_CLEAR",
 	"MB_SKU_ID_2","",
 	"MB_SKU_ID_3","",
-	"","BIOS_DEBUG_MODE",
+	"SYS_PWR_FAULT_ALERT","BIOS_DEBUG_MODE",
 	/*H0-H3 line 112-119*/
 	"FM_IOEXP_U538_INT_N","",
 	"FM_IOEXP_U539_INT_N","FM_MODULE_PWR_EN_N_1B",
-- 
2.52.0

Re: [PATCH v3 1/5] ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The pre-existing gpio@27 node was not updated to route its interrupt to the new ioexp0 aggregator, breaking the intended design.
- [Medium] The newly added gpio@28 node uses an I2C address (0x28) that is physically impossible for a standard PCA9555 chip.
- [Medium] The gpio@23 downstream expander node is missing from the device tree.
- [Medium] Conflict between interrupt assignments and SGPIO pin names for gpio@74 and ioexp0.
--

--- Patch [1]: [PATCH v3 1/5] ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs ---
commit 8d0ec3e4ec2df315ded9be783e4deeb197721ee9
Author: Fred Chen <fredchen.openbmc@gmail.com>

ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs

This commit adds several GPIO expanders on the switch board for NIC, PEX,
and cable presence monitoring. Due to a design change, ioexp0 (0x20) now
aggregates interrupts from the downstream expanders (0x21-0x27) onto a
single sgpiom0 line.

> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
> @@ -616,6 +616,8 @@ gpio@74 {
>  				reg = <0x74>;
>  				gpio-controller;
>  				#gpio-cells = <2>;
> +				interrupt-parent = <&sgpiom0>;
> +				interrupts = <146 IRQ_TYPE_LEVEL_LOW>;

[Severity: Medium]
Does this interrupt assignment conflict with the SGPIO pin names?

The interrupt 146 is assigned to gpio@74 here, but in sgpiom0's
gpio-line-names, line 146 is labeled 'FM_SMB_ALERT_MCIO_0A_N'.

Is this an intentional override or a hardware description mismatch that
could lead to incorrect interrupt handling?

[ ... ]

> +	ioexp0: gpio@20 {
> +		compatible = "nxp,pca9555";
> +		reg = <0x20>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&sgpiom0>;
> +		interrupts = <148 IRQ_TYPE_LEVEL_LOW>;

[Severity: Medium]
Similar to the issue above, interrupt 148 is assigned here to ioexp0,
but sgpiom0's line 148 is named 'I3C_MCIO_0B_ALERT_ISO_R_N'. Could this
conflict cause misinterpretation of alerts?

> +		gpio-line-names =
> +			"IOEXP_21h_INT_N","IOEXP_22h_INT_N",
> +			"IOEXP_23h_INT_N","IOEXP_24h_INT_N",

[Severity: Medium]
The commit message states that ioexp0 aggregates interrupts from the contiguous
downstream expanders range 0x21-0x27, and the line names here explicitly
reserve pin 2 for 'IOEXP_23h_INT_N'.

However, there doesn't seem to be a gpio@23 node provided in the device tree.
Will the hardware connected to the 0x23 expander be unmanaged by the kernel?

[ ... ]

>  	gpio@27 {
>  		compatible = "nxp,pca9555";
>  		reg = <0x27>;
> @@ -1349,6 +1457,21 @@ gpio@27 {
>  			"SPI_MUX_SEL","","","";
>  	};

[Severity: Medium]
Since the commit explicitly changes the design to route 0x21-0x27 expander
interrupts to ioexp0, should this existing gpio@27 node also be updated with
an 'interrupt-parent = <&ioexp0>' property?

Without it, will the physical interrupts on the gpio@27 INT_N pin assert
ioexp0's line 6 but remain unhandled, potentially leading to an interrupt
storm?

> +	gpio@28 {
> +		compatible = "nxp,pca9555";
> +		reg = <0x28>;

[Severity: Medium]
Can the PCA9555 physically respond to address 0x28?

The NXP PCA9555 hardware typically has 3 address pins (A0, A1, A2) and a fixed
base of 0x20, meaning its valid 7-bit I2C addresses are strictly 0x20 through
0x27. Will the kernel fail to probe the PCA9555 GPIO expander at this address?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807083415.672008-1-fredchen.openbmc@gmail.com?part=1

[PATCH v3 2/5] ARM: dts: aspeed: santabarbara: Disable power monitor nodes

[Fred Chen]

Due to a design change, this power monitor IC now has multiple
sources, and different vendors' parts require different drivers.
Disable these nodes so the kernel does not auto-probe a driver, and
let userspace instantiate the correct driver based on the part
actually populated on the board.

Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
index 2a822e38f091..04fa9a5e0d04 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
@@ -585,24 +585,28 @@ power-monitor@40 {
 				compatible = "ti,ina230";
 				reg = <0x40>;
 				shunt-resistor = <2000>;
+				status = "disabled";
 			};
 
 			power-monitor@41 {
 				compatible = "ti,ina230";
 				reg = <0x41>;
 				shunt-resistor = <2000>;
+				status = "disabled";
 			};
 
 			power-monitor@44 {
 				compatible = "ti,ina230";
 				reg = <0x44>;
 				shunt-resistor = <2000>;
+				status = "disabled";
 			};
 
 			power-monitor@45 {
 				compatible = "ti,ina230";
 				reg = <0x45>;
 				shunt-resistor = <2000>;
+				status = "disabled";
 			};
 		};
 
-- 
2.52.0

[PATCH v3 3/5] ARM: dts: aspeed: santabarbara: Add JTAG GPIO line names

[Fred Chen]

Label the GPIO lines used for the CPU JTAG debug interface
(TDI/TCK/TMS/TDO and CPLD DBREQ/TRST). These lines are driven from
userspace via GPIO bit-banging to emulate JTAG signals for CPU
debugging, so naming them lets userspace request the lines by name.

Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
---
 .../boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts  | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
index 04fa9a5e0d04..9d334a01d407 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
@@ -199,7 +199,9 @@ &gpio0 {
 	/*F0-F7*/	"","","","","","","","",
 	/*G0-G7*/	"FM_MUX1_SEL_R","","","","","","","",
 	/*H0-H7*/	"","","","","","","","",
-	/*I0-I7*/	"","","","","","","","",
+	/*I0-I7*/	"","JTAG_1_BMC_TDI",
+			"JTAG_1_BMC_TCK","JTAG_1_BMC_TMS",
+			"JTAG_1_BMC_TDO","","","",
 	/*J0-J7*/	"","","","","","","","",
 	/*K0-K7*/	"","","","","","","","",
 	/*L0-L7*/	"","","","","","","","",
@@ -1911,8 +1913,8 @@ &sgpiom0 {
 	"FM_IOEXP_U541_INT_N","FM_MODULE_PWR_EN_N_3B",
 	/*H4-H7 line 120-127*/
 	"FM_IOEXP_PDB2_U1003_INT_N","FM_MODULE_PWR_EN_N_4B",
-	"","",
-	"","",
+	"","JTAG_CPLD_DBREQ",
+	"","JTAG_CPLD_TRST",
 	"FM_MAIN_PWREN_RMC_EN_ISO_R","",
 	/*I0-I3 line 128-135*/
 	"","","","",
-- 
2.52.0

[PATCH v3 4/5] ARM: dts: aspeed: santabarbara: Add SGPIO line names

[Fred Chen]

Label two groups of SGPIO lines.

- FM_MCIO_[1-4]_THERMTRIP_N: thermal trip signals carried over the
  MCIO cables, indicating overheat on each of the four asic modules.
- UFM_READ_CMPLT: asserted by the BMC after it finishes reading UFM
  data, to notify the CPLD that the data can be cleared.

Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
---
 .../boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts   | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
index 9d334a01d407..3d35a5a74104 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
@@ -1907,7 +1907,7 @@ &sgpiom0 {
 	"MB_SKU_ID_3","",
 	"SYS_PWR_FAULT_ALERT","BIOS_DEBUG_MODE",
 	/*H0-H3 line 112-119*/
-	"FM_IOEXP_U538_INT_N","",
+	"FM_IOEXP_U538_INT_N","UFM_READ_CMPLT",
 	"FM_IOEXP_U539_INT_N","FM_MODULE_PWR_EN_N_1B",
 	"FM_IOEXP_U540_INT_N","FM_MODULE_PWR_EN_N_2B",
 	"FM_IOEXP_U541_INT_N","FM_MODULE_PWR_EN_N_3B",
@@ -1941,7 +1941,10 @@ &sgpiom0 {
 	"I3C_MCIO_4B_ALERT_ISO_R_N","",
 	"","",
 	/*K4-K7 line 168-175*/
-	"","","","","","","","",
+	"FM_MCIO_1_THERMTRIP_N","",
+	"FM_MCIO_2_THERMTRIP_N","",
+	"FM_MCIO_3_THERMTRIP_N","",
+	"FM_MCIO_4_THERMTRIP_N","",
 	/*L0-L3 line 176-183*/
 	"FM_CPU0_THERMTRIP_N","",
 	"FM_CPU0_PROCHOT_N","",
-- 
2.52.0

[PATCH v3 5/5] ARM: dts: aspeed: santabarbara: Add leak cable present IO expander

[Fred Chen]

Add a pca9555 GPIO expander (0x22) on i2c6/i2c8/i2c10/i2c13, one per
module board, to expose the PRSNT_MODULE[0-3]_LEAK_CABLE_R_N line used
to detect whether the module's leak-detection cable is plugged
in.

Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
---
 .../aspeed-bmc-facebook-santabarbara.dts      | 56 ++++++++++++++++++-
 1 file changed, 54 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
index 3d35a5a74104..ca5bd805d975 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
@@ -641,6 +641,19 @@ gpio@74 {
 &i2c6 {
 	status = "okay";
 
+	gpio@22 {
+		compatible = "nxp,pca9555";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&sgpiom0>;
+		interrupts = <150 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"PRSNT_MODULE0_LEAK_CABLE_R_N","",
+			"","","","","","",
+			"","","","","","","","";
+	};
+
 	// Rainbow0 FRU
 	eeprom@52 {
 		compatible = "atmel,24c256";
@@ -866,6 +879,19 @@ ipmb@10 {
 &i2c8 {
 	status = "okay";
 
+	gpio@22 {
+		compatible = "nxp,pca9555";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&sgpiom0>;
+		interrupts = <154 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"PRSNT_MODULE2_LEAK_CABLE_R_N","",
+			"","","","","","",
+			"","","","","","","","";
+	};
+
 	// Rainbow2 FRU
 	eeprom@52 {
 		compatible = "atmel,24c256";
@@ -1106,7 +1132,20 @@ eeprom@56 {
 &i2c10 {
 	status = "okay";
 
-	// Rainbow3 FRU
+	gpio@22 {
+		compatible = "nxp,pca9555";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&sgpiom0>;
+		interrupts = <158 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"PRSNT_MODULE1_LEAK_CABLE_R_N","",
+			"","","","","","",
+			"","","","","","","","";
+	};
+
+	// Rainbow1 FRU
 	eeprom@52 {
 		compatible = "atmel,24c256";
 		reg = <0x52>;
@@ -1588,7 +1627,20 @@ i2c12mux0ch7: i2c@7 {
 &i2c13 {
 	status = "okay";
 
-	// Rainbow1 FRU
+	gpio@22 {
+		compatible = "nxp,pca9555";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&sgpiom0>;
+		interrupts = <162 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+			"PRSNT_MODULE3_LEAK_CABLE_R_N","",
+			"","","","","","",
+			"","","","","","","","";
+	};
+
+	// Rainbow3 FRU
 	eeprom@52 {
 		compatible = "atmel,24c256";
 		reg = <0x52>;
-- 
2.52.0