[PATCH v6 4/6] mfd: aspeed-pci-core: add AST2600 PCIe BMC device driver

[Phil Rosenthal]

On Tue, Oct 13, 2026 at 09:22:15AM +0300, Andy Shevchenko wrote:
> I interpret this clearly as "Let's allow vendors to continue making
> mistakes and provide wrong DT/configuration bits." My vote is
> definitely *no* to a such. If this needs to be done to support some
> weird firmware in the wild it must:
> - be a quirk that is clear sign that one has avoid such an example
> - inform the vendor to fix their crap
>
> Did I get it wrong?

Thanks for your review.

I see it a little differently, though my wording didn't help. For the
BMC side added by this series, I agree with you: with
aspeed,vuart-over-pci set, vuart3 and vuart4 should always be on SIRQ
0 and 1, the values the host's vectors 16 and 17 rely on, set in
aspeed-g6.dtsi rather than left to each board. That's the simple fix
for v7 of this series, with no discovery, since here the BMC and host
sides both come from this series. That's probably the less common
case, though: most of these boards run the firmware the board maker
ships with them, not OpenBMC. [my assumption, I don't have data]

The case I had in mind is firmware outside this series: the stock BMC
firmware on the ASUS board, which already ships. Which SIRQ a VUART
uses is a choice on the BMC side, and nothing documents which MSI
vector that becomes on the PCIe side or lets the host read it. From
testing, the vector looks like 16 + SIRQ: this series uses SIRQ 0 and
1 and gets vectors 16 and 17, and on the ASUS board the VUART is on
vector 20, which would be SIRQ 4, the 8250_aspeed_vuart default and
the COM1 interrupt. But that's inferred, as the host can't see the
SIRQ the firmware chose. So there's no documented value for the vendor
to fix to, and boards in the field keep their firmware.

Jacky, three things from ASPEED would help. First, confirming whether
the vector is always 16 + SIRQ. Second, having the SDK put the VUARTs
used over PCI on the same SIRQs as this series, so that firmware built
on the SDK matches the host driver. Third, longer term, a register the
host can read that gives the SIRQ or vector, since even a documented
mapping doesn't tell the host which SIRQ the firmware chose. In the
meantime, boards already in the field still need handling.

For those I'd make it a quirk, as you say. The class code tells them
apart: the stock firmware leaves the function at 0c0701, while this
series' BMC side sets ff. So the vector search would run only for
0c0701, wherever that support ends up, and never for boards using
this series.

If you'd rather not have a search at all, the quirk could instead use
the vector seen on the ASUS board, 20, for class 0c0701. That only
holds for firmware that picked the same SIRQ, and since stock firmware
from any vendor would have the same class code, each board whose
firmware picked a different SIRQ would need its own entry keyed on
DMI. With a wrong vector the port's tty output would stall, so that case
needs to be handled: the quirk would still check that the vector fires and
poll if it doesn't. The search avoids both, with a single quirk entry.

Would either form be acceptable to you?

Whichever you prefer, it doesn't settle where the stock firmware
support should go, in aspeed-pci-core or in the separate driver I
proposed [1]; that's still open, and the quirk would be the same in
either.

[1] https://lore.kernel.org/r/8CD30026-4C04-4E0F-B7A3-5C107D2A8410@phil.gs

Thanks,
Phil