Re: [PATCH] serial: 8250_pci: Add support for ASPEED BMC VUARTs over PCIe

[Tan Siewert <tan.siewert@9elements.com>]

On 10/10/26 12:47 PM, Phil Rosenthal wrote:
> On Sat, Oct 10, 2026, Andy Shevchenko wrote:
>> I will look into this deeper when I return from the LPC 2026 trip, but
>> what you are doing sounds really wrong.

*snip*

> One correction to v1: it said interrupts don't work on this device.
> They do. The board just uses a different MSI vector than the one I
> tried, and which vector it is depends on the BMC firmware.

Disclaimer: It's been a while since I worked on this driver, so please 
take my words with a grain of salt.

Correct, the BMC firmware sets its SIRQ statically. As far as we have 
seen on devices that use VUART over PCIe, they used the vendor 
recommended interrupts which are 0 and 1 (vectors 16 and 17 on the host 
side).

> In a separate driver I can find the vector at probe time and fall back
> to polling if there isn't one. That makes the console about 7 times faster
> than polling (about 15 KB/s instead of 2 KB/s), and the CPU no longer has to
> poll the port. I couldn't do that cleanly as a quirk in 8250_pci.c, but
> it would work the same in a driver for the whole device.
> 
> Grégoire Layet (Cc'd) has a series for the same device [1]
> It adds an MFD driver, drivers/mfd/aspeed-pci-core.c, that registers the
> serial ports as a child device. But it only binds when the BMC runs a modified
> OpenBMC, which changes the device's class code and puts the serial port
> interrupts on fixed MSI vectors.

@Grégoire do you remember why `8250_aspeed_vuart` sets the PCIe class 
code to `0xff000000`?

The reason for having an MFD driver instead of a separate 8250 serial 
driver is simple: We want to have the ability to support multiple 
devices like KCS over PCIe or Mailbox too, which uses the same BARs.
There was a discussion about this already in previous versions of the 
series that Grégoire has proposed (I think it was v2) [0].

> With stock firmware, like on this board, it doesn't bind at all.
> So there are two ways forward:
> 
> 1. A separate 8250 driver for stock firmware, as I proposed.
> 
> 2. Extend Grégoire's driver so it also handles stock firmware: match the
>     KCS class code as well, and find the MSI vector at probe time instead
>     of assuming it. I'd work that out with Grégoire and send it on top of
>     his series, together with the ipmi_si change. KCS would stay with
>     ipmi_si's ACPI path either way.

If you found a way to find the correct MSI vectors at probe time (with 
other features like KCS or Mailbox enabled), please propose it so. 
AFAICR we've looked into this and haven't found a suitable solution for it.

[0] 
https://lore.kernel.org/all/cover.1780929570.git.gregoire.layet@9elements.com/

Cheers,
Tan

> 
> I'm happy with either. Please let me know which you'd prefer, and I'll
> wait for that before sending anything new.
> 
> [1] https://lore.kernel.org/r/20260818-aspeed-driver-v6-v6-0-fd7cc0b338ea@9elements.com
> 
> Thanks,
> Phil
> 
> 
>> On Oct 10, 2026, at 4:10 AM, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>
>> On Fri, Oct 9, 2026 at 4:45 PM Phil Rosenthal <phil@phil.gs> wrote:
>>>> On Oct 9, 2026, at 4:57 AM, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>>>
>>>> There is already a driver for this 8250_aspeed_vuart.c. Please, do not
>>>> add new quirks to 8250_pci.c.
>>>
>>> Thanks for the review.
>>>
>>> As far as I can tell, 8250_aspeed_vuart.c drives the other end of the
>>> VUART. It is an OF platform driver (aspeed,ast2400-vuart and
>>> aspeed,ast2500-vuart) for Linux running on the BMC itself: it depends on
>>> ARCH_ASPEED, has no PCI ID table, and programs the BMC-side GCRA/GCRB
>>> registers (VUART enable, host SIRQ routing), which the host cannot
>>> reach.
>>>
>>> This patch is for the host side. There the VUART appears as 16550
>>> registers in BAR1 of the BMC's PCIe function (1a03:2402), and nothing
>>> binds that function today,
>>
>> In the comments to the patch you told that ipmi_si matches it.
>>
>>> so SOL goes quiet once Linux starts. I don't
>>> see a way to reuse 8250_aspeed_vuart.c for it, but please correct me if
>>> I'm missing something.
>>>
>>> Understood about 8250_pci.c. Would a separate driver be acceptable,
>>> e.g. drivers/tty/serial/8250/8250_aspeed_pci.c using 8250_pcilib, along
>>> the lines of 8250_pericom.c? It would do the same as this patch: find
>>> the VUARTs the BMC has enabled in BAR1 and register them as polled
>>> ports. If that works for you, I'll send it as v2.
>>
>> What has Pericom to do with all this?
>>
>> ...
>>
>> I will look into this deeper when I return from the LPC 2026 trip, but
>> what you are doing sounds really wrong.
>>
>> -- 
>> With Best Regards,
>> Andy Shevchenko
> 


-- 
Tan Siewert
(they/she)

9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email:  tan.siewert@9elements.com
Phone:  +49 234 68 94 188

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Eray Basar

Datenschutzhinweise nach Art. 13 DSGVO