RE: [QUESTION]: Same IO bus address in different _CRS methods

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux