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/[email protected]/
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/[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
--
Tan Siewert
(they/she)
9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: [email protected]
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
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
