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
