On Fri, Mar 10, 2017 at 1:25 AM, Gabriele Paoloni <gabriele.paoloni@xxxxxxxxxx> wrote: >> -----Original Message----- >> From: arndbergmann@xxxxxxxxx [mailto:arndbergmann@xxxxxxxxx] On Behalf >> Of Arnd Bergmann >> Sent: 09 March 2017 22:50 >> To: Bjorn Helgaas >> Cc: Gabriele Paoloni; Bjorn Helgaas; Tomasz Nowicki; Lorenzo Pieralisi; >> agraf@xxxxxxx; Yuanzhichang; xuwei (O); John Garry; linux- >> pci@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx >> Subject: Re: [QUESTION]: Same IO bus address in different _CRS methods >> >> What is the expected way to deal with a device using an I/O resource >> >> that is not a child of either PCI host bridge in this case (e.g. a >> >> BMC behind a PCI-LPC bridge)? Is this only allowed to exist below >> >> the device that provides the respective I/O space? >> > >> > That's a good question. I'm not really familiar with PCI-LPC >> bridges. >> > I guess they're not PCI-to-PCI bridges and wouldn't have I/O windows >> > like I'm used to? What *do* they look like? >> >> They are like PCI-ISA bridges, connecting devices that use either >> hardcoded I/O ports (uart, ipmi-kcs, ...) or ISAPNP. >> >> In the case that we are interested in specifically here, there is not >> actually a PCI-LPC bridge, but a LPC host bridge that is independent >> of PCI but has its own I/O space, and a number of child devices >> attached >> to that. > > I think that for the case that we were discussing we needed to know > whether we could make the assumption to have unique IO bus addresses > in a whole ACPI table. > > The idea for ACPI was to rework acpi_pci_root_remap_iospace and, > rather than using the PIO tokens retrieved by pci_register_io_range(), > remove the call to this function and use the bus addresses defined > in the _CRS method. > > From what Bjorn said it seems that we have at least some cases where > these bus addresses are not unique; therefore in linux we need to generate > the PIO tokens dynamically. > > If you guys agree on the conclusion above I will continue with the > rework of the HiSilicon LPC driver with the assumption that we need > dynamically assigned tokens also for ACPI. Yes, unless Bjorn has some last concerns, I think this is all good and the only proper way to continue. Thanks for bearing with me through the detour that ended up in the same place we were in before... Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
