Groups > linux.kernel > #1291685 > unrolled thread

[PATCH 01/11] resource: Add System RAM resource type

Started by	Toshi Kani <toshi.kani@hpe.com>
First post	2015-12-15 00:40 +0100
Last post	2015-12-24 22:40 +0100
Articles	20 on this page of 27 — 4 participants

Back to article view | Back to linux.kernel

  [PATCH 01/11] resource: Add System RAM resource type Toshi Kani <toshi.kani@hpe.com> - 2015-12-15 00:40 +0100
    [PATCH 08/11] memremap: Change region_intersects() to use System RAM type Toshi Kani <toshi.kani@hpe.com> - 2015-12-15 00:40 +0100
    [PATCH 06/11] kexec: Set IORESOURCE_SYSTEM_RAM to System RAM Toshi Kani <toshi.kani@hpe.com> - 2015-12-15 00:40 +0100
    [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type Toshi Kani <toshi.kani@hpe.com> - 2015-12-15 00:40 +0100
      Re: [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System  RAM type Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-12-15 01:30 +0100
    [PATCH 07/11] memory-hotplug: Set IORESOURCE_SYSTEM_RAM to System RAM Toshi Kani <toshi.kani@hpe.com> - 2015-12-15 00:40 +0100
    [PATCH 04/11] arch: Set IORESOURCE_SYSTEM_RAM to System RAM Toshi Kani <toshi.kani@hpe.com> - 2015-12-15 00:40 +0100
    [PATCH 09/11] resource: Change walk_system_ram to use System RAM type Toshi Kani <toshi.kani@hpe.com> - 2015-12-15 00:40 +0100
    [PATCH 05/11] xen: Set IORESOURCE_SYSTEM_RAM to System RAM Toshi Kani <toshi.kani@hpe.com> - 2015-12-15 00:50 +0100
    [PATCH 03/11] x86/e820: Set IORESOURCE_SYSTEM_RAM to System RAM Toshi Kani <toshi.kani@hpe.com> - 2015-12-15 00:50 +0100
    Re: [PATCH 01/11] resource: Add System RAM resource type Borislav Petkov <bp@alien8.de> - 2015-12-16 13:30 +0100
      Re: [PATCH 01/11] resource: Add System RAM resource type Toshi Kani <toshi.kani@hpe.com> - 2015-12-16 16:50 +0100
        Re: [PATCH 01/11] resource: Add System RAM resource type Borislav Petkov <bp@alien8.de> - 2015-12-16 16:50 +0100
          Re: [PATCH 01/11] resource: Add System RAM resource type Toshi Kani <toshi.kani@hpe.com> - 2015-12-16 17:40 +0100
            Re: [PATCH 01/11] resource: Add System RAM resource type Borislav Petkov <bp@alien8.de> - 2015-12-16 18:50 +0100
              Re: [PATCH 01/11] resource: Add System RAM resource type Dan Williams <dan.j.williams@intel.com> - 2015-12-16 19:00 +0100
                Re: [PATCH 01/11] resource: Add System RAM resource type Borislav Petkov <bp@alien8.de> - 2015-12-16 19:20 +0100
                  Re: [PATCH 01/11] resource: Add System RAM resource type Dan Williams <dan.j.williams@intel.com> - 2015-12-16 20:00 +0100
                    Re: [PATCH 01/11] resource: Add System RAM resource type Borislav Petkov <bp@alien8.de> - 2015-12-16 20:20 +0100
                  Re: [PATCH 01/11] resource: Add System RAM resource type Toshi Kani <toshi.kani@hpe.com> - 2015-12-16 23:00 +0100
                    Re: [PATCH 01/11] resource: Add System RAM resource type Borislav Petkov <bp@alien8.de> - 2015-12-22 12:40 +0100
                      Re: [PATCH 01/11] resource: Add System RAM resource type Toshi Kani <toshi.kani@hpe.com> - 2015-12-22 21:10 +0100
                        Re: [PATCH 01/11] resource: Add System RAM resource type Borislav Petkov <bp@alien8.de> - 2015-12-23 15:30 +0100
                          Re: [PATCH 01/11] resource: Add System RAM resource type Toshi Kani <toshi.kani@hpe.com> - 2015-12-24 03:30 +0100
                            Re: [PATCH 01/11] resource: Add System RAM resource type Toshi Kani <toshi.kani@hpe.com> - 2015-12-24 18:10 +0100
                              Re: [PATCH 01/11] resource: Add System RAM resource type Borislav Petkov <bp@alien8.de> - 2015-12-24 21:00 +0100
                                Re: [PATCH 01/11] resource: Add System RAM resource type Toshi Kani <toshi.kani@hpe.com> - 2015-12-24 22:40 +0100

Page 1 of 2 [1] 2 Next page →

#1291685 — [PATCH 01/11] resource: Add System RAM resource type

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-15 00:40 +0100
Subject	[PATCH 01/11] resource: Add System RAM resource type
Message-ID	<qFKSJ-4sB-19@gated-at.bofh.it>

I/O resource type, IORESOURCE_MEM, is used for all types of
memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
reserved, and so on.  This requires walk_system_ram_range(),
walk_system_ram_res(), and region_intersects() to use strcmp()
against string "System RAM" to search System RAM ranges in the
iomem table, which is inefficient.  __ioremap_caller() and
reserve_memtype() on x86, for instance, call walk_system_ram_range()
for every request to check if a given range is in System RAM ranges.

However, adding a new I/O resource type for System RAM is not
a viable option [1].  Instead, this patch adds a new modifier
flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].

To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
work continuously for System RAM, resource_ext_type() is added
for extracting extended type bit(s).

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reference[1]: https://lkml.org/lkml/2015/12/3/540
Reference[2]: https://lkml.org/lkml/2015/12/3/582
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 include/linux/ioport.h |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 24bea08..4b65d94 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -49,12 +49,19 @@ struct resource {
 #define IORESOURCE_WINDOW	0x00200000	/* forwarded by bridge */
 #define IORESOURCE_MUXED	0x00400000	/* Resource is software muxed */
 
+#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource extended types */
+#define IORESOURCE_SYSRAM	0x01000000	/* System RAM (modifier) */
+
 #define IORESOURCE_EXCLUSIVE	0x08000000	/* Userland may not map this resource */
+
 #define IORESOURCE_DISABLED	0x10000000
 #define IORESOURCE_UNSET	0x20000000	/* No address assigned yet */
 #define IORESOURCE_AUTO		0x40000000
 #define IORESOURCE_BUSY		0x80000000	/* Driver has marked this resource busy */
 
+/* I/O resource extended types */
+#define IORESOURCE_SYSTEM_RAM		(IORESOURCE_MEM|IORESOURCE_SYSRAM)
+
 /* PnP IRQ specific bits (IORESOURCE_BITS) */
 #define IORESOURCE_IRQ_HIGHEDGE		(1<<0)
 #define IORESOURCE_IRQ_LOWEDGE		(1<<1)
@@ -170,6 +177,10 @@ static inline unsigned long resource_type(const struct resource *res)
 {
 	return res->flags & IORESOURCE_TYPE_BITS;
 }
+static inline unsigned long resource_ext_type(const struct resource *res)
+{
+	return res->flags & IORESOURCE_EXT_TYPE_BITS;
+}
 /* True iff r1 completely contains r2 */
 static inline bool resource_contains(struct resource *r1, struct resource *r2)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1291686 — [PATCH 08/11] memremap: Change region_intersects() to use System RAM type

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-15 00:40 +0100
Subject	[PATCH 08/11] memremap: Change region_intersects() to use System RAM type
Message-ID	<qFKSJ-4sB-17@gated-at.bofh.it>
In reply to	#1291685

Change region_intersects() to add @flags, and make @name optinal
with NULL.  When NULL is set to @name, it skips strcmp().

Change the callers of region_intersects(), memremap() and
devm_memremap(), to set IORESOURCE_SYSTEM_RAM to @flags for
searching System RAM.

Also, export region_intersects() so that the EINJ driver can
call this function in a later patch.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 include/linux/mm.h |    3 ++-
 kernel/memremap.c  |   13 +++++++------
 kernel/resource.c  |   25 ++++++++++++++-----------
 3 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 00bad77..d2ee94a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -362,7 +362,8 @@ enum {
 	REGION_MIXED,
 };
 
-int region_intersects(resource_size_t offset, size_t size, const char *type);
+int region_intersects(resource_size_t offset, size_t size, unsigned long flags,
+			const char *name);
 
 /* Support for virtually mapped pages */
 struct page *vmalloc_to_page(const void *addr);
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 7658d32..cefd382 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -44,7 +44,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * being mapped does not have i/o side effects and the __iomem
  * annotation is not applicable.
  *
- * MEMREMAP_WB - matches the default mapping for "System RAM" on
+ * MEMREMAP_WB - matches the default mapping for System RAM on
  * the architecture.  This is usually a read-allocate write-back cache.
  * Morever, if MEMREMAP_WB is specified and the requested remap region is RAM
  * memremap() will bypass establishing a new mapping and instead return
@@ -53,11 +53,12 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * MEMREMAP_WT - establish a mapping whereby writes either bypass the
  * cache or are written through to memory and never exist in a
  * cache-dirty state with respect to program visibility.  Attempts to
- * map "System RAM" with this mapping type will fail.
+ * map System RAM with this mapping type will fail.
  */
 void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 {
-	int is_ram = region_intersects(offset, size, "System RAM");
+	int is_ram = region_intersects(offset, size,
+					IORESOURCE_SYSTEM_RAM, NULL);
 	void *addr = NULL;
 
 	if (is_ram == REGION_MIXED) {
@@ -73,7 +74,7 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 		 * MEMREMAP_WB is special in that it can be satisifed
 		 * from the direct map.  Some archs depend on the
 		 * capability of memremap() to autodetect cases where
-		 * the requested range is potentially in "System RAM"
+		 * the requested range is potentially in System RAM.
 		 */
 		if (is_ram == REGION_INTERSECTS)
 			addr = try_ram_remap(offset, size);
@@ -85,7 +86,7 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 	 * If we don't have a mapping yet and more request flags are
 	 * pending then we will be attempting to establish a new virtual
 	 * address mapping.  Enforce that this mapping is not aliasing
-	 * "System RAM"
+	 * System RAM.
 	 */
 	if (!addr && is_ram == REGION_INTERSECTS && flags) {
 		WARN_ONCE(1, "memremap attempted on ram %pa size: %#lx\n",
@@ -163,7 +164,7 @@ static void devm_memremap_pages_release(struct device *dev, void *res)
 void *devm_memremap_pages(struct device *dev, struct resource *res)
 {
 	int is_ram = region_intersects(res->start, resource_size(res),
-			"System RAM");
+					IORESOURCE_SYSTEM_RAM, NULL);
 	struct page_map *page_map;
 	int error, nid;
 
diff --git a/kernel/resource.c b/kernel/resource.c
index d30a175..56bed6d 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -496,31 +496,33 @@ EXPORT_SYMBOL_GPL(page_is_ram);
  * region_intersects() - determine intersection of region with known resources
  * @start: region start address
  * @size: size of region
- * @name: name of resource (in iomem_resource)
+ * @flags: flags of resource (in iomem_resource)
+ * @name: name of resource (in iomem_resource) or NULL
  *
  * Check if the specified region partially overlaps or fully eclipses a
- * resource identified by @name.  Return REGION_DISJOINT if the region
- * does not overlap @name, return REGION_MIXED if the region overlaps
- * @type and another resource, and return REGION_INTERSECTS if the
- * region overlaps @type and no other defined resource. Note, that
- * REGION_INTERSECTS is also returned in the case when the specified
- * region overlaps RAM and undefined memory holes.
+ * resource identified by @flags and @name (optinal with NULL).  Return
+ * REGION_DISJOINT if the region does not overlap @flags/@name, return
+ * REGION_MIXED if the region overlaps @flags/@name and another resource,
+ * and return REGION_INTERSECTS if the region overlaps @flags/@name and
+ * no other defined resource. Note, that REGION_INTERSECTS is also returned
+ * in the case when the specified region overlaps RAM and undefined memory
+ * holes.
  *
  * region_intersect() is used by memory remapping functions to ensure
  * the user is not remapping RAM and is a vast speed up over walking
  * through the resource table page by page.
  */
-int region_intersects(resource_size_t start, size_t size, const char *name)
+int region_intersects(resource_size_t start, size_t size, unsigned long flags,
+			const char *name)
 {
-	unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 	resource_size_t end = start + size - 1;
 	int type = 0; int other = 0;
 	struct resource *p;
 
 	read_lock(&resource_lock);
 	for (p = iomem_resource.child; p ; p = p->sibling) {
-		bool is_type = strcmp(p->name, name) == 0 &&
-				((p->flags & flags) == flags);
+		bool is_type = ((p->flags & flags) == flags) &&
+				(!name || strcmp(p->name, name) == 0);
 
 		if (start >= p->start && start <= p->end)
 			is_type ? type++ : other++;
@@ -539,6 +541,7 @@ int region_intersects(resource_size_t start, size_t size, const char *name)
 
 	return REGION_DISJOINT;
 }
+EXPORT_SYMBOL_GPL(region_intersects);
 
 void __weak arch_remove_reservations(struct resource *avail)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291687 — [PATCH 06/11] kexec: Set IORESOURCE_SYSTEM_RAM to System RAM

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-15 00:40 +0100
Subject	[PATCH 06/11] kexec: Set IORESOURCE_SYSTEM_RAM to System RAM
Message-ID	<qFKSK-4sB-31@gated-at.bofh.it>
In reply to	#1291685

Set IORESOURCE_SYSTEM_RAM to the flags of resource ranges with
"System RAM", and "Crash kernel", which is a child node of
System RAM.

Change kexec_add_buffer() to call walk_iomem_res() with
IORESOURCE_SYSTEM_RAM type for "Crash kernel".

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 kernel/kexec_core.c |    6 +++---
 kernel/kexec_file.c |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 11b64a6..c47cd98 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -66,13 +66,13 @@ struct resource crashk_res = {
 	.name  = "Crash kernel",
 	.start = 0,
 	.end   = 0,
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 struct resource crashk_low_res = {
 	.name  = "Crash kernel",
 	.start = 0,
 	.end   = 0,
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 int kexec_should_crash(struct task_struct *p)
@@ -934,7 +934,7 @@ int crash_shrink_memory(unsigned long new_size)
 
 	ram_res->start = end;
 	ram_res->end = crashk_res.end;
-	ram_res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+	ram_res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 	ram_res->name = "System RAM";
 
 	crashk_res.end = end - 1;
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b70ada0..c245085 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -523,7 +523,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer, unsigned long bufsz,
 	/* Walk the RAM ranges and allocate a suitable range for the buffer */
 	if (image->type == KEXEC_TYPE_CRASH)
 		ret = walk_iomem_res("Crash kernel",
-				     IORESOURCE_MEM | IORESOURCE_BUSY,
+				     IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
 				     crashk_res.start, crashk_res.end, kbuf,
 				     locate_mem_hole_callback);
 	else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291688 — [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-15 00:40 +0100
Subject	[PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type
Message-ID	<qFKSK-4sB-37@gated-at.bofh.it>
In reply to	#1291685

Change s3c_pm_run_res() to check with IORESOURCE_SYSTEM_RAM,
instead of strcmp() with "System RAM", in the resource table.

No functional change is made to the interface.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 arch/arm/plat-samsung/pm-check.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/pm-check.c b/arch/arm/plat-samsung/pm-check.c
index 04aff2c..70f2f69 100644
--- a/arch/arm/plat-samsung/pm-check.c
+++ b/arch/arm/plat-samsung/pm-check.c
@@ -53,8 +53,8 @@ static void s3c_pm_run_res(struct resource *ptr, run_fn_t fn, u32 *arg)
 		if (ptr->child != NULL)
 			s3c_pm_run_res(ptr->child, fn, arg);
 
-		if ((ptr->flags & IORESOURCE_MEM) &&
-		    strcmp(ptr->name, "System RAM") == 0) {
+		if ((ptr->flags & IORESOURCE_SYSTEM_RAM)
+				== IORESOURCE_SYSTEM_RAM) {
 			S3C_PMDBG("Found system RAM at %08lx..%08lx\n",
 				  (unsigned long)ptr->start,
 				  (unsigned long)ptr->end);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291721 — Re: [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type

From	Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date	2015-12-15 01:30 +0100
Subject	Re: [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type
Message-ID	<qFLF8-522-29@gated-at.bofh.it>
In reply to	#1291688

On 15.12.2015 08:37, Toshi Kani wrote:
> Change s3c_pm_run_res() to check with IORESOURCE_SYSTEM_RAM,
> instead of strcmp() with "System RAM", in the resource table.
> 
> No functional change is made to the interface.
> 
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> ---
>  arch/arm/plat-samsung/pm-check.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291692 — [PATCH 07/11] memory-hotplug: Set IORESOURCE_SYSTEM_RAM to System RAM

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-15 00:40 +0100
Subject	[PATCH 07/11] memory-hotplug: Set IORESOURCE_SYSTEM_RAM to System RAM
Message-ID	<qFKSL-4sB-55@gated-at.bofh.it>
In reply to	#1291685

Set IORESOURCE_SYSTEM_RAM to the flags of memory hotplug resource
ranges with "System RAM".

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 mm/memory_hotplug.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 67d488a..9458423 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -136,7 +136,7 @@ static struct resource *register_memory_resource(u64 start, u64 size)
 	res->name = "System RAM";
 	res->start = start;
 	res->end = start + size - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	if (request_resource(&iomem_resource, res) < 0) {
 		pr_debug("System RAM resource %pR cannot be added\n", res);
 		kfree(res);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291695 — [PATCH 04/11] arch: Set IORESOURCE_SYSTEM_RAM to System RAM

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-15 00:40 +0100
Subject	[PATCH 04/11] arch: Set IORESOURCE_SYSTEM_RAM to System RAM
Message-ID	<qFKSK-4sB-39@gated-at.bofh.it>
In reply to	#1291685

Set IORESOURCE_SYSTEM_RAM to the flags of resource ranges with
"System RAM", "Kernel code", "Kernel data", and "Kernel bss".

Note, IORESOURCE_SYSRAM (i.e. modifier bit) is set to the flags
when IORESOURCE_MEM is already set.  IORESOURCE_SYSTEM_RAM is
defined as (IORESOURCE_MEM|IORESOURCE_SYSRAM).

Note2, Some archs do not set flags for children nodes, such as
"Kernel code".  This patch keeps the flags unset in such cases.

Cc: linux-arch@vger.kernel.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 arch/arm/kernel/setup.c       |    6 +++---
 arch/arm64/kernel/setup.c     |    6 +++---
 arch/avr32/kernel/setup.c     |    6 +++---
 arch/ia64/kernel/efi.c        |    6 ++++--
 arch/ia64/kernel/setup.c      |    6 +++---
 arch/m32r/kernel/setup.c      |    4 ++--
 arch/mips/kernel/setup.c      |   10 ++++++----
 arch/parisc/mm/init.c         |    6 +++---
 arch/powerpc/mm/mem.c         |    2 +-
 arch/s390/kernel/setup.c      |    8 ++++----
 arch/score/kernel/setup.c     |    2 +-
 arch/sh/kernel/setup.c        |    8 ++++----
 arch/sparc/mm/init_64.c       |    8 ++++----
 arch/tile/kernel/setup.c      |   11 ++++++++---
 arch/unicore32/kernel/setup.c |    6 +++---
 15 files changed, 52 insertions(+), 43 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 20edd34..ae44e09 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -173,13 +173,13 @@ static struct resource mem_res[] = {
 		.name = "Kernel code",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	},
 	{
 		.name = "Kernel data",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	}
 };
 
@@ -781,7 +781,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		res->name  = "System RAM";
 		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
 		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..450987d 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -73,13 +73,13 @@ static struct resource mem_res[] = {
 		.name = "Kernel code",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	},
 	{
 		.name = "Kernel data",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	}
 };
 
@@ -210,7 +210,7 @@ static void __init request_standard_resources(void)
 		res->name  = "System RAM";
 		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
 		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
 
diff --git a/arch/avr32/kernel/setup.c b/arch/avr32/kernel/setup.c
index 209ae5a..e692889 100644
--- a/arch/avr32/kernel/setup.c
+++ b/arch/avr32/kernel/setup.c
@@ -49,13 +49,13 @@ static struct resource __initdata kernel_data = {
 	.name	= "Kernel data",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_MEM,
+	.flags	= IORESOURCE_SYSTEM_RAM,
 };
 static struct resource __initdata kernel_code = {
 	.name	= "Kernel code",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_MEM,
+	.flags	= IORESOURCE_SYSTEM_RAM,
 	.sibling = &kernel_data,
 };
 
@@ -134,7 +134,7 @@ add_physical_memory(resource_size_t start, resource_size_t end)
 	new->start = start;
 	new->end = end;
 	new->name = "System RAM";
-	new->flags = IORESOURCE_MEM;
+	new->flags = IORESOURCE_SYSTEM_RAM;
 
 	*pprev = new;
 }
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index caae3f4..b6939b0 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -1207,10 +1207,12 @@ efi_initialize_iomem_resources(struct resource *code_resource,
 				if (md->attribute & EFI_MEMORY_WP) {
 					name = "System ROM";
 					flags |= IORESOURCE_READONLY;
-				} else if (md->attribute == EFI_MEMORY_UC)
+				} else if (md->attribute == EFI_MEMORY_UC) {
 					name = "Uncached RAM";
-				else
+				} else {
 					name = "System RAM";
+					flags |= IORESOURCE_SYSRAM;
+				}
 				break;
 
 			case EFI_ACPI_MEMORY_NVS:
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 4f118b0..2029a38 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -80,17 +80,17 @@ unsigned long vga_console_membase;
 
 static struct resource data_resource = {
 	.name	= "Kernel data",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 unsigned long ia64_max_cacheline_size;
diff --git a/arch/m32r/kernel/setup.c b/arch/m32r/kernel/setup.c
index 0392112..5f62ff0 100644
--- a/arch/m32r/kernel/setup.c
+++ b/arch/m32r/kernel/setup.c
@@ -70,14 +70,14 @@ static struct resource data_resource = {
 	.name   = "Kernel data",
 	.start  = 0,
 	.end    = 0,
-	.flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name   = "Kernel code",
 	.start  = 0,
 	.end    = 0,
-	.flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 unsigned long memory_start;
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 66aac55..c385af1 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -732,21 +732,23 @@ static void __init resource_init(void)
 			end = HIGHMEM_START - 1;
 
 		res = alloc_bootmem(sizeof(struct resource));
+
+		res->start = start;
+		res->end = end;
+		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+
 		switch (boot_mem_map.map[i].type) {
 		case BOOT_MEM_RAM:
 		case BOOT_MEM_INIT_RAM:
 		case BOOT_MEM_ROM_DATA:
 			res->name = "System RAM";
+			res->flags |= IORESOURCE_SYSRAM;
 			break;
 		case BOOT_MEM_RESERVED:
 		default:
 			res->name = "reserved";
 		}
 
-		res->start = start;
-		res->end = end;
-
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 		request_resource(&iomem_resource, res);
 
 		/*
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 1b366c4..3c07d6b 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -55,12 +55,12 @@ signed char pfnnid_map[PFNNID_MAP_MAX] __read_mostly;
 
 static struct resource data_resource = {
 	.name	= "Kernel data",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource pdcdata_resource = {
@@ -201,7 +201,7 @@ static void __init setup_bootmem(void)
 		res->name = "System RAM";
 		res->start = pmem_ranges[i].start_pfn << PAGE_SHIFT;
 		res->end = res->start + (pmem_ranges[i].pages << PAGE_SHIFT)-1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 		request_resource(&iomem_resource, res);
 	}
 
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 22d94c3..e78a2b7 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -541,7 +541,7 @@ static int __init add_system_ram_resources(void)
 			res->name = "System RAM";
 			res->start = base;
 			res->end = base + size - 1;
-			res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+			res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 			WARN_ON(request_resource(&iomem_resource, res) < 0);
 		}
 	}
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index c837bca..b65a883 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,17 +376,17 @@ static void __init setup_lowcore(void)
 
 static struct resource code_resource = {
 	.name  = "Kernel code",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource data_resource = {
 	.name = "Kernel data",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource bss_resource = {
 	.name = "Kernel bss",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource __initdata *standard_resources[] = {
@@ -410,7 +410,7 @@ static void __init setup_resources(void)
 
 	for_each_memblock(memory, reg) {
 		res = alloc_bootmem_low(sizeof(*res));
-		res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
 		res->start = reg->base;
diff --git a/arch/score/kernel/setup.c b/arch/score/kernel/setup.c
index b48459a..f3a0649 100644
--- a/arch/score/kernel/setup.c
+++ b/arch/score/kernel/setup.c
@@ -101,7 +101,7 @@ static void __init resource_init(void)
 	res->name = "System RAM";
 	res->start = MEMORY_START;
 	res->end = MEMORY_START + MEMORY_SIZE - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	request_resource(&iomem_resource, res);
 
 	request_resource(res, &code_resource);
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index de19cfa..3f1c18b 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -78,17 +78,17 @@ static char __initdata command_line[COMMAND_LINE_SIZE] = { 0, };
 
 static struct resource code_resource = {
 	.name = "Kernel code",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource data_resource = {
 	.name = "Kernel data",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 unsigned long memory_start;
@@ -202,7 +202,7 @@ void __init __add_active_range(unsigned int nid, unsigned long start_pfn,
 	res->name = "System RAM";
 	res->start = start;
 	res->end = end - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 	if (request_resource(&iomem_resource, res)) {
 		pr_err("unable to request memory_resource 0x%lx 0x%lx\n",
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 3025bd5..a02d43d 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2862,17 +2862,17 @@ void hugetlb_setup(struct pt_regs *regs)
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource data_resource = {
 	.name	= "Kernel data",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static inline resource_size_t compute_kern_paddr(void *addr)
@@ -2908,7 +2908,7 @@ static int __init report_memory(void)
 		res->name = "System RAM";
 		res->start = pavail[i].phys_addr;
 		res->end = pavail[i].phys_addr + pavail[i].reg_size - 1;
-		res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		if (insert_resource(&iomem_resource, res) < 0) {
 			pr_warn("Resource insertion failed.\n");
diff --git a/arch/tile/kernel/setup.c b/arch/tile/kernel/setup.c
index 6b755d1..6606fe2 100644
--- a/arch/tile/kernel/setup.c
+++ b/arch/tile/kernel/setup.c
@@ -1632,14 +1632,14 @@ static struct resource data_resource = {
 	.name	= "Kernel data",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 /*
@@ -1673,10 +1673,15 @@ insert_ram_resource(u64 start_pfn, u64 end_pfn, bool reserved)
 		kzalloc(sizeof(struct resource), GFP_ATOMIC);
 	if (!res)
 		return NULL;
-	res->name = reserved ? "Reserved" : "System RAM";
 	res->start = start_pfn << PAGE_SHIFT;
 	res->end = (end_pfn << PAGE_SHIFT) - 1;
 	res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+	if (reserved) {
+		res->name = "Reserved";
+	} else {
+		res->name = "System RAM";
+		res->flags |= IORESOURCE_SYSRAM;
+	}
 	if (insert_resource(&iomem_resource, res)) {
 		kfree(res);
 		return NULL;
diff --git a/arch/unicore32/kernel/setup.c b/arch/unicore32/kernel/setup.c
index 3fa317f..c2bffa5 100644
--- a/arch/unicore32/kernel/setup.c
+++ b/arch/unicore32/kernel/setup.c
@@ -72,13 +72,13 @@ static struct resource mem_res[] = {
 		.name = "Kernel code",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	},
 	{
 		.name = "Kernel data",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	}
 };
 
@@ -211,7 +211,7 @@ request_standard_resources(struct meminfo *mi)
 		res->name  = "System RAM";
 		res->start = mi->bank[i].start;
 		res->end   = mi->bank[i].start + mi->bank[i].size - 1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291696 — [PATCH 09/11] resource: Change walk_system_ram to use System RAM type

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-15 00:40 +0100
Subject	[PATCH 09/11] resource: Change walk_system_ram to use System RAM type
Message-ID	<qFKSL-4sB-53@gated-at.bofh.it>
In reply to	#1291685

Change walk_system_ram_res() and walk_system_ram_range() to
call find_next_iomem_res() by setting IORESOURCE_SYSTEM_RAM
to @res->flags and NULL to @name.  With this change, they
walk through the resource table without doing strcmp().

No functional change is made to the interfaces.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 kernel/resource.c |   26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 56bed6d..c6f13d0 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -334,8 +334,8 @@ EXPORT_SYMBOL(release_resource);
 
 /*
  * Finds the lowest iomem reosurce exists with-in [res->start.res->end)
- * the caller must specify res->start, res->end, res->flags and "name".
- * If found, returns 0, res is overwritten, if not found, returns -1.
+ * the caller must specify res->start, res->end, res->flags and optionally
+ * "name".  If found, returns 0, res is overwritten, if not found, returns -1.
  * This walks through whole tree and not just first level children
  * until and unless first_level_children_only is true.
  */
@@ -415,9 +415,9 @@ int walk_iomem_res(char *name, unsigned long flags, u64 start, u64 end,
 }
 
 /*
- * This function calls callback against all memory range of "System RAM"
- * which are marked as IORESOURCE_MEM and IORESOUCE_BUSY.
- * Now, this function is only for "System RAM". This function deals with
+ * This function calls callback against all memory range of System RAM
+ * which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
+ * Now, this function is only for System RAM. This function deals with
  * full ranges and not pfn. If resources are not pfn aligned, dealing
  * with pfn can truncate ranges.
  */
@@ -430,10 +430,10 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 
 	res.start = start;
 	res.end = end;
-	res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	orig_end = res.end;
 	while ((res.start < res.end) &&
-		(!find_next_iomem_res(&res, "System RAM", true))) {
+		(!find_next_iomem_res(&res, NULL, true))) {
 		ret = (*func)(res.start, res.end, arg);
 		if (ret)
 			break;
@@ -446,9 +446,9 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
 
 /*
- * This function calls callback against all memory range of "System RAM"
- * which are marked as IORESOURCE_MEM and IORESOUCE_BUSY.
- * Now, this function is only for "System RAM".
+ * This function calls callback against all memory range of System RAM
+ * which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
+ * Now, this function is only for System RAM.
  */
 int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
 		void *arg, int (*func)(unsigned long, unsigned long, void *))
@@ -460,10 +460,10 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
 
 	res.start = (u64) start_pfn << PAGE_SHIFT;
 	res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
-	res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	orig_end = res.end;
 	while ((res.start < res.end) &&
-		(find_next_iomem_res(&res, "System RAM", true) >= 0)) {
+		(find_next_iomem_res(&res, NULL, true) >= 0)) {
 		pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
 		end_pfn = (res.end + 1) >> PAGE_SHIFT;
 		if (end_pfn > pfn)
@@ -484,7 +484,7 @@ static int __is_ram(unsigned long pfn, unsigned long nr_pages, void *arg)
 }
 /*
  * This generic page_is_ram() returns true if specified address is
- * registered as "System RAM" in iomem_resource list.
+ * registered as System RAM in iomem_resource list.
  */
 int __weak page_is_ram(unsigned long pfn)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291700 — [PATCH 05/11] xen: Set IORESOURCE_SYSTEM_RAM to System RAM

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-15 00:50 +0100
Subject	[PATCH 05/11] xen: Set IORESOURCE_SYSTEM_RAM to System RAM
Message-ID	<qFL2q-4xi-5@gated-at.bofh.it>
In reply to	#1291685

Set IORESOURCE_SYSTEM_RAM to the flags of memory hotplug resource
ranges with "System RAM".

Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 drivers/xen/balloon.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 12eab50..dc4305b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -257,7 +257,7 @@ static struct resource *additional_memory_resource(phys_addr_t size)
 		return NULL;
 
 	res->name = "System RAM";
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 	ret = allocate_resource(&iomem_resource, res,
 				size, 0, -1,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291702 — [PATCH 03/11] x86/e820: Set IORESOURCE_SYSTEM_RAM to System RAM

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-15 00:50 +0100
Subject	[PATCH 03/11] x86/e820: Set IORESOURCE_SYSTEM_RAM to System RAM
Message-ID	<qFL2q-4xi-11@gated-at.bofh.it>
In reply to	#1291685

Change e820_reserve_resources() to set IORESOURCE_SYSTEM_RAM for
E820_RESERVED_KERN and E820_RAM, which are set to "System RAM".

Also set IORESOURCE_SYSTEM_RAM to "Kernel data", "Kernel code",
and "Kernel bss", which are children nodes of System RAM.

Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 arch/x86/kernel/e820.c  |   18 +++++++++++++++++-
 arch/x86/kernel/setup.c |    6 +++---
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 569c1e4..4c8bcbc 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -925,6 +925,22 @@ static const char *e820_type_to_string(int e820_type)
 	}
 }
 
+static int e820_type_to_iomem_type(int e820_type)
+{
+	switch (e820_type) {
+	case E820_RESERVED_KERN:
+	case E820_RAM:
+		return IORESOURCE_SYSTEM_RAM;
+	case E820_ACPI:
+	case E820_NVS:
+	case E820_UNUSABLE:
+	case E820_PRAM:
+	case E820_PMEM:
+	default:
+		return IORESOURCE_MEM;
+	}
+}
+
 static bool do_mark_busy(u32 type, struct resource *res)
 {
 	/* this is the legacy bios/dos rom-shadow + mmio region */
@@ -967,7 +983,7 @@ void __init e820_reserve_resources(void)
 		res->start = e820.map[i].addr;
 		res->end = end;
 
-		res->flags = IORESOURCE_MEM;
+		res->flags = e820_type_to_iomem_type(e820.map[i].type);
 
 		/*
 		 * don't register the region that could be conflicted with
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d2bbe34..a492c30 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -152,21 +152,21 @@ static struct resource data_resource = {
 	.name	= "Kernel data",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292929

From	Borislav Petkov <bp@alien8.de>
Date	2015-12-16 13:30 +0100
Message-ID	<qGjns-1I6-21@gated-at.bofh.it>
In reply to	#1291685

On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote:
> I/O resource type, IORESOURCE_MEM, is used for all types of
> memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
> Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
> reserved, and so on.  This requires walk_system_ram_range(),
> walk_system_ram_res(), and region_intersects() to use strcmp()
> against string "System RAM" to search System RAM ranges in the
> iomem table, which is inefficient.  __ioremap_caller() and
> reserve_memtype() on x86, for instance, call walk_system_ram_range()
> for every request to check if a given range is in System RAM ranges.
> 
> However, adding a new I/O resource type for System RAM is not
> a viable option [1].

I think you should explain here why it isn't a viable option instead of
quoting some flaky reference which might or might not be there in the
future.

> Instead, this patch adds a new modifier
> flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
> extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].
> 
> To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
> work continuously for System RAM, resource_ext_type() is added
> for extracting extended type bit(s).
> 
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Reference[1]: https://lkml.org/lkml/2015/12/3/540
> Reference[2]: https://lkml.org/lkml/2015/12/3/582

References should look something like this:

Link: http://lkml.kernel.org/r/<Message-ID>

> Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> ---
>  include/linux/ioport.h |   11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 24bea08..4b65d94 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -49,12 +49,19 @@ struct resource {
>  #define IORESOURCE_WINDOW	0x00200000	/* forwarded by bridge */
>  #define IORESOURCE_MUXED	0x00400000	/* Resource is software muxed */
>  
> +#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource extended types */

Should this be 0x07000000 so that we make all there bits belong to the
extended types? Are we going to need so many?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293044

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-16 16:50 +0100
Message-ID	<qGmuZ-3Cs-9@gated-at.bofh.it>
In reply to	#1292929

On Wed, 2015-12-16 at 13:26 +0100, Borislav Petkov wrote:
> On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote:
> > I/O resource type, IORESOURCE_MEM, is used for all types of
> > memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
> > Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
> > reserved, and so on.  This requires walk_system_ram_range(),
> > walk_system_ram_res(), and region_intersects() to use strcmp()
> > against string "System RAM" to search System RAM ranges in the
> > iomem table, which is inefficient.  __ioremap_caller() and
> > reserve_memtype() on x86, for instance, call walk_system_ram_range()
> > for every request to check if a given range is in System RAM ranges.
> > 
> > However, adding a new I/O resource type for System RAM is not
> > a viable option [1].
> 
> I think you should explain here why it isn't a viable option instead of
> quoting some flaky reference which might or might not be there in the
> future.

Agreed.  I will include summary of the descriptions here.

> > Instead, this patch adds a new modifier
> > flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
> > extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].
> > 
> > To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
> > work continuously for System RAM, resource_ext_type() is added
> > for extracting extended type bit(s).
> > 
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Reference[1]: https://lkml.org/lkml/2015/12/3/540
> > Reference[2]: https://lkml.org/lkml/2015/12/3/582
> 
> References should look something like this:
> 
> Link: http://lkml.kernel.org/r/<Message-ID>;

I see.  I will update per the format.

> > Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> > ---
> >  include/linux/ioport.h |   11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > index 24bea08..4b65d94 100644
> > --- a/include/linux/ioport.h
> > +++ b/include/linux/ioport.h
> > @@ -49,12 +49,19 @@ struct resource {
> >  #define IORESOURCE_WINDOW	0x00200000	/* forwarded by
> > bridge */
> >  #define IORESOURCE_MUXED	0x00400000	/* Resource is
> > software muxed */
> >  
> > +#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource
> > extended types */
> 
> Should this be 0x07000000 so that we make all there bits belong to the
> extended types? Are we going to need so many?

Besides "System RAM", which is commonly searched by multiple callers, we
only have a few other uncommon cases:
 - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
Storage".
 - kexec_file.c searches for "Crash kernel".
 - einj.c will search for "Persistent Memory".

This is because drivers typically know their ranges without searching
through the resource table.  So, it does not seem that we need to
preallocate the bits at this point.

Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293054

From	Borislav Petkov <bp@alien8.de>
Date	2015-12-16 16:50 +0100
Message-ID	<qGmv0-3Cs-29@gated-at.bofh.it>
In reply to	#1293044

On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote:
> Besides "System RAM", which is commonly searched by multiple callers, we
> only have a few other uncommon cases:
>  - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
> Storage".
>  - kexec_file.c searches for "Crash kernel".
>  - einj.c will search for "Persistent Memory".

Right, about those other types: your patchset improves the situation
but doesn't really get rid of the strcmp() and the strings. And using
strings to find resource types still looks yucky to me, even a week
later. :)

So how hard is it to do:

	region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM);
	region_intersects(base_addr, size, IORESOURCE_MEM, RES_TYPE_PERSISTENT);
	walk_iomem_res(RES_TYPE_GART, IORESOURCE_MEM, 0, -1, ced, get_gart_ranges_callback);
	...

and so on instead of using those silly strings?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293095

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-16 17:40 +0100
Message-ID	<qGnho-4bq-15@gated-at.bofh.it>
In reply to	#1293054

On Wed, 2015-12-16 at 16:49 +0100, Borislav Petkov wrote:
> On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote:
> > Besides "System RAM", which is commonly searched by multiple callers,
> > we
> > only have a few other uncommon cases:
> >  - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
> > Storage".
> >  - kexec_file.c searches for "Crash kernel".
> >  - einj.c will search for "Persistent Memory".
> 
> Right, about those other types: your patchset improves the situation
> but doesn't really get rid of the strcmp() and the strings. And using
> strings to find resource types still looks yucky to me, even a week
> later. :)
> 
> So how hard is it to do:
> 
> 	region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM);
> 	region_intersects(base_addr, size, IORESOURCE_MEM,
> RES_TYPE_PERSISTENT);
> 	walk_iomem_res(RES_TYPE_GART, IORESOURCE_MEM, 0, -1, ced,
> get_gart_ranges_callback);
> 	...
> 
> and so on instead of using those silly strings?

We do not have enough bits left to cover any potential future use-cases
with other strings if we are going to get rid of strcmp() completely. 
 Since the searches from crash and kexec are one-time thing, and einj is a
R&D tool, I think we can leave the strcmp() check for these special cases,
and keep the interface flexible with any strings.

Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293178

From	Borislav Petkov <bp@alien8.de>
Date	2015-12-16 18:50 +0100
Message-ID	<qGona-4Os-77@gated-at.bofh.it>
In reply to	#1293095

On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote:
> We do not have enough bits left to cover any potential future use-cases
> with other strings if we are going to get rid of strcmp() completely.

Look at the examples I gave. I'm talking about having an additional
identifier which can be a number and not a bit.

>  Since the searches from crash and kexec are one-time thing, and einj
> is a R&D tool, I think we can leave the strcmp() check for these
> special cases, and keep the interface flexible with any strings.

I don't think using strings is anywhere close to flexible. If at all, it
is an odd use case which shouldnt've been allowed in in the first place.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293204

From	Dan Williams <dan.j.williams@intel.com>
Date	2015-12-16 19:00 +0100
Message-ID	<qGowR-4RZ-53@gated-at.bofh.it>
In reply to	#1293178

On Wed, Dec 16, 2015 at 9:45 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote:
>> We do not have enough bits left to cover any potential future use-cases
>> with other strings if we are going to get rid of strcmp() completely.
>
> Look at the examples I gave. I'm talking about having an additional
> identifier which can be a number and not a bit.
>
>>  Since the searches from crash and kexec are one-time thing, and einj
>> is a R&D tool, I think we can leave the strcmp() check for these
>> special cases, and keep the interface flexible with any strings.
>
> I don't think using strings is anywhere close to flexible. If at all, it
> is an odd use case which shouldnt've been allowed in in the first place.
>

It's possible that as far as the resource table is concerned the
resource type might just be "reserved".  It may not be until after a
driver loads that we discover the memory range type.  The identifying
string is driver specific at that point.

All this to say that with strcmp we can search for any custom type .
Otherwise I think we're looking at updating the request_region()
interface to take a type parameter.  That makes strcmp capability more
attractive compared to updating a potentially large number of
request_region() call sites.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293264

From	Borislav Petkov <bp@alien8.de>
Date	2015-12-16 19:20 +0100
Message-ID	<qGoQa-5f3-35@gated-at.bofh.it>
In reply to	#1293204

On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote:
> It's possible that as far as the resource table is concerned the
> resource type might just be "reserved".  It may not be until after a
> driver loads that we discover the memory range type.  The identifying
> string is driver specific at that point.

So how many types are we talking about here? Because I don't find a whole lot:

$ git grep -E "(walk_iomem_res|find_next_iomem_res|region_intersects)" -- *.c | grep -Eo '\".*\"'
"GART"
"ACPI Tables"
"ACPI Non-volatile Storage"
"Crash kernel"
"System RAM"
"System RAM"
"System RAM"

An int type could contain 2^32 different types.

> All this to say that with strcmp we can search for any custom type .
> Otherwise I think we're looking at updating the request_region()
> interface to take a type parameter.  That makes strcmp capability more
> attractive compared to updating a potentially large number of
> request_region() call sites.

Right, but I don't think that @name param to request_region() was ever
meant to be mis-used as a matching attribute when iterating over the
resource types.

Now, imagine you have to do this pretty often. Which is faster: a
strcmp() or an int comparison...?

Even if this cannot be changed easily/in one go, maybe we should at
least think about starting doing it right so that the strcmp() "fun" is
phased out gradually...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293307

From	Dan Williams <dan.j.williams@intel.com>
Date	2015-12-16 20:00 +0100
Message-ID	<qGpsS-5tw-1@gated-at.bofh.it>
In reply to	#1293264

On Wed, Dec 16, 2015 at 10:17 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote:
[..]
> Now, imagine you have to do this pretty often. Which is faster: a
> strcmp() or an int comparison...?

Aside from "System RAM" checks I don't think any of these strcmp
usages are in fast paths.

> Even if this cannot be changed easily/in one go, maybe we should at
> least think about starting doing it right so that the strcmp() "fun" is
> phased out gradually...

Sure, but I really don't find use of strcmp() that onerous in slow paths.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293321

From	Borislav Petkov <bp@alien8.de>
Date	2015-12-16 20:20 +0100
Message-ID	<qGpMd-5PL-9@gated-at.bofh.it>
In reply to	#1293307

On Wed, Dec 16, 2015 at 10:57:52AM -0800, Dan Williams wrote:
> Aside from "System RAM" checks I don't think any of these strcmp
> usages are in fast paths.

Sure, 0.1% slowdown here, 0.2% slowdown there... this is how you get a
bloated kernel.

In addition to that, using strings to identify resources is ugly. "It
was there so we used it" is not an excuse.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293360

From	Toshi Kani <toshi.kani@hpe.com>
Date	2015-12-16 23:00 +0100
Message-ID	<qGsh3-7gQ-1@gated-at.bofh.it>
In reply to	#1293264

On Wed, 2015-12-16 at 19:17 +0100, Borislav Petkov wrote:
> On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote:
> > It's possible that as far as the resource table is concerned the
> > resource type might just be "reserved".  It may not be until after a
> > driver loads that we discover the memory range type.  The identifying
> > string is driver specific at that point.
> 
> So how many types are we talking about here? Because I don't find a whole
> lot:
> 
> $ git grep -E "(walk_iomem_res|find_next_iomem_res|region_intersects)" --
> *.c | grep -Eo '\".*\"'
> "GART"
> "ACPI Tables"
> "ACPI Non-volatile Storage"
> "Crash kernel"
> "System RAM"
> "System RAM"
> "System RAM"
> 
> An int type could contain 2^32 different types.

In this approach, as I understand, we add a new field to 'struct resource',
i.e. 'type' in this example.

 struct resource crashk_res = {
        .name  = "Crash kernel",
        .start = 0,
        .end   = 0,
        .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+ 	.type  = RES_TYPE_CRASH_KERNEL,
 };

And we change the callers, such as "kernel/kexec_file.c" to search with
this RES_TYPE.

 ret = walk_iomem_res(RES_TYPE_CRASH_KERNEL,
		IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY, ...);

We only change the resource entries that support the search interfaces to:
 - Assign RES_TYPE_XXX.
 - Initialize 'type' in its 'struct resource' with the type.

This avoids changing all drivers.  When we have a new search for "foo", we
will then need to:
 - Define RES_TYPE_FOO.
 - Add '.type = RES_TYPE_FOO' to the code where it initializes the "foo"
entry.

This scheme may have a problem, though.  For instance, when someone writes
a loadable module that searches for "foo", but the "foo" entry may be
initialized in a distro kernel/driver that cannot be modified.  Since this
search is only necessary to obtain a range initialized by other module,
this scenario is likely to happen.  We no longer have ability to search for
a new entry unless we modify the code that initializes the entry first.

> > All this to say that with strcmp we can search for any custom type .
> > Otherwise I think we're looking at updating the request_region()
> > interface to take a type parameter.  That makes strcmp capability more
> > attractive compared to updating a potentially large number of
> > request_region() call sites.
> 
> Right, but I don't think that @name param to request_region() was ever
> meant to be mis-used as a matching attribute when iterating over the
> resource types.

Even if we avoid strcmp() with @name in the kernel, user applications will
continue to use @name since that is the only type available in /proc/iomem.
 For instance, kexec has its own search function with a string name.

 https://github.com/Tasssadar/kexec-tools/blob/master/kexec/kexec-iomem.c

> Now, imagine you have to do this pretty often. Which is faster: a
> strcmp() or an int comparison...?
> 
> Even if this cannot be changed easily/in one go, maybe we should at
> least think about starting doing it right so that the strcmp() "fun" is
> phased out gradually...

When a new commonly-used search name comes up, we can define it as a new
extended I/O resource type similar to IORESOURCE_SYSTEM_RAM.  For the
current remaining cases, i.e. crash, kexec, and einj, they have no impact
to performance.  Leaving these special cases aside will keep the ability to
search for any entry without changing the kernel, and save some memory
space from adding the new 'type'.

Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

[PATCH 01/11] resource: Add System RAM resource type

Contents

#1291685 — [PATCH 01/11] resource: Add System RAM resource type

#1291686 — [PATCH 08/11] memremap: Change region_intersects() to use System RAM type

#1291687 — [PATCH 06/11] kexec: Set IORESOURCE_SYSTEM_RAM to System RAM

#1291688 — [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type

#1291721 — Re: [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type

#1291692 — [PATCH 07/11] memory-hotplug: Set IORESOURCE_SYSTEM_RAM to System RAM

#1291695 — [PATCH 04/11] arch: Set IORESOURCE_SYSTEM_RAM to System RAM

#1291696 — [PATCH 09/11] resource: Change walk_system_ram to use System RAM type

#1291700 — [PATCH 05/11] xen: Set IORESOURCE_SYSTEM_RAM to System RAM

#1291702 — [PATCH 03/11] x86/e820: Set IORESOURCE_SYSTEM_RAM to System RAM

#1292929

#1293044

#1293054

#1293095

#1293178

#1293204

#1293264

#1293307

#1293321

#1293360