Add pcie_lpc node and pcie_kcs4 child to the ast2600 g6 common dtsi.

The ASPEED AST2600 has a PCIe to LPC controller. It includes a KCS
interface on channel 4. This is a fully KCS-compatible interface
that is exposed over PCIe.

This can be used by the host for IPMI when the PCIe BMC Device is
activated.

While the datasheet provides interrupt numbers for KCS channels 1, 2,
3 and 4 over PCI, not all 4 are described in the "PCIe to LPC Controller"
section. Since only the KCS channel 4 is described, only this channel is
added.

Ordered next to existing lpc node for address ordering.
Use existing "aspeed,ast2600-lpc-v2" compatible string.
The pcie_kcs4 uses existing "aspeed,ast2600-kcs-bmc" compatible as it's a
standard KCS interface.

Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
 arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 56bb3b0444f7..ac351f01048f 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -658,6 +658,21 @@ ibt: ibt@140 {
 				};
 			};

+			pcie_lpc: pcie-lpc@1e789800 {
+				compatible = "aspeed,ast2600-lpc-v2", "simple-mfd", "syscon";
+				reg = <0x1e789800 0x800>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0x0 0x1e789800 0x800>;
+
+				pcie_kcs4: pcie-kcs@114 {
+					compatible = "aspeed,ast2600-kcs-bmc";
+					reg = <0x114 0x1>, <0x118 0x1>, <0x11c 0x1>;
+					interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
+					status = "disabled";
+				};
+			};
+
 			sdc: sdc@1e740000 {
 				compatible = "aspeed,ast2600-sd-controller";
 				reg = <0x1e740000 0x100>;

base-commit: 03f906d8f5541e8bb741035981304feceed5993d
--
2.54.0

> Add pcie_lpc node and pcie_kcs4 child to the ast2600 g6 common dtsi.
> 
> The ASPEED AST2600 has a PCIe to LPC controller. It includes a KCS
> interface on channel 4. This is a fully KCS-compatible interface
> that is exposed over PCIe.
> 
> This can be used by the host for IPMI when the PCIe BMC Device is
> activated.
> 
> While the datasheet provides interrupt numbers for KCS channels 1, 2,
> 3 and 4 over PCI, not all 4 are described in the "PCIe to LPC Controller"
> section. Since only the KCS channel 4 is described, only this channel is
> added.
> 
> Ordered next to existing lpc node for address ordering.
> Use existing "aspeed,ast2600-lpc-v2" compatible string.
> The pcie_kcs4 uses existing "aspeed,ast2600-kcs-bmc" compatible as it's a
> standard KCS interface.
> 
> Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> index 56bb3b0444f7..ac351f01048f 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> @@ -658,6 +658,21 @@ ibt: ibt@140 {
>  				};
>  			};
>  
> +			pcie_lpc: pcie-lpc@1e789800 {

lpc@1e789000 already maps 0x1e789000-0x1e78a000 and 0x1e789914 falls inside it,
so you're describing a second `ast2600-lpc-v2` node which is unnecessary.

Suggestion: Merge pcie_kcs4 into lpc@1e789000 and use 914 as offset. That way
you don't accidentally cause an overlap for the devices if you describe more in
the future.

	Tan

-- 
Tan Siewert <tan.siewert@9elements.com>

> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> > index 56bb3b0444f7..ac351f01048f 100644
> > --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> > @@ -658,6 +658,21 @@ ibt: ibt@140 {
> >                               };
> >                       };
> >
> > +                     pcie_lpc: pcie-lpc@1e789800 {
>
> lpc@1e789000 already maps 0x1e789000-0x1e78a000 and 0x1e789914 falls inside it,

I agree that there is an overlap in address space in my patch.
I will fix this in a new revision.

> so you're describing a second `ast2600-lpc-v2` node which is unnecessary.
>
> Suggestion: Merge pcie_kcs4 into lpc@1e789000 and use 914 as offset. That way
> you don't accidentally cause an overlap for the devices if you describe more in
> the future.

The 'kcs_bmc_aspeed' driver has the kcs channels address hard-coded.
If the 'reg' property does not contain the three addresses used by one
of the four channels, the driver returns -EINVAL.
So having a pcie-kcs4 with regs 0x914, 0x918 and 0x91c doesn't work.

This is why a second LPC node was added, for the pcie-kcs4 to have
regs 0x114, 0x118 and 0x11c;

I know we should write device tree sources based on hardware rather
than around driver limitations.
Changing how the driver behaves seems excessive for supporting KCS over PCIe.
I think a point can be made that the LPC over PCIe is a different LPC bus.

Regards,
Grégoire

On Mon, 2026-07-20 at 18:31 +0200, Grégoire Layet wrote:
> > > diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> > > index 56bb3b0444f7..ac351f01048f 100644
> > > --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> > > +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> > > @@ -658,6 +658,21 @@ ibt: ibt@140 {
> > >                               };
> > >                       };
> > > 
> > > +                     pcie_lpc: pcie-lpc@1e789800 {
> > 
> > lpc@1e789000 already maps 0x1e789000-0x1e78a000 and 0x1e789914 falls inside it,
> 
> I agree that there is an overlap in address space in my patch.
> I will fix this in a new revision.
> 
> > so you're describing a second `ast2600-lpc-v2` node which is unnecessary.
> > 
> > Suggestion: Merge pcie_kcs4 into lpc@1e789000 and use 914 as offset. That way
> > you don't accidentally cause an overlap for the devices if you describe more in
> > the future.
> 
> The 'kcs_bmc_aspeed' driver has the kcs channels address hard-coded.
> If the 'reg' property does not contain the three addresses used by one
> of the four channels, the driver returns -EINVAL.
> So having a pcie-kcs4 with regs 0x914, 0x918 and 0x91c doesn't work.

It does work if you fix the driver to allow it.

> 
> This is why a second LPC node was added, for the pcie-kcs4 to have
> regs 0x114, 0x118 and 0x11c;
> 
> I know we should write device tree sources based on hardware rather
> than around driver limitations.
> Changing how the driver behaves seems excessive for supporting KCS over PCIe.

I don't think this is true.

> I think a point can be made that the LPC over PCIe is a different LPC bus.

In my opinion it's most helpful if Table 8 in the datasheet is used as
the reference for address ranges in the devicetree. With that in mind,
I don't intend to apply a patch adding a new node as you've proposed. I
suggest adjusting the driver to identify the X{{I,O}D,ST}R4 addresses
as channel 4, under the existing LPC node as Tan suggested.

Andrew

> > > so you're describing a second `ast2600-lpc-v2` node which is unnecessary.
> > >
> > > Suggestion: Merge pcie_kcs4 into lpc@1e789000 and use 914 as offset. That way
> > > you don't accidentally cause an overlap for the devices if you describe more in
> > > the future.
> >
> > The 'kcs_bmc_aspeed' driver has the kcs channels address hard-coded.
> > If the 'reg' property does not contain the three addresses used by one
> > of the four channels, the driver returns -EINVAL.
> > So having a pcie-kcs4 with regs 0x914, 0x918 and 0x91c doesn't work.
>
> It does work if you fix the driver to allow it.
>
> >
> > This is why a second LPC node was added, for the pcie-kcs4 to have
> > regs 0x114, 0x118 and 0x11c;
> >
> > I know we should write device tree sources based on hardware rather
> > than around driver limitations.
> > Changing how the driver behaves seems excessive for supporting KCS over PCIe.
>
> I don't think this is true.
>
> > I think a point can be made that the LPC over PCIe is a different LPC bus.
>
> In my opinion it's most helpful if Table 8 in the datasheet is used as
> the reference for address ranges in the devicetree. With that in mind,
> I don't intend to apply a patch adding a new node as you've proposed. I
> suggest adjusting the driver to identify the X{{I,O}D,ST}R4 addresses
> as channel 4, under the existing LPC node as Tan suggested.

Sure, thanks for the clear details.
With the Table 8 in mind, I agree and I was wrong.
I'll work on that.

Regards,
Grégoire