Re: [PATCH 3/4] dt-bindings: ipmi: Add optional LPC properties to ASPEED BT devices
Krzysztof Kozlowski <[email protected]> Tue, 30 Jun 2026 08:11:34 +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 | <[email protected]> |
On 29/06/2026 08:49, Yu-Che Hsieh via B4 Relay wrote: > From: Yu-Che Hsieh <[email protected]> > > Allocating IO and IRQ resources to LPC devices is in-theory an operation > > for the host, however ASPEED systems describe these resources through > > BMC-internal configuration, as already supported by the ASPEED KCS BMC What is with this line breaks? > > binding. > > Add aspeed,lpc-io-reg and aspeed,lpc-interrupts to the ASPEED BT BMC > > binding so firmware can describe the host LPC IO address and SerIRQ > > configuration using the same properties as KCS devices. > > Signed-off-by: Yu-Che Hsieh <[email protected]> > --- > .../bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml > index c4f7cdbbe16b..1803c6bbae93 100644 > --- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml > +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml > @@ -25,6 +25,24 @@ properties: > interrupts: > maxItems: 1 > > + aspeed,lpc-io-reg: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + maxItems: 1 > + description: | > + The host CPU LPC IO address for the BT device. No, you do not get second reg property. > + > + aspeed,lpc-interrupts: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 2 > + maxItems: 2 > + description: | > + A 2-cell property expressing the LPC SerIRQ number and the interrupt > + level/sense encoding (specified in the standard fashion). > + > + Note that the generated interrupt is issued from the BMC to the host, and > + thus the target interrupt controller is not captured by the BMC's > + devicetree. No, you do not get second interrupts property. > Best regards, Krzysztof