On Tue, Jan 14, 2020 at 08:14:11PM +0800, Hanjun Guo wrote: > 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 <pankaj.bansal@xxxxxxx> > Link: https://lore.kernel.org/linux-acpi/20191215203303.29811-1-pankaj.bansal@xxxxxxx/ > Signed-off-by: Hanjun Guo <guohanjun@xxxxxxxxxx> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> > Cc: Pankaj Bansal <pankaj.bansal@xxxxxxx> > Cc: Will Deacon <will@xxxxxxxxxx> > Cc: Sudeep Holla <sudeep.holla@xxxxxxx> > Cc: Catalin Marinas <catalin.marinas@xxxxxxx> > Cc: Robin Murphy <robin.murphy@xxxxxxx> > --- I'm a bit confused about the SoB chain here and which tree this is targetting. Lorenzo? Will
