From: Sasha Levin Date: Sat, 22 Feb 2020 18:56:27 +0000 (-0500) Subject: Drop acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch X-Git-Tag: v4.19.106~5 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=47665b6f74a5974926fa1b61f6f772e9b6544a49;p=thirdparty%2Fkernel%2Fstable-queue.git Drop acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch Signed-off-by: Sasha Levin --- diff --git a/queue-4.14/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch b/queue-4.14/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch deleted file mode 100644 index 952c55d1207..00000000000 --- a/queue-4.14/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch +++ /dev/null @@ -1,156 +0,0 @@ -From 6849aee2349bef078883faf3180f983c07adaa83 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Tue, 14 Jan 2020 20:14:11 +0800 -Subject: ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map() - -From: Hanjun Guo - -[ Upstream commit 3c23b83a88d00383e1d498cfa515249aa2fe0238 ] - -The IORT specification [0] (Section 3, table 4, page 9) defines the -'Number of IDs' as 'The number of IDs in the range minus one'. - -However, the IORT ID mapping function iort_id_map() treats the 'Number -of IDs' field as if it were the full IDs mapping count, with the -following check in place to detect out of boundary input IDs: - -InputID >= Input base + Number of IDs - -This check is flawed in that it considers the 'Number of IDs' field as -the full number of IDs mapping and disregards the 'minus one' from -the IDs count. - -The correct check in iort_id_map() should be implemented as: - -InputID > Input base + Number of IDs - -this implements the specification correctly but unfortunately it breaks -existing firmwares that erroneously set the 'Number of IDs' as the full -IDs mapping count rather than IDs mapping count minus one. - -e.g. - -PCI hostbridge mapping entry 1: -Input base: 0x1000 -ID Count: 0x100 -Output base: 0x1000 -Output reference: 0xC4 //ITS reference - -PCI hostbridge mapping entry 2: -Input base: 0x1100 -ID Count: 0x100 -Output base: 0x2000 -Output reference: 0xD4 //ITS reference - -Two mapping entries which the second entry's Input base = the first -entry's Input base + ID count, so for InputID 0x1100 and with the -correct InputID check in place in iort_id_map() the kernel would map -the InputID to ITS 0xC4 not 0xD4 as it would be expected. - -Therefore, to keep supporting existing flawed firmwares, introduce a -workaround that instructs the kernel to use the old InputID range check -logic in iort_id_map(), so that we can support both firmwares written -with the flawed 'Number of IDs' logic and the correct one as defined in -the specifications. - -[0]: http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf - -Reported-by: Pankaj Bansal -Link: https://lore.kernel.org/linux-acpi/20191215203303.29811-1-pankaj.bansal@nxp.com/ -Signed-off-by: Hanjun Guo -Signed-off-by: Lorenzo Pieralisi -Cc: Pankaj Bansal -Cc: Will Deacon -Cc: Sudeep Holla -Cc: Catalin Marinas -Cc: Robin Murphy -Signed-off-by: Will Deacon -Signed-off-by: Sasha Levin ---- - drivers/acpi/arm64/iort.c | 57 +++++++++++++++++++++++++++++++++++++-- - 1 file changed, 55 insertions(+), 2 deletions(-) - -diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c -index b0a7afd4e7d35..f45bb681b3db5 100644 ---- a/drivers/acpi/arm64/iort.c -+++ b/drivers/acpi/arm64/iort.c -@@ -282,6 +282,59 @@ out: - return status; - } - -+struct iort_workaround_oem_info { -+ char oem_id[ACPI_OEM_ID_SIZE + 1]; -+ char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1]; -+ u32 oem_revision; -+}; -+ -+static bool apply_id_count_workaround; -+ -+static struct iort_workaround_oem_info wa_info[] __initdata = { -+ { -+ .oem_id = "HISI ", -+ .oem_table_id = "HIP07 ", -+ .oem_revision = 0, -+ }, { -+ .oem_id = "HISI ", -+ .oem_table_id = "HIP08 ", -+ .oem_revision = 0, -+ } -+}; -+ -+static void __init -+iort_check_id_count_workaround(struct acpi_table_header *tbl) -+{ -+ int i; -+ -+ for (i = 0; i < ARRAY_SIZE(wa_info); i++) { -+ if (!memcmp(wa_info[i].oem_id, tbl->oem_id, ACPI_OEM_ID_SIZE) && -+ !memcmp(wa_info[i].oem_table_id, tbl->oem_table_id, ACPI_OEM_TABLE_ID_SIZE) && -+ wa_info[i].oem_revision == tbl->oem_revision) { -+ apply_id_count_workaround = true; -+ pr_warn(FW_BUG "ID count for ID mapping entry is wrong, applying workaround\n"); -+ break; -+ } -+ } -+} -+ -+static inline u32 iort_get_map_max(struct acpi_iort_id_mapping *map) -+{ -+ u32 map_max = map->input_base + map->id_count; -+ -+ /* -+ * The IORT specification revision D (Section 3, table 4, page 9) says -+ * Number of IDs = The number of IDs in the range minus one, but the -+ * IORT code ignored the "minus one", and some firmware did that too, -+ * so apply a workaround here to keep compatible with both the spec -+ * compliant and non-spec compliant firmwares. -+ */ -+ if (apply_id_count_workaround) -+ map_max--; -+ -+ return map_max; -+} -+ - static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, - u32 *rid_out) - { -@@ -298,8 +351,7 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, - return -ENXIO; - } - -- if (rid_in < map->input_base || -- (rid_in >= map->input_base + map->id_count)) -+ if (rid_in < map->input_base || rid_in > iort_get_map_max(map)) - return -ENXIO; - - *rid_out = map->output_base + (rid_in - map->input_base); -@@ -1275,5 +1327,6 @@ void __init acpi_iort_init(void) - return; - } - -+ iort_check_id_count_workaround(iort_table); - iort_init_platform_devices(); - } --- -2.20.1 - diff --git a/queue-4.14/series b/queue-4.14/series index 05404fbbcef..40f46861b27 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -120,7 +120,6 @@ f2fs-free-sysfs-kobject.patch scsi-iscsi-don-t-destroy-session-if-there-are-outsta.patch arm64-fix-alternatives-with-llvm-s-integrated-assemb.patch watchdog-softlockup-enforce-that-timestamp-is-valid-.patch -acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch f2fs-fix-memleak-of-kobject.patch x86-mm-fix-nx-bit-clearing-issue-in-kernel_map_pages.patch pwm-omap-dmtimer-remove-pwm-chip-in-.remove-before-m.patch diff --git a/queue-4.19/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch b/queue-4.19/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch deleted file mode 100644 index 3a225987c8b..00000000000 --- a/queue-4.19/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch +++ /dev/null @@ -1,156 +0,0 @@ -From defd3244646d37e55c0d670bb9ee0ba953ba33fb Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Tue, 14 Jan 2020 20:14:11 +0800 -Subject: ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map() - -From: Hanjun Guo - -[ Upstream commit 3c23b83a88d00383e1d498cfa515249aa2fe0238 ] - -The IORT specification [0] (Section 3, table 4, page 9) defines the -'Number of IDs' as 'The number of IDs in the range minus one'. - -However, the IORT ID mapping function iort_id_map() treats the 'Number -of IDs' field as if it were the full IDs mapping count, with the -following check in place to detect out of boundary input IDs: - -InputID >= Input base + Number of IDs - -This check is flawed in that it considers the 'Number of IDs' field as -the full number of IDs mapping and disregards the 'minus one' from -the IDs count. - -The correct check in iort_id_map() should be implemented as: - -InputID > Input base + Number of IDs - -this implements the specification correctly but unfortunately it breaks -existing firmwares that erroneously set the 'Number of IDs' as the full -IDs mapping count rather than IDs mapping count minus one. - -e.g. - -PCI hostbridge mapping entry 1: -Input base: 0x1000 -ID Count: 0x100 -Output base: 0x1000 -Output reference: 0xC4 //ITS reference - -PCI hostbridge mapping entry 2: -Input base: 0x1100 -ID Count: 0x100 -Output base: 0x2000 -Output reference: 0xD4 //ITS reference - -Two mapping entries which the second entry's Input base = the first -entry's Input base + ID count, so for InputID 0x1100 and with the -correct InputID check in place in iort_id_map() the kernel would map -the InputID to ITS 0xC4 not 0xD4 as it would be expected. - -Therefore, to keep supporting existing flawed firmwares, introduce a -workaround that instructs the kernel to use the old InputID range check -logic in iort_id_map(), so that we can support both firmwares written -with the flawed 'Number of IDs' logic and the correct one as defined in -the specifications. - -[0]: http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf - -Reported-by: Pankaj Bansal -Link: https://lore.kernel.org/linux-acpi/20191215203303.29811-1-pankaj.bansal@nxp.com/ -Signed-off-by: Hanjun Guo -Signed-off-by: Lorenzo Pieralisi -Cc: Pankaj Bansal -Cc: Will Deacon -Cc: Sudeep Holla -Cc: Catalin Marinas -Cc: Robin Murphy -Signed-off-by: Will Deacon -Signed-off-by: Sasha Levin ---- - drivers/acpi/arm64/iort.c | 57 +++++++++++++++++++++++++++++++++++++-- - 1 file changed, 55 insertions(+), 2 deletions(-) - -diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c -index e11b5da6f828f..7d86468300b78 100644 ---- a/drivers/acpi/arm64/iort.c -+++ b/drivers/acpi/arm64/iort.c -@@ -306,6 +306,59 @@ out: - return status; - } - -+struct iort_workaround_oem_info { -+ char oem_id[ACPI_OEM_ID_SIZE + 1]; -+ char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1]; -+ u32 oem_revision; -+}; -+ -+static bool apply_id_count_workaround; -+ -+static struct iort_workaround_oem_info wa_info[] __initdata = { -+ { -+ .oem_id = "HISI ", -+ .oem_table_id = "HIP07 ", -+ .oem_revision = 0, -+ }, { -+ .oem_id = "HISI ", -+ .oem_table_id = "HIP08 ", -+ .oem_revision = 0, -+ } -+}; -+ -+static void __init -+iort_check_id_count_workaround(struct acpi_table_header *tbl) -+{ -+ int i; -+ -+ for (i = 0; i < ARRAY_SIZE(wa_info); i++) { -+ if (!memcmp(wa_info[i].oem_id, tbl->oem_id, ACPI_OEM_ID_SIZE) && -+ !memcmp(wa_info[i].oem_table_id, tbl->oem_table_id, ACPI_OEM_TABLE_ID_SIZE) && -+ wa_info[i].oem_revision == tbl->oem_revision) { -+ apply_id_count_workaround = true; -+ pr_warn(FW_BUG "ID count for ID mapping entry is wrong, applying workaround\n"); -+ break; -+ } -+ } -+} -+ -+static inline u32 iort_get_map_max(struct acpi_iort_id_mapping *map) -+{ -+ u32 map_max = map->input_base + map->id_count; -+ -+ /* -+ * The IORT specification revision D (Section 3, table 4, page 9) says -+ * Number of IDs = The number of IDs in the range minus one, but the -+ * IORT code ignored the "minus one", and some firmware did that too, -+ * so apply a workaround here to keep compatible with both the spec -+ * compliant and non-spec compliant firmwares. -+ */ -+ if (apply_id_count_workaround) -+ map_max--; -+ -+ return map_max; -+} -+ - static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, - u32 *rid_out) - { -@@ -322,8 +375,7 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, - return -ENXIO; - } - -- if (rid_in < map->input_base || -- (rid_in >= map->input_base + map->id_count)) -+ if (rid_in < map->input_base || rid_in > iort_get_map_max(map)) - return -ENXIO; - - *rid_out = map->output_base + (rid_in - map->input_base); -@@ -1542,5 +1594,6 @@ void __init acpi_iort_init(void) - return; - } - -+ iort_check_id_count_workaround(iort_table); - iort_init_platform_devices(); - } --- -2.20.1 - diff --git a/queue-4.19/series b/queue-4.19/series index fee2774f425..8b5500672a6 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -131,7 +131,6 @@ scsi-iscsi-don-t-destroy-session-if-there-are-outsta.patch arm64-fix-alternatives-with-llvm-s-integrated-assemb.patch drm-amd-display-fixup-dml-dependencies.patch watchdog-softlockup-enforce-that-timestamp-is-valid-.patch -acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch f2fs-fix-memleak-of-kobject.patch x86-mm-fix-nx-bit-clearing-issue-in-kernel_map_pages.patch pwm-omap-dmtimer-remove-pwm-chip-in-.remove-before-m.patch diff --git a/queue-5.4/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch b/queue-5.4/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch deleted file mode 100644 index 8fde998339c..00000000000 --- a/queue-5.4/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch +++ /dev/null @@ -1,156 +0,0 @@ -From cf837dd479b8c9e8ba5ca16b7d51fe7776b369f9 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Tue, 14 Jan 2020 20:14:11 +0800 -Subject: ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map() - -From: Hanjun Guo - -[ Upstream commit 3c23b83a88d00383e1d498cfa515249aa2fe0238 ] - -The IORT specification [0] (Section 3, table 4, page 9) defines the -'Number of IDs' as 'The number of IDs in the range minus one'. - -However, the IORT ID mapping function iort_id_map() treats the 'Number -of IDs' field as if it were the full IDs mapping count, with the -following check in place to detect out of boundary input IDs: - -InputID >= Input base + Number of IDs - -This check is flawed in that it considers the 'Number of IDs' field as -the full number of IDs mapping and disregards the 'minus one' from -the IDs count. - -The correct check in iort_id_map() should be implemented as: - -InputID > Input base + Number of IDs - -this implements the specification correctly but unfortunately it breaks -existing firmwares that erroneously set the 'Number of IDs' as the full -IDs mapping count rather than IDs mapping count minus one. - -e.g. - -PCI hostbridge mapping entry 1: -Input base: 0x1000 -ID Count: 0x100 -Output base: 0x1000 -Output reference: 0xC4 //ITS reference - -PCI hostbridge mapping entry 2: -Input base: 0x1100 -ID Count: 0x100 -Output base: 0x2000 -Output reference: 0xD4 //ITS reference - -Two mapping entries which the second entry's Input base = the first -entry's Input base + ID count, so for InputID 0x1100 and with the -correct InputID check in place in iort_id_map() the kernel would map -the InputID to ITS 0xC4 not 0xD4 as it would be expected. - -Therefore, to keep supporting existing flawed firmwares, introduce a -workaround that instructs the kernel to use the old InputID range check -logic in iort_id_map(), so that we can support both firmwares written -with the flawed 'Number of IDs' logic and the correct one as defined in -the specifications. - -[0]: http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf - -Reported-by: Pankaj Bansal -Link: https://lore.kernel.org/linux-acpi/20191215203303.29811-1-pankaj.bansal@nxp.com/ -Signed-off-by: Hanjun Guo -Signed-off-by: Lorenzo Pieralisi -Cc: Pankaj Bansal -Cc: Will Deacon -Cc: Sudeep Holla -Cc: Catalin Marinas -Cc: Robin Murphy -Signed-off-by: Will Deacon -Signed-off-by: Sasha Levin ---- - drivers/acpi/arm64/iort.c | 57 +++++++++++++++++++++++++++++++++++++-- - 1 file changed, 55 insertions(+), 2 deletions(-) - -diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c -index 5a7551d060f25..161b609e4cdfb 100644 ---- a/drivers/acpi/arm64/iort.c -+++ b/drivers/acpi/arm64/iort.c -@@ -298,6 +298,59 @@ out: - return status; - } - -+struct iort_workaround_oem_info { -+ char oem_id[ACPI_OEM_ID_SIZE + 1]; -+ char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1]; -+ u32 oem_revision; -+}; -+ -+static bool apply_id_count_workaround; -+ -+static struct iort_workaround_oem_info wa_info[] __initdata = { -+ { -+ .oem_id = "HISI ", -+ .oem_table_id = "HIP07 ", -+ .oem_revision = 0, -+ }, { -+ .oem_id = "HISI ", -+ .oem_table_id = "HIP08 ", -+ .oem_revision = 0, -+ } -+}; -+ -+static void __init -+iort_check_id_count_workaround(struct acpi_table_header *tbl) -+{ -+ int i; -+ -+ for (i = 0; i < ARRAY_SIZE(wa_info); i++) { -+ if (!memcmp(wa_info[i].oem_id, tbl->oem_id, ACPI_OEM_ID_SIZE) && -+ !memcmp(wa_info[i].oem_table_id, tbl->oem_table_id, ACPI_OEM_TABLE_ID_SIZE) && -+ wa_info[i].oem_revision == tbl->oem_revision) { -+ apply_id_count_workaround = true; -+ pr_warn(FW_BUG "ID count for ID mapping entry is wrong, applying workaround\n"); -+ break; -+ } -+ } -+} -+ -+static inline u32 iort_get_map_max(struct acpi_iort_id_mapping *map) -+{ -+ u32 map_max = map->input_base + map->id_count; -+ -+ /* -+ * The IORT specification revision D (Section 3, table 4, page 9) says -+ * Number of IDs = The number of IDs in the range minus one, but the -+ * IORT code ignored the "minus one", and some firmware did that too, -+ * so apply a workaround here to keep compatible with both the spec -+ * compliant and non-spec compliant firmwares. -+ */ -+ if (apply_id_count_workaround) -+ map_max--; -+ -+ return map_max; -+} -+ - static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, - u32 *rid_out) - { -@@ -314,8 +367,7 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, - return -ENXIO; - } - -- if (rid_in < map->input_base || -- (rid_in >= map->input_base + map->id_count)) -+ if (rid_in < map->input_base || rid_in > iort_get_map_max(map)) - return -ENXIO; - - *rid_out = map->output_base + (rid_in - map->input_base); -@@ -1637,5 +1689,6 @@ void __init acpi_iort_init(void) - return; - } - -+ iort_check_id_count_workaround(iort_table); - iort_init_platform_devices(); - } --- -2.20.1 - diff --git a/queue-5.4/series b/queue-5.4/series index 0bfad1824c5..4cfefb00d85 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -248,7 +248,6 @@ sched-core-fix-size-of-rq-uclamp-initialization.patch sched-topology-assert-non-numa-topology-masks-don-t-.patch perf-x86-amd-constrain-large-increment-per-cycle-eve.patch watchdog-softlockup-enforce-that-timestamp-is-valid-.patch -acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch debugobjects-fix-various-data-races.patch asoc-sof-intel-hda-fix-skl-dai-count.patch regulator-vctrl-regulator-avoid-deadlock-getting-and.patch diff --git a/queue-5.5/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch b/queue-5.5/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch deleted file mode 100644 index 34e3bc97df3..00000000000 --- a/queue-5.5/acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch +++ /dev/null @@ -1,156 +0,0 @@ -From 89c1b3d3579e87612373d72ca331587605ff6533 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Tue, 14 Jan 2020 20:14:11 +0800 -Subject: ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map() - -From: Hanjun Guo - -[ Upstream commit 3c23b83a88d00383e1d498cfa515249aa2fe0238 ] - -The IORT specification [0] (Section 3, table 4, page 9) defines the -'Number of IDs' as 'The number of IDs in the range minus one'. - -However, the IORT ID mapping function iort_id_map() treats the 'Number -of IDs' field as if it were the full IDs mapping count, with the -following check in place to detect out of boundary input IDs: - -InputID >= Input base + Number of IDs - -This check is flawed in that it considers the 'Number of IDs' field as -the full number of IDs mapping and disregards the 'minus one' from -the IDs count. - -The correct check in iort_id_map() should be implemented as: - -InputID > Input base + Number of IDs - -this implements the specification correctly but unfortunately it breaks -existing firmwares that erroneously set the 'Number of IDs' as the full -IDs mapping count rather than IDs mapping count minus one. - -e.g. - -PCI hostbridge mapping entry 1: -Input base: 0x1000 -ID Count: 0x100 -Output base: 0x1000 -Output reference: 0xC4 //ITS reference - -PCI hostbridge mapping entry 2: -Input base: 0x1100 -ID Count: 0x100 -Output base: 0x2000 -Output reference: 0xD4 //ITS reference - -Two mapping entries which the second entry's Input base = the first -entry's Input base + ID count, so for InputID 0x1100 and with the -correct InputID check in place in iort_id_map() the kernel would map -the InputID to ITS 0xC4 not 0xD4 as it would be expected. - -Therefore, to keep supporting existing flawed firmwares, introduce a -workaround that instructs the kernel to use the old InputID range check -logic in iort_id_map(), so that we can support both firmwares written -with the flawed 'Number of IDs' logic and the correct one as defined in -the specifications. - -[0]: http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf - -Reported-by: Pankaj Bansal -Link: https://lore.kernel.org/linux-acpi/20191215203303.29811-1-pankaj.bansal@nxp.com/ -Signed-off-by: Hanjun Guo -Signed-off-by: Lorenzo Pieralisi -Cc: Pankaj Bansal -Cc: Will Deacon -Cc: Sudeep Holla -Cc: Catalin Marinas -Cc: Robin Murphy -Signed-off-by: Will Deacon -Signed-off-by: Sasha Levin ---- - drivers/acpi/arm64/iort.c | 57 +++++++++++++++++++++++++++++++++++++-- - 1 file changed, 55 insertions(+), 2 deletions(-) - -diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c -index 33f71983e0017..6078064684c6c 100644 ---- a/drivers/acpi/arm64/iort.c -+++ b/drivers/acpi/arm64/iort.c -@@ -298,6 +298,59 @@ out: - return status; - } - -+struct iort_workaround_oem_info { -+ char oem_id[ACPI_OEM_ID_SIZE + 1]; -+ char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1]; -+ u32 oem_revision; -+}; -+ -+static bool apply_id_count_workaround; -+ -+static struct iort_workaround_oem_info wa_info[] __initdata = { -+ { -+ .oem_id = "HISI ", -+ .oem_table_id = "HIP07 ", -+ .oem_revision = 0, -+ }, { -+ .oem_id = "HISI ", -+ .oem_table_id = "HIP08 ", -+ .oem_revision = 0, -+ } -+}; -+ -+static void __init -+iort_check_id_count_workaround(struct acpi_table_header *tbl) -+{ -+ int i; -+ -+ for (i = 0; i < ARRAY_SIZE(wa_info); i++) { -+ if (!memcmp(wa_info[i].oem_id, tbl->oem_id, ACPI_OEM_ID_SIZE) && -+ !memcmp(wa_info[i].oem_table_id, tbl->oem_table_id, ACPI_OEM_TABLE_ID_SIZE) && -+ wa_info[i].oem_revision == tbl->oem_revision) { -+ apply_id_count_workaround = true; -+ pr_warn(FW_BUG "ID count for ID mapping entry is wrong, applying workaround\n"); -+ break; -+ } -+ } -+} -+ -+static inline u32 iort_get_map_max(struct acpi_iort_id_mapping *map) -+{ -+ u32 map_max = map->input_base + map->id_count; -+ -+ /* -+ * The IORT specification revision D (Section 3, table 4, page 9) says -+ * Number of IDs = The number of IDs in the range minus one, but the -+ * IORT code ignored the "minus one", and some firmware did that too, -+ * so apply a workaround here to keep compatible with both the spec -+ * compliant and non-spec compliant firmwares. -+ */ -+ if (apply_id_count_workaround) -+ map_max--; -+ -+ return map_max; -+} -+ - static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, - u32 *rid_out) - { -@@ -314,8 +367,7 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, - return -ENXIO; - } - -- if (rid_in < map->input_base || -- (rid_in >= map->input_base + map->id_count)) -+ if (rid_in < map->input_base || rid_in > iort_get_map_max(map)) - return -ENXIO; - - *rid_out = map->output_base + (rid_in - map->input_base); -@@ -1631,5 +1683,6 @@ void __init acpi_iort_init(void) - return; - } - -+ iort_check_id_count_workaround(iort_table); - iort_init_platform_devices(); - } --- -2.20.1 - diff --git a/queue-5.5/series b/queue-5.5/series index f499fb293d5..ea7489367e1 100644 --- a/queue-5.5/series +++ b/queue-5.5/series @@ -287,7 +287,6 @@ sched-topology-assert-non-numa-topology-masks-don-t-.patch perf-x86-amd-constrain-large-increment-per-cycle-eve.patch watchdog-softlockup-enforce-that-timestamp-is-valid-.patch enetc-don-t-print-from-enetc_sched_speed_set-when-li.patch -acpi-iort-fix-number-of-ids-handling-in-iort_id_map.patch x86-apic-uv-avoid-unused-variable-warning.patch debugobjects-fix-various-data-races.patch asoc-wm_adsp-correct-cache-handling-of-new-kernel-co.patch