From: Chris Down <chris@chrisdown.name>
To: linux-kernel@vger.kernel.org
Cc: x86@kernel.org
Subject: [PATCH] x86/ioremap: Always incriminate the caller on failure
Date: Tue, 15 Feb 2022 14:07:21 +0000 [thread overview]
Message-ID: <YguzmS7umfiaSSHU@chrisdown.name> (raw)
On my T14s Gen2, I get the following on startup:
e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:00:1f.6 eth0: MAC: 14, PHY: 12, PBA No: FFFFFF-0FF
sof-audio-pci-intel-tgl 0000:00:1f.3: warn: FW ABI is more recent than kernel
ioremap error for 0x930bc000-0x930bd000, requested 0x2, got 0x0
sof-audio-pci-intel-tgl 0000:00:1f.3: unknown sof_ext_man header type 3 size 0x30
ucsi_acpi: probe of USBC000:00 failed with error -12
Notice the ioremap error which appears sandwiched between SOF driver
messages. Without more knowledge of the kernel, and due to the
interleaving of printk errors, it's not immediately obvious to the
system administrator where this message comes from (although in this
case tracing confirms that it comes from ucsi_acpi's ->probe, as one
might expect).
To avoid issues with printk interleaving, always incriminate the caller
on ioremap() failure since we have it. While we're here, also change
these from printk(KERN_FOO) to pr_foo(), which we already use elsewhere
in ioremap.c
Signed-off-by: Chris Down <chris@chrisdown.name>
---
arch/x86/mm/ioremap.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 026031b3b782..4051094e614b 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -195,8 +195,8 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
return NULL;
if (!phys_addr_valid(phys_addr)) {
- printk(KERN_WARNING "ioremap: invalid physical address %llx\n",
- (unsigned long long)phys_addr);
+ pr_warn("%pS: ioremap: invalid physical address %llx\n",
+ caller, (unsigned long long)phys_addr);
WARN_ON_ONCE(1);
return NULL;
}
@@ -207,8 +207,8 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
* Don't allow anybody to remap normal RAM that we're using..
*/
if (io_desc.flags & IORES_MAP_SYSTEM_RAM) {
- WARN_ONCE(1, "ioremap on RAM at %pa - %pa\n",
- &phys_addr, &last_addr);
+ WARN_ONCE(1, "%pS: ioremap on RAM at %pa - %pa\n",
+ caller, &phys_addr, &last_addr);
return NULL;
}
@@ -222,14 +222,15 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
retval = memtype_reserve(phys_addr, (u64)phys_addr + size,
pcm, &new_pcm);
if (retval) {
- printk(KERN_ERR "ioremap memtype_reserve failed %d\n", retval);
+ pr_err("%pS: ioremap memtype_reserve failed %d\n",
+ caller, retval);
return NULL;
}
if (pcm != new_pcm) {
if (!is_new_memtype_allowed(phys_addr, size, pcm, new_pcm)) {
- printk(KERN_ERR
- "ioremap error for 0x%llx-0x%llx, requested 0x%x, got 0x%x\n",
+ pr_err("%pS: ioremap error for 0x%llx-0x%llx, requested 0x%x, got 0x%x\n",
+ caller,
(unsigned long long)phys_addr,
(unsigned long long)(phys_addr + size),
pcm, new_pcm);
@@ -292,7 +293,7 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
* tree.
*/
if (iomem_map_sanity_check(unaligned_phys_addr, unaligned_size))
- pr_warn("caller %pS mapping multiple BARs\n", caller);
+ pr_warn("%pS: mapping multiple BARs\n", caller);
return ret_addr;
err_free_area:
--
2.34.1
reply other threads:[~2022-02-15 14:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YguzmS7umfiaSSHU@chrisdown.name \
--to=chris@chrisdown.name \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox