Hi Andy,
On Sat, Oct 10, 2026, Andy Shevchenko wrote:
> In the comments to the patch you told that ipmi_si matches it.
Yes, ipmi_si binds to it, because the function has the KCS class code.
But it can't use it: it looks for the KCS registers in BAR0, and here
they are in BAR1. So ipmi_si holds the device without doing anything
useful, and nothing drives the serial ports.
> What has Pericom to do with all this?
Nothing, it was only meant as an example of an 8250 PCI driver that
lives in its own file instead of 8250_pci.c.
> I will look into this deeper when I return from the LPC 2026 trip, but
> what you are doing sounds really wrong.
Thanks. In short, for when you're back:
This device confused me at first too. On the Supermicro boards I've
used, the BMC's serial port shows up as an ordinary COM port (I/O
0x2f8), and SOL just works with the standard 8250 driver. On this ASUS
board, every device was bound to a driver, yet SOL still went quiet once
Linux booted. The reason is that the serial ports are only reachable
through the BMC's PCI device:
09:01.0 IPMI Interface [0c07]: ASPEED Technology, Inc. Device [1a03:2402]
(rev 01) (prog-if 01 [KCS])
Memory at 84000000 (32-bit, non-prefetchable) [size=1M]
Memory at 84100000 (32-bit, non-prefetchable) [size=256K]
The second BAR has both the BMC's KCS registers (at 0xe88) and up to two
16550-compatible serial ports (at 0xfe0 and 0xbe0). One of the serial
ports carries IPMI Serial over LAN.
ipmi_si looks for the KCS interface in two ways, and on this board both
happen:
- From the ACPI tables, which give it the right address in the second
BAR. This is what makes ipmitool work on this board.
- From the PCI class code. Then it binds the PCI device, but looks for
KCS in the first BAR, finds nothing there, and stays bound anyway.
Neither of these drives the serial ports.
My patches don't change the ACPI path, so ipmitool and /dev/ipmi0 work
the same with or without them. What they add is the SOL console, which
today doesn't work at all once Linux is running.
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. 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. 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.
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/[email protected]
Thanks,
Phil
> On Oct 10, 2026, at 4:10 AM, Andy Shevchenko <[email protected]>
> wrote:
>
> On Fri, Oct 9, 2026 at 4:45 PM Phil Rosenthal <[email protected]> wrote:
>>> On Oct 9, 2026, at 4:57 AM, Andy Shevchenko <[email protected]>
>>> 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
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
