There are some arch, like PPC64, that need to be able to scan all the
PCI functions. The problem comes in on a logically partitioned system
where function 0 on a PCI-PCI bridge is assigned to one partition and
say function 2 is assiged to another partition. On the second
partition, it would appear that function 0 does not exist, but function
2 does. If all the functions are not scanned, everything under function
2 would not be detected.
Thanks,
Jake
On Tue, Jan 27, 2004 at 10:55:01AM -0600, Jake Moilanen wrote:
> There are some arch, like PPC64, that need to be able to scan all the
> PCI functions. The problem comes in on a logically partitioned system
> where function 0 on a PCI-PCI bridge is assigned to one partition and
> say function 2 is assiged to another partition. On the second
> partition, it would appear that function 0 does not exist, but function
> 2 does. If all the functions are not scanned, everything under function
> 2 would not be detected.
Heh, I think the PPC64 people need to get together and all talk about
this, as I just got a different patch, that solves much the same problem
from John Rose (it's on the linuxppc64 mailing list.)
Can you two get together and not patch the same section of code to do
the same thing in different ways?
thanks,
greg k-h
Greg KH <[email protected]> wrote:
>
> On Tue, Jan 27, 2004 at 10:55:01AM -0600, Jake Moilanen wrote:
> > There are some arch, like PPC64, that need to be able to scan all the
> > PCI functions. The problem comes in on a logically partitioned system
> > where function 0 on a PCI-PCI bridge is assigned to one partition and
> > say function 2 is assiged to another partition. On the second
> > partition, it would appear that function 0 does not exist, but function
> > 2 does. If all the functions are not scanned, everything under function
> > 2 would not be detected.
>
> Heh, I think the PPC64 people need to get together and all talk about
> this, as I just got a different patch, that solves much the same problem
> from John Rose (it's on the linuxppc64 mailing list.)
>
> Can you two get together and not patch the same section of code to do
> the same thing in different ways?
While we're on the topic, what's with the below patch? I've had it in -mm
for ages but apparently there's some disagreement over it.
From: Anton Blanchard <[email protected]>
We have IO BARs on ppc64 machines that begin at address 0. The current
pci probe code will ignore anything that starts at 0. Remove these checks.
---
drivers/pci/probe.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff -puN drivers/pci/probe.c~ppc64-bar-0-fix drivers/pci/probe.c
--- 25/drivers/pci/probe.c~ppc64-bar-0-fix 2004-01-13 23:23:18.000000000 -0800
+++ 25-akpm/drivers/pci/probe.c 2004-01-13 23:23:18.000000000 -0800
@@ -176,7 +176,7 @@ void __devinit pci_read_bridge_bases(str
limit |= (io_limit_hi << 16);
}
- if (base && base <= limit) {
+ if (base <= limit) {
res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO;
res->start = base;
res->end = limit + 0xfff;
@@ -187,7 +187,7 @@ void __devinit pci_read_bridge_bases(str
pci_read_config_word(dev, PCI_MEMORY_LIMIT, &mem_limit_lo);
base = (mem_base_lo & PCI_MEMORY_RANGE_MASK) << 16;
limit = (mem_limit_lo & PCI_MEMORY_RANGE_MASK) << 16;
- if (base && base <= limit) {
+ if (base <= limit) {
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
res->start = base;
res->end = limit + 0xfffff;
@@ -213,7 +213,7 @@ void __devinit pci_read_bridge_bases(str
}
#endif
}
- if (base && base <= limit) {
+ if (base <= limit) {
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
res->start = base;
res->end = limit + 0xfffff;
_
On Tue, 27 Jan 2004, Andrew Morton wrote:
>
> While we're on the topic, what's with the below patch? I've had it in -mm
> for ages but apparently there's some disagreement over it.
I'd be very worried, since I'm pretty sure that there _are_ devices where
"zero means disabled".
On the other hand, the resource management should do the right thing
anyway, so I guess it should be safe. Especially if it's been in -mm for a
long time..
Linus
Hi-
> Heh, I think the PPC64 people need to get together and all talk about
> this, as I just got a different patch, that solves much the same problem
> from John Rose (it's on the linuxppc64 mailing list.)
>
> Can you two get together and not patch the same section of code to do
> the same thing in different ways?
These patches don't address the same problem. Jake's problem has to do
with pci_scan_slot() ending too soon when going from function 0->7 at
boot time. My problem has to do with pci_scan_slot() going too far from
function 0->7 at dlpar add time. Greg, will follow up with you outside
of this thread.
Thanks-
John
--
John Rose <[email protected]>
On Tue, Jan 27, 2004 at 01:33:14PM -0800, Andrew Morton wrote:
> Greg KH <[email protected]> wrote:
> >
> > On Tue, Jan 27, 2004 at 10:55:01AM -0600, Jake Moilanen wrote:
> > > There are some arch, like PPC64, that need to be able to scan all the
> > > PCI functions. The problem comes in on a logically partitioned system
> > > where function 0 on a PCI-PCI bridge is assigned to one partition and
> > > say function 2 is assiged to another partition. On the second
> > > partition, it would appear that function 0 does not exist, but function
> > > 2 does. If all the functions are not scanned, everything under function
> > > 2 would not be detected.
> >
> > Heh, I think the PPC64 people need to get together and all talk about
> > this, as I just got a different patch, that solves much the same problem
> > from John Rose (it's on the linuxppc64 mailing list.)
> >
> > Can you two get together and not patch the same section of code to do
> > the same thing in different ways?
>
> While we're on the topic, what's with the below patch? I've had it in -mm
> for ages but apparently there's some disagreement over it.
It looks ok to me, but Linus and Ivan were the ones disagreeing over how
to implement this correctly, as they understand the resource management
logic a lot better than I.
They should be the ones to say if this is ok or not.
thanks,
greg k-h
> From: Anton Blanchard <[email protected]>
>
> We have IO BARs on ppc64 machines that begin at address 0. The current
> pci probe code will ignore anything that starts at 0. Remove these checks.
>
>
>
> ---
>
> drivers/pci/probe.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff -puN drivers/pci/probe.c~ppc64-bar-0-fix drivers/pci/probe.c
> --- 25/drivers/pci/probe.c~ppc64-bar-0-fix 2004-01-13 23:23:18.000000000 -0800
> +++ 25-akpm/drivers/pci/probe.c 2004-01-13 23:23:18.000000000 -0800
> @@ -176,7 +176,7 @@ void __devinit pci_read_bridge_bases(str
> limit |= (io_limit_hi << 16);
> }
>
> - if (base && base <= limit) {
> + if (base <= limit) {
> res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO;
> res->start = base;
> res->end = limit + 0xfff;
> @@ -187,7 +187,7 @@ void __devinit pci_read_bridge_bases(str
> pci_read_config_word(dev, PCI_MEMORY_LIMIT, &mem_limit_lo);
> base = (mem_base_lo & PCI_MEMORY_RANGE_MASK) << 16;
> limit = (mem_limit_lo & PCI_MEMORY_RANGE_MASK) << 16;
> - if (base && base <= limit) {
> + if (base <= limit) {
> res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
> res->start = base;
> res->end = limit + 0xfffff;
> @@ -213,7 +213,7 @@ void __devinit pci_read_bridge_bases(str
> }
> #endif
> }
> - if (base && base <= limit) {
> + if (base <= limit) {
> res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
> res->start = base;
> res->end = limit + 0xfffff;
>
> _
Hello!
> There are some arch, like PPC64, that need to be able to scan all the
> PCI functions. The problem comes in on a logically partitioned system
> where function 0 on a PCI-PCI bridge is assigned to one partition and
> say function 2 is assiged to another partition. On the second
> partition, it would appear that function 0 does not exist, but function
> 2 does. If all the functions are not scanned, everything under function
> 2 would not be detected.
Enabling scan of all functions globally is probably going to cause troubles,
because there are single-function devices which respond to all function
numbers. You need to enable this quirk selectively.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"God doesn't play dice." -- Albert Einstein
On Tue, Jan 27, 2004 at 01:44:44PM -0800, Greg KH wrote:
> > - if (base && base <= limit) {
> > + if (base <= limit) {
I think the patch is safe. Architectures that don't accept
bridge windows (and regular BARs) at bus address 0 already have
that check elsewhere.
For example, in arch/i386/pci/i386.c:pcibios_allocate_bus_resources():
...
for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
r = &dev->resource[idx];
if (!r->start)
^^^^^^^^^
continue;
...
Ivan.