[PATCH v2] ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map()
will at kernel.org
Fri Jan 17 04:44:45 PST 2020
On Fri, Jan 17, 2020 at 12:32:26PM +0000, Lorenzo Pieralisi wrote:
> On Fri, Jan 17, 2020 at 12:14:49PM +0000, Will Deacon wrote:
> > On Tue, Jan 14, 2020 at 08:14:11PM +0800, Hanjun Guo wrote:
> > > Reported-by: Pankaj Bansal <pankaj.bansal at nxp.com>
> > > Link: https://firstname.lastname@example.org/
> > > Signed-off-by: Hanjun Guo <guohanjun at huawei.com>
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > Cc: Pankaj Bansal <pankaj.bansal at nxp.com>
> > > Cc: Will Deacon <will at kernel.org>
> > > Cc: Sudeep Holla <sudeep.holla at arm.com>
> > > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > > Cc: Robin Murphy <robin.murphy at arm.com>
> > > ---
> > I'm a bit confused about the SoB chain here and which tree this is
> > targetting.
> > Lorenzo?
> sorry about that. It targets arm64 - previously wasn't addressed
> to you and Catalin:
> I rewrote the commit log and asked Hanjun to repost it to target an arm64
No need to apologise, just trying to figure out what's going on. Thanks for
> Having said that, this patch makes me nervous, it can break on platforms
> that have non-compliant firmware, I wonder whether it is best to leave
> it in -next for a whole cycle (I can send it to -next) to catch any
> fall-out rather than targeting v5.6 given that technically is _not_ a
> fix (we may even have to revert it - it requires coverage on all ARM64
> ACPI systems).
> What do you think ?
My experience with linux-next is that it doesn't get tonnes of runtime
testing but rather lots of build testing, so I'd be inclined to queue
this for 5.6 (i.e. for the upcoming merge window) and revert it the moment
it causes a problem.
I'll stick it on its own branch so we can also drop it if something comes
up before then.
More information about the linux-arm-kernel