Re: [PATCH v2 2/2] ACPI/IORT: work around num_ids ambiguity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020/5/6 20:55, Will Deacon wrote:
On Wed, May 06, 2020 at 08:44:55PM +0800, Hanjun Guo wrote:
On 2020/5/4 15:36, Ard Biesheuvel wrote:
On Mon, 4 May 2020 at 06:32, Hanjun Guo <guohanjun@xxxxxxxxxx> wrote:
On 2020/5/2 0:10, Ard Biesheuvel wrote:
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 98be18266a73..9f139a94a1d3 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -300,7 +300,7 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
    }

    static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
-                    u32 *rid_out)
+                    u32 *rid_out, bool check_overlap)
    {
        /* Single mapping does not care for input id */
        if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
@@ -316,10 +316,34 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
        }

        if (rid_in < map->input_base ||
-         (rid_in >= map->input_base + map->id_count))
+         (rid_in > map->input_base + map->id_count))
                return -ENXIO;

+     if (check_overlap) {
+             /*
+              * We already found a mapping for this input ID at the end of
+              * another region. If it coincides with the start of this
+              * region, we assume the prior match was due to the off-by-1
+              * issue mentioned below, and allow it to be superseded.
+              * Otherwise, things are *really* broken, and we just disregard
+              * duplicate matches entirely to retain compatibility.
+              */
+             pr_err(FW_BUG "[map %p] conflicting mapping for input ID 0x%x\n",
+                    map, rid_in);

As we already applied a workaround here, can we add "applying
workaround" in the error message? This will make the customers
less uneasy to see such message in the boot log. Once the product
was deliveried to customers, it's not that easy to update all the
firmwares entirely.


Sure.

Since Will already merged this patchset, I would like to send a patch
on top of it, what do you think?

Yes, please! I figured I'd queue it, as I could always revert it if your
testing came back negative but extra stuff on top is always fine.

OK, I will prepare a patch and send out for review.

Thanks
Hanjun




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux