LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures
@ 2015-01-08  2:32 Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 01/19] ACPI: Remove redundant check in function acpi_dev_resource_address_space() Jiang Liu
                   ` (19 more replies)
  0 siblings, 20 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

During enabling ACPI based IOAPIC hotplug, Thomas noticed some issues
in ACPI resource parsing interfaces. So this is an effort to improve them.

Patch 1-12 improve ACPI resource parsing interfaces and also fixes some
bugs.

Patch 13-19 try to share the common data structure resource_list_entry
between PCI and ACPI. It may also be shared with PNP too.

The patchset is based on v3.19-rc3 and you may get it from:
https://github.com/jiangliu/linux.git acpires_v1

Jiang Liu (11):
  ACPI: Fix a bug in parsing ACPI Memroy24 resource
  ACPI: Normalize return value of resource parser functions
  ACPI: Set flag IORESOURCE_UNSET for unassigned resources
  ACPI: Enforce stricter checks for address space descriptors
  ACPI: Return translation offset when parsing ACPI address space
    resources
  ACPI: Translate resource into master side address for bridge window
    resources
  ACPI: Add field offset to struct resource_list_entry
  ACPI: Introduce helper function acpi_dev_filter_resource_type()
  resources: Move struct resource_list_entry from ACPI into resource
    core
  PCI: Use common resource list management code instead of private
    implementation
  x86/PCI/ACPI: Use common ACPI resource interfaces to simplify
    implementation

Thomas Gleixner (8):
  ACPI: Remove redundant check in function
    acpi_dev_resource_address_space()
  ACPI: Implement proper length checks for mem resources
  ACPI: Use the length check for io resources as well
  ACPI: Let the parser return false for disabled resources
  ACPI: Provide union for address_space64 and ext_address_space64
  ACPI: Unify the parsing of address_space and ext_address_space
  ACPI: Move the window flag logic to the combined parser
  ACPI: Add prefetch decoding to the address space parser

 arch/arm/kernel/bios32.c            |    5 +-
 arch/x86/pci/acpi.c                 |  297 ++++++++++---------------------
 arch/x86/pci/bus_numa.c             |    4 +-
 drivers/acpi/acpi_lpss.c            |    6 +-
 drivers/acpi/acpi_platform.c        |    2 +-
 drivers/acpi/resource.c             |  333 ++++++++++++++++++++++-------------
 drivers/dma/acpi-dma.c              |    8 +-
 drivers/pci/bus.c                   |   18 +-
 drivers/pci/host-bridge.c           |    8 +-
 drivers/pci/host/pci-host-generic.c |    4 +-
 drivers/pci/host/pci-xgene.c        |    4 +-
 drivers/pci/host/pcie-xilinx.c      |    4 +-
 drivers/pci/probe.c                 |   10 +-
 drivers/pnp/pnpacpi/rsparser.c      |    4 +-
 include/acpi/acrestyp.h             |   49 ++++--
 include/linux/acpi.h                |   12 +-
 include/linux/ioport.h              |   25 +++
 include/linux/pci.h                 |    8 +-
 kernel/resource.c                   |   48 +++++
 19 files changed, 452 insertions(+), 397 deletions(-)

-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 01/19] ACPI: Remove redundant check in function acpi_dev_resource_address_space()
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 02/19] ACPI: Implement proper length checks for mem resources Jiang Liu
                   ` (18 subsequent siblings)
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Tony Luck, x86, linux-kernel, linux-pci, linux-acpi, Jiang Liu

From: Thomas Gleixner <tglx@linutronix.de>

The ACPI type is checked in acpi_resource_to_address64() anyway.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |    9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 782a0d15c25f..d4c3d7640715 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -189,15 +189,6 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
 	u64 len;
 	u8 io_decode;
 
-	switch (ares->type) {
-	case ACPI_RESOURCE_TYPE_ADDRESS16:
-	case ACPI_RESOURCE_TYPE_ADDRESS32:
-	case ACPI_RESOURCE_TYPE_ADDRESS64:
-		break;
-	default:
-		return false;
-	}
-
 	status = acpi_resource_to_address64(ares, &addr);
 	if (ACPI_FAILURE(status))
 		return false;
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 02/19] ACPI: Implement proper length checks for mem resources
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 01/19] ACPI: Remove redundant check in function acpi_dev_resource_address_space() Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 03/19] ACPI: Use the length check for io resources as well Jiang Liu
                   ` (17 subsequent siblings)
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Tony Luck, x86, linux-kernel, linux-pci, linux-acpi, Jiang Liu

From: Thomas Gleixner <tglx@linutronix.de>

Check whether the resulting length is the same as the given
length. Check for start <= end as well.

We need to hand in the resource for this, so we can apply the flags
directly.

[Jiang] Remove enforcement that resource starting address must be
non-zero.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |   61 ++++++++++++++++++++++++++---------------------
 1 file changed, 34 insertions(+), 27 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index d4c3d7640715..f20e23d4fb16 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -34,21 +34,37 @@
 #define valid_IRQ(i) (true)
 #endif
 
-static unsigned long acpi_dev_memresource_flags(u64 len, u8 write_protect,
-						bool window)
+static bool acpi_dev_resource_len_valid(u64 start, u64 end, u64 len, bool io)
 {
-	unsigned long flags = IORESOURCE_MEM;
+	u64 reslen = end - start + 1;
 
-	if (len == 0)
-		flags |= IORESOURCE_DISABLED;
+	/*
+	 * CHECKME: len might be required to check versus a minimum
+	 * length as well. 1 for io is fine, but for memory it does
+	 * not make any sense at all.
+	 */
+	if (len && reslen && reslen == len && start <= end)
+		return true;
+
+	pr_info("ACPI: invalid or unassigned resource %s [%016llx - %016llx] length [%016llx]\n",
+		io ? "io" : "mem", start, end, len);
+
+	return false;
+}
+
+static void acpi_dev_memresource_flags(struct resource *res, u64 len,
+				       u8 write_protect, bool window)
+{
+	res->flags = IORESOURCE_MEM;
+
+	if (!acpi_dev_resource_len_valid(res->start, res->end, len, false))
+		res->flags |= IORESOURCE_DISABLED;
 
 	if (write_protect == ACPI_READ_WRITE_MEMORY)
-		flags |= IORESOURCE_MEM_WRITEABLE;
+		res->flags |= IORESOURCE_MEM_WRITEABLE;
 
 	if (window)
-		flags |= IORESOURCE_WINDOW;
-
-	return flags;
+		res->flags |= IORESOURCE_WINDOW;
 }
 
 static void acpi_dev_get_memresource(struct resource *res, u64 start, u64 len,
@@ -56,7 +72,7 @@ static void acpi_dev_get_memresource(struct resource *res, u64 start, u64 len,
 {
 	res->start = start;
 	res->end = start + len - 1;
-	res->flags = acpi_dev_memresource_flags(len, write_protect, false);
+	acpi_dev_memresource_flags(res, len, write_protect, false);
 }
 
 /**
@@ -77,24 +93,18 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
 	switch (ares->type) {
 	case ACPI_RESOURCE_TYPE_MEMORY24:
 		memory24 = &ares->data.memory24;
-		if (!memory24->minimum && !memory24->address_length)
-			return false;
 		acpi_dev_get_memresource(res, memory24->minimum,
 					 memory24->address_length,
 					 memory24->write_protect);
 		break;
 	case ACPI_RESOURCE_TYPE_MEMORY32:
 		memory32 = &ares->data.memory32;
-		if (!memory32->minimum && !memory32->address_length)
-			return false;
 		acpi_dev_get_memresource(res, memory32->minimum,
 					 memory32->address_length,
 					 memory32->write_protect);
 		break;
 	case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
 		fixed_memory32 = &ares->data.fixed_memory32;
-		if (!fixed_memory32->address && !fixed_memory32->address_length)
-			return false;
 		acpi_dev_get_memresource(res, fixed_memory32->address,
 					 fixed_memory32->address_length,
 					 fixed_memory32->write_protect);
@@ -102,7 +112,8 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
 	default:
 		return false;
 	}
-	return true;
+
+	return !(res->flags & IORESOURCE_DISABLED);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_memory);
 
@@ -186,7 +197,6 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
 	acpi_status status;
 	struct acpi_resource_address64 addr;
 	bool window;
-	u64 len;
 	u8 io_decode;
 
 	status = acpi_resource_to_address64(ares, &addr);
@@ -199,10 +209,9 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
 
 	switch(addr.resource_type) {
 	case ACPI_MEMORY_RANGE:
-		len = addr.maximum - addr.minimum + 1;
-		res->flags = acpi_dev_memresource_flags(len,
-						addr.info.mem.write_protect,
-						window);
+		acpi_dev_memresource_flags(res, addr.address_length,
+					   addr.info.mem.write_protect,
+					   window);
 		break;
 	case ACPI_IO_RANGE:
 		io_decode = addr.granularity == 0xfff ?
@@ -236,7 +245,6 @@ bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
 {
 	struct acpi_resource_extended_address64 *ext_addr;
 	bool window;
-	u64 len;
 	u8 io_decode;
 
 	if (ares->type != ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64)
@@ -250,10 +258,9 @@ bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
 
 	switch(ext_addr->resource_type) {
 	case ACPI_MEMORY_RANGE:
-		len = ext_addr->maximum - ext_addr->minimum + 1;
-		res->flags = acpi_dev_memresource_flags(len,
-					ext_addr->info.mem.write_protect,
-					window);
+		acpi_dev_memresource_flags(res, ext_addr->address_length,
+					   ext_addr->info.mem.write_protect,
+					   window);
 		break;
 	case ACPI_IO_RANGE:
 		io_decode = ext_addr->granularity == 0xfff ?
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 03/19] ACPI: Use the length check for io resources as well
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 01/19] ACPI: Remove redundant check in function acpi_dev_resource_address_space() Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 02/19] ACPI: Implement proper length checks for mem resources Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 04/19] ACPI: Let the parser return false for disabled resources Jiang Liu
                   ` (16 subsequent siblings)
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Tony Luck, x86, linux-kernel, linux-pci, linux-acpi, Jiang Liu

From: Thomas Gleixner <tglx@linutronix.de>

Also apply length check to IO resources.

[Jiang] Remove enforcement that resource starting address must be
non-zero.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |   44 +++++++++++++++++++-------------------------
 1 file changed, 19 insertions(+), 25 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index f20e23d4fb16..c0578c05e2c2 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -117,31 +117,30 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_memory);
 
-static unsigned int acpi_dev_ioresource_flags(u64 start, u64 end, u8 io_decode,
-					      bool window)
+static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
+				      u8 io_decode, bool window)
 {
-	int flags = IORESOURCE_IO;
+	res->flags = IORESOURCE_IO;
 
-	if (io_decode == ACPI_DECODE_16)
-		flags |= IORESOURCE_IO_16BIT_ADDR;
+	if (!acpi_dev_resource_len_valid(res->start, res->end, len, true))
+		res->flags |= IORESOURCE_DISABLED;
 
-	if (start > end || end >= 0x10003)
-		flags |= IORESOURCE_DISABLED;
+	if (res->end >= 0x10003)
+		res->flags |= IORESOURCE_DISABLED;
 
-	if (window)
-		flags |= IORESOURCE_WINDOW;
+	if (io_decode == ACPI_DECODE_16)
+		res->flags |= IORESOURCE_IO_16BIT_ADDR;
 
-	return flags;
+	if (window)
+		res->flags |= IORESOURCE_WINDOW;
 }
 
 static void acpi_dev_get_ioresource(struct resource *res, u64 start, u64 len,
 				    u8 io_decode)
 {
-	u64 end = start + len - 1;
-
 	res->start = start;
-	res->end = end;
-	res->flags = acpi_dev_ioresource_flags(start, end, io_decode, false);
+	res->end = start + len - 1;
+	acpi_dev_ioresource_flags(res, len, io_decode, false);
 }
 
 /**
@@ -161,16 +160,12 @@ bool acpi_dev_resource_io(struct acpi_resource *ares, struct resource *res)
 	switch (ares->type) {
 	case ACPI_RESOURCE_TYPE_IO:
 		io = &ares->data.io;
-		if (!io->minimum && !io->address_length)
-			return false;
 		acpi_dev_get_ioresource(res, io->minimum,
 					io->address_length,
 					io->io_decode);
 		break;
 	case ACPI_RESOURCE_TYPE_FIXED_IO:
 		fixed_io = &ares->data.fixed_io;
-		if (!fixed_io->address && !fixed_io->address_length)
-			return false;
 		acpi_dev_get_ioresource(res, fixed_io->address,
 					fixed_io->address_length,
 					ACPI_DECODE_10);
@@ -178,7 +173,8 @@ bool acpi_dev_resource_io(struct acpi_resource *ares, struct resource *res)
 	default:
 		return false;
 	}
-	return true;
+
+	return !(res->flags & IORESOURCE_DISABLED);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_io);
 
@@ -216,9 +212,8 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
 	case ACPI_IO_RANGE:
 		io_decode = addr.granularity == 0xfff ?
 				ACPI_DECODE_10 : ACPI_DECODE_16;
-		res->flags = acpi_dev_ioresource_flags(addr.minimum,
-						       addr.maximum,
-						       io_decode, window);
+		acpi_dev_ioresource_flags(res, addr.address_length,
+					  io_decode, window);
 		break;
 	case ACPI_BUS_NUMBER_RANGE:
 		res->flags = IORESOURCE_BUS;
@@ -265,9 +260,8 @@ bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
 	case ACPI_IO_RANGE:
 		io_decode = ext_addr->granularity == 0xfff ?
 				ACPI_DECODE_10 : ACPI_DECODE_16;
-		res->flags = acpi_dev_ioresource_flags(ext_addr->minimum,
-						       ext_addr->maximum,
-						       io_decode, window);
+		acpi_dev_ioresource_flags(res, ext_addr->address_length,
+					  io_decode, window);
 		break;
 	case ACPI_BUS_NUMBER_RANGE:
 		res->flags = IORESOURCE_BUS;
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 04/19] ACPI: Let the parser return false for disabled resources
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (2 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 03/19] ACPI: Use the length check for io resources as well Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64 Jiang Liu
                   ` (15 subsequent siblings)
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Tony Luck, x86, linux-kernel, linux-pci, linux-acpi, Jiang Liu

From: Thomas Gleixner <tglx@linutronix.de>

If the parser disables a resource during parsing, let it return false,
so the calling code does not need to implement further checks.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index c0578c05e2c2..deb70a839f80 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -219,10 +219,10 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
 		res->flags = IORESOURCE_BUS;
 		break;
 	default:
-		res->flags = 0;
+		return false;
 	}
 
-	return true;
+	return !(res->flags & IORESOURCE_DISABLED);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_address_space);
 
@@ -267,10 +267,10 @@ bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
 		res->flags = IORESOURCE_BUS;
 		break;
 	default:
-		res->flags = 0;
+		return false;
 	}
 
-	return true;
+	return !(res->flags & IORESOURCE_DISABLED);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_ext_address_space);
 
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (3 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 04/19] ACPI: Let the parser return false for disabled resources Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-21  0:32   ` Rafael J. Wysocki
  2015-01-22  2:32   ` Zheng, Lv
  2015-01-08  2:32 ` [RFC Patch 06/19] ACPI: Unify the parsing of address_space and ext_address_space Jiang Liu
                   ` (14 subsequent siblings)
  19 siblings, 2 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Robert Moore, Lv Zheng, Rafael J. Wysocki,
	Len Brown
  Cc: Tony Luck, x86, linux-kernel, linux-pci, linux-acpi, Jiang Liu, devel

From: Thomas Gleixner <tglx@linutronix.de>

address_space64 and ext_address_space64 share substracts just at
different offsets. To unify the parsing functions implement the two
structs as unions of their substructs, so we can extract the shared
data.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 include/acpi/acrestyp.h |   49 ++++++++++++++++++++++++++++++++++-------------
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
index eb760ca0b2e0..307d5b2605c8 100644
--- a/include/acpi/acrestyp.h
+++ b/include/acpi/acrestyp.h
@@ -326,23 +326,46 @@ struct acpi_resource_address32 {
 	struct acpi_resource_source resource_source;
 };
 
-struct acpi_resource_address64 {
-	ACPI_RESOURCE_ADDRESS_COMMON u64 granularity;
-	u64 minimum;
-	u64 maximum;
-	u64 translation_offset;
+#define ACPI_RESOURCE_ADDRESS64_COMMON \
+	u64 granularity;	       \
+	u64 minimum;		       \
+	u64 maximum;		       \
+	u64 translation_offset;	       \
 	u64 address_length;
-	struct acpi_resource_source resource_source;
+
+struct acpi_resource_address64_common {
+ACPI_RESOURCE_ADDRESS64_COMMON};
+
+struct acpi_resource_address64 {
+	union {
+		struct {
+			ACPI_RESOURCE_ADDRESS_COMMON
+			ACPI_RESOURCE_ADDRESS64_COMMON
+			struct acpi_resource_source resource_source;
+		};
+		struct {
+			struct acpi_resource_address base;
+			struct acpi_resource_address64_common addr;
+			struct acpi_resource_source resource_source;
+		} common;
+	};
 };
 
 struct acpi_resource_extended_address64 {
-	ACPI_RESOURCE_ADDRESS_COMMON u8 revision_ID;
-	u64 granularity;
-	u64 minimum;
-	u64 maximum;
-	u64 translation_offset;
-	u64 address_length;
-	u64 type_specific;
+	union {
+		struct {
+			ACPI_RESOURCE_ADDRESS_COMMON
+			u8 revision_ID;
+			ACPI_RESOURCE_ADDRESS64_COMMON
+			u64 type_specific;
+		};
+		struct {
+			struct acpi_resource_address base;
+			u8 revision_ID;
+			struct acpi_resource_address64_common addr;
+			u64 type_specific;
+		} common;
+	};
 };
 
 struct acpi_resource_extended_irq {
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 06/19] ACPI: Unify the parsing of address_space and ext_address_space
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (4 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64 Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 07/19] ACPI: Move the window flag logic to the combined parser Jiang Liu
                   ` (13 subsequent siblings)
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Tony Luck, x86, linux-kernel, linux-pci, linux-acpi, Jiang Liu

From: Thomas Gleixner <tglx@linutronix.de>

With the unions in place which let us identify the substructs we can
use a single parser for address_space and ext_address_space.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |   88 ++++++++++++++++++-----------------------------
 1 file changed, 33 insertions(+), 55 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index deb70a839f80..d1ceba02afde 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -178,6 +178,35 @@ bool acpi_dev_resource_io(struct acpi_resource *ares, struct resource *res)
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_io);
 
+static bool acpi_decode_space(struct resource *res,
+			      struct acpi_resource_address *base,
+			      struct acpi_resource_address64_common *addr)
+{
+	u8 iodec = addr->granularity == 0xfff ? ACPI_DECODE_10 : ACPI_DECODE_16;
+	bool window = base->producer_consumer == ACPI_PRODUCER;
+	bool wp = base->info.mem.write_protect;
+	u64 len = addr->address_length;
+
+	res->start = addr->minimum;
+	res->end = addr->maximum;
+
+	switch(base->resource_type) {
+	case ACPI_MEMORY_RANGE:
+		acpi_dev_memresource_flags(res, len, wp, window);
+		break;
+	case ACPI_IO_RANGE:
+		acpi_dev_ioresource_flags(res, len, iodec, window);
+		break;
+	case ACPI_BUS_NUMBER_RANGE:
+		res->flags = IORESOURCE_BUS;
+		break;
+	default:
+		return false;
+	}
+
+	return !(res->flags & IORESOURCE_DISABLED);
+}
+
 /**
  * acpi_dev_resource_address_space - Extract ACPI address space information.
  * @ares: Input ACPI resource object.
@@ -190,39 +219,12 @@ EXPORT_SYMBOL_GPL(acpi_dev_resource_io);
 bool acpi_dev_resource_address_space(struct acpi_resource *ares,
 				     struct resource *res)
 {
-	acpi_status status;
 	struct acpi_resource_address64 addr;
-	bool window;
-	u8 io_decode;
-
-	status = acpi_resource_to_address64(ares, &addr);
-	if (ACPI_FAILURE(status))
-		return false;
 
-	res->start = addr.minimum;
-	res->end = addr.maximum;
-	window = addr.producer_consumer == ACPI_PRODUCER;
-
-	switch(addr.resource_type) {
-	case ACPI_MEMORY_RANGE:
-		acpi_dev_memresource_flags(res, addr.address_length,
-					   addr.info.mem.write_protect,
-					   window);
-		break;
-	case ACPI_IO_RANGE:
-		io_decode = addr.granularity == 0xfff ?
-				ACPI_DECODE_10 : ACPI_DECODE_16;
-		acpi_dev_ioresource_flags(res, addr.address_length,
-					  io_decode, window);
-		break;
-	case ACPI_BUS_NUMBER_RANGE:
-		res->flags = IORESOURCE_BUS;
-		break;
-	default:
+	if (ACPI_FAILURE(acpi_resource_to_address64(ares, &addr)))
 		return false;
-	}
 
-	return !(res->flags & IORESOURCE_DISABLED);
+	return acpi_decode_space(res, &addr.common.base, &addr.common.addr);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_address_space);
 
@@ -239,38 +241,14 @@ bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
 					 struct resource *res)
 {
 	struct acpi_resource_extended_address64 *ext_addr;
-	bool window;
-	u8 io_decode;
 
 	if (ares->type != ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64)
 		return false;
 
 	ext_addr = &ares->data.ext_address64;
 
-	res->start = ext_addr->minimum;
-	res->end = ext_addr->maximum;
-	window = ext_addr->producer_consumer == ACPI_PRODUCER;
-
-	switch(ext_addr->resource_type) {
-	case ACPI_MEMORY_RANGE:
-		acpi_dev_memresource_flags(res, ext_addr->address_length,
-					   ext_addr->info.mem.write_protect,
-					   window);
-		break;
-	case ACPI_IO_RANGE:
-		io_decode = ext_addr->granularity == 0xfff ?
-				ACPI_DECODE_10 : ACPI_DECODE_16;
-		acpi_dev_ioresource_flags(res, ext_addr->address_length,
-					  io_decode, window);
-		break;
-	case ACPI_BUS_NUMBER_RANGE:
-		res->flags = IORESOURCE_BUS;
-		break;
-	default:
-		return false;
-	}
-
-	return !(res->flags & IORESOURCE_DISABLED);
+	return acpi_decode_space(res, &ext_addr->common.base,
+				 &ext_addr->common.addr);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_ext_address_space);
 
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 07/19] ACPI: Move the window flag logic to the combined parser
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (5 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 06/19] ACPI: Unify the parsing of address_space and ext_address_space Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 08/19] ACPI: Add prefetch decoding to the address space parser Jiang Liu
                   ` (12 subsequent siblings)
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Tony Luck, x86, linux-kernel, linux-pci, linux-acpi, Jiang Liu

From: Thomas Gleixner <tglx@linutronix.de>

Normal memory and io resources have window always set to false. Move
the flag logic to the unified address space parser.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |   22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index d1ceba02afde..a56a64164410 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -53,7 +53,7 @@ static bool acpi_dev_resource_len_valid(u64 start, u64 end, u64 len, bool io)
 }
 
 static void acpi_dev_memresource_flags(struct resource *res, u64 len,
-				       u8 write_protect, bool window)
+				       u8 write_protect)
 {
 	res->flags = IORESOURCE_MEM;
 
@@ -62,9 +62,6 @@ static void acpi_dev_memresource_flags(struct resource *res, u64 len,
 
 	if (write_protect == ACPI_READ_WRITE_MEMORY)
 		res->flags |= IORESOURCE_MEM_WRITEABLE;
-
-	if (window)
-		res->flags |= IORESOURCE_WINDOW;
 }
 
 static void acpi_dev_get_memresource(struct resource *res, u64 start, u64 len,
@@ -72,7 +69,7 @@ static void acpi_dev_get_memresource(struct resource *res, u64 start, u64 len,
 {
 	res->start = start;
 	res->end = start + len - 1;
-	acpi_dev_memresource_flags(res, len, write_protect, false);
+	acpi_dev_memresource_flags(res, len, write_protect);
 }
 
 /**
@@ -118,7 +115,7 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
 EXPORT_SYMBOL_GPL(acpi_dev_resource_memory);
 
 static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
-				      u8 io_decode, bool window)
+				      u8 io_decode)
 {
 	res->flags = IORESOURCE_IO;
 
@@ -130,9 +127,6 @@ static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
 
 	if (io_decode == ACPI_DECODE_16)
 		res->flags |= IORESOURCE_IO_16BIT_ADDR;
-
-	if (window)
-		res->flags |= IORESOURCE_WINDOW;
 }
 
 static void acpi_dev_get_ioresource(struct resource *res, u64 start, u64 len,
@@ -140,7 +134,7 @@ static void acpi_dev_get_ioresource(struct resource *res, u64 start, u64 len,
 {
 	res->start = start;
 	res->end = start + len - 1;
-	acpi_dev_ioresource_flags(res, len, io_decode, false);
+	acpi_dev_ioresource_flags(res, len, io_decode);
 }
 
 /**
@@ -183,7 +177,6 @@ static bool acpi_decode_space(struct resource *res,
 			      struct acpi_resource_address64_common *addr)
 {
 	u8 iodec = addr->granularity == 0xfff ? ACPI_DECODE_10 : ACPI_DECODE_16;
-	bool window = base->producer_consumer == ACPI_PRODUCER;
 	bool wp = base->info.mem.write_protect;
 	u64 len = addr->address_length;
 
@@ -192,10 +185,10 @@ static bool acpi_decode_space(struct resource *res,
 
 	switch(base->resource_type) {
 	case ACPI_MEMORY_RANGE:
-		acpi_dev_memresource_flags(res, len, wp, window);
+		acpi_dev_memresource_flags(res, len, wp);
 		break;
 	case ACPI_IO_RANGE:
-		acpi_dev_ioresource_flags(res, len, iodec, window);
+		acpi_dev_ioresource_flags(res, len, iodec);
 		break;
 	case ACPI_BUS_NUMBER_RANGE:
 		res->flags = IORESOURCE_BUS;
@@ -204,6 +197,9 @@ static bool acpi_decode_space(struct resource *res,
 		return false;
 	}
 
+	if (base->producer_consumer == ACPI_PRODUCER)
+		res->flags |= IORESOURCE_WINDOW;
+
 	return !(res->flags & IORESOURCE_DISABLED);
 }
 
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 08/19] ACPI: Add prefetch decoding to the address space parser
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (6 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 07/19] ACPI: Move the window flag logic to the combined parser Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-21  0:35   ` Rafael J. Wysocki
  2015-01-08  2:32 ` [RFC Patch 09/19] ACPI: Fix a bug in parsing ACPI Memroy24 resource Jiang Liu
                   ` (11 subsequent siblings)
  19 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Tony Luck, x86, linux-kernel, linux-pci, linux-acpi, Jiang Liu

From: Thomas Gleixner <tglx@linutronix.de>

Add support of PREFETCH attributre to ACPI address space and extended
address space parser.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index a56a64164410..abe3a29ad802 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -200,6 +200,9 @@ static bool acpi_decode_space(struct resource *res,
 	if (base->producer_consumer == ACPI_PRODUCER)
 		res->flags |= IORESOURCE_WINDOW;
 
+	if (base->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
+		res->flags |= IORESOURCE_PREFETCH;
+
 	return !(res->flags & IORESOURCE_DISABLED);
 }
 
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 09/19] ACPI: Fix a bug in parsing ACPI Memroy24 resource
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (7 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 08/19] ACPI: Add prefetch decoding to the address space parser Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-21  0:42   ` Rafael J. Wysocki
  2015-01-08  2:32 ` [RFC Patch 10/19] ACPI: Normalize return value of resource parser functions Jiang Liu
                   ` (10 subsequent siblings)
  19 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

According to ACPI spec 5, section 6.4.3.1 "24-Bit Memory Range Descriptor",
minimum, maximum and address_length field in struct acpi_resource_memory24
is in granularity of 256-bytes. So shift 8-bit left to get correct address.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index abe3a29ad802..f4aeef22a9d8 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -90,8 +90,8 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
 	switch (ares->type) {
 	case ACPI_RESOURCE_TYPE_MEMORY24:
 		memory24 = &ares->data.memory24;
-		acpi_dev_get_memresource(res, memory24->minimum,
-					 memory24->address_length,
+		acpi_dev_get_memresource(res, memory24->minimum << 8,
+					 memory24->address_length << 8,
 					 memory24->write_protect);
 		break;
 	case ACPI_RESOURCE_TYPE_MEMORY32:
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 10/19] ACPI: Normalize return value of resource parser functions
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (8 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 09/19] ACPI: Fix a bug in parsing ACPI Memroy24 resource Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 11/19] ACPI: Set flag IORESOURCE_UNSET for unassigned resources Jiang Liu
                   ` (9 subsequent siblings)
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

Normalize return value of resource parse functions as:
1) return "true" if resource is assigned.
2) return "false" and IORESOURCE_DISABLED setting in res->flags if
   resource is unassigned.
3) return "false" and zeroing res->flags if it's not an valid or
   expected resource.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index f4aeef22a9d8..db444c5cdd0e 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -80,6 +80,11 @@ static void acpi_dev_get_memresource(struct resource *res, u64 start, u64 len,
  * Check if the given ACPI resource object represents a memory resource and
  * if that's the case, use the information in it to populate the generic
  * resource object pointed to by @res.
+ *
+ * Return:
+ * 1) false with res->flags setting to zero: not the expected resource type
+ * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
+ * 3) true: valid assigned resource
  */
 bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
 {
@@ -107,6 +112,7 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
 					 fixed_memory32->write_protect);
 		break;
 	default:
+		res->flags = 0;
 		return false;
 	}
 
@@ -145,6 +151,11 @@ static void acpi_dev_get_ioresource(struct resource *res, u64 start, u64 len,
  * Check if the given ACPI resource object represents an I/O resource and
  * if that's the case, use the information in it to populate the generic
  * resource object pointed to by @res.
+ *
+ * Return:
+ * 1) false with res->flags setting to zero: not the expected resource type
+ * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
+ * 3) true: valid assigned resource
  */
 bool acpi_dev_resource_io(struct acpi_resource *ares, struct resource *res)
 {
@@ -165,6 +176,7 @@ bool acpi_dev_resource_io(struct acpi_resource *ares, struct resource *res)
 					ACPI_DECODE_10);
 		break;
 	default:
+		res->flags = 0;
 		return false;
 	}
 
@@ -214,12 +226,18 @@ static bool acpi_decode_space(struct resource *res,
  * Check if the given ACPI resource object represents an address space resource
  * and if that's the case, use the information in it to populate the generic
  * resource object pointed to by @res.
+ *
+ * Return:
+ * 1) false with res->flags setting to zero: not the expected resource type
+ * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
+ * 3) true: valid assigned resource
  */
 bool acpi_dev_resource_address_space(struct acpi_resource *ares,
 				     struct resource *res)
 {
 	struct acpi_resource_address64 addr;
 
+	res->flags = 0;
 	if (ACPI_FAILURE(acpi_resource_to_address64(ares, &addr)))
 		return false;
 
@@ -235,12 +253,18 @@ EXPORT_SYMBOL_GPL(acpi_dev_resource_address_space);
  * Check if the given ACPI resource object represents an extended address space
  * resource and if that's the case, use the information in it to populate the
  * generic resource object pointed to by @res.
+ *
+ * Return:
+ * 1) false with res->flags setting to zero: not the expected resource type
+ * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
+ * 3) true: valid assigned resource
  */
 bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
 					 struct resource *res)
 {
 	struct acpi_resource_extended_address64 *ext_addr;
 
+	res->flags = 0;
 	if (ares->type != ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64)
 		return false;
 
@@ -338,6 +362,11 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
  * represented by the resource and populate the generic resource object pointed
  * to by @res accordingly.  If the registration of the GSI is not successful,
  * IORESOURCE_DISABLED will be set it that object's flags.
+ *
+ * Return:
+ * 1) false with res->flags setting to zero: not the expected resource type
+ * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
+ * 3) true: valid assigned resource
  */
 bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
 				 struct resource *res)
@@ -371,6 +400,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
 					 ext_irq->sharable, false);
 		break;
 	default:
+		res->flags = 0;
 		return false;
 	}
 
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 11/19] ACPI: Set flag IORESOURCE_UNSET for unassigned resources
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (9 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 10/19] ACPI: Normalize return value of resource parser functions Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-08  2:32 ` [RFC Patch 12/19] ACPI: Enforce stricter checks for address space descriptors Jiang Liu
                   ` (8 subsequent siblings)
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

Also set flag IORESOURCE_UNSET for unassigned resource in addition to
IORESOURCE_DISABLED to mark resource as unassigned.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index db444c5cdd0e..26b47f1da523 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -58,7 +58,7 @@ static void acpi_dev_memresource_flags(struct resource *res, u64 len,
 	res->flags = IORESOURCE_MEM;
 
 	if (!acpi_dev_resource_len_valid(res->start, res->end, len, false))
-		res->flags |= IORESOURCE_DISABLED;
+		res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
 
 	if (write_protect == ACPI_READ_WRITE_MEMORY)
 		res->flags |= IORESOURCE_MEM_WRITEABLE;
@@ -126,10 +126,10 @@ static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
 	res->flags = IORESOURCE_IO;
 
 	if (!acpi_dev_resource_len_valid(res->start, res->end, len, true))
-		res->flags |= IORESOURCE_DISABLED;
+		res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
 
 	if (res->end >= 0x10003)
-		res->flags |= IORESOURCE_DISABLED;
+		res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
 
 	if (io_decode == ACPI_DECODE_16)
 		res->flags |= IORESOURCE_IO_16BIT_ADDR;
@@ -303,7 +303,7 @@ static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi)
 {
 	res->start = gsi;
 	res->end = gsi;
-	res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED;
+	res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
 }
 
 static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 12/19] ACPI: Enforce stricter checks for address space descriptors
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (10 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 11/19] ACPI: Set flag IORESOURCE_UNSET for unassigned resources Jiang Liu
@ 2015-01-08  2:32 ` Jiang Liu
  2015-01-21  0:45   ` Rafael J. Wysocki
  2015-01-08  2:33 ` [RFC Patch 13/19] ACPI: Return translation offset when parsing ACPI address space resources Jiang Liu
                   ` (7 subsequent siblings)
  19 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:32 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

Enforce stricter checks for address space descriptors according to
ACPI spec.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 26b47f1da523..e82149e44347 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -192,6 +192,14 @@ static bool acpi_decode_space(struct resource *res,
 	bool wp = base->info.mem.write_protect;
 	u64 len = addr->address_length;
 
+	/*
+	 * Filter out invalid descriptor according to ACPI Spec 5.0, section
+	 * 6.4.3.5 Address Space Resource Descriptors.
+	 */
+	if ((base->min_address_fixed != base->max_address_fixed && len) ||
+	    (base->min_address_fixed && base->max_address_fixed && !len))
+		return false;
+
 	res->start = addr->minimum;
 	res->end = addr->maximum;
 
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 13/19] ACPI: Return translation offset when parsing ACPI address space resources
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (11 preceding siblings ...)
  2015-01-08  2:32 ` [RFC Patch 12/19] ACPI: Enforce stricter checks for address space descriptors Jiang Liu
@ 2015-01-08  2:33 ` Jiang Liu
  2015-01-08  2:33 ` [RFC Patch 14/19] ACPI: Translate resource into master side address for bridge window resources Jiang Liu
                   ` (6 subsequent siblings)
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:33 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

Change function acpi_dev_resource_address_space() and
acpi_dev_resource_ext_address_space() to return address space
translation offset.

It's based on a patch from Yinghai Lu <yinghai@kernel.org>.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c        |   22 +++++++++++++++-------
 drivers/pnp/pnpacpi/rsparser.c |    4 ++--
 include/linux/acpi.h           |    6 ++++--
 3 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index e82149e44347..d3aa56674bd4 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -184,7 +184,7 @@ bool acpi_dev_resource_io(struct acpi_resource *ares, struct resource *res)
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_io);
 
-static bool acpi_decode_space(struct resource *res,
+static bool acpi_decode_space(struct resource *res, resource_size_t *offset,
 			      struct acpi_resource_address *base,
 			      struct acpi_resource_address64_common *addr)
 {
@@ -217,6 +217,9 @@ static bool acpi_decode_space(struct resource *res,
 		return false;
 	}
 
+	if (offset)
+		*offset = addr->translation_offset;
+
 	if (base->producer_consumer == ACPI_PRODUCER)
 		res->flags |= IORESOURCE_WINDOW;
 
@@ -230,6 +233,7 @@ static bool acpi_decode_space(struct resource *res,
  * acpi_dev_resource_address_space - Extract ACPI address space information.
  * @ares: Input ACPI resource object.
  * @res: Output generic resource object.
+ * @offset: Output translation offset
  *
  * Check if the given ACPI resource object represents an address space resource
  * and if that's the case, use the information in it to populate the generic
@@ -241,7 +245,8 @@ static bool acpi_decode_space(struct resource *res,
  * 3) true: valid assigned resource
  */
 bool acpi_dev_resource_address_space(struct acpi_resource *ares,
-				     struct resource *res)
+				     struct resource *res,
+				     resource_size_t *offset)
 {
 	struct acpi_resource_address64 addr;
 
@@ -249,7 +254,8 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
 	if (ACPI_FAILURE(acpi_resource_to_address64(ares, &addr)))
 		return false;
 
-	return acpi_decode_space(res, &addr.common.base, &addr.common.addr);
+	return acpi_decode_space(res, offset,
+				 &addr.common.base, &addr.common.addr);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_address_space);
 
@@ -257,6 +263,7 @@ EXPORT_SYMBOL_GPL(acpi_dev_resource_address_space);
  * acpi_dev_resource_ext_address_space - Extract ACPI address space information.
  * @ares: Input ACPI resource object.
  * @res: Output generic resource object.
+ * @offset: Output translation offset
  *
  * Check if the given ACPI resource object represents an extended address space
  * resource and if that's the case, use the information in it to populate the
@@ -268,7 +275,8 @@ EXPORT_SYMBOL_GPL(acpi_dev_resource_address_space);
  * 3) true: valid assigned resource
  */
 bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
-					 struct resource *res)
+					 struct resource *res,
+					 resource_size_t *offset)
 {
 	struct acpi_resource_extended_address64 *ext_addr;
 
@@ -278,7 +286,7 @@ bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
 
 	ext_addr = &ares->data.ext_address64;
 
-	return acpi_decode_space(res, &ext_addr->common.base,
+	return acpi_decode_space(res, offset, &ext_addr->common.base,
 				 &ext_addr->common.addr);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_resource_ext_address_space);
@@ -478,8 +486,8 @@ static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
 
 	if (acpi_dev_resource_memory(ares, &r)
 	    || acpi_dev_resource_io(ares, &r)
-	    || acpi_dev_resource_address_space(ares, &r)
-	    || acpi_dev_resource_ext_address_space(ares, &r))
+	    || acpi_dev_resource_address_space(ares, &r, NULL)
+	    || acpi_dev_resource_ext_address_space(ares, &r, NULL))
 		return acpi_dev_new_resource_entry(&r, c);
 
 	for (i = 0; acpi_dev_resource_interrupt(ares, i, &r); i++) {
diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
index 66977ebf13b3..e7bd483704e2 100644
--- a/drivers/pnp/pnpacpi/rsparser.c
+++ b/drivers/pnp/pnpacpi/rsparser.c
@@ -183,8 +183,8 @@ static acpi_status pnpacpi_allocated_resource(struct acpi_resource *res,
 	struct resource r = {0};
 	int i, flags;
 
-	if (acpi_dev_resource_address_space(res, &r)
-	    || acpi_dev_resource_ext_address_space(res, &r)) {
+	if (acpi_dev_resource_address_space(res, &r, NULL)
+	    || acpi_dev_resource_ext_address_space(res, &r, NULL)) {
 		pnp_add_resource(dev, &r);
 		return AE_OK;
 	}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 856d381b1d5b..bde8119f5897 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -288,9 +288,11 @@ extern int pnpacpi_disabled;
 bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res);
 bool acpi_dev_resource_io(struct acpi_resource *ares, struct resource *res);
 bool acpi_dev_resource_address_space(struct acpi_resource *ares,
-				     struct resource *res);
+				     struct resource *res,
+				     resource_size_t *offset);
 bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
-					 struct resource *res);
+					 struct resource *res,
+					 resource_size_t *offset);
 unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable);
 bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
 				 struct resource *res);
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 14/19] ACPI: Translate resource into master side address for bridge window resources
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (12 preceding siblings ...)
  2015-01-08  2:33 ` [RFC Patch 13/19] ACPI: Return translation offset when parsing ACPI address space resources Jiang Liu
@ 2015-01-08  2:33 ` Jiang Liu
  2015-01-21  0:50   ` Rafael J. Wysocki
  2015-01-08  2:33 ` [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry Jiang Liu
                   ` (5 subsequent siblings)
  19 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:33 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

Add translation_offset into the result address for bridge window
resources to form the master side address.

Currently acpi_dev_resource_{ext_}address_space() are only used for
devices instead of bridges, so it won't break current users. Later
it will be used to support PCI host bridge drivers.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index d3aa56674bd4..16d334a1ee25 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -203,6 +203,20 @@ static bool acpi_decode_space(struct resource *res, resource_size_t *offset,
 	res->start = addr->minimum;
 	res->end = addr->maximum;
 
+	/*
+	 * For bridges that translate addresses across the bridge,
+	 * translation_offset is the offset that must be added to the
+	 * address on the secondary side to obtain the address on the
+	 * primary side. Non-bridge devices must list 0 for all Address
+	 * Translation offset bits.
+	 */
+	if (base->producer_consumer == ACPI_PRODUCER) {
+		res->start += addr->translation_offset;
+		res->end += addr->translation_offset;
+	} else if (addr->translation_offset) {
+		return false;
+	}
+
 	switch(base->resource_type) {
 	case ACPI_MEMORY_RANGE:
 		acpi_dev_memresource_flags(res, len, wp);
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (13 preceding siblings ...)
  2015-01-08  2:33 ` [RFC Patch 14/19] ACPI: Translate resource into master side address for bridge window resources Jiang Liu
@ 2015-01-08  2:33 ` Jiang Liu
  2015-01-21  0:53   ` Rafael J. Wysocki
  2015-01-08  2:33 ` [RFC Patch 16/19] ACPI: Introduce helper function acpi_dev_filter_resource_type() Jiang Liu
                   ` (4 subsequent siblings)
  19 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:33 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

Add field offset to struct resource_list_entry to host address space
translation offset so it could be used to represent bridge resources.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |   13 ++++++++-----
 include/linux/acpi.h    |    1 +
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 16d334a1ee25..54204ac94f8e 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -462,7 +462,8 @@ struct res_proc_context {
 };
 
 static acpi_status acpi_dev_new_resource_entry(struct resource *r,
-					       struct res_proc_context *c)
+					       struct res_proc_context *c,
+					       resource_size_t offset)
 {
 	struct resource_list_entry *rentry;
 
@@ -472,6 +473,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
 		return AE_NO_MEMORY;
 	}
 	rentry->res = *r;
+	rentry->offset = offset;
 	list_add_tail(&rentry->node, c->list);
 	c->count++;
 	return AE_OK;
@@ -480,6 +482,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
 static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
 					     void *context)
 {
+	resource_size_t offset = 0;
 	struct res_proc_context *c = context;
 	struct resource r;
 	int i;
@@ -500,14 +503,14 @@ static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
 
 	if (acpi_dev_resource_memory(ares, &r)
 	    || acpi_dev_resource_io(ares, &r)
-	    || acpi_dev_resource_address_space(ares, &r, NULL)
-	    || acpi_dev_resource_ext_address_space(ares, &r, NULL))
-		return acpi_dev_new_resource_entry(&r, c);
+	    || acpi_dev_resource_address_space(ares, &r, &offset)
+	    || acpi_dev_resource_ext_address_space(ares, &r, &offset))
+		return acpi_dev_new_resource_entry(&r, c, offset);
 
 	for (i = 0; acpi_dev_resource_interrupt(ares, i, &r); i++) {
 		acpi_status status;
 
-		status = acpi_dev_new_resource_entry(&r, c);
+		status = acpi_dev_new_resource_entry(&r, c, 0);
 		if (ACPI_FAILURE(status))
 			return status;
 	}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index bde8119f5897..fea78e772450 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -300,6 +300,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
 struct resource_list_entry {
 	struct list_head node;
 	struct resource res;
+	resource_size_t offset;
 };
 
 void acpi_dev_free_resource_list(struct list_head *list);
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 16/19] ACPI: Introduce helper function acpi_dev_filter_resource_type()
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (14 preceding siblings ...)
  2015-01-08  2:33 ` [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry Jiang Liu
@ 2015-01-08  2:33 ` Jiang Liu
  2015-01-15 21:30   ` Thomas Gleixner
  2015-01-08  2:33 ` [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core Jiang Liu
                   ` (3 subsequent siblings)
  19 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:33 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

Introduce helper function acpi_dev_filter_resource_type(), which may
be used by acpi_dev_get_resources() to filer out resource based on
resource type.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/resource.c |   54 +++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/acpi.h    |    1 +
 2 files changed, 55 insertions(+)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 54204ac94f8e..8ea7c26d6915 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -570,3 +570,57 @@ int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
 	return c.count;
 }
 EXPORT_SYMBOL_GPL(acpi_dev_get_resources);
+
+/**
+ * acpi_dev_filter_resource_type - Filter ACPI resource according to resource
+ *				   types
+ * @ares: Input ACPI resource object.
+ * @arg: Valid resource types of IORESOURCE_XXX
+ *
+ * This is a hepler function to support acpi_dev_get_resources(), which filters
+ * ACPI resource objects according to resource types.
+ */
+int acpi_dev_filter_resource_type(struct acpi_resource *ares, void *arg)
+{
+	unsigned long type = 0, types = (unsigned long)arg;
+
+	switch (ares->type) {
+	case ACPI_RESOURCE_TYPE_MEMORY24:
+	case ACPI_RESOURCE_TYPE_MEMORY32:
+	case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+		type = IORESOURCE_MEM;
+		break;
+	case ACPI_RESOURCE_TYPE_IO:
+	case ACPI_RESOURCE_TYPE_FIXED_IO:
+		type = IORESOURCE_IO;
+		break;
+	case ACPI_RESOURCE_TYPE_IRQ:
+	case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+		type = IORESOURCE_IRQ;
+		break;
+	case ACPI_RESOURCE_TYPE_DMA:
+	case ACPI_RESOURCE_TYPE_FIXED_DMA:
+		type = IORESOURCE_DMA;
+		break;
+	case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
+		type = IORESOURCE_REG;
+		break;
+	case ACPI_RESOURCE_TYPE_ADDRESS16:
+	case ACPI_RESOURCE_TYPE_ADDRESS32:
+	case ACPI_RESOURCE_TYPE_ADDRESS64:
+	case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
+		if (ares->data.address.resource_type == ACPI_MEMORY_RANGE)
+			type = IORESOURCE_MEM;
+		else if (ares->data.address.resource_type == ACPI_IO_RANGE)
+			type = IORESOURCE_IO;
+		else if (ares->data.address.resource_type ==
+			 ACPI_BUS_NUMBER_RANGE)
+			type = IORESOURCE_BUS;
+		break;
+	default:
+		break;
+	}
+
+	return (type & types) ? 0 : 1;
+}
+EXPORT_SYMBOL_GPL(acpi_dev_filter_resource_type);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index fea78e772450..1df4a0211ae5 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -307,6 +307,7 @@ void acpi_dev_free_resource_list(struct list_head *list);
 int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
 			   int (*preproc)(struct acpi_resource *, void *),
 			   void *preproc_data);
+int acpi_dev_filter_resource_type(struct acpi_resource *ares, void *arg);
 
 int acpi_check_resource_conflict(const struct resource *res);
 
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (15 preceding siblings ...)
  2015-01-08  2:33 ` [RFC Patch 16/19] ACPI: Introduce helper function acpi_dev_filter_resource_type() Jiang Liu
@ 2015-01-08  2:33 ` Jiang Liu
  2015-01-21  1:10   ` Rafael J. Wysocki
  2015-01-08  2:33 ` [RFC Patch 18/19] PCI: Use common resource list management code instead of private implementation Jiang Liu
                   ` (2 subsequent siblings)
  19 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:33 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Len Brown, Dan Williams, Vinod Koul,
	Vivek Goyal, Thierry Reding, Andrew Morton, Mike Travis
  Cc: Jiang Liu, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi,
	dmaengine

Currently ACPI, PCI and pnp all implement the same resource list
management with different data structure. We need to transfer from
one data structure into another when passing resources from one
subsystem into another subsystem. Sp move struct resource_list_entry
from ACPI into resource core, so it could be reused by different
subystems and avoid the data structure conversion.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 drivers/acpi/acpi_lpss.c     |    6 +++---
 drivers/acpi/acpi_platform.c |    2 +-
 drivers/acpi/resource.c      |   13 ++++--------
 drivers/dma/acpi-dma.c       |    8 +++----
 include/linux/acpi.h         |    6 ------
 include/linux/ioport.h       |   25 ++++++++++++++++++++++
 kernel/resource.c            |   48 ++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 85 insertions(+), 23 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 4f3febf8a589..39b548dba70b 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -333,12 +333,12 @@ static int acpi_lpss_create_device(struct acpi_device *adev,
 		goto err_out;
 
 	list_for_each_entry(rentry, &resource_list, node)
-		if (resource_type(&rentry->res) == IORESOURCE_MEM) {
+		if (resource_type(rentry->res) == IORESOURCE_MEM) {
 			if (dev_desc->prv_size_override)
 				pdata->mmio_size = dev_desc->prv_size_override;
 			else
-				pdata->mmio_size = resource_size(&rentry->res);
-			pdata->mmio_base = ioremap(rentry->res.start,
+				pdata->mmio_size = resource_size(rentry->res);
+			pdata->mmio_base = ioremap(rentry->res->start,
 						   pdata->mmio_size);
 			break;
 		}
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 6ba8beb6b9d2..238e32b9cbb0 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -71,7 +71,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
 		}
 		count = 0;
 		list_for_each_entry(rentry, &resource_list, node)
-			resources[count++] = rentry->res;
+			resources[count++] = *rentry->res;
 
 		acpi_dev_free_resource_list(&resource_list);
 	}
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 8ea7c26d6915..c0dc038274d4 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -444,12 +444,7 @@ EXPORT_SYMBOL_GPL(acpi_dev_resource_interrupt);
  */
 void acpi_dev_free_resource_list(struct list_head *list)
 {
-	struct resource_list_entry *rentry, *re;
-
-	list_for_each_entry_safe(rentry, re, list, node) {
-		list_del(&rentry->node);
-		kfree(rentry);
-	}
+	resource_list_free_list(list);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_free_resource_list);
 
@@ -467,14 +462,14 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
 {
 	struct resource_list_entry *rentry;
 
-	rentry = kmalloc(sizeof(*rentry), GFP_KERNEL);
+	rentry = resource_list_alloc(NULL, 0);
 	if (!rentry) {
 		c->error = -ENOMEM;
 		return AE_NO_MEMORY;
 	}
-	rentry->res = *r;
+	*rentry->res = *r;
 	rentry->offset = offset;
-	list_add_tail(&rentry->node, c->list);
+	resource_list_insert(c->list, rentry, true);
 	c->count++;
 	return AE_OK;
 }
diff --git a/drivers/dma/acpi-dma.c b/drivers/dma/acpi-dma.c
index de361a156b34..1ce84abe0924 100644
--- a/drivers/dma/acpi-dma.c
+++ b/drivers/dma/acpi-dma.c
@@ -56,10 +56,10 @@ static int acpi_dma_parse_resource_group(const struct acpi_csrt_group *grp,
 		return 0;
 
 	list_for_each_entry(rentry, &resource_list, node) {
-		if (resource_type(&rentry->res) == IORESOURCE_MEM)
-			mem = rentry->res.start;
-		else if (resource_type(&rentry->res) == IORESOURCE_IRQ)
-			irq = rentry->res.start;
+		if (resource_type(rentry->res) == IORESOURCE_MEM)
+			mem = rentry->res->start;
+		else if (resource_type(rentry->res) == IORESOURCE_IRQ)
+			irq = rentry->res->start;
 	}
 
 	acpi_dev_free_resource_list(&resource_list);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 1df4a0211ae5..6d7f7edca22c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -297,12 +297,6 @@ unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable);
 bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
 				 struct resource *res);
 
-struct resource_list_entry {
-	struct list_head node;
-	struct resource res;
-	resource_size_t offset;
-};
-
 void acpi_dev_free_resource_list(struct list_head *list);
 int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
 			   int (*preproc)(struct acpi_resource *, void *),
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 2c5250222278..a6f4841ca40c 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -11,6 +11,7 @@
 #ifndef __ASSEMBLY__
 #include <linux/compiler.h>
 #include <linux/types.h>
+
 /*
  * Resources are tree-like, allowing
  * nesting etc..
@@ -255,6 +256,30 @@ static inline bool resource_overlaps(struct resource *r1, struct resource *r2)
        return (r1->start <= r2->end && r1->end >= r2->start);
 }
 
+/*
+ * Common resource list management data structure and interfaces to support
+ * ACPI, PNP and PCI host bridge etc.
+ */
+struct resource_list_entry {
+	struct list_head	node;
+	struct resource		*res;	/* In master (CPU) address space */
+	resource_size_t		offset;	/* Translation offset for bridge */
+	struct resource		__res;	/* Default storage for res */
+};
+
+extern struct resource_list_entry *resource_list_alloc(struct resource *res,
+						       size_t extra_size);
+extern void resource_list_free(struct resource_list_entry *entry);
+extern void resource_list_insert(struct list_head *head,
+				 struct resource_list_entry *entry, bool tail);
+extern void resource_list_delete(struct resource_list_entry *entry);
+extern void resource_list_free_list(struct list_head *head);
+
+#define resource_list_for_each_entry(entry, list)	\
+	list_for_each_entry((entry), (list), node)
+
+#define resource_list_for_each_entry_safe(entry, tmp, list)	\
+	list_for_each_entry_safe((entry), (tmp), (list), node)
 
 #endif /* __ASSEMBLY__ */
 #endif	/* _LINUX_IOPORT_H */
diff --git a/kernel/resource.c b/kernel/resource.c
index 0bcebffc4e77..414183809383 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1529,6 +1529,54 @@ int iomem_is_exclusive(u64 addr)
 	return err;
 }
 
+struct resource_list_entry *resource_list_alloc(struct resource *res,
+						size_t extra_size)
+{
+	struct resource_list_entry *entry;
+
+	entry = kzalloc(sizeof(*entry) + extra_size, GFP_KERNEL);
+	if (entry) {
+		INIT_LIST_HEAD(&entry->node);
+		entry->res = res ? res : &entry->__res;
+	}
+
+	return entry;
+}
+EXPORT_SYMBOL(resource_list_alloc);
+
+void resource_list_free(struct resource_list_entry *entry)
+{
+	kfree(entry);
+}
+EXPORT_SYMBOL(resource_list_free);
+
+void resource_list_insert(struct list_head *head,
+			  struct resource_list_entry *entry, bool tail)
+{
+	if (tail)
+		list_add_tail(&entry->node, head);
+	else
+		list_add(&entry->node, head);
+}
+EXPORT_SYMBOL(resource_list_insert);
+
+void resource_list_delete(struct resource_list_entry *entry)
+{
+	list_del(&entry->node);
+}
+EXPORT_SYMBOL(resource_list_delete);
+
+void resource_list_free_list(struct list_head *head)
+{
+	struct resource_list_entry *entry, *tmp;
+
+	list_for_each_entry_safe(entry, tmp, head, node) {
+		list_del(&entry->node);
+		resource_list_free(entry);
+	}
+}
+EXPORT_SYMBOL(resource_list_free_list);
+
 static int __init strict_iomem(char *str)
 {
 	if (strstr(str, "relaxed"))
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 18/19] PCI: Use common resource list management code instead of private implementation
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (16 preceding siblings ...)
  2015-01-08  2:33 ` [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core Jiang Liu
@ 2015-01-08  2:33 ` Jiang Liu
  2015-01-08  2:33 ` [RFC Patch 19/19] x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation Jiang Liu
  2015-01-11 22:38 ` [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Rafael J. Wysocki
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:33 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Russell King, Ingo Molnar, H. Peter Anvin, x86,
	Will Deacon, Tanmay Inamdar, Michal Simek, Sören Brinkmann,
	Yijing Wang, Murali Karicheri, Srikanth Thokala
  Cc: Jiang Liu, Tony Luck, linux-kernel, linux-pci, linux-acpi,
	Russell King, linux-arm-kernel

Use common resource list management data structure and interfaces
instead of private implementation.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/arm/kernel/bios32.c            |    5 ++---
 arch/x86/pci/bus_numa.c             |    4 ++--
 drivers/pci/bus.c                   |   18 ++++++------------
 drivers/pci/host-bridge.c           |    8 ++++----
 drivers/pci/host/pci-host-generic.c |    4 ++--
 drivers/pci/host/pci-xgene.c        |    4 ++--
 drivers/pci/host/pcie-xilinx.c      |    4 ++--
 drivers/pci/probe.c                 |   10 +++++-----
 include/linux/pci.h                 |    8 +-------
 9 files changed, 26 insertions(+), 39 deletions(-)

diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index a4effd6d8f2f..968b03cb6376 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -422,17 +422,16 @@ static int pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 static int pcibios_init_resources(int busnr, struct pci_sys_data *sys)
 {
 	int ret;
-	struct pci_host_bridge_window *window;
+	struct resource_list_entry *window;
 
 	if (list_empty(&sys->resources)) {
 		pci_add_resource_offset(&sys->resources,
 			 &iomem_resource, sys->mem_offset);
 	}
 
-	list_for_each_entry(window, &sys->resources, list) {
+	resource_list_for_each_entry(window, &sys->resources)
 		if (resource_type(window->res) == IORESOURCE_IO)
 			return 0;
-	}
 
 	sys->io_res.start = (busnr * SZ_64K) ?  : pcibios_min_io;
 	sys->io_res.end = (busnr + 1) * SZ_64K - 1;
diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index f3a2cfc14125..6785af30ed39 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -31,7 +31,7 @@ void x86_pci_root_bus_resources(int bus, struct list_head *resources)
 {
 	struct pci_root_info *info = x86_find_pci_root_info(bus);
 	struct pci_root_res *root_res;
-	struct pci_host_bridge_window *window;
+	struct resource_list_entry *window;
 	bool found = false;
 
 	if (!info)
@@ -41,7 +41,7 @@ void x86_pci_root_bus_resources(int bus, struct list_head *resources)
 	       bus);
 
 	/* already added by acpi ? */
-	list_for_each_entry(window, resources, list)
+	resource_list_for_each_entry(window, resources)
 		if (window->res->flags & IORESOURCE_BUS) {
 			found = true;
 			break;
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 73aef51a28f0..82bd96b60a0b 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -20,17 +20,16 @@
 void pci_add_resource_offset(struct list_head *resources, struct resource *res,
 			     resource_size_t offset)
 {
-	struct pci_host_bridge_window *window;
+	struct resource_list_entry *entry;
 
-	window = kzalloc(sizeof(struct pci_host_bridge_window), GFP_KERNEL);
-	if (!window) {
+	entry = resource_list_alloc(res, 0);
+	if (!entry) {
 		printk(KERN_ERR "PCI: can't add host bridge window %pR\n", res);
 		return;
 	}
 
-	window->res = res;
-	window->offset = offset;
-	list_add_tail(&window->list, resources);
+	entry->offset = offset;
+	resource_list_insert(resources, entry, true);
 }
 EXPORT_SYMBOL(pci_add_resource_offset);
 
@@ -42,12 +41,7 @@ EXPORT_SYMBOL(pci_add_resource);
 
 void pci_free_resource_list(struct list_head *resources)
 {
-	struct pci_host_bridge_window *window, *tmp;
-
-	list_for_each_entry_safe(window, tmp, resources, list) {
-		list_del(&window->list);
-		kfree(window);
-	}
+	resource_list_free_list(resources);
 }
 EXPORT_SYMBOL(pci_free_resource_list);
 
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 0e5f3c95af5b..3ea13883e6a5 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -35,10 +35,10 @@ void pcibios_resource_to_bus(struct pci_bus *bus, struct pci_bus_region *region,
 			     struct resource *res)
 {
 	struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
-	struct pci_host_bridge_window *window;
+	struct resource_list_entry *window;
 	resource_size_t offset = 0;
 
-	list_for_each_entry(window, &bridge->windows, list) {
+	resource_list_for_each_entry(window, &bridge->windows) {
 		if (resource_contains(window->res, res)) {
 			offset = window->offset;
 			break;
@@ -60,10 +60,10 @@ void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
 			     struct pci_bus_region *region)
 {
 	struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
-	struct pci_host_bridge_window *window;
+	struct resource_list_entry *window;
 	resource_size_t offset = 0;
 
-	list_for_each_entry(window, &bridge->windows, list) {
+	resource_list_for_each_entry(window, &bridge->windows) {
 		struct pci_bus_region bus_region;
 
 		if (resource_type(res) != resource_type(window->res))
diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
index 6eb1aa75bd37..16d5d6eeb35a 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -149,14 +149,14 @@ static int gen_pci_parse_request_of_pci_ranges(struct gen_pci *pci)
 	struct device *dev = pci->host.dev.parent;
 	struct device_node *np = dev->of_node;
 	resource_size_t iobase;
-	struct pci_host_bridge_window *win;
+	struct resource_list_entry *win;
 
 	err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pci->resources,
 					       &iobase);
 	if (err)
 		return err;
 
-	list_for_each_entry(win, &pci->resources, list) {
+	resource_list_for_each_entry(win, &pci->resources) {
 		struct resource *parent, *res = win->res;
 
 		switch (resource_type(res)) {
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index b1d0596457c5..e335b834f950 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -401,11 +401,11 @@ static int xgene_pcie_map_ranges(struct xgene_pcie_port *port,
 				 struct list_head *res,
 				 resource_size_t io_base)
 {
-	struct pci_host_bridge_window *window;
+	struct resource_list_entry *window;
 	struct device *dev = port->dev;
 	int ret;
 
-	list_for_each_entry(window, res, list) {
+	resource_list_for_each_entry(window, res) {
 		struct resource *res = window->res;
 		u64 restype = resource_type(res);
 
diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index ef3ebaf9a738..253e993a111f 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -737,7 +737,7 @@ static int xilinx_pcie_parse_and_add_res(struct xilinx_pcie_port *port)
 	resource_size_t offset;
 	struct of_pci_range_parser parser;
 	struct of_pci_range range;
-	struct pci_host_bridge_window *win;
+	struct resource_list_entry *win;
 	int err = 0, mem_resno = 0;
 
 	/* Get the ranges */
@@ -807,7 +807,7 @@ static int xilinx_pcie_parse_and_add_res(struct xilinx_pcie_port *port)
 
 free_resources:
 	release_child_resources(&iomem_resource);
-	list_for_each_entry(win, &port->resources, list)
+	resource_list_for_each_entry(win, &port->resources)
 		devm_kfree(dev, win->res);
 	pci_free_resource_list(&port->resources);
 
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 23212f8ae09b..df6a40932aa0 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1895,7 +1895,7 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 	int error;
 	struct pci_host_bridge *bridge;
 	struct pci_bus *b, *b2;
-	struct pci_host_bridge_window *window, *n;
+	struct resource_list_entry *window, *n;
 	struct resource *res;
 	resource_size_t offset;
 	char bus_addr[64];
@@ -1959,8 +1959,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 		printk(KERN_INFO "PCI host bridge to bus %s\n", dev_name(&b->dev));
 
 	/* Add initial resources to the bus */
-	list_for_each_entry_safe(window, n, resources, list) {
-		list_move_tail(&window->list, &bridge->windows);
+	resource_list_for_each_entry_safe(window, n, resources) {
+		list_move_tail(&window->node, &bridge->windows);
 		res = window->res;
 		offset = window->offset;
 		if (res->flags & IORESOURCE_BUS)
@@ -2060,12 +2060,12 @@ void pci_bus_release_busn_res(struct pci_bus *b)
 struct pci_bus *pci_scan_root_bus(struct device *parent, int bus,
 		struct pci_ops *ops, void *sysdata, struct list_head *resources)
 {
-	struct pci_host_bridge_window *window;
+	struct resource_list_entry *window;
 	bool found = false;
 	struct pci_bus *b;
 	int max;
 
-	list_for_each_entry(window, resources, list)
+	resource_list_for_each_entry(window, resources)
 		if (window->res->flags & IORESOURCE_BUS) {
 			found = true;
 			break;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 360a966a97a5..74afd92c05e8 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -395,16 +395,10 @@ static inline int pci_channel_offline(struct pci_dev *pdev)
 	return (pdev->error_state != pci_channel_io_normal);
 }
 
-struct pci_host_bridge_window {
-	struct list_head list;
-	struct resource *res;		/* host bridge aperture (CPU address) */
-	resource_size_t offset;		/* bus address + offset = CPU address */
-};
-
 struct pci_host_bridge {
 	struct device dev;
 	struct pci_bus *bus;		/* root bus */
-	struct list_head windows;	/* pci_host_bridge_windows */
+	struct list_head windows;	/* resource_list_entry */
 	void (*release_fn)(struct pci_host_bridge *);
 	void *release_data;
 };
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* [RFC Patch 19/19] x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (17 preceding siblings ...)
  2015-01-08  2:33 ` [RFC Patch 18/19] PCI: Use common resource list management code instead of private implementation Jiang Liu
@ 2015-01-08  2:33 ` Jiang Liu
  2015-01-11 22:38 ` [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Rafael J. Wysocki
  19 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-08  2:33 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Ingo Molnar, H. Peter Anvin, x86
  Cc: Jiang Liu, Tony Luck, linux-kernel, linux-pci, linux-acpi

Use common ACPI resource discovery interfaces to simplify PCI host bridge
resource enumeration.

It also fixes the issue discovered by Thomas that function setup_resource()
incorrectly validates IO port resources against iomem_resource.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/x86/pci/acpi.c |  297 ++++++++++++++++-----------------------------------
 1 file changed, 95 insertions(+), 202 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b132b8e3..749266c8c671 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -10,9 +10,6 @@
 struct pci_root_info {
 	struct acpi_device *bridge;
 	char name[16];
-	unsigned int res_num;
-	struct resource *res;
-	resource_size_t *res_offset;
 	struct pci_sysdata sd;
 #ifdef	CONFIG_PCI_MMCONFIG
 	bool mcfg_added;
@@ -218,130 +215,44 @@ static void teardown_mcfg_map(struct pci_root_info *info)
 }
 #endif
 
-static acpi_status resource_to_addr(struct acpi_resource *resource,
-				    struct acpi_resource_address64 *addr)
-{
-	acpi_status status;
-	struct acpi_resource_memory24 *memory24;
-	struct acpi_resource_memory32 *memory32;
-	struct acpi_resource_fixed_memory32 *fixed_memory32;
-
-	memset(addr, 0, sizeof(*addr));
-	switch (resource->type) {
-	case ACPI_RESOURCE_TYPE_MEMORY24:
-		memory24 = &resource->data.memory24;
-		addr->resource_type = ACPI_MEMORY_RANGE;
-		addr->minimum = memory24->minimum;
-		addr->address_length = memory24->address_length;
-		addr->maximum = addr->minimum + addr->address_length - 1;
-		return AE_OK;
-	case ACPI_RESOURCE_TYPE_MEMORY32:
-		memory32 = &resource->data.memory32;
-		addr->resource_type = ACPI_MEMORY_RANGE;
-		addr->minimum = memory32->minimum;
-		addr->address_length = memory32->address_length;
-		addr->maximum = addr->minimum + addr->address_length - 1;
-		return AE_OK;
-	case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
-		fixed_memory32 = &resource->data.fixed_memory32;
-		addr->resource_type = ACPI_MEMORY_RANGE;
-		addr->minimum = fixed_memory32->address;
-		addr->address_length = fixed_memory32->address_length;
-		addr->maximum = addr->minimum + addr->address_length - 1;
-		return AE_OK;
-	case ACPI_RESOURCE_TYPE_ADDRESS16:
-	case ACPI_RESOURCE_TYPE_ADDRESS32:
-	case ACPI_RESOURCE_TYPE_ADDRESS64:
-		status = acpi_resource_to_address64(resource, addr);
-		if (ACPI_SUCCESS(status) &&
-		    (addr->resource_type == ACPI_MEMORY_RANGE ||
-		    addr->resource_type == ACPI_IO_RANGE) &&
-		    addr->address_length > 0) {
-			return AE_OK;
-		}
-		break;
-	}
-	return AE_ERROR;
-}
-
-static acpi_status count_resource(struct acpi_resource *acpi_res, void *data)
+static void validate_resources(struct device *dev, struct list_head *crs_res,
+			       unsigned long type)
 {
-	struct pci_root_info *info = data;
-	struct acpi_resource_address64 addr;
-	acpi_status status;
-
-	status = resource_to_addr(acpi_res, &addr);
-	if (ACPI_SUCCESS(status))
-		info->res_num++;
-	return AE_OK;
-}
-
-static acpi_status setup_resource(struct acpi_resource *acpi_res, void *data)
-{
-	struct pci_root_info *info = data;
-	struct resource *res;
-	struct acpi_resource_address64 addr;
-	acpi_status status;
-	unsigned long flags;
-	u64 start, orig_end, end;
-
-	status = resource_to_addr(acpi_res, &addr);
-	if (!ACPI_SUCCESS(status))
-		return AE_OK;
-
-	if (addr.resource_type == ACPI_MEMORY_RANGE) {
-		flags = IORESOURCE_MEM;
-		if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
-			flags |= IORESOURCE_PREFETCH;
-	} else if (addr.resource_type == ACPI_IO_RANGE) {
-		flags = IORESOURCE_IO;
-	} else
-		return AE_OK;
-
-	start = addr.minimum + addr.translation_offset;
-	orig_end = end = addr.maximum + addr.translation_offset;
-
-	/* Exclude non-addressable range or non-addressable portion of range */
-	end = min(end, (u64)iomem_resource.end);
-	if (end <= start) {
-		dev_info(&info->bridge->dev,
-			"host bridge window [%#llx-%#llx] "
-			"(ignored, not CPU addressable)\n", start, orig_end);
-		return AE_OK;
-	} else if (orig_end != end) {
-		dev_info(&info->bridge->dev,
-			"host bridge window [%#llx-%#llx] "
-			"([%#llx-%#llx] ignored, not CPU addressable)\n", 
-			start, orig_end, end + 1, orig_end);
-	}
+	LIST_HEAD(list);
+	struct resource *res1, *res2, *root = NULL;
+	struct resource_list_entry *tmp, *entry, *entry2;
 
-	res = &info->res[info->res_num];
-	res->name = info->name;
-	res->flags = flags;
-	res->start = start;
-	res->end = end;
-	info->res_offset[info->res_num] = addr.translation_offset;
-	info->res_num++;
+	BUG_ON((type & (IORESOURCE_MEM | IORESOURCE_IO)) == 0);
+	root = (type & IORESOURCE_MEM) ? &iomem_resource : &ioport_resource;
 
-	if (!pci_use_crs)
-		dev_printk(KERN_DEBUG, &info->bridge->dev,
-			   "host bridge window %pR (ignored)\n", res);
+	list_splice_init(crs_res, &list);
+	resource_list_for_each_entry_safe(entry, tmp, &list) {
+		bool free = false;
+		resource_size_t end;
 
-	return AE_OK;
-}
-
-static void coalesce_windows(struct pci_root_info *info, unsigned long type)
-{
-	int i, j;
-	struct resource *res1, *res2;
-
-	for (i = 0; i < info->res_num; i++) {
-		res1 = &info->res[i];
+		res1 = entry->res;
 		if (!(res1->flags & type))
-			continue;
+			goto next;
+
+		/* Exclude non-addressable range or non-addressable portion */
+		end = min(res1->end, root->end);
+		if (end <= res1->start) {
+			dev_info(dev, "host bridge window [%#llx-%#llx] (ignored, not CPU addressable)\n",
+				 (unsigned long long)res1->start,
+				 (unsigned long long)res1->end);
+			free = true;
+			goto next;
+		} else if (res1->end != end) {
+			dev_info(dev, "host bridge window [%#llx-%#llx] ([%#llx-%#llx] ignored, not CPU addressable)\n",
+				 (unsigned long long)res1->start,
+				 (unsigned long long)res1->end,
+				 (unsigned long long)end + 1,
+				 (unsigned long long)res1->end);
+			res1->end = end;
+		}
 
-		for (j = i + 1; j < info->res_num; j++) {
-			res2 = &info->res[j];
+		resource_list_for_each_entry(entry2, crs_res) {
+			res2 = entry2->res;
 			if (!(res2->flags & type))
 				continue;
 
@@ -353,118 +264,93 @@ static void coalesce_windows(struct pci_root_info *info, unsigned long type)
 			if (resource_overlaps(res1, res2)) {
 				res2->start = min(res1->start, res2->start);
 				res2->end = max(res1->end, res2->end);
-				dev_info(&info->bridge->dev,
-					 "host bridge window expanded to %pR; %pR ignored\n",
+				dev_info(dev, "host bridge window expanded to %pR; %pR ignored\n",
 					 res2, res1);
-				res1->flags = 0;
+				free = true;
+				goto next;
 			}
 		}
+
+next:
+		resource_list_delete(entry);
+		if (free)
+			resource_list_free(entry);
+		else
+			resource_list_insert(crs_res, entry, true);
 	}
 }
 
 static void add_resources(struct pci_root_info *info,
-			  struct list_head *resources)
+			  struct list_head *resources,
+			  struct list_head *crs_res)
 {
-	int i;
-	struct resource *res, *root, *conflict;
-
-	coalesce_windows(info, IORESOURCE_MEM);
-	coalesce_windows(info, IORESOURCE_IO);
+	struct resource_list_entry *entry, *tmp;
+	struct resource *res, *conflict, *root = NULL;
 
-	for (i = 0; i < info->res_num; i++) {
-		res = &info->res[i];
+	validate_resources(&info->bridge->dev, crs_res, IORESOURCE_MEM);
+	validate_resources(&info->bridge->dev, crs_res, IORESOURCE_IO);
 
+	resource_list_for_each_entry_safe(entry, tmp, crs_res) {
+		res = entry->res;
 		if (res->flags & IORESOURCE_MEM)
 			root = &iomem_resource;
 		else if (res->flags & IORESOURCE_IO)
 			root = &ioport_resource;
 		else
-			continue;
+			BUG_ON(res);
 
 		conflict = insert_resource_conflict(root, res);
-		if (conflict)
+		if (conflict) {
 			dev_info(&info->bridge->dev,
 				 "ignoring host bridge window %pR (conflicts with %s %pR)\n",
 				 res, conflict->name, conflict);
-		else
-			pci_add_resource_offset(resources, res,
-					info->res_offset[i]);
+			resource_list_delete(entry);
+			resource_list_free(entry);
+		}
 	}
-}
 
-static void free_pci_root_info_res(struct pci_root_info *info)
-{
-	kfree(info->res);
-	info->res = NULL;
-	kfree(info->res_offset);
-	info->res_offset = NULL;
-	info->res_num = 0;
+	list_splice_tail(crs_res, resources);
 }
 
-static void __release_pci_root_info(struct pci_root_info *info)
+static void release_pci_root_info(struct pci_host_bridge *bridge)
 {
-	int i;
 	struct resource *res;
+	struct resource_list_entry *entry;
+	struct pci_root_info *info = bridge->release_data;
 
-	for (i = 0; i < info->res_num; i++) {
-		res = &info->res[i];
-
-		if (!res->parent)
-			continue;
-
-		if (!(res->flags & (IORESOURCE_MEM | IORESOURCE_IO)))
-			continue;
-
-		release_resource(res);
+	resource_list_for_each_entry(entry, &bridge->windows) {
+		res = entry->res;
+		if (res->parent &&
+		    (res->flags & (IORESOURCE_MEM | IORESOURCE_IO)))
+			release_resource(res);
 	}
 
-	free_pci_root_info_res(info);
-
 	teardown_mcfg_map(info);
-
 	kfree(info);
 }
 
-static void release_pci_root_info(struct pci_host_bridge *bridge)
-{
-	struct pci_root_info *info = bridge->release_data;
-
-	__release_pci_root_info(info);
-}
-
 static void probe_pci_root_info(struct pci_root_info *info,
 				struct acpi_device *device,
-				int busnum, int domain)
+				int busnum, int domain,
+				struct list_head *list)
 {
-	size_t size;
+	int ret;
+	struct resource_list_entry *entry;
 
 	sprintf(info->name, "PCI Bus %04x:%02x", domain, busnum);
 	info->bridge = device;
-
-	info->res_num = 0;
-	acpi_walk_resources(device->handle, METHOD_NAME__CRS, count_resource,
-				info);
-	if (!info->res_num)
-		return;
-
-	size = sizeof(*info->res) * info->res_num;
-	info->res = kzalloc_node(size, GFP_KERNEL, info->sd.node);
-	if (!info->res) {
-		info->res_num = 0;
-		return;
-	}
-
-	size = sizeof(*info->res_offset) * info->res_num;
-	info->res_num = 0;
-	info->res_offset = kzalloc_node(size, GFP_KERNEL, info->sd.node);
-	if (!info->res_offset) {
-		kfree(info->res);
-		info->res = NULL;
-		return;
-	}
-
-	acpi_walk_resources(device->handle, METHOD_NAME__CRS, setup_resource,
-				info);
+	ret = acpi_dev_get_resources(device, list,
+				     acpi_dev_filter_resource_type,
+				     (void *)(IORESOURCE_IO | IORESOURCE_MEM));
+	if (ret < 0)
+		dev_warn(&device->dev,
+			 "failed to parse _CRS method, error code %d.\n", ret);
+	else if (ret == 0)
+		dev_dbg(&device->dev,
+			"no IO and memory resources present in _CRS.\n");
+	else
+		resource_list_for_each_entry(entry, list)
+			entry->res->name = info->name;
 }
 
 struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
@@ -473,6 +359,8 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 	struct pci_root_info *info;
 	int domain = root->segment;
 	int busnum = root->secondary.start;
+	struct resource_list_entry *res_entry;
+	LIST_HEAD(crs_res);
 	LIST_HEAD(resources);
 	struct pci_bus *bus;
 	struct pci_sysdata *sd;
@@ -520,18 +408,22 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 		memcpy(bus->sysdata, sd, sizeof(*sd));
 		kfree(info);
 	} else {
-		probe_pci_root_info(info, device, busnum, domain);
-
 		/* insert busn res at first */
 		pci_add_resource(&resources,  &root->secondary);
+
 		/*
 		 * _CRS with no apertures is normal, so only fall back to
 		 * defaults or native bridge info if we're ignoring _CRS.
 		 */
-		if (pci_use_crs)
-			add_resources(info, &resources);
-		else {
-			free_pci_root_info_res(info);
+		probe_pci_root_info(info, device, busnum, domain, &crs_res);
+		if (pci_use_crs) {
+			add_resources(info, &resources, &crs_res);
+		} else {
+			resource_list_for_each_entry(res_entry, &crs_res)
+				dev_printk(KERN_DEBUG, &device->dev,
+					   "host bridge window %pR (ignored)\n",
+					   res_entry->res);
+			resource_list_free_list(&crs_res);
 			x86_pci_root_bus_resources(busnum, &resources);
 		}
 
@@ -546,8 +438,9 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 				to_pci_host_bridge(bus->bridge),
 				release_pci_root_info, info);
 		} else {
-			pci_free_resource_list(&resources);
-			__release_pci_root_info(info);
+			resource_list_free_list(&resources);
+			teardown_mcfg_map(info);
+			kfree(info);
 		}
 	}
 
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures
  2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
                   ` (18 preceding siblings ...)
  2015-01-08  2:33 ` [RFC Patch 19/19] x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation Jiang Liu
@ 2015-01-11 22:38 ` Rafael J. Wysocki
  2015-01-19 14:26   ` Jiang Liu
  19 siblings, 1 reply; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-11 22:38 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Thursday, January 08, 2015 10:32:47 AM Jiang Liu wrote:
> During enabling ACPI based IOAPIC hotplug, Thomas noticed some issues
> in ACPI resource parsing interfaces. So this is an effort to improve them.
> 
> Patch 1-12 improve ACPI resource parsing interfaces and also fixes some
> bugs.
> 
> Patch 13-19 try to share the common data structure resource_list_entry
> between PCI and ACPI. It may also be shared with PNP too.

I've looked at the patches briefly.

I like the changes at the general level, but there are some things I'm
potentially concerned about in them.  Need more time to look at them,
I'll do my best to do that this week while at the conference.

> The patchset is based on v3.19-rc3 and you may get it from:
> https://github.com/jiangliu/linux.git acpires_v1
> 
> Jiang Liu (11):
>   ACPI: Fix a bug in parsing ACPI Memroy24 resource
>   ACPI: Normalize return value of resource parser functions
>   ACPI: Set flag IORESOURCE_UNSET for unassigned resources
>   ACPI: Enforce stricter checks for address space descriptors
>   ACPI: Return translation offset when parsing ACPI address space
>     resources
>   ACPI: Translate resource into master side address for bridge window
>     resources
>   ACPI: Add field offset to struct resource_list_entry
>   ACPI: Introduce helper function acpi_dev_filter_resource_type()
>   resources: Move struct resource_list_entry from ACPI into resource
>     core
>   PCI: Use common resource list management code instead of private
>     implementation
>   x86/PCI/ACPI: Use common ACPI resource interfaces to simplify
>     implementation
> 
> Thomas Gleixner (8):
>   ACPI: Remove redundant check in function
>     acpi_dev_resource_address_space()
>   ACPI: Implement proper length checks for mem resources
>   ACPI: Use the length check for io resources as well
>   ACPI: Let the parser return false for disabled resources
>   ACPI: Provide union for address_space64 and ext_address_space64
>   ACPI: Unify the parsing of address_space and ext_address_space
>   ACPI: Move the window flag logic to the combined parser
>   ACPI: Add prefetch decoding to the address space parser
> 
>  arch/arm/kernel/bios32.c            |    5 +-
>  arch/x86/pci/acpi.c                 |  297 ++++++++++---------------------
>  arch/x86/pci/bus_numa.c             |    4 +-
>  drivers/acpi/acpi_lpss.c            |    6 +-
>  drivers/acpi/acpi_platform.c        |    2 +-
>  drivers/acpi/resource.c             |  333 ++++++++++++++++++++++-------------
>  drivers/dma/acpi-dma.c              |    8 +-
>  drivers/pci/bus.c                   |   18 +-
>  drivers/pci/host-bridge.c           |    8 +-
>  drivers/pci/host/pci-host-generic.c |    4 +-
>  drivers/pci/host/pci-xgene.c        |    4 +-
>  drivers/pci/host/pcie-xilinx.c      |    4 +-
>  drivers/pci/probe.c                 |   10 +-
>  drivers/pnp/pnpacpi/rsparser.c      |    4 +-
>  include/acpi/acrestyp.h             |   49 ++++--
>  include/linux/acpi.h                |   12 +-
>  include/linux/ioport.h              |   25 +++
>  include/linux/pci.h                 |    8 +-
>  kernel/resource.c                   |   48 +++++
>  19 files changed, 452 insertions(+), 397 deletions(-)
> 
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 16/19] ACPI: Introduce helper function acpi_dev_filter_resource_type()
  2015-01-08  2:33 ` [RFC Patch 16/19] ACPI: Introduce helper function acpi_dev_filter_resource_type() Jiang Liu
@ 2015-01-15 21:30   ` Thomas Gleixner
  2015-01-16  0:58     ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Thomas Gleixner @ 2015-01-15 21:30 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Rafael J. Wysocki, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Thu, 8 Jan 2015, Jiang Liu wrote:

> Introduce helper function acpi_dev_filter_resource_type(), which may
> be used by acpi_dev_get_resources() to filer out resource based on
> resource type.
> 
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  drivers/acpi/resource.c |   54 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/acpi.h    |    1 +
>  2 files changed, 55 insertions(+)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 54204ac94f8e..8ea7c26d6915 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -570,3 +570,57 @@ int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
>  	return c.count;
>  }
>  EXPORT_SYMBOL_GPL(acpi_dev_get_resources);
> +
> +/**
> + * acpi_dev_filter_resource_type - Filter ACPI resource according to resource
> + *				   types
> + * @ares: Input ACPI resource object.
> + * @arg: Valid resource types of IORESOURCE_XXX
> + *
> + * This is a hepler function to support acpi_dev_get_resources(), which filters
> + * ACPI resource objects according to resource types.
> + */
> +int acpi_dev_filter_resource_type(struct acpi_resource *ares, void *arg)

Why is the filter a void pointer instead of an simple unsigned long?
That does not make any sense as you convert it to unsigned long right away:

> +{
> +	unsigned long type = 0, types = (unsigned long)arg;

So this should be:

int acpi_dev_filter_resource_type(struct acpi_resource *ares, unsigned long type_mask)

or something like that.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 16/19] ACPI: Introduce helper function acpi_dev_filter_resource_type()
  2015-01-15 21:30   ` Thomas Gleixner
@ 2015-01-16  0:58     ` Jiang Liu
  0 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-16  0:58 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Rafael J. Wysocki, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On 2015/1/16 5:30, Thomas Gleixner wrote:
> On Thu, 8 Jan 2015, Jiang Liu wrote:
> 
>> Introduce helper function acpi_dev_filter_resource_type(), which may
>> be used by acpi_dev_get_resources() to filer out resource based on
>> resource type.
>>
>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>> ---
>>  drivers/acpi/resource.c |   54 +++++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/acpi.h    |    1 +
>>  2 files changed, 55 insertions(+)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 54204ac94f8e..8ea7c26d6915 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -570,3 +570,57 @@ int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
>>  	return c.count;
>>  }
>>  EXPORT_SYMBOL_GPL(acpi_dev_get_resources);
>> +
>> +/**
>> + * acpi_dev_filter_resource_type - Filter ACPI resource according to resource
>> + *				   types
>> + * @ares: Input ACPI resource object.
>> + * @arg: Valid resource types of IORESOURCE_XXX
>> + *
>> + * This is a hepler function to support acpi_dev_get_resources(), which filters
>> + * ACPI resource objects according to resource types.
>> + */
>> +int acpi_dev_filter_resource_type(struct acpi_resource *ares, void *arg)
> 
> Why is the filter a void pointer instead of an simple unsigned long?
> That does not make any sense as you convert it to unsigned long right away:
> 
>> +{
>> +	unsigned long type = 0, types = (unsigned long)arg;
> 
> So this should be:
> 
> int acpi_dev_filter_resource_type(struct acpi_resource *ares, unsigned long type_mask)
> 
> or something like that.
Hi Thomas,
	I used void * instead of unsigned long for type_mask so
acpi_dev_filter_resource_type() could directly used by
acpi_dev_get_resources(). Otherwise we need to use something like
acpi_dev_get_resources(..., (void *)acpi_dev_filter_resource_type, ...).
I will find a way to solve this:)
Regards!
Gerry

> 
> Thanks,
> 
> 	tglx
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures
  2015-01-11 22:38 ` [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Rafael J. Wysocki
@ 2015-01-19 14:26   ` Jiang Liu
  2015-01-19 15:06     ` Rafael J. Wysocki
  0 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-19 14:26 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On 2015/1/12 6:38, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:32:47 AM Jiang Liu wrote:
>> During enabling ACPI based IOAPIC hotplug, Thomas noticed some issues
>> in ACPI resource parsing interfaces. So this is an effort to improve them.
>>
>> Patch 1-12 improve ACPI resource parsing interfaces and also fixes some
>> bugs.
>>
>> Patch 13-19 try to share the common data structure resource_list_entry
>> between PCI and ACPI. It may also be shared with PNP too.
> 
> I've looked at the patches briefly.
> 
> I like the changes at the general level, but there are some things I'm
> potentially concerned about in them.  Need more time to look at them,
> I'll do my best to do that this week while at the conference.
Hi Rafael,
	Thanks for your time. Any comments about this series?
Regards,
Gerry

> 
>> The patchset is based on v3.19-rc3 and you may get it from:
>> https://github.com/jiangliu/linux.git acpires_v1
>>
>> Jiang Liu (11):
>>   ACPI: Fix a bug in parsing ACPI Memroy24 resource
>>   ACPI: Normalize return value of resource parser functions
>>   ACPI: Set flag IORESOURCE_UNSET for unassigned resources
>>   ACPI: Enforce stricter checks for address space descriptors
>>   ACPI: Return translation offset when parsing ACPI address space
>>     resources
>>   ACPI: Translate resource into master side address for bridge window
>>     resources
>>   ACPI: Add field offset to struct resource_list_entry
>>   ACPI: Introduce helper function acpi_dev_filter_resource_type()
>>   resources: Move struct resource_list_entry from ACPI into resource
>>     core
>>   PCI: Use common resource list management code instead of private
>>     implementation
>>   x86/PCI/ACPI: Use common ACPI resource interfaces to simplify
>>     implementation
>>
>> Thomas Gleixner (8):
>>   ACPI: Remove redundant check in function
>>     acpi_dev_resource_address_space()
>>   ACPI: Implement proper length checks for mem resources
>>   ACPI: Use the length check for io resources as well
>>   ACPI: Let the parser return false for disabled resources
>>   ACPI: Provide union for address_space64 and ext_address_space64
>>   ACPI: Unify the parsing of address_space and ext_address_space
>>   ACPI: Move the window flag logic to the combined parser
>>   ACPI: Add prefetch decoding to the address space parser
>>
>>  arch/arm/kernel/bios32.c            |    5 +-
>>  arch/x86/pci/acpi.c                 |  297 ++++++++++---------------------
>>  arch/x86/pci/bus_numa.c             |    4 +-
>>  drivers/acpi/acpi_lpss.c            |    6 +-
>>  drivers/acpi/acpi_platform.c        |    2 +-
>>  drivers/acpi/resource.c             |  333 ++++++++++++++++++++++-------------
>>  drivers/dma/acpi-dma.c              |    8 +-
>>  drivers/pci/bus.c                   |   18 +-
>>  drivers/pci/host-bridge.c           |    8 +-
>>  drivers/pci/host/pci-host-generic.c |    4 +-
>>  drivers/pci/host/pci-xgene.c        |    4 +-
>>  drivers/pci/host/pcie-xilinx.c      |    4 +-
>>  drivers/pci/probe.c                 |   10 +-
>>  drivers/pnp/pnpacpi/rsparser.c      |    4 +-
>>  include/acpi/acrestyp.h             |   49 ++++--
>>  include/linux/acpi.h                |   12 +-
>>  include/linux/ioport.h              |   25 +++
>>  include/linux/pci.h                 |    8 +-
>>  kernel/resource.c                   |   48 +++++
>>  19 files changed, 452 insertions(+), 397 deletions(-)
>>
>>
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures
  2015-01-19 14:26   ` Jiang Liu
@ 2015-01-19 15:06     ` Rafael J. Wysocki
  0 siblings, 0 replies; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-19 15:06 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Monday, January 19, 2015 10:26:00 PM Jiang Liu wrote:
> On 2015/1/12 6:38, Rafael J. Wysocki wrote:
> > On Thursday, January 08, 2015 10:32:47 AM Jiang Liu wrote:
> >> During enabling ACPI based IOAPIC hotplug, Thomas noticed some issues
> >> in ACPI resource parsing interfaces. So this is an effort to improve them.
> >>
> >> Patch 1-12 improve ACPI resource parsing interfaces and also fixes some
> >> bugs.
> >>
> >> Patch 13-19 try to share the common data structure resource_list_entry
> >> between PCI and ACPI. It may also be shared with PNP too.
> > 
> > I've looked at the patches briefly.
> > 
> > I like the changes at the general level, but there are some things I'm
> > potentially concerned about in them.  Need more time to look at them,
> > I'll do my best to do that this week while at the conference.
> Hi Rafael,
> 	Thanks for your time. Any comments about this series?

Please give me some more time.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64
  2015-01-08  2:32 ` [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64 Jiang Liu
@ 2015-01-21  0:32   ` Rafael J. Wysocki
  2015-01-22  2:32   ` Zheng, Lv
  1 sibling, 0 replies; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21  0:32 UTC (permalink / raw)
  To: Jiang Liu, Robert Moore, Lv Zheng, David Box
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Rafael J. Wysocki, Len Brown, Tony Luck, x86, linux-kernel,
	linux-pci, linux-acpi, devel

On Thursday, January 08, 2015 10:32:52 AM Jiang Liu wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> address_space64 and ext_address_space64 share substracts just at
> different offsets. To unify the parsing functions implement the two
> structs as unions of their substructs, so we can extract the shared
> data.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>

This is ACPICA code, so if we change this, either we'll diverge from the
upstream (which is highly undesirable), or we'll have to change it for
the majority of OSes on the planet (all except Windows).

Lv, Bob, David, any comments here?

> ---
>  include/acpi/acrestyp.h |   49 ++++++++++++++++++++++++++++++++++-------------
>  1 file changed, 36 insertions(+), 13 deletions(-)
> 
> diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
> index eb760ca0b2e0..307d5b2605c8 100644
> --- a/include/acpi/acrestyp.h
> +++ b/include/acpi/acrestyp.h
> @@ -326,23 +326,46 @@ struct acpi_resource_address32 {
>  	struct acpi_resource_source resource_source;
>  };
>  
> -struct acpi_resource_address64 {
> -	ACPI_RESOURCE_ADDRESS_COMMON u64 granularity;
> -	u64 minimum;
> -	u64 maximum;
> -	u64 translation_offset;
> +#define ACPI_RESOURCE_ADDRESS64_COMMON \
> +	u64 granularity;	       \
> +	u64 minimum;		       \
> +	u64 maximum;		       \
> +	u64 translation_offset;	       \
>  	u64 address_length;
> -	struct acpi_resource_source resource_source;
> +
> +struct acpi_resource_address64_common {
> +ACPI_RESOURCE_ADDRESS64_COMMON};
> +
> +struct acpi_resource_address64 {
> +	union {
> +		struct {
> +			ACPI_RESOURCE_ADDRESS_COMMON
> +			ACPI_RESOURCE_ADDRESS64_COMMON
> +			struct acpi_resource_source resource_source;
> +		};
> +		struct {
> +			struct acpi_resource_address base;
> +			struct acpi_resource_address64_common addr;
> +			struct acpi_resource_source resource_source;
> +		} common;
> +	};
>  };
>  
>  struct acpi_resource_extended_address64 {
> -	ACPI_RESOURCE_ADDRESS_COMMON u8 revision_ID;
> -	u64 granularity;
> -	u64 minimum;
> -	u64 maximum;
> -	u64 translation_offset;
> -	u64 address_length;
> -	u64 type_specific;
> +	union {
> +		struct {
> +			ACPI_RESOURCE_ADDRESS_COMMON
> +			u8 revision_ID;
> +			ACPI_RESOURCE_ADDRESS64_COMMON
> +			u64 type_specific;
> +		};
> +		struct {
> +			struct acpi_resource_address base;
> +			u8 revision_ID;
> +			struct acpi_resource_address64_common addr;
> +			u64 type_specific;
> +		} common;
> +	};
>  };
>  
>  struct acpi_resource_extended_irq {
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 08/19] ACPI: Add prefetch decoding to the address space parser
  2015-01-08  2:32 ` [RFC Patch 08/19] ACPI: Add prefetch decoding to the address space parser Jiang Liu
@ 2015-01-21  0:35   ` Rafael J. Wysocki
  2015-01-21  5:26     ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21  0:35 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Thursday, January 08, 2015 10:32:55 AM Jiang Liu wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Add support of PREFETCH attributre to ACPI address space and extended
> address space parser.

This potentially enables untested configurations which tends to uncover bugs,
so I'm concerned.

What's the possible impact of this?

> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  drivers/acpi/resource.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index a56a64164410..abe3a29ad802 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -200,6 +200,9 @@ static bool acpi_decode_space(struct resource *res,
>  	if (base->producer_consumer == ACPI_PRODUCER)
>  		res->flags |= IORESOURCE_WINDOW;
>  
> +	if (base->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> +		res->flags |= IORESOURCE_PREFETCH;
> +
>  	return !(res->flags & IORESOURCE_DISABLED);
>  }
>  
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 09/19] ACPI: Fix a bug in parsing ACPI Memroy24 resource
  2015-01-08  2:32 ` [RFC Patch 09/19] ACPI: Fix a bug in parsing ACPI Memroy24 resource Jiang Liu
@ 2015-01-21  0:42   ` Rafael J. Wysocki
  2015-01-21  2:15     ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21  0:42 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Thursday, January 08, 2015 10:32:56 AM Jiang Liu wrote:
> According to ACPI spec 5, section 6.4.3.1 "24-Bit Memory Range Descriptor",
> minimum, maximum and address_length field in struct acpi_resource_memory24
> is in granularity of 256-bytes. So shift 8-bit left to get correct address.

Are you sure about this?

I'm reading ACPI 5.1 ATM and (on page 316) it only says about the range length
being in 256 byte blocks.

> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  drivers/acpi/resource.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index abe3a29ad802..f4aeef22a9d8 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -90,8 +90,8 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
>  	switch (ares->type) {
>  	case ACPI_RESOURCE_TYPE_MEMORY24:
>  		memory24 = &ares->data.memory24;
> -		acpi_dev_get_memresource(res, memory24->minimum,
> -					 memory24->address_length,
> +		acpi_dev_get_memresource(res, memory24->minimum << 8,
> +					 memory24->address_length << 8,
>  					 memory24->write_protect);
>  		break;
>  	case ACPI_RESOURCE_TYPE_MEMORY32:
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 12/19] ACPI: Enforce stricter checks for address space descriptors
  2015-01-08  2:32 ` [RFC Patch 12/19] ACPI: Enforce stricter checks for address space descriptors Jiang Liu
@ 2015-01-21  0:45   ` Rafael J. Wysocki
  2015-01-21  2:18     ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21  0:45 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Thursday, January 08, 2015 10:32:59 AM Jiang Liu wrote:
> Enforce stricter checks for address space descriptors according to
> ACPI spec.

So is the spec the only reason for doing this?  If so, I'd say don't.

> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  drivers/acpi/resource.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 26b47f1da523..e82149e44347 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -192,6 +192,14 @@ static bool acpi_decode_space(struct resource *res,
>  	bool wp = base->info.mem.write_protect;
>  	u64 len = addr->address_length;
>  
> +	/*
> +	 * Filter out invalid descriptor according to ACPI Spec 5.0, section
> +	 * 6.4.3.5 Address Space Resource Descriptors.
> +	 */
> +	if ((base->min_address_fixed != base->max_address_fixed && len) ||
> +	    (base->min_address_fixed && base->max_address_fixed && !len))
> +		return false;
> +
>  	res->start = addr->minimum;
>  	res->end = addr->maximum;
>  
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 14/19] ACPI: Translate resource into master side address for bridge window resources
  2015-01-08  2:33 ` [RFC Patch 14/19] ACPI: Translate resource into master side address for bridge window resources Jiang Liu
@ 2015-01-21  0:50   ` Rafael J. Wysocki
  2015-01-21  5:36     ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21  0:50 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Thursday, January 08, 2015 10:33:01 AM Jiang Liu wrote:
> Add translation_offset into the result address for bridge window
> resources to form the master side address.
> 
> Currently acpi_dev_resource_{ext_}address_space() are only used for
> devices instead of bridges, so it won't break current users. Later
> it will be used to support PCI host bridge drivers.
> 
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  drivers/acpi/resource.c |   14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index d3aa56674bd4..16d334a1ee25 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -203,6 +203,20 @@ static bool acpi_decode_space(struct resource *res, resource_size_t *offset,
>  	res->start = addr->minimum;
>  	res->end = addr->maximum;
>  
> +	/*
> +	 * For bridges that translate addresses across the bridge,
> +	 * translation_offset is the offset that must be added to the
> +	 * address on the secondary side to obtain the address on the
> +	 * primary side. Non-bridge devices must list 0 for all Address
> +	 * Translation offset bits.
> +	 */
> +	if (base->producer_consumer == ACPI_PRODUCER) {

OK, so the assumption is that this check is never true in the current code, right?

> +		res->start += addr->translation_offset;
> +		res->end += addr->translation_offset;
> +	} else if (addr->translation_offset) {

And won't this break anything even if so?

> +		return false;
> +	}
> +
>  	switch(base->resource_type) {
>  	case ACPI_MEMORY_RANGE:
>  		acpi_dev_memresource_flags(res, len, wp);
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry
  2015-01-08  2:33 ` [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry Jiang Liu
@ 2015-01-21  0:53   ` Rafael J. Wysocki
  2015-01-21  5:37     ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21  0:53 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Thursday, January 08, 2015 10:33:02 AM Jiang Liu wrote:
> Add field offset to struct resource_list_entry to host address space
> translation offset so it could be used to represent bridge resources.
> 
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  drivers/acpi/resource.c |   13 ++++++++-----
>  include/linux/acpi.h    |    1 +
>  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 16d334a1ee25..54204ac94f8e 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -462,7 +462,8 @@ struct res_proc_context {
>  };
>  
>  static acpi_status acpi_dev_new_resource_entry(struct resource *r,
> -					       struct res_proc_context *c)
> +					       struct res_proc_context *c,
> +					       resource_size_t offset)
>  {
>  	struct resource_list_entry *rentry;
>  
> @@ -472,6 +473,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>  		return AE_NO_MEMORY;
>  	}
>  	rentry->res = *r;
> +	rentry->offset = offset;
>  	list_add_tail(&rentry->node, c->list);
>  	c->count++;
>  	return AE_OK;
> @@ -480,6 +482,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>  static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
>  					     void *context)
>  {
> +	resource_size_t offset = 0;
>  	struct res_proc_context *c = context;
>  	struct resource r;
>  	int i;
> @@ -500,14 +503,14 @@ static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
>  
>  	if (acpi_dev_resource_memory(ares, &r)
>  	    || acpi_dev_resource_io(ares, &r)
> -	    || acpi_dev_resource_address_space(ares, &r, NULL)
> -	    || acpi_dev_resource_ext_address_space(ares, &r, NULL))
> -		return acpi_dev_new_resource_entry(&r, c);
> +	    || acpi_dev_resource_address_space(ares, &r, &offset)
> +	    || acpi_dev_resource_ext_address_space(ares, &r, &offset))
> +		return acpi_dev_new_resource_entry(&r, c, offset);
>  
>  	for (i = 0; acpi_dev_resource_interrupt(ares, i, &r); i++) {
>  		acpi_status status;
>  
> -		status = acpi_dev_new_resource_entry(&r, c);
> +		status = acpi_dev_new_resource_entry(&r, c, 0);
>  		if (ACPI_FAILURE(status))
>  			return status;
>  	}
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index bde8119f5897..fea78e772450 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -300,6 +300,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>  struct resource_list_entry {
>  	struct list_head node;
>  	struct resource res;
> +	resource_size_t offset;

Well, so instead of adding the offset thing here and there, wouldn't it be
cleaner to introduce something like

	struct ext_resource {
		sturct resource res;
		resource_size_t offset;
	};

and use struct ext_resource instead of struct resource where an offset is needed?

Just a thought ...

>  };
>  
>  void acpi_dev_free_resource_list(struct list_head *list);
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core
  2015-01-08  2:33 ` [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core Jiang Liu
@ 2015-01-21  1:10   ` Rafael J. Wysocki
  2015-01-21  6:37     ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21  1:10 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Dan Williams, Vinod Koul, Vivek Goyal, Thierry Reding,
	Andrew Morton, Mike Travis, Tony Luck, x86, linux-kernel,
	linux-pci, linux-acpi, dmaengine

On Thursday, January 08, 2015 10:33:04 AM Jiang Liu wrote:
> Currently ACPI, PCI and pnp all implement the same resource list
> management with different data structure. We need to transfer from
> one data structure into another when passing resources from one
> subsystem into another subsystem. Sp move struct resource_list_entry
> from ACPI into resource core, so it could be reused by different
> subystems and avoid the data structure conversion.
> 
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  drivers/acpi/acpi_lpss.c     |    6 +++---
>  drivers/acpi/acpi_platform.c |    2 +-
>  drivers/acpi/resource.c      |   13 ++++--------
>  drivers/dma/acpi-dma.c       |    8 +++----
>  include/linux/acpi.h         |    6 ------
>  include/linux/ioport.h       |   25 ++++++++++++++++++++++
>  kernel/resource.c            |   48 ++++++++++++++++++++++++++++++++++++++++++
>  7 files changed, 85 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index 4f3febf8a589..39b548dba70b 100644
> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c
> @@ -333,12 +333,12 @@ static int acpi_lpss_create_device(struct acpi_device *adev,
>  		goto err_out;
>  
>  	list_for_each_entry(rentry, &resource_list, node)
> -		if (resource_type(&rentry->res) == IORESOURCE_MEM) {
> +		if (resource_type(rentry->res) == IORESOURCE_MEM) {
>  			if (dev_desc->prv_size_override)
>  				pdata->mmio_size = dev_desc->prv_size_override;
>  			else
> -				pdata->mmio_size = resource_size(&rentry->res);
> -			pdata->mmio_base = ioremap(rentry->res.start,
> +				pdata->mmio_size = resource_size(rentry->res);
> +			pdata->mmio_base = ioremap(rentry->res->start,
>  						   pdata->mmio_size);
>  			break;
>  		}
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index 6ba8beb6b9d2..238e32b9cbb0 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -71,7 +71,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
>  		}
>  		count = 0;
>  		list_for_each_entry(rentry, &resource_list, node)
> -			resources[count++] = rentry->res;
> +			resources[count++] = *rentry->res;
>  
>  		acpi_dev_free_resource_list(&resource_list);
>  	}
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 8ea7c26d6915..c0dc038274d4 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -444,12 +444,7 @@ EXPORT_SYMBOL_GPL(acpi_dev_resource_interrupt);
>   */
>  void acpi_dev_free_resource_list(struct list_head *list)
>  {
> -	struct resource_list_entry *rentry, *re;
> -
> -	list_for_each_entry_safe(rentry, re, list, node) {
> -		list_del(&rentry->node);
> -		kfree(rentry);
> -	}
> +	resource_list_free_list(list);
>  }
>  EXPORT_SYMBOL_GPL(acpi_dev_free_resource_list);
>  
> @@ -467,14 +462,14 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>  {
>  	struct resource_list_entry *rentry;
>  
> -	rentry = kmalloc(sizeof(*rentry), GFP_KERNEL);
> +	rentry = resource_list_alloc(NULL, 0);
>  	if (!rentry) {
>  		c->error = -ENOMEM;
>  		return AE_NO_MEMORY;
>  	}
> -	rentry->res = *r;
> +	*rentry->res = *r;
>  	rentry->offset = offset;
> -	list_add_tail(&rentry->node, c->list);
> +	resource_list_insert(c->list, rentry, true);
>  	c->count++;
>  	return AE_OK;
>  }
> diff --git a/drivers/dma/acpi-dma.c b/drivers/dma/acpi-dma.c
> index de361a156b34..1ce84abe0924 100644
> --- a/drivers/dma/acpi-dma.c
> +++ b/drivers/dma/acpi-dma.c
> @@ -56,10 +56,10 @@ static int acpi_dma_parse_resource_group(const struct acpi_csrt_group *grp,
>  		return 0;
>  
>  	list_for_each_entry(rentry, &resource_list, node) {
> -		if (resource_type(&rentry->res) == IORESOURCE_MEM)
> -			mem = rentry->res.start;
> -		else if (resource_type(&rentry->res) == IORESOURCE_IRQ)
> -			irq = rentry->res.start;
> +		if (resource_type(rentry->res) == IORESOURCE_MEM)
> +			mem = rentry->res->start;
> +		else if (resource_type(rentry->res) == IORESOURCE_IRQ)
> +			irq = rentry->res->start;
>  	}
>  
>  	acpi_dev_free_resource_list(&resource_list);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 1df4a0211ae5..6d7f7edca22c 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -297,12 +297,6 @@ unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable);
>  bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>  				 struct resource *res);
>  
> -struct resource_list_entry {
> -	struct list_head node;
> -	struct resource res;
> -	resource_size_t offset;
> -};
> -
>  void acpi_dev_free_resource_list(struct list_head *list);
>  int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
>  			   int (*preproc)(struct acpi_resource *, void *),
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 2c5250222278..a6f4841ca40c 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -11,6 +11,7 @@
>  #ifndef __ASSEMBLY__
>  #include <linux/compiler.h>
>  #include <linux/types.h>
> +
>  /*
>   * Resources are tree-like, allowing
>   * nesting etc..
> @@ -255,6 +256,30 @@ static inline bool resource_overlaps(struct resource *r1, struct resource *r2)
>         return (r1->start <= r2->end && r1->end >= r2->start);
>  }
>  
> +/*
> + * Common resource list management data structure and interfaces to support
> + * ACPI, PNP and PCI host bridge etc.
> + */
> +struct resource_list_entry {
> +	struct list_head	node;
> +	struct resource		*res;	/* In master (CPU) address space */
> +	resource_size_t		offset;	/* Translation offset for bridge */
> +	struct resource		__res;	/* Default storage for res */
> +};
> +
> +extern struct resource_list_entry *resource_list_alloc(struct resource *res,
> +						       size_t extra_size);
> +extern void resource_list_free(struct resource_list_entry *entry);
> +extern void resource_list_insert(struct list_head *head,
> +				 struct resource_list_entry *entry, bool tail);
> +extern void resource_list_delete(struct resource_list_entry *entry);
> +extern void resource_list_free_list(struct list_head *head);
> +
> +#define resource_list_for_each_entry(entry, list)	\
> +	list_for_each_entry((entry), (list), node)
> +
> +#define resource_list_for_each_entry_safe(entry, tmp, list)	\
> +	list_for_each_entry_safe((entry), (tmp), (list), node)
>  
>  #endif /* __ASSEMBLY__ */
>  #endif	/* _LINUX_IOPORT_H */
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 0bcebffc4e77..414183809383 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -1529,6 +1529,54 @@ int iomem_is_exclusive(u64 addr)
>  	return err;
>  }
>  
> +struct resource_list_entry *resource_list_alloc(struct resource *res,
> +						size_t extra_size)

What about create_resource_list_entry()?  Less confusing surely.

> +{
> +	struct resource_list_entry *entry;
> +
> +	entry = kzalloc(sizeof(*entry) + extra_size, GFP_KERNEL);
> +	if (entry) {
> +		INIT_LIST_HEAD(&entry->node);
> +		entry->res = res ? res : &entry->__res;
> +	}
> +
> +	return entry;
> +}
> +EXPORT_SYMBOL(resource_list_alloc);
> +
> +void resource_list_free(struct resource_list_entry *entry)
> +{
> +	kfree(entry);
> +}
> +EXPORT_SYMBOL(resource_list_free);

Well, I'm not sure I like this.  The name suggests that it would free the
entire list and what's wrong with using kfree() directly on "entry" anyway?

> +
> +void resource_list_insert(struct list_head *head,
> +			  struct resource_list_entry *entry, bool tail)

I would call this resource_list_add() if anything.

Also it may be better to have two helpers, one for "add" and one for "add_tail"
(and perhaps define them as static inline?).

And why change the ordering between "head" and "entry".  That's alomost
guaranteed to confuse people.

> +{
> +	if (tail)
> +		list_add_tail(&entry->node, head);
> +	else
> +		list_add(&entry->node, head);
> +}
> +EXPORT_SYMBOL(resource_list_insert);
> +
> +void resource_list_delete(struct resource_list_entry *entry)
> +{
> +	list_del(&entry->node);
> +}
> +EXPORT_SYMBOL(resource_list_delete);

Couldn't this be a static inline)?

Or maybe we can combine the "list_del" with "kfree" in one function?

> +
> +void resource_list_free_list(struct list_head *head)
> +{
> +	struct resource_list_entry *entry, *tmp;
> +
> +	list_for_each_entry_safe(entry, tmp, head, node) {
> +		list_del(&entry->node);
> +		resource_list_free(entry);
> +	}
> +}
> +EXPORT_SYMBOL(resource_list_free_list);
> +
>  static int __init strict_iomem(char *str)
>  {
>  	if (strstr(str, "relaxed"))
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 09/19] ACPI: Fix a bug in parsing ACPI Memroy24 resource
  2015-01-21  0:42   ` Rafael J. Wysocki
@ 2015-01-21  2:15     ` Jiang Liu
  2015-01-21  2:59       ` Rafael J. Wysocki
  0 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-21  2:15 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On 2015/1/21 8:42, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:32:56 AM Jiang Liu wrote:
>> According to ACPI spec 5, section 6.4.3.1 "24-Bit Memory Range Descriptor",
>> minimum, maximum and address_length field in struct acpi_resource_memory24
>> is in granularity of 256-bytes. So shift 8-bit left to get correct address.
> 
> Are you sure about this?
> 
> I'm reading ACPI 5.1 ATM and (on page 316) it only says about the range length
> being in 256 byte blocks.
Hi Rafael,
	According to ACPI spec 5.a sec 6.4.3.1,
Byte 4, "Range minimum base address, _MIN, bits[7:0]", "Address
bits[15:8] of the minimum base memory address for which
the card may be configured."
Byte 5, "Range minimum base address, _MIN, bits[15:8]", "Address
bits[23:16] of the minimum base memory address for
which the card may be configured".
Byte 10, "Range length, _LEN, bits[7:0]", "This field contains the lower
eight bits of the memory range length. The range length provides the
length of the memory range in 256 byte blocks."
Byte 11, "Range length, _LEN, bits[15:8]", "This field contains the
upper eight bits of the memory range length. The range length field
provides the length of the memory range in 256 byte blocks."

That means _MIN defines bits[23:8] of the minimal address, and _LEN
is in granularity of 256 bytes, so shift them left by 8 bits.
Regards,
Gerry

> 
>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>> ---
>>  drivers/acpi/resource.c |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index abe3a29ad802..f4aeef22a9d8 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -90,8 +90,8 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
>>  	switch (ares->type) {
>>  	case ACPI_RESOURCE_TYPE_MEMORY24:
>>  		memory24 = &ares->data.memory24;
>> -		acpi_dev_get_memresource(res, memory24->minimum,
>> -					 memory24->address_length,
>> +		acpi_dev_get_memresource(res, memory24->minimum << 8,
>> +					 memory24->address_length << 8,
>>  					 memory24->write_protect);
>>  		break;
>>  	case ACPI_RESOURCE_TYPE_MEMORY32:
>>
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 12/19] ACPI: Enforce stricter checks for address space descriptors
  2015-01-21  0:45   ` Rafael J. Wysocki
@ 2015-01-21  2:18     ` Jiang Liu
  2015-01-21  3:01       ` Rafael J. Wysocki
  0 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-21  2:18 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On 2015/1/21 8:45, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:32:59 AM Jiang Liu wrote:
>> Enforce stricter checks for address space descriptors according to
>> ACPI spec.
> 
> So is the spec the only reason for doing this?  If so, I'd say don't.
Hi Rafael,
	Yes, it's just for spec. I will drop this patch to avoid
regressions.
Regards!
Gerry

> 
>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>> ---
>>  drivers/acpi/resource.c |    8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 26b47f1da523..e82149e44347 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -192,6 +192,14 @@ static bool acpi_decode_space(struct resource *res,
>>  	bool wp = base->info.mem.write_protect;
>>  	u64 len = addr->address_length;
>>  
>> +	/*
>> +	 * Filter out invalid descriptor according to ACPI Spec 5.0, section
>> +	 * 6.4.3.5 Address Space Resource Descriptors.
>> +	 */
>> +	if ((base->min_address_fixed != base->max_address_fixed && len) ||
>> +	    (base->min_address_fixed && base->max_address_fixed && !len))
>> +		return false;
>> +
>>  	res->start = addr->minimum;
>>  	res->end = addr->maximum;
>>  
>>
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 09/19] ACPI: Fix a bug in parsing ACPI Memroy24 resource
  2015-01-21  2:59       ` Rafael J. Wysocki
@ 2015-01-21  2:48         ` Jiang Liu
  0 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-21  2:48 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On 2015/1/21 10:59, Rafael J. Wysocki wrote:
> On Wednesday, January 21, 2015 10:15:01 AM Jiang Liu wrote:
>> On 2015/1/21 8:42, Rafael J. Wysocki wrote:
>>> On Thursday, January 08, 2015 10:32:56 AM Jiang Liu wrote:
>>>> According to ACPI spec 5, section 6.4.3.1 "24-Bit Memory Range Descriptor",
>>>> minimum, maximum and address_length field in struct acpi_resource_memory24
>>>> is in granularity of 256-bytes. So shift 8-bit left to get correct address.
>>>
>>> Are you sure about this?
>>>
>>> I'm reading ACPI 5.1 ATM and (on page 316) it only says about the range length
>>> being in 256 byte blocks.
>> Hi Rafael,
>> 	According to ACPI spec 5.a sec 6.4.3.1,
>> Byte 4, "Range minimum base address, _MIN, bits[7:0]", "Address
>> bits[15:8] of the minimum base memory address for which
>> the card may be configured."
>> Byte 5, "Range minimum base address, _MIN, bits[15:8]", "Address
>> bits[23:16] of the minimum base memory address for
>> which the card may be configured".
> 
> Ah, OK.
> 
> So bits [15:0] of the _MIN field are bits [23:8] of the address.  Tricky that.
> 
> I wonder why no problems with that have ever been reported ...
I guess nobody really makes use of this structure:(

> 
>> Byte 10, "Range length, _LEN, bits[7:0]", "This field contains the lower
>> eight bits of the memory range length. The range length provides the
>> length of the memory range in 256 byte blocks."
>> Byte 11, "Range length, _LEN, bits[15:8]", "This field contains the
>> upper eight bits of the memory range length. The range length field
>> provides the length of the memory range in 256 byte blocks."
>>
>> That means _MIN defines bits[23:8] of the minimal address, and _LEN
>> is in granularity of 256 bytes, so shift them left by 8 bits.
>> Regards,
>> Gerry
>>
>>>
>>>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>>>> ---
>>>>  drivers/acpi/resource.c |    4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>>>> index abe3a29ad802..f4aeef22a9d8 100644
>>>> --- a/drivers/acpi/resource.c
>>>> +++ b/drivers/acpi/resource.c
>>>> @@ -90,8 +90,8 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
>>>>  	switch (ares->type) {
>>>>  	case ACPI_RESOURCE_TYPE_MEMORY24:
>>>>  		memory24 = &ares->data.memory24;
>>>> -		acpi_dev_get_memresource(res, memory24->minimum,
>>>> -					 memory24->address_length,
>>>> +		acpi_dev_get_memresource(res, memory24->minimum << 8,
>>>> +					 memory24->address_length << 8,
>>>>  					 memory24->write_protect);
>>>>  		break;
>>>>  	case ACPI_RESOURCE_TYPE_MEMORY32:
>>>>
>>>
>> --
>> 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/
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 09/19] ACPI: Fix a bug in parsing ACPI Memroy24 resource
  2015-01-21  2:15     ` Jiang Liu
@ 2015-01-21  2:59       ` Rafael J. Wysocki
  2015-01-21  2:48         ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21  2:59 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Wednesday, January 21, 2015 10:15:01 AM Jiang Liu wrote:
> On 2015/1/21 8:42, Rafael J. Wysocki wrote:
> > On Thursday, January 08, 2015 10:32:56 AM Jiang Liu wrote:
> >> According to ACPI spec 5, section 6.4.3.1 "24-Bit Memory Range Descriptor",
> >> minimum, maximum and address_length field in struct acpi_resource_memory24
> >> is in granularity of 256-bytes. So shift 8-bit left to get correct address.
> > 
> > Are you sure about this?
> > 
> > I'm reading ACPI 5.1 ATM and (on page 316) it only says about the range length
> > being in 256 byte blocks.
> Hi Rafael,
> 	According to ACPI spec 5.a sec 6.4.3.1,
> Byte 4, "Range minimum base address, _MIN, bits[7:0]", "Address
> bits[15:8] of the minimum base memory address for which
> the card may be configured."
> Byte 5, "Range minimum base address, _MIN, bits[15:8]", "Address
> bits[23:16] of the minimum base memory address for
> which the card may be configured".

Ah, OK.

So bits [15:0] of the _MIN field are bits [23:8] of the address.  Tricky that.

I wonder why no problems with that have ever been reported ...

> Byte 10, "Range length, _LEN, bits[7:0]", "This field contains the lower
> eight bits of the memory range length. The range length provides the
> length of the memory range in 256 byte blocks."
> Byte 11, "Range length, _LEN, bits[15:8]", "This field contains the
> upper eight bits of the memory range length. The range length field
> provides the length of the memory range in 256 byte blocks."
> 
> That means _MIN defines bits[23:8] of the minimal address, and _LEN
> is in granularity of 256 bytes, so shift them left by 8 bits.
> Regards,
> Gerry
> 
> > 
> >> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> >> ---
> >>  drivers/acpi/resource.c |    4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> >> index abe3a29ad802..f4aeef22a9d8 100644
> >> --- a/drivers/acpi/resource.c
> >> +++ b/drivers/acpi/resource.c
> >> @@ -90,8 +90,8 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
> >>  	switch (ares->type) {
> >>  	case ACPI_RESOURCE_TYPE_MEMORY24:
> >>  		memory24 = &ares->data.memory24;
> >> -		acpi_dev_get_memresource(res, memory24->minimum,
> >> -					 memory24->address_length,
> >> +		acpi_dev_get_memresource(res, memory24->minimum << 8,
> >> +					 memory24->address_length << 8,
> >>  					 memory24->write_protect);
> >>  		break;
> >>  	case ACPI_RESOURCE_TYPE_MEMORY32:
> >>
> > 
> --
> 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/

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 12/19] ACPI: Enforce stricter checks for address space descriptors
  2015-01-21  2:18     ` Jiang Liu
@ 2015-01-21  3:01       ` Rafael J. Wysocki
  0 siblings, 0 replies; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21  3:01 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Wednesday, January 21, 2015 10:18:25 AM Jiang Liu wrote:
> On 2015/1/21 8:45, Rafael J. Wysocki wrote:
> > On Thursday, January 08, 2015 10:32:59 AM Jiang Liu wrote:
> >> Enforce stricter checks for address space descriptors according to
> >> ACPI spec.
> > 
> > So is the spec the only reason for doing this?  If so, I'd say don't.
> Hi Rafael,
> 	Yes, it's just for spec. I will drop this patch to avoid
> regressions.

A debug message covering that may be useful, though, in case things don't
work and this is the reason.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 08/19] ACPI: Add prefetch decoding to the address space parser
  2015-01-21  0:35   ` Rafael J. Wysocki
@ 2015-01-21  5:26     ` Jiang Liu
  2015-01-21 14:48       ` Rafael J. Wysocki
  0 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-21  5:26 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On 2015/1/21 8:35, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:32:55 AM Jiang Liu wrote:
>> From: Thomas Gleixner <tglx@linutronix.de>
>>
>> Add support of PREFETCH attributre to ACPI address space and extended
>> address space parser.
> 
> This potentially enables untested configurations which tends to uncover bugs,
> so I'm concerned.
> 
> What's the possible impact of this?
Hi Rafael,
	I have analyzed all call sites related to this change, most
users just care about resource type(IO, MEM, IRQ etc) and ignore
the prefetch property. Seems only PCI subsystem cares about PREFETCH.
Regards,
Gerry

> 
>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>> ---
>>  drivers/acpi/resource.c |    3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index a56a64164410..abe3a29ad802 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -200,6 +200,9 @@ static bool acpi_decode_space(struct resource *res,
>>  	if (base->producer_consumer == ACPI_PRODUCER)
>>  		res->flags |= IORESOURCE_WINDOW;
>>  
>> +	if (base->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
>> +		res->flags |= IORESOURCE_PREFETCH;
>> +
>>  	return !(res->flags & IORESOURCE_DISABLED);
>>  }
>>  
>>
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 14/19] ACPI: Translate resource into master side address for bridge window resources
  2015-01-21  0:50   ` Rafael J. Wysocki
@ 2015-01-21  5:36     ` Jiang Liu
  2015-01-21 14:48       ` Rafael J. Wysocki
  0 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-21  5:36 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On 2015/1/21 8:50, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:33:01 AM Jiang Liu wrote:
>> Add translation_offset into the result address for bridge window
>> resources to form the master side address.
>>
>> Currently acpi_dev_resource_{ext_}address_space() are only used for
>> devices instead of bridges, so it won't break current users. Later
>> it will be used to support PCI host bridge drivers.
>>
>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>> ---
>>  drivers/acpi/resource.c |   14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index d3aa56674bd4..16d334a1ee25 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -203,6 +203,20 @@ static bool acpi_decode_space(struct resource *res, resource_size_t *offset,
>>  	res->start = addr->minimum;
>>  	res->end = addr->maximum;
>>  
>> +	/*
>> +	 * For bridges that translate addresses across the bridge,
>> +	 * translation_offset is the offset that must be added to the
>> +	 * address on the secondary side to obtain the address on the
>> +	 * primary side. Non-bridge devices must list 0 for all Address
>> +	 * Translation offset bits.
>> +	 */
>> +	if (base->producer_consumer == ACPI_PRODUCER) {
> 
> OK, so the assumption is that this check is never true in the current code, right?
Yes.
> 
>> +		res->start += addr->translation_offset;
>> +		res->end += addr->translation_offset;
>> +	} else if (addr->translation_offset) {
> 
> And won't this break anything even if so?
I'm trying to follow the spec, how about giving a warning here
instead of failure?
Regards!
Gerry
> 
>> +		return false;
>> +	}
>> +
>>  	switch(base->resource_type) {
>>  	case ACPI_MEMORY_RANGE:
>>  		acpi_dev_memresource_flags(res, len, wp);
>>
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry
  2015-01-21  0:53   ` Rafael J. Wysocki
@ 2015-01-21  5:37     ` Jiang Liu
  2015-01-21 14:47       ` Rafael J. Wysocki
  0 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-21  5:37 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On 2015/1/21 8:53, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:33:02 AM Jiang Liu wrote:
>> Add field offset to struct resource_list_entry to host address space
>> translation offset so it could be used to represent bridge resources.
>>
>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>> ---
>>  drivers/acpi/resource.c |   13 ++++++++-----
>>  include/linux/acpi.h    |    1 +
>>  2 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 16d334a1ee25..54204ac94f8e 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -462,7 +462,8 @@ struct res_proc_context {
>>  };
>>  
>>  static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>> -					       struct res_proc_context *c)
>> +					       struct res_proc_context *c,
>> +					       resource_size_t offset)
>>  {
>>  	struct resource_list_entry *rentry;
>>  
>> @@ -472,6 +473,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>>  		return AE_NO_MEMORY;
>>  	}
>>  	rentry->res = *r;
>> +	rentry->offset = offset;
>>  	list_add_tail(&rentry->node, c->list);
>>  	c->count++;
>>  	return AE_OK;
>> @@ -480,6 +482,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>>  static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
>>  					     void *context)
>>  {
>> +	resource_size_t offset = 0;
>>  	struct res_proc_context *c = context;
>>  	struct resource r;
>>  	int i;
>> @@ -500,14 +503,14 @@ static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
>>  
>>  	if (acpi_dev_resource_memory(ares, &r)
>>  	    || acpi_dev_resource_io(ares, &r)
>> -	    || acpi_dev_resource_address_space(ares, &r, NULL)
>> -	    || acpi_dev_resource_ext_address_space(ares, &r, NULL))
>> -		return acpi_dev_new_resource_entry(&r, c);
>> +	    || acpi_dev_resource_address_space(ares, &r, &offset)
>> +	    || acpi_dev_resource_ext_address_space(ares, &r, &offset))
>> +		return acpi_dev_new_resource_entry(&r, c, offset);
>>  
>>  	for (i = 0; acpi_dev_resource_interrupt(ares, i, &r); i++) {
>>  		acpi_status status;
>>  
>> -		status = acpi_dev_new_resource_entry(&r, c);
>> +		status = acpi_dev_new_resource_entry(&r, c, 0);
>>  		if (ACPI_FAILURE(status))
>>  			return status;
>>  	}
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index bde8119f5897..fea78e772450 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -300,6 +300,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>>  struct resource_list_entry {
>>  	struct list_head node;
>>  	struct resource res;
>> +	resource_size_t offset;
> 
> Well, so instead of adding the offset thing here and there, wouldn't it be
> cleaner to introduce something like
> 
> 	struct ext_resource {
> 		sturct resource res;
> 		resource_size_t offset;
> 	};
> 
> and use struct ext_resource instead of struct resource where an offset is needed?
> 
> Just a thought ...
Hi Rafael,
	Following patches will achieve this by sharing struct resource_list_entry.
Regards!
Gerry
> 
>>  };
>>  
>>  void acpi_dev_free_resource_list(struct list_head *list);
>>
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core
  2015-01-21  1:10   ` Rafael J. Wysocki
@ 2015-01-21  6:37     ` Jiang Liu
  2015-01-21  9:43       ` Thomas Gleixner
  0 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-21  6:37 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Dan Williams, Vinod Koul, Vivek Goyal, Thierry Reding,
	Andrew Morton, Mike Travis, Tony Luck, x86, linux-kernel,
	linux-pci, linux-acpi, dmaengine

On 2015/1/21 9:10, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:33:04 AM Jiang Liu wrote:
<snit>
>> diff --git a/kernel/resource.c b/kernel/resource.c
>> index 0bcebffc4e77..414183809383 100644
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
>> @@ -1529,6 +1529,54 @@ int iomem_is_exclusive(u64 addr)
>>  	return err;
>>  }
>>  
>> +struct resource_list_entry *resource_list_alloc(struct resource *res,
>> +						size_t extra_size)
> 
> What about create_resource_list_entry()?  Less confusing surely.
Sure, I will rename it as resource_list_create_entry().

> 
>> +{
>> +	struct resource_list_entry *entry;
>> +
>> +	entry = kzalloc(sizeof(*entry) + extra_size, GFP_KERNEL);
>> +	if (entry) {
>> +		INIT_LIST_HEAD(&entry->node);
>> +		entry->res = res ? res : &entry->__res;
>> +	}
>> +
>> +	return entry;
>> +}
>> +EXPORT_SYMBOL(resource_list_alloc);
>> +
>> +void resource_list_free(struct resource_list_entry *entry)
>> +{
>> +	kfree(entry);
>> +}
>> +EXPORT_SYMBOL(resource_list_free);
> 
> Well, I'm not sure I like this.  The name suggests that it would free the
> entire list and what's wrong with using kfree() directly on "entry" anyway?
I just want to make interface symmetric. We may also support some type
of callback when freeing resources in future.

> 
>> +
>> +void resource_list_insert(struct list_head *head,
>> +			  struct resource_list_entry *entry, bool tail)
> 
> I would call this resource_list_add() if anything.
> 
> Also it may be better to have two helpers, one for "add" and one for "add_tail"
> (and perhaps define them as static inline?).
We can't use inline functions here because that needs pulling list.h
into ioport.h, then causing building issues to header inclusion order.

> 
> And why change the ordering between "head" and "entry".  That's alomost
> guaranteed to confuse people.
My fault, will change in next version.
> 
>> +{
>> +	if (tail)
>> +		list_add_tail(&entry->node, head);
>> +	else
>> +		list_add(&entry->node, head);
>> +}
>> +EXPORT_SYMBOL(resource_list_insert);
>> +
>> +void resource_list_delete(struct resource_list_entry *entry)
>> +{
>> +	list_del(&entry->node);
>> +}
>> +EXPORT_SYMBOL(resource_list_delete);
> 
> Couldn't this be a static inline)?
Inline will cause header file inclusion order issue:(

> 
> Or maybe we can combine the "list_del" with "kfree" in one function?
There are callers which need separating list_del from kfree,
so exported two interfaces here. Will add another helper interface
resource_list_destroy_entry().

Regards!
Gerry
> 
>> +
>> +void resource_list_free_list(struct list_head *head)
>> +{
>> +	struct resource_list_entry *entry, *tmp;
>> +
>> +	list_for_each_entry_safe(entry, tmp, head, node) {
>> +		list_del(&entry->node);
>> +		resource_list_free(entry);
>> +	}
>> +}
>> +EXPORT_SYMBOL(resource_list_free_list);
>> +
>>  static int __init strict_iomem(char *str)
>>  {
>>  	if (strstr(str, "relaxed"))
>>
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core
  2015-01-21  6:37     ` Jiang Liu
@ 2015-01-21  9:43       ` Thomas Gleixner
  2015-01-21 12:32         ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Thomas Gleixner @ 2015-01-21  9:43 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Rafael J. Wysocki, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Dan Williams, Vinod Koul, Vivek Goyal, Thierry Reding,
	Andrew Morton, Mike Travis, Tony Luck, x86, linux-kernel,
	linux-pci, linux-acpi, dmaengine

On Wed, 21 Jan 2015, Jiang Liu wrote:
> On 2015/1/21 9:10, Rafael J. Wysocki wrote:
> >> +
> >> +void resource_list_insert(struct list_head *head,
> >> +			  struct resource_list_entry *entry, bool tail)
> > 
> > I would call this resource_list_add() if anything.
> > 
> > Also it may be better to have two helpers, one for "add" and one for "add_tail"
> > (and perhaps define them as static inline?).
> We can't use inline functions here because that needs pulling list.h
> into ioport.h, then causing building issues to header inclusion order.

Create a new header file to avoid the circular dependencies then.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core
  2015-01-21  9:43       ` Thomas Gleixner
@ 2015-01-21 12:32         ` Jiang Liu
  0 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-21 12:32 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Rafael J. Wysocki, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Dan Williams, Vinod Koul, Vivek Goyal, Thierry Reding,
	Andrew Morton, Mike Travis, Tony Luck, x86, linux-kernel,
	linux-pci, linux-acpi, dmaengine

On 2015/1/21 17:43, Thomas Gleixner wrote:
> On Wed, 21 Jan 2015, Jiang Liu wrote:
>> On 2015/1/21 9:10, Rafael J. Wysocki wrote:
>>>> +
>>>> +void resource_list_insert(struct list_head *head,
>>>> +			  struct resource_list_entry *entry, bool tail)
>>>
>>> I would call this resource_list_add() if anything.
>>>
>>> Also it may be better to have two helpers, one for "add" and one for "add_tail"
>>> (and perhaps define them as static inline?).
>> We can't use inline functions here because that needs pulling list.h
>> into ioport.h, then causing building issues to header inclusion order.
> 
> Create a new header file to avoid the circular dependencies then.
Great, create include/linux/resource_list.h for it so we could
inline those simple functions.
Regards,
Gerry

> 
> Thanks,
> 
> 	tglx
> --
> 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/
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry
  2015-01-21  5:37     ` Jiang Liu
@ 2015-01-21 14:47       ` Rafael J. Wysocki
  2015-01-21 15:01         ` Jiang Liu
  0 siblings, 1 reply; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21 14:47 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Wednesday, January 21, 2015 01:37:40 PM Jiang Liu wrote:
> On 2015/1/21 8:53, Rafael J. Wysocki wrote:
> > On Thursday, January 08, 2015 10:33:02 AM Jiang Liu wrote:
> >> Add field offset to struct resource_list_entry to host address space
> >> translation offset so it could be used to represent bridge resources.
> >>
> >> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> >> ---
> >>  drivers/acpi/resource.c |   13 ++++++++-----
> >>  include/linux/acpi.h    |    1 +
> >>  2 files changed, 9 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> >> index 16d334a1ee25..54204ac94f8e 100644
> >> --- a/drivers/acpi/resource.c
> >> +++ b/drivers/acpi/resource.c
> >> @@ -462,7 +462,8 @@ struct res_proc_context {
> >>  };
> >>  
> >>  static acpi_status acpi_dev_new_resource_entry(struct resource *r,
> >> -					       struct res_proc_context *c)
> >> +					       struct res_proc_context *c,
> >> +					       resource_size_t offset)
> >>  {
> >>  	struct resource_list_entry *rentry;
> >>  
> >> @@ -472,6 +473,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
> >>  		return AE_NO_MEMORY;
> >>  	}
> >>  	rentry->res = *r;
> >> +	rentry->offset = offset;
> >>  	list_add_tail(&rentry->node, c->list);
> >>  	c->count++;
> >>  	return AE_OK;
> >> @@ -480,6 +482,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
> >>  static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
> >>  					     void *context)
> >>  {
> >> +	resource_size_t offset = 0;
> >>  	struct res_proc_context *c = context;
> >>  	struct resource r;
> >>  	int i;
> >> @@ -500,14 +503,14 @@ static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
> >>  
> >>  	if (acpi_dev_resource_memory(ares, &r)
> >>  	    || acpi_dev_resource_io(ares, &r)
> >> -	    || acpi_dev_resource_address_space(ares, &r, NULL)
> >> -	    || acpi_dev_resource_ext_address_space(ares, &r, NULL))
> >> -		return acpi_dev_new_resource_entry(&r, c);
> >> +	    || acpi_dev_resource_address_space(ares, &r, &offset)
> >> +	    || acpi_dev_resource_ext_address_space(ares, &r, &offset))
> >> +		return acpi_dev_new_resource_entry(&r, c, offset);
> >>  
> >>  	for (i = 0; acpi_dev_resource_interrupt(ares, i, &r); i++) {
> >>  		acpi_status status;
> >>  
> >> -		status = acpi_dev_new_resource_entry(&r, c);
> >> +		status = acpi_dev_new_resource_entry(&r, c, 0);
> >>  		if (ACPI_FAILURE(status))
> >>  			return status;
> >>  	}
> >> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> >> index bde8119f5897..fea78e772450 100644
> >> --- a/include/linux/acpi.h
> >> +++ b/include/linux/acpi.h
> >> @@ -300,6 +300,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> >>  struct resource_list_entry {
> >>  	struct list_head node;
> >>  	struct resource res;
> >> +	resource_size_t offset;
> > 
> > Well, so instead of adding the offset thing here and there, wouldn't it be
> > cleaner to introduce something like
> > 
> > 	struct ext_resource {
> > 		sturct resource res;
> > 		resource_size_t offset;
> > 	};
> > 
> > and use struct ext_resource instead of struct resource where an offset is needed?
> > 
> > Just a thought ...
> Hi Rafael,
> 	Following patches will achieve this by sharing struct resource_list_entry.

Well, yes, they will partially, but that still won't avoid the need to pass
offset (or pointers to that) to several functions separately if I'm not
mistaken.  Which is kind of ugly.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 14/19] ACPI: Translate resource into master side address for bridge window resources
  2015-01-21  5:36     ` Jiang Liu
@ 2015-01-21 14:48       ` Rafael J. Wysocki
  0 siblings, 0 replies; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21 14:48 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Wednesday, January 21, 2015 01:36:21 PM Jiang Liu wrote:
> On 2015/1/21 8:50, Rafael J. Wysocki wrote:
> > On Thursday, January 08, 2015 10:33:01 AM Jiang Liu wrote:
> >> Add translation_offset into the result address for bridge window
> >> resources to form the master side address.
> >>
> >> Currently acpi_dev_resource_{ext_}address_space() are only used for
> >> devices instead of bridges, so it won't break current users. Later
> >> it will be used to support PCI host bridge drivers.
> >>
> >> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> >> ---
> >>  drivers/acpi/resource.c |   14 ++++++++++++++
> >>  1 file changed, 14 insertions(+)
> >>
> >> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> >> index d3aa56674bd4..16d334a1ee25 100644
> >> --- a/drivers/acpi/resource.c
> >> +++ b/drivers/acpi/resource.c
> >> @@ -203,6 +203,20 @@ static bool acpi_decode_space(struct resource *res, resource_size_t *offset,
> >>  	res->start = addr->minimum;
> >>  	res->end = addr->maximum;
> >>  
> >> +	/*
> >> +	 * For bridges that translate addresses across the bridge,
> >> +	 * translation_offset is the offset that must be added to the
> >> +	 * address on the secondary side to obtain the address on the
> >> +	 * primary side. Non-bridge devices must list 0 for all Address
> >> +	 * Translation offset bits.
> >> +	 */
> >> +	if (base->producer_consumer == ACPI_PRODUCER) {
> > 
> > OK, so the assumption is that this check is never true in the current code, right?
> Yes.
> > 
> >> +		res->start += addr->translation_offset;
> >> +		res->end += addr->translation_offset;
> >> +	} else if (addr->translation_offset) {
> > 
> > And won't this break anything even if so?
> I'm trying to follow the spec, how about giving a warning here
> instead of failure?

Yes, that would be safer IMO.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 08/19] ACPI: Add prefetch decoding to the address space parser
  2015-01-21  5:26     ` Jiang Liu
@ 2015-01-21 14:48       ` Rafael J. Wysocki
  0 siblings, 0 replies; 51+ messages in thread
From: Rafael J. Wysocki @ 2015-01-21 14:48 UTC (permalink / raw)
  To: Jiang Liu
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On Wednesday, January 21, 2015 01:26:25 PM Jiang Liu wrote:
> On 2015/1/21 8:35, Rafael J. Wysocki wrote:
> > On Thursday, January 08, 2015 10:32:55 AM Jiang Liu wrote:
> >> From: Thomas Gleixner <tglx@linutronix.de>
> >>
> >> Add support of PREFETCH attributre to ACPI address space and extended
> >> address space parser.
> > 
> > This potentially enables untested configurations which tends to uncover bugs,
> > so I'm concerned.
> > 
> > What's the possible impact of this?
> Hi Rafael,
> 	I have analyzed all call sites related to this change, most
> users just care about resource type(IO, MEM, IRQ etc) and ignore
> the prefetch property. Seems only PCI subsystem cares about PREFETCH.

OK


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry
  2015-01-21 14:47       ` Rafael J. Wysocki
@ 2015-01-21 15:01         ` Jiang Liu
  0 siblings, 0 replies; 51+ messages in thread
From: Jiang Liu @ 2015-01-21 15:01 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Bjorn Helgaas, Yinghai Lu, Borislav Petkov,
	Len Brown, Tony Luck, x86, linux-kernel, linux-pci, linux-acpi

On 2015/1/21 22:47, Rafael J. Wysocki wrote:
> On Wednesday, January 21, 2015 01:37:40 PM Jiang Liu wrote:
>> On 2015/1/21 8:53, Rafael J. Wysocki wrote:
>>> On Thursday, January 08, 2015 10:33:02 AM Jiang Liu wrote:
>>>> Add field offset to struct resource_list_entry to host address space
>>>> translation offset so it could be used to represent bridge resources.
>>>>
>>>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>>>> ---
>>>>  drivers/acpi/resource.c |   13 ++++++++-----
>>>>  include/linux/acpi.h    |    1 +
>>>>  2 files changed, 9 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>>>> index 16d334a1ee25..54204ac94f8e 100644
>>>> --- a/drivers/acpi/resource.c
>>>> +++ b/drivers/acpi/resource.c
>>>> @@ -462,7 +462,8 @@ struct res_proc_context {
>>>>  };
>>>>  
>>>>  static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>>>> -					       struct res_proc_context *c)
>>>> +					       struct res_proc_context *c,
>>>> +					       resource_size_t offset)
>>>>  {
>>>>  	struct resource_list_entry *rentry;
>>>>  
>>>> @@ -472,6 +473,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>>>>  		return AE_NO_MEMORY;
>>>>  	}
>>>>  	rentry->res = *r;
>>>> +	rentry->offset = offset;
>>>>  	list_add_tail(&rentry->node, c->list);
>>>>  	c->count++;
>>>>  	return AE_OK;
>>>> @@ -480,6 +482,7 @@ static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>>>>  static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
>>>>  					     void *context)
>>>>  {
>>>> +	resource_size_t offset = 0;
>>>>  	struct res_proc_context *c = context;
>>>>  	struct resource r;
>>>>  	int i;
>>>> @@ -500,14 +503,14 @@ static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
>>>>  
>>>>  	if (acpi_dev_resource_memory(ares, &r)
>>>>  	    || acpi_dev_resource_io(ares, &r)
>>>> -	    || acpi_dev_resource_address_space(ares, &r, NULL)
>>>> -	    || acpi_dev_resource_ext_address_space(ares, &r, NULL))
>>>> -		return acpi_dev_new_resource_entry(&r, c);
>>>> +	    || acpi_dev_resource_address_space(ares, &r, &offset)
>>>> +	    || acpi_dev_resource_ext_address_space(ares, &r, &offset))
>>>> +		return acpi_dev_new_resource_entry(&r, c, offset);
>>>>  
>>>>  	for (i = 0; acpi_dev_resource_interrupt(ares, i, &r); i++) {
>>>>  		acpi_status status;
>>>>  
>>>> -		status = acpi_dev_new_resource_entry(&r, c);
>>>> +		status = acpi_dev_new_resource_entry(&r, c, 0);
>>>>  		if (ACPI_FAILURE(status))
>>>>  			return status;
>>>>  	}
>>>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>>>> index bde8119f5897..fea78e772450 100644
>>>> --- a/include/linux/acpi.h
>>>> +++ b/include/linux/acpi.h
>>>> @@ -300,6 +300,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>>>>  struct resource_list_entry {
>>>>  	struct list_head node;
>>>>  	struct resource res;
>>>> +	resource_size_t offset;
>>>
>>> Well, so instead of adding the offset thing here and there, wouldn't it be
>>> cleaner to introduce something like
>>>
>>> 	struct ext_resource {
>>> 		sturct resource res;
>>> 		resource_size_t offset;
>>> 	};
>>>
>>> and use struct ext_resource instead of struct resource where an offset is needed?
>>>
>>> Just a thought ...
>> Hi Rafael,
>> 	Following patches will achieve this by sharing struct resource_list_entry.
> 
> Well, yes, they will partially, but that still won't avoid the need to pass
> offset (or pointers to that) to several functions separately if I'm not
> mistaken.  Which is kind of ugly.
Hi Rafael,
	Sorry, I missed your point with last reply. I have the basic
idea about how to follow your suggestion now, will do it in next
version.
Regards,
Gerry

^ permalink raw reply	[flat|nested] 51+ messages in thread

* RE: [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64
  2015-01-08  2:32 ` [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64 Jiang Liu
  2015-01-21  0:32   ` Rafael J. Wysocki
@ 2015-01-22  2:32   ` Zheng, Lv
  2015-01-22  2:57     ` Jiang Liu
  1 sibling, 1 reply; 51+ messages in thread
From: Zheng, Lv @ 2015-01-22  2:32 UTC (permalink / raw)
  To: Jiang Liu, Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas,
	Yinghai Lu, Borislav Petkov, Moore, Robert, Wysocki, Rafael J,
	Len Brown
  Cc: Luck, Tony, x86, linux-kernel, linux-pci, linux-acpi, devel

Hi, Thomas and Jiang

> From: Jiang Liu [mailto:jiang.liu@linux.intel.com]
> Sent: Thursday, January 08, 2015 10:33 AM
> 
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> address_space64 and ext_address_space64 share substracts just at
> different offsets. To unify the parsing functions implement the two
> structs as unions of their substructs, so we can extract the shared
> data.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  include/acpi/acrestyp.h |   49 ++++++++++++++++++++++++++++++++++-------------
>  1 file changed, 36 insertions(+), 13 deletions(-)
> 
> diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
> index eb760ca0b2e0..307d5b2605c8 100644
> --- a/include/acpi/acrestyp.h
> +++ b/include/acpi/acrestyp.h
> @@ -326,23 +326,46 @@ struct acpi_resource_address32 {
>  	struct acpi_resource_source resource_source;
>  };
> 
> -struct acpi_resource_address64 {
> -	ACPI_RESOURCE_ADDRESS_COMMON u64 granularity;
> -	u64 minimum;
> -	u64 maximum;
> -	u64 translation_offset;
> +#define ACPI_RESOURCE_ADDRESS64_COMMON \
> +	u64 granularity;	       \
> +	u64 minimum;		       \
> +	u64 maximum;		       \
> +	u64 translation_offset;	       \
>  	u64 address_length;
> -	struct acpi_resource_source resource_source;
> +
> +struct acpi_resource_address64_common {
> +ACPI_RESOURCE_ADDRESS64_COMMON};
> +
> +struct acpi_resource_address64 {
> +	union {
> +		struct {
> +			ACPI_RESOURCE_ADDRESS_COMMON
> +			ACPI_RESOURCE_ADDRESS64_COMMON
> +			struct acpi_resource_source resource_source;
> +		};

This looks wrong to ACPICA upstream.

> +		struct {
> +			struct acpi_resource_address base;
> +			struct acpi_resource_address64_common addr;
> +			struct acpi_resource_source resource_source;
> +		} common;
> +	};
>  };

And this.
Though anonymous structs/unions are now C11 standard, I still didn't see it used in the ACPICA upstream.
It could be a problem if someone still compiles ACPICA using old compilers.

> 
>  struct acpi_resource_extended_address64 {
> -	ACPI_RESOURCE_ADDRESS_COMMON u8 revision_ID;
> -	u64 granularity;
> -	u64 minimum;
> -	u64 maximum;
> -	u64 translation_offset;
> -	u64 address_length;
> -	u64 type_specific;
> +	union {
> +		struct {
> +			ACPI_RESOURCE_ADDRESS_COMMON
> +			u8 revision_ID;
> +			ACPI_RESOURCE_ADDRESS64_COMMON
> +			u64 type_specific;
> +		};

Ditto.

> +		struct {
> +			struct acpi_resource_address base;
> +			u8 revision_ID;
> +			struct acpi_resource_address64_common addr;
> +			u64 type_specific;
> +		} common;
> +	};

Ditto.

I think what you want is the ability to access common.addr and common.base from different resource address64 types.
So we can achieve this directly in the ACPICA upstream without using the union.

I tried this in the ACPICA upstream and the result is:
https://github.com/zetalog/acpica/commit/0f4ed510
Let me send its linuxized version after this email.

Thanks and best regards
-Lv

>  };
> 
>  struct acpi_resource_extended_irq {
> --
> 1.7.10.4


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64
  2015-01-22  2:32   ` Zheng, Lv
@ 2015-01-22  2:57     ` Jiang Liu
  2015-01-22  3:24       ` Zheng, Lv
  0 siblings, 1 reply; 51+ messages in thread
From: Jiang Liu @ 2015-01-22  2:57 UTC (permalink / raw)
  To: Zheng, Lv, Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas,
	Yinghai Lu, Borislav Petkov, Moore, Robert, Wysocki, Rafael J,
	Len Brown
  Cc: Luck, Tony, x86, linux-kernel, linux-pci, linux-acpi, devel



On 2015/1/22 10:32, Zheng, Lv wrote:
> Hi, Thomas and Jiang
> 
>> From: Jiang Liu [mailto:jiang.liu@linux.intel.com]
>> Sent: Thursday, January 08, 2015 10:33 AM
>>
>> From: Thomas Gleixner <tglx@linutronix.de>
>>
>> address_space64 and ext_address_space64 share substracts just at
>> different offsets. To unify the parsing functions implement the two
>> structs as unions of their substructs, so we can extract the shared
>> data.
>>
>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>> ---
>>  include/acpi/acrestyp.h |   49 ++++++++++++++++++++++++++++++++++-------------
>>  1 file changed, 36 insertions(+), 13 deletions(-)
>>
>> diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
>> index eb760ca0b2e0..307d5b2605c8 100644
>> --- a/include/acpi/acrestyp.h
>> +++ b/include/acpi/acrestyp.h
>> @@ -326,23 +326,46 @@ struct acpi_resource_address32 {
>>  	struct acpi_resource_source resource_source;
>>  };
>>
>> -struct acpi_resource_address64 {
>> -	ACPI_RESOURCE_ADDRESS_COMMON u64 granularity;
>> -	u64 minimum;
>> -	u64 maximum;
>> -	u64 translation_offset;
>> +#define ACPI_RESOURCE_ADDRESS64_COMMON \
>> +	u64 granularity;	       \
>> +	u64 minimum;		       \
>> +	u64 maximum;		       \
>> +	u64 translation_offset;	       \
>>  	u64 address_length;
>> -	struct acpi_resource_source resource_source;
>> +
>> +struct acpi_resource_address64_common {
>> +ACPI_RESOURCE_ADDRESS64_COMMON};
>> +
>> +struct acpi_resource_address64 {
>> +	union {
>> +		struct {
>> +			ACPI_RESOURCE_ADDRESS_COMMON
>> +			ACPI_RESOURCE_ADDRESS64_COMMON
>> +			struct acpi_resource_source resource_source;
>> +		};
> 
> This looks wrong to ACPICA upstream.
> 
>> +		struct {
>> +			struct acpi_resource_address base;
>> +			struct acpi_resource_address64_common addr;
>> +			struct acpi_resource_source resource_source;
>> +		} common;
>> +	};
>>  };
> 
> And this.
> Though anonymous structs/unions are now C11 standard, I still didn't see it used in the ACPICA upstream.
> It could be a problem if someone still compiles ACPICA using old compilers.
> 
>>
>>  struct acpi_resource_extended_address64 {
>> -	ACPI_RESOURCE_ADDRESS_COMMON u8 revision_ID;
>> -	u64 granularity;
>> -	u64 minimum;
>> -	u64 maximum;
>> -	u64 translation_offset;
>> -	u64 address_length;
>> -	u64 type_specific;
>> +	union {
>> +		struct {
>> +			ACPI_RESOURCE_ADDRESS_COMMON
>> +			u8 revision_ID;
>> +			ACPI_RESOURCE_ADDRESS64_COMMON
>> +			u64 type_specific;
>> +		};
> 
> Ditto.
> 
>> +		struct {
>> +			struct acpi_resource_address base;
>> +			u8 revision_ID;
>> +			struct acpi_resource_address64_common addr;
>> +			u64 type_specific;
>> +		} common;
>> +	};
> 
> Ditto.
> 
> I think what you want is the ability to access common.addr and common.base from different resource address64 types.
> So we can achieve this directly in the ACPICA upstream without using the union.
> 
> I tried this in the ACPICA upstream and the result is:
> https://github.com/zetalog/acpica/commit/0f4ed510
> Let me send its linuxized version after this email.
Hi Lv,
	Thanks for your great support:)
	What's the normal process to propagate this patch into
linux kernel? Or how long will it take? We have another hotplug
patch set which depends on this patch set, then depends on this
ACPICA core change.
Regards!
Gerry
> 
> Thanks and best regards
> -Lv
> 
>>  };
>>
>>  struct acpi_resource_extended_irq {
>> --
>> 1.7.10.4
> 

^ permalink raw reply	[flat|nested] 51+ messages in thread

* RE: [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64
  2015-01-22  2:57     ` Jiang Liu
@ 2015-01-22  3:24       ` Zheng, Lv
  2015-01-22 10:38         ` Thomas Gleixner
  0 siblings, 1 reply; 51+ messages in thread
From: Zheng, Lv @ 2015-01-22  3:24 UTC (permalink / raw)
  To: Jiang Liu, Rafael J. Wysocki, Thomas Gleixner, Bjorn Helgaas,
	Yinghai Lu, Borislav Petkov, Moore, Robert, Wysocki, Rafael J,
	Len Brown
  Cc: Luck, Tony, x86, linux-kernel, linux-pci, linux-acpi, devel

Hi, Gerry

> From: Jiang Liu [mailto:jiang.liu@linux.intel.com]
> Sent: Thursday, January 22, 2015 10:58 AM
> 
> On 2015/1/22 10:32, Zheng, Lv wrote:
> > Hi, Thomas and Jiang
> >
> >> From: Jiang Liu [mailto:jiang.liu@linux.intel.com]
> >> Sent: Thursday, January 08, 2015 10:33 AM
> >>
> >> From: Thomas Gleixner <tglx@linutronix.de>
> >>
> >> address_space64 and ext_address_space64 share substracts just at
> >> different offsets. To unify the parsing functions implement the two
> >> structs as unions of their substructs, so we can extract the shared
> >> data.
> >>
> >> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> >> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> >> ---
> >>  include/acpi/acrestyp.h |   49 ++++++++++++++++++++++++++++++++++-------------
> >>  1 file changed, 36 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
> >> index eb760ca0b2e0..307d5b2605c8 100644
> >> --- a/include/acpi/acrestyp.h
> >> +++ b/include/acpi/acrestyp.h
> >> @@ -326,23 +326,46 @@ struct acpi_resource_address32 {
> >>  	struct acpi_resource_source resource_source;
> >>  };
> >>
> >> -struct acpi_resource_address64 {
> >> -	ACPI_RESOURCE_ADDRESS_COMMON u64 granularity;
> >> -	u64 minimum;
> >> -	u64 maximum;
> >> -	u64 translation_offset;
> >> +#define ACPI_RESOURCE_ADDRESS64_COMMON \
> >> +	u64 granularity;	       \
> >> +	u64 minimum;		       \
> >> +	u64 maximum;		       \
> >> +	u64 translation_offset;	       \
> >>  	u64 address_length;
> >> -	struct acpi_resource_source resource_source;
> >> +
> >> +struct acpi_resource_address64_common {
> >> +ACPI_RESOURCE_ADDRESS64_COMMON};
> >> +
> >> +struct acpi_resource_address64 {
> >> +	union {
> >> +		struct {
> >> +			ACPI_RESOURCE_ADDRESS_COMMON
> >> +			ACPI_RESOURCE_ADDRESS64_COMMON
> >> +			struct acpi_resource_source resource_source;
> >> +		};
> >
> > This looks wrong to ACPICA upstream.
> >
> >> +		struct {
> >> +			struct acpi_resource_address base;
> >> +			struct acpi_resource_address64_common addr;
> >> +			struct acpi_resource_source resource_source;
> >> +		} common;
> >> +	};
> >>  };
> >
> > And this.
> > Though anonymous structs/unions are now C11 standard, I still didn't see it used in the ACPICA upstream.
> > It could be a problem if someone still compiles ACPICA using old compilers.
> >
> >>
> >>  struct acpi_resource_extended_address64 {
> >> -	ACPI_RESOURCE_ADDRESS_COMMON u8 revision_ID;
> >> -	u64 granularity;
> >> -	u64 minimum;
> >> -	u64 maximum;
> >> -	u64 translation_offset;
> >> -	u64 address_length;
> >> -	u64 type_specific;
> >> +	union {
> >> +		struct {
> >> +			ACPI_RESOURCE_ADDRESS_COMMON
> >> +			u8 revision_ID;
> >> +			ACPI_RESOURCE_ADDRESS64_COMMON
> >> +			u64 type_specific;
> >> +		};
> >
> > Ditto.
> >
> >> +		struct {
> >> +			struct acpi_resource_address base;
> >> +			u8 revision_ID;
> >> +			struct acpi_resource_address64_common addr;
> >> +			u64 type_specific;
> >> +		} common;
> >> +	};
> >
> > Ditto.
> >
> > I think what you want is the ability to access common.addr and common.base from different resource address64 types.
> > So we can achieve this directly in the ACPICA upstream without using the union.
> >
> > I tried this in the ACPICA upstream and the result is:
> > https://github.com/zetalog/acpica/commit/0f4ed510
> > Let me send its linuxized version after this email.
> Hi Lv,
> 	Thanks for your great support:)
> 	What's the normal process to propagate this patch into
> linux kernel? Or how long will it take? We have another hotplug
> patch set which depends on this patch set, then depends on this
> ACPICA core change.

There won't be divergences if things are proceeded in this way:
If we can reach an agreement on the linuxized version, then it can be merged directly by Rafael.
And I'll zap it from the ACPICA release series.

Thanks and best regards
-Lv

> Regards!
> Gerry
> >
> > Thanks and best regards
> > -Lv
> >
> >>  };
> >>
> >>  struct acpi_resource_extended_irq {
> >> --
> >> 1.7.10.4
> >

^ permalink raw reply	[flat|nested] 51+ messages in thread

* RE: [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64
  2015-01-22  3:24       ` Zheng, Lv
@ 2015-01-22 10:38         ` Thomas Gleixner
  0 siblings, 0 replies; 51+ messages in thread
From: Thomas Gleixner @ 2015-01-22 10:38 UTC (permalink / raw)
  To: Zheng, Lv
  Cc: Jiang Liu, Rafael J. Wysocki, Bjorn Helgaas, Yinghai Lu,
	Borislav Petkov, Moore, Robert, Wysocki, Rafael J, Len Brown,
	Luck, Tony, x86, linux-kernel, linux-pci, linux-acpi, devel

On Thu, 22 Jan 2015, Zheng, Lv wrote:
> If we can reach an agreement on the linuxized version, then it can
> be merged directly by Rafael.  And I'll zap it from the ACPICA
> release series.

Fine with me.

Thanks,

	tglx


^ permalink raw reply	[flat|nested] 51+ messages in thread

end of thread, other threads:[~2015-01-22 10:39 UTC | newest]

Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-08  2:32 [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Jiang Liu
2015-01-08  2:32 ` [RFC Patch 01/19] ACPI: Remove redundant check in function acpi_dev_resource_address_space() Jiang Liu
2015-01-08  2:32 ` [RFC Patch 02/19] ACPI: Implement proper length checks for mem resources Jiang Liu
2015-01-08  2:32 ` [RFC Patch 03/19] ACPI: Use the length check for io resources as well Jiang Liu
2015-01-08  2:32 ` [RFC Patch 04/19] ACPI: Let the parser return false for disabled resources Jiang Liu
2015-01-08  2:32 ` [RFC Patch 05/19] ACPI: Provide union for address_space64 and ext_address_space64 Jiang Liu
2015-01-21  0:32   ` Rafael J. Wysocki
2015-01-22  2:32   ` Zheng, Lv
2015-01-22  2:57     ` Jiang Liu
2015-01-22  3:24       ` Zheng, Lv
2015-01-22 10:38         ` Thomas Gleixner
2015-01-08  2:32 ` [RFC Patch 06/19] ACPI: Unify the parsing of address_space and ext_address_space Jiang Liu
2015-01-08  2:32 ` [RFC Patch 07/19] ACPI: Move the window flag logic to the combined parser Jiang Liu
2015-01-08  2:32 ` [RFC Patch 08/19] ACPI: Add prefetch decoding to the address space parser Jiang Liu
2015-01-21  0:35   ` Rafael J. Wysocki
2015-01-21  5:26     ` Jiang Liu
2015-01-21 14:48       ` Rafael J. Wysocki
2015-01-08  2:32 ` [RFC Patch 09/19] ACPI: Fix a bug in parsing ACPI Memroy24 resource Jiang Liu
2015-01-21  0:42   ` Rafael J. Wysocki
2015-01-21  2:15     ` Jiang Liu
2015-01-21  2:59       ` Rafael J. Wysocki
2015-01-21  2:48         ` Jiang Liu
2015-01-08  2:32 ` [RFC Patch 10/19] ACPI: Normalize return value of resource parser functions Jiang Liu
2015-01-08  2:32 ` [RFC Patch 11/19] ACPI: Set flag IORESOURCE_UNSET for unassigned resources Jiang Liu
2015-01-08  2:32 ` [RFC Patch 12/19] ACPI: Enforce stricter checks for address space descriptors Jiang Liu
2015-01-21  0:45   ` Rafael J. Wysocki
2015-01-21  2:18     ` Jiang Liu
2015-01-21  3:01       ` Rafael J. Wysocki
2015-01-08  2:33 ` [RFC Patch 13/19] ACPI: Return translation offset when parsing ACPI address space resources Jiang Liu
2015-01-08  2:33 ` [RFC Patch 14/19] ACPI: Translate resource into master side address for bridge window resources Jiang Liu
2015-01-21  0:50   ` Rafael J. Wysocki
2015-01-21  5:36     ` Jiang Liu
2015-01-21 14:48       ` Rafael J. Wysocki
2015-01-08  2:33 ` [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry Jiang Liu
2015-01-21  0:53   ` Rafael J. Wysocki
2015-01-21  5:37     ` Jiang Liu
2015-01-21 14:47       ` Rafael J. Wysocki
2015-01-21 15:01         ` Jiang Liu
2015-01-08  2:33 ` [RFC Patch 16/19] ACPI: Introduce helper function acpi_dev_filter_resource_type() Jiang Liu
2015-01-15 21:30   ` Thomas Gleixner
2015-01-16  0:58     ` Jiang Liu
2015-01-08  2:33 ` [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core Jiang Liu
2015-01-21  1:10   ` Rafael J. Wysocki
2015-01-21  6:37     ` Jiang Liu
2015-01-21  9:43       ` Thomas Gleixner
2015-01-21 12:32         ` Jiang Liu
2015-01-08  2:33 ` [RFC Patch 18/19] PCI: Use common resource list management code instead of private implementation Jiang Liu
2015-01-08  2:33 ` [RFC Patch 19/19] x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation Jiang Liu
2015-01-11 22:38 ` [RFC Patch 00/19] Improve ACPI resource parsing interfaces and data structures Rafael J. Wysocki
2015-01-19 14:26   ` Jiang Liu
2015-01-19 15:06     ` Rafael J. Wysocki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).