From: Boaz Harrosh <boaz@plexistor.com> To: Ingo Molnar <mingo@kernel.org> Cc: Ingo Molnar <mingo@redhat.com>, Andy Lutomirski <luto@amacapital.net>, Ross Zwisler <ross.zwisler@linux.intel.com>, X86 ML <x86@kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, "Roger C. Pao" <rcpao.enmotus@gmail.com>, Dan Williams <dan.j.williams@intel.com>, Thomas Gleixner <tglx@linutronix.de>, Linus Torvalds <torvalds@linux-foundation.org>, linux-nvdimm <linux-nvdimm@lists.01.org>, "H. Peter Anvin" <hpa@zytor.com>, Matthew Wilcox <willy@linux.intel.com>, Christoph Hellwig <hch@infradead.org>, Andrew Morton <akpm@linux-foundation.org>, Vivek Goyal <vgoyal@redhat.com> Subject: [PATCH 2/3 v4] resource: Add new flag IORESOURCE_MEM_WARN Date: Tue, 24 Feb 2015 17:00:07 +0200 [thread overview] Message-ID: <54EC91F7.2030201@plexistor.com> (raw) In-Reply-To: <20150224090742.GC19930@gmail.com> Resource providers set this flag if they want that request_region will print a warning in dmesg if this particular memory resource is locked by a driver. Thous acting as a Protocol Police about experimental devices that did not pass a committee approval. The Only user of this flag is x86/kernel/e820.c that wants to WARN about UNKNOWN memory types. NOTE: It would be preferred if I defined a general flag say IORESOURCE_WARN, where any kind of resource provider can WARN on use, but we have run out of flags in the 32bit long systems. So I defined a free bit from the resource specific flags for mem resources. This is why I need to check if this is a memory resource first so not to conflict with other resource specific flags. (Though actually no one is using this specific bit) CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: "H. Peter Anvin" <hpa@zytor.com> CC: x86@kernel.org CC: Dan Williams <dan.j.williams@intel.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Bjorn Helgaas <bhelgaas@google.com> CC: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Boaz Harrosh <boaz@plexistor.com> --- arch/x86/kernel/e820.c | 3 +++ include/linux/ioport.h | 1 + kernel/resource.c | 9 ++++++++- 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 1a8a1c3..105bb37 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -961,6 +961,9 @@ void __init e820_reserve_resources(void) res->flags = IORESOURCE_MEM; + if (_is_unknown_type(e820.map[i].type)) + res->flags |= IORESOURCE_MEM_WARN; + /* * don't register the region that could be conflicted with * pci device BAR resource and insert them later in diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 2c525022..f78972b 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -90,6 +90,7 @@ struct resource { #define IORESOURCE_MEM_32BIT (3<<3) #define IORESOURCE_MEM_SHADOWABLE (1<<5) /* dup: IORESOURCE_SHADOWABLE */ #define IORESOURCE_MEM_EXPANSIONROM (1<<6) +#define IORESOURCE_MEM_WARN (1<<7) /* WARN if requested by driver */ /* PnP I/O specific bits (IORESOURCE_BITS) */ #define IORESOURCE_IO_16BIT_ADDR (1<<0) diff --git a/kernel/resource.c b/kernel/resource.c index 19f2357..4bab16f 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -1075,8 +1075,15 @@ struct resource * __request_region(struct resource *parent, break; if (conflict != parent) { parent = conflict; - if (!(conflict->flags & IORESOURCE_BUSY)) + if (!(conflict->flags & IORESOURCE_BUSY)) { + if (unlikely( + (resource_type(conflict) == IORESOURCE_MEM) + && (conflict->flags & IORESOURCE_MEM_WARN))) + pr_warn("request region with unknown memory type [mem %#010llx-%#010llx] %s\n", + conflict->start, conflict->end, + conflict->name); continue; + } } if (conflict->flags & flags & IORESOURCE_MUXED) { add_wait_queue(&muxed_resource_wait, &wait); -- 1.9.3
WARNING: multiple messages have this Message-ID (diff)
From: Boaz Harrosh <boaz@plexistor.com> To: Ingo Molnar <mingo@kernel.org> Cc: Ingo Molnar <mingo@redhat.com>, Andy Lutomirski <luto@amacapital.net>, Ross Zwisler <ross.zwisler@linux.intel.com>, X86 ML <x86@kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, "Roger C. Pao" <rcpao.enmotus@gmail.com>, Dan Williams <dan.j.williams@intel.com>, Thomas Gleixner <tglx@linutronix.de>, Linus Torvalds <torvalds@linux-foundation.org>, linux-nvdimm <linux-nvdimm@ml01.01.org>, "H. Peter Anvin" <hpa@zytor.com>, Matthew Wilcox <willy@linux.intel.com>, Christoph Hellwig <hch@infradead.org>, Andrew Morton <akpm@linux-foundation.org>, Vivek Goyal <vgoyal@redhat.com> Subject: [PATCH 2/3 v4] resource: Add new flag IORESOURCE_MEM_WARN Date: Tue, 24 Feb 2015 17:00:07 +0200 [thread overview] Message-ID: <54EC91F7.2030201@plexistor.com> (raw) In-Reply-To: <20150224090742.GC19930@gmail.com> Resource providers set this flag if they want that request_region will print a warning in dmesg if this particular memory resource is locked by a driver. Thous acting as a Protocol Police about experimental devices that did not pass a committee approval. The Only user of this flag is x86/kernel/e820.c that wants to WARN about UNKNOWN memory types. NOTE: It would be preferred if I defined a general flag say IORESOURCE_WARN, where any kind of resource provider can WARN on use, but we have run out of flags in the 32bit long systems. So I defined a free bit from the resource specific flags for mem resources. This is why I need to check if this is a memory resource first so not to conflict with other resource specific flags. (Though actually no one is using this specific bit) CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: "H. Peter Anvin" <hpa@zytor.com> CC: x86@kernel.org CC: Dan Williams <dan.j.williams@intel.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Bjorn Helgaas <bhelgaas@google.com> CC: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Boaz Harrosh <boaz@plexistor.com> --- arch/x86/kernel/e820.c | 3 +++ include/linux/ioport.h | 1 + kernel/resource.c | 9 ++++++++- 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 1a8a1c3..105bb37 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -961,6 +961,9 @@ void __init e820_reserve_resources(void) res->flags = IORESOURCE_MEM; + if (_is_unknown_type(e820.map[i].type)) + res->flags |= IORESOURCE_MEM_WARN; + /* * don't register the region that could be conflicted with * pci device BAR resource and insert them later in diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 2c525022..f78972b 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -90,6 +90,7 @@ struct resource { #define IORESOURCE_MEM_32BIT (3<<3) #define IORESOURCE_MEM_SHADOWABLE (1<<5) /* dup: IORESOURCE_SHADOWABLE */ #define IORESOURCE_MEM_EXPANSIONROM (1<<6) +#define IORESOURCE_MEM_WARN (1<<7) /* WARN if requested by driver */ /* PnP I/O specific bits (IORESOURCE_BITS) */ #define IORESOURCE_IO_16BIT_ADDR (1<<0) diff --git a/kernel/resource.c b/kernel/resource.c index 19f2357..4bab16f 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -1075,8 +1075,15 @@ struct resource * __request_region(struct resource *parent, break; if (conflict != parent) { parent = conflict; - if (!(conflict->flags & IORESOURCE_BUSY)) + if (!(conflict->flags & IORESOURCE_BUSY)) { + if (unlikely( + (resource_type(conflict) == IORESOURCE_MEM) + && (conflict->flags & IORESOURCE_MEM_WARN))) + pr_warn("request region with unknown memory type [mem %#010llx-%#010llx] %s\n", + conflict->start, conflict->end, + conflict->name); continue; + } } if (conflict->flags & flags & IORESOURCE_MUXED) { add_wait_queue(&muxed_resource_wait, &wait); -- 1.9.3
next prev parent reply other threads:[~2015-02-24 15:00 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-23 12:29 [PATCH 0/3 v2] e820: Fix handling of NvDIMM chips Boaz Harrosh 2015-02-23 12:29 ` Boaz Harrosh 2015-02-23 12:33 ` [PATCH 1/3] e820: Don't let unknown DIMM type come out BUSY Boaz Harrosh 2015-02-23 12:33 ` Boaz Harrosh 2015-02-24 4:22 ` Dan Williams 2015-02-24 4:22 ` Dan Williams 2015-02-24 7:59 ` Boaz Harrosh 2015-02-24 7:59 ` Boaz Harrosh 2015-02-24 8:34 ` Ingo Molnar 2015-02-24 8:34 ` Ingo Molnar 2015-02-24 8:51 ` Boaz Harrosh 2015-02-24 8:51 ` Boaz Harrosh 2015-02-26 2:09 ` Dan Williams 2015-02-26 2:09 ` Dan Williams 2015-02-23 12:43 ` [PATCH 2/3] resource: Add new flag IORESOURCE_WARN (64bit) Boaz Harrosh 2015-02-23 12:43 ` Boaz Harrosh 2015-02-23 15:46 ` Andy Lutomirski 2015-02-23 15:46 ` Andy Lutomirski 2015-02-24 7:20 ` Boaz Harrosh 2015-02-24 7:20 ` Boaz Harrosh 2015-02-24 19:58 ` Andy Lutomirski 2015-02-24 19:58 ` Andy Lutomirski 2015-02-24 8:39 ` [PATCH 2/3 v3] resource: Add new flag IORESOURCE_MEM_WARN Boaz Harrosh 2015-02-24 8:39 ` Boaz Harrosh 2015-02-24 8:44 ` Boaz Harrosh 2015-02-24 8:44 ` Boaz Harrosh 2015-02-24 9:06 ` Ingo Molnar 2015-02-24 9:06 ` Ingo Molnar 2015-02-24 9:08 ` Boaz Harrosh 2015-02-24 9:08 ` Boaz Harrosh 2015-02-24 9:07 ` Ingo Molnar 2015-02-24 9:07 ` Ingo Molnar 2015-02-24 9:09 ` Boaz Harrosh 2015-02-24 9:09 ` Boaz Harrosh 2015-02-24 15:00 ` Boaz Harrosh [this message] 2015-02-24 15:00 ` [PATCH 2/3 v4] " Boaz Harrosh 2015-02-24 17:04 ` Dan Williams 2015-02-24 17:04 ` Dan Williams 2015-02-25 6:36 ` Boaz Harrosh 2015-02-25 6:36 ` Boaz Harrosh 2015-02-23 12:46 ` [PATCH 3A/3 good] e820: Add the unknown-12 Memory type (DDR3-NvDIMM) Boaz Harrosh 2015-02-23 12:46 ` Boaz Harrosh 2015-02-23 15:48 ` Andy Lutomirski 2015-02-23 15:48 ` Andy Lutomirski 2015-02-23 12:48 ` [PATCH 3B/3 fat] e820: dynamic unknown-xxx names (for DDR3-NvDIMM) Boaz Harrosh 2015-02-23 12:48 ` Boaz Harrosh 2015-02-23 15:49 ` Andy Lutomirski 2015-02-23 15:49 ` Andy Lutomirski 2015-02-24 7:38 ` Boaz Harrosh 2015-02-24 7:38 ` Boaz Harrosh 2015-02-25 10:22 ` [PATCH 0/3 v2] e820: Fix handling of NvDIMM chips Ingo Molnar 2015-02-25 10:22 ` Ingo Molnar 2015-02-25 14:42 ` Boaz Harrosh 2015-02-25 14:42 ` Boaz Harrosh
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=54EC91F7.2030201@plexistor.com \ --to=boaz@plexistor.com \ --cc=akpm@linux-foundation.org \ --cc=dan.j.williams@intel.com \ --cc=hch@infradead.org \ --cc=hpa@zytor.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvdimm@lists.01.org \ --cc=luto@amacapital.net \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=rcpao.enmotus@gmail.com \ --cc=ross.zwisler@linux.intel.com \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=vgoyal@redhat.com \ --cc=willy@linux.intel.com \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.