[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47a4795427d11c7c2d7713edda36d0c63c585c8d.camel@infradead.org>
Date: Tue, 06 May 2025 12:38:21 -0700
From: David Woodhouse <dwmw2@...radead.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Ashish Kalra
<ashish.kalra@....com>, "Kirill A. Shutemov"
<kirill.shutemov@...ux.intel.com>, linux-kernel@...r.kernel.org
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, Denis Mukhin
<dmukhin@...d.com>
Subject: Re: [PATCH v1 0/6] x86/boot: Enable earlyprintk on MMIO (8-bit)
On Fri, 2025-05-02 at 15:29 +0300, Andy Shevchenko wrote:
> Some of the platforms may have no legacy COM ports and only provide
> an MMIO accessible UART. Add support for such to earlyprintk for the
> boot phase of the kernel.
Aha, I understand now... you've added this *only* for the boot code,
and haven't added the corresponding support to the in-kernel
earlyprintk, in arch/x86/kernel/early_printk.c
The latter does already support MMIO but it only supports a 32-bit
stride, not 8-bit.
Please could you make that consistent, and ensure the earlyprintk=
arguments function the same for both phases? I'm happy to add the
kexec-debug parts on top of *that*.
It would be really helpful if we could test this in QEMU; it shouldn't
be that hard to make it provide a 16550 on MMIO, along the lines of the
one-line hack I posted yesterday.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)
Powered by blists - more mailing lists