回覆: 回覆: [PATCH 3/4] dt-bindings: ipmi: Add optional LPC properties to ASPEED BT devices

[YC Hsieh]

> I don't understand what you are referring to, entire context is gone
> because essentially you top-posted.

Sorry about that. I misunderstood the mailing list etiquette.
Inline reply below.

On 29/06/2026 08:49, Yu-Che Hsieh via B4 Relay wrote:
>> From: Yu-Che Hsieh <yc_hsieh@xxxxxxxxxxxxxx>
>>
>> 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?

Apologies for the broken formatting in the commit message.
I will fix it in the next revision.

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

Understood.

These values are not addressable resources of the BMC node itself;
rather, they describe how the BMC's LPC engine is exposed on the host
LPC bus. I am not sure how they should be represented in DT, since
they do not seem to fit the usual semantics of either "reg" or "interrupts".

Do you have a preferred way to represent this kind of host-facing LPC
configuration in the binding?

Thanks,
Yu-Che