Hi Tan, Grégoire, Thanks for joining in. I should have Cc'd you both on v1 [1]. In short: on boards whose BMC runs the vendor's stock firmware (here an ASUS ASMB10-iKVM), IPMI Serial over LAN goes quiet once Linux starts, because nothing on the host drives the VUART behind the BMC's PCIe function. That firmware leaves the function's class code at KCS (0c0701), so aspeed-pci-core doesn't bind it, and v1 was a quirk in 8250_pci for those boards. Andy asked me not to add quirks to 8250_pci, so as I see it, the support needs to be either a separate driver or part of Grégoire's series.
On Sun, Oct 11, 2026, Tan Siewert wrote: > 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). Thanks, that fits what I see if the vector is 16 + SIRQ: this board (ASUS Pro WS W680-ACE IPMI, BMC firmware 1.3.13) uses vector 20 for the VUART at 0x3f8, so SIRQ 4, the legacy COM1 interrupt. So ASUS's stock firmware doesn't follow ASPEED's recommendation, and other vendors' may not either, which is why I'd rather find the vector than assume it. The function also has no INTx here (its Interrupt Pin register is 0), so without the right MSI vector the only option is polling. > 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. That's a fair point: a separate 8250 driver binds the whole function, so nothing else could bind it for KCS or the mailbox. The vector discovery below works the same in either shape, so I'm happy to go whichever way Andy and Grégoire prefer. With stock firmware, KCS doesn't go through the PCI function, though. Here the BIOS describes the KCS interface in ACPI (IPI0001: BAR1 + 0xe88, register spacing 4, no IRQ), and ipmi_si binds that ACPI device, so ipmitool keeps working while a serial driver owns the function. What does get in the way is ipmi_si's PCI driver: it binds the function because of the KCS class code, finds nothing at the start of BAR0, and stays bound. I have a small patch that makes it skip this device. An MFD that matches the KCS class code would need it too, and would need to leave KCS to ipmi_si when ACPI describes it, or both would drive the same registers. > 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. This is what I do, before any port is registered: 1. Clear IER on every VUART, so that none of them can interrupt. 2. Allocate all 32 vectors and request 1-31 with a handler that only records which vector fired. Vector 0 is left alone: with multi-MSI the function has one MSI address/data, which is cleared when vector 0 is shut down, so freeing it would cut off all vectors. 3. For each VUART in turn, four 10 ms windows: quiet, THRE enabled, THRE enabled again, quiet. THRE fires right away because the transmitter is idle. A vector belongs to the VUART only if it fired in both THRE windows and in neither quiet window. 4. If any VUART has no unique vector, free the vectors and poll all of them. The other functions don't need to be quiet for this. The host can't mask KCS or mailbox interrupts, but whatever they raise during the test also shows up in the quiet windows and is filtered out. If the VUART shared a vector with a busy KCS or mailbox interrupt, that vector would fire in a quiet window and be rejected, so the result is polling, not a wrong vector. It can only go wrong if an unrelated interrupt fires in exactly both THRE windows and neither quiet one. On this board, with all 32 vectors armed, a phase with only in-band KCS traffic (ipmitool) raised no MSI on any vector, so this firmware doesn't seem to raise KCS interrupts on the host at all. This is the only board I have, so the filtering is untested against a firmware that does, if there is one. This only finds the VUARTs' vectors. The host can't raise a KCS or mailbox interrupt on its own the way it can with THRE. A KCS transaction might provoke one, but I haven't tried that. Do you know which vectors KCS and the mailbox use on the firmware you've seen? In an MFD this would sit in the core: allocate the vectors once, run the test before adding the serial child, and pass the vector down as its IRQ, along with matching the KCS class code for stock firmware. If that's the direction Andy prefers, I can post it on top of Grégoire's series. I'll wait for Andy before sending anything. In the meantime, for reference, the separate driver I've been testing is at [2], packaged with DKMS for people with these boards. The vector discovery is in aspeed_pci8250_find_irqs(). I also have a few robustness notes on Grégoire's v6 from testing here. Once it's clear whether stock firmware support goes into his series or a separate driver, I'll send them either together with the stock firmware changes or as a review on their own. [1] https://lore.kernel.org/r/[email protected] [2] https://github.com/philrosenthal/aspeed-pci-vuart-dkms/blob/v2.1/dkms/8250_aspeed_pci.c Thanks, Phil > On Oct 11, 2026, at 12:18 PM, Tan Siewert <[email protected]> wrote: > > 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
