Re: [PATCH] ARM: dts: aspeed-g6: add pcie-lpc and pcie-kcs4

GrĂ©goire Layet <[email protected]> Wed, 22 Jul 2026 09:48:33 +0200
Newsgroups org.ozlabs.lists.linux-aspeed,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <CAFi2wKaWiE61y_rUr_2UNN2_fSAEswG7CXQrPMWT0NiSVBcBVg@mail.gmail.com>
> > > so you're describing a second `ast2600-lpc-v2` node which is unnecess=
ary.
> > >
> > > 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 descri=
be 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 b=
us.
>
> 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=C3=A9goire