Hi Arnd and Bjorn Many thanks for your answers > -----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 > > On Thu, Mar 9, 2017 at 11:37 PM, Bjorn Helgaas <helgaas@xxxxxxxxxx> > wrote: > > On Thu, Mar 09, 2017 at 11:09:24PM +0100, Arnd Bergmann wrote: > >> On Thu, Mar 9, 2017 at 7:11 PM, Bjorn Helgaas <helgaas@xxxxxxxxxx> > wrote: > >> > On Thu, Mar 09, 2017 at 03:41:03PM +0000, Gabriele Paoloni wrote: > >> >> Hi Bjorn and all > >> >> > >> >> I have a question regarding bus addresses for IO resources in the > >> >> ACPI table. > >> >> > >> >> The question is if from an ACPI perspective it is legal to have > two > >> >> entries in separate _CRS methods using the same IO bus address. > >> >> > >> >> As an example please see the code at the bottom: we have the same > >> >> bus address starting at 0x0 with (obviously) different offsets > >> >> leading to different CPU physical addresses. Is this legal? > >> > > >> > Yes. > >> > > >> > These are on separate PCI buses (PCI0 leads to 0000:00 and PCI1 > leads > >> > to 0001:e0), so there should be no conflict. Those are completely > >> > independent PCI buses, and their bus address spaces are also > >> > independent. > >> > > >> > You do have to make sure the CPU physical addresses don't > conflict, of > >> > course. > >> > >> Ok. My reading of the ia64 code was that it would reject this as > being > >> overlapping resources, but I was probably misreading then. > > > > I'm fairly sure ia64 supported multiple 0-0xffff I/O port spaces (in > PCI > > I/O space), but I don't have dmesg logs from any of those machines > any > > more. > > Ok. I've read the code again and you are right: ia64 checks that the > CPU address is unique, not the PCI I/O space address. > > >> 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. Again many thanks Gab > > Arnd ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
