On Thu, 7 May 2020 at 15:47, Hanjun Guo <guohanjun@xxxxxxxxxx> wrote: > > As we already applied a workaround for the off-by-1 issue, > it's good to add extra message "applying workaround" to > make people less uneasy to see such message in the boot log. > > Signed-off-by: Hanjun Guo <guohanjun@xxxxxxxxxx> Hi Hanjun, > --- > > Based on top of for-next/acpi branch of ARM64 repo > > drivers/acpi/arm64/iort.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > index b011d25..f3d492a 100644 > --- a/drivers/acpi/arm64/iort.c > +++ b/drivers/acpi/arm64/iort.c > @@ -328,7 +328,7 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, > * 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", > + pr_err(FW_BUG "[map %p] conflicting mapping for input ID 0x%x, applying workaround\n", This is not correct. The workaround is only applied if rid_in == map->input_base, so better to print a second line after the 'return' below that is only reached in that particular case. > map, rid_in); > if (rid_in != map->input_base) > return -ENXIO; > -- > 1.7.12.4 >
