arch/x86/kernel/eisa.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
Area at the 0x0FFFD9 physical location in the PC memory space is regular
memory, traditionally ROM BIOS and more recently a copy of BIOS code and
data in RAM, write-protected.
Use memremap() then to get access to it rather than ioremap(), avoiding
issues in virtualization scenarios and complementing changes such as
commit f7750a795687 ("x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use
memremap() for RAM mappings") or commit 5997efb96756 ("x86/boot: Use
memremap() to map the MPF and MPC data").
Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Closes: https://lore.kernel.org/r/20240822095122.736522-1-kirill.shutemov@linux.intel.com
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
Changes from v1:
- Access the signature directly rather than via `readl', fixing a sparse
warning found by CI.
---
arch/x86/kernel/eisa.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
linux-x86-eisa-bus-probe-memremap.diff
Index: linux-macro/arch/x86/kernel/eisa.c
===================================================================
--- linux-macro.orig/arch/x86/kernel/eisa.c
+++ linux-macro/arch/x86/kernel/eisa.c
@@ -11,15 +11,15 @@
static __init int eisa_bus_probe(void)
{
- void __iomem *p;
+ unsigned int *p;
if ((xen_pv_domain() && !xen_initial_domain()) || cc_platform_has(CC_ATTR_GUEST_SEV_SNP))
return 0;
- p = ioremap(0x0FFFD9, 4);
- if (p && readl(p) == 'E' + ('I' << 8) + ('S' << 16) + ('A' << 24))
+ p = memremap(0x0FFFD9, 4, MEMREMAP_WB);
+ if (p && *p == 'E' + ('I' << 8) + ('S' << 16) + ('A' << 24))
EISA_bus = 1;
- iounmap(p);
+ memunmap(p);
return 0;
}
subsys_initcall(eisa_bus_probe);
On Mon, Aug 26, 2024 at 10:21:47AM +0100, Maciej W. Rozycki wrote:
> + if (p && *p == 'E' + ('I' << 8) + ('S' << 16) + ('A' << 24))
Should this simply use strcmp now?
On Wed, 28 Aug 2024, Christoph Hellwig wrote:
> > + if (p && *p == 'E' + ('I' << 8) + ('S' << 16) + ('A' << 24))
>
> Should this simply use strcmp now?
It's not an ASCIIZ string, so I guess memcmp() instead. I can see there
is still no clarity as to whether memremap() is enough here (though it
escapes me why it wouldn't, given that early_memremap() analogously works
for the MP-table with the scenarios in question), so I'll let things
settle and look into an update once I'm back from my holiday next week.
NB sparse chokes on some headers' contents here, so it seems I can't
really make use of it without figuring out what's wrong first.
Maciej
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: a678164aadbf68d80f7ab79b8bd5cfe3711e42fa
Gitweb: https://git.kernel.org/tip/a678164aadbf68d80f7ab79b8bd5cfe3711e42fa
Author: Maciej W. Rozycki <macro@orcam.me.uk>
AuthorDate: Mon, 26 Aug 2024 10:21:47 +01:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Thu, 29 Aug 2024 15:57:09 +02:00
x86/EISA: Dereference memory directly instead of using readl()
Sparse expect an __iomem pointer, but after converting the EISA probe to
memremap() the pointer is a regular memory pointer. Access it directly
instead.
[ tglx: Converted it to fix the already applied version ]
Fixes: 80a4da05642c ("x86/EISA: Use memremap() to probe for the EISA BIOS signature")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/alpine.DEB.2.21.2408261015270.30766@angie.orcam.me.uk
---
arch/x86/kernel/eisa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/eisa.c b/arch/x86/kernel/eisa.c
index 5a4f99a..9535a65 100644
--- a/arch/x86/kernel/eisa.c
+++ b/arch/x86/kernel/eisa.c
@@ -11,13 +11,13 @@
static __init int eisa_bus_probe(void)
{
- void *p;
+ u32 *p;
if ((xen_pv_domain() && !xen_initial_domain()) || cc_platform_has(CC_ATTR_GUEST_SEV_SNP))
return 0;
p = memremap(0x0FFFD9, 4, MEMREMAP_WB);
- if (p && readl(p) == 'E' + ('I' << 8) + ('S' << 16) + ('A' << 24))
+ if (p && *p == 'E' + ('I' << 8) + ('S' << 16) + ('A' << 24))
EISA_bus = 1;
memunmap(p);
return 0;
© 2016 - 2025 Red Hat, Inc.