• M
    IXP4xx: Fix IO_SPACE_LIMIT for 2.6.31-rc core PCI changes · dee2b904
    Mikael Pettersson 提交于
    2.6.31-rc kernels don't boot on my ixp4xx box (ds101), because the libata
    driver doesn't find the PCI IDE controller any more. 2.6.30 was fine.
    I traced this to a PCI update (1f82de10)
    in 2.6.30-git19. Diffing the kernel boot logs from 2.6.30-git18 and
    2.6.30-git19 illustrates the breakage:
    
    > --- dmesg-2.6.30-git18	2009-08-04 01:45:22.000000000 +0200
    > +++ dmesg-2.6.30-git19	2009-08-04 01:45:46.000000000 +0200
    > @@ -26,6 +26,13 @@
    >  pci 0000:00:02.2: PME# supported from D0 D1 D2 D3hot
    >  pci 0000:00:02.2: PME# disabled
    >  PCI: bus0: Fast back to back transfers disabled
    > +pci 0000:00:01.0: BAR 0: can't allocate I/O resource [0x10000-0xffff]
    > +pci 0000:00:01.0: BAR 1: can't allocate I/O resource [0x10000-0xffff]
    > +pci 0000:00:01.0: BAR 2: can't allocate I/O resource [0x10000-0xffff]
    > +pci 0000:00:01.0: BAR 3: can't allocate I/O resource [0x10000-0xffff]
    > +pci 0000:00:01.0: BAR 4: can't allocate I/O resource [0x10000-0xffff]
    > +pci 0000:00:02.0: BAR 4: can't allocate I/O resource [0x10000-0xffff]
    > +pci 0000:00:02.1: BAR 4: can't allocate I/O resource [0x10000-0xffff]
    >  bio: create slab <bio-0> at 0
    >  SCSI subsystem initialized
    >  NET: Registered protocol family 2
    > @@ -44,11 +51,7 @@
    >  console [ttyS0] enabled
    >  serial8250.0: ttyS1 at MMIO 0xc8001000 (irq = 13) is a XScale
    >  Driver 'sd' needs updating - please use bus_type methods
    > -PCI: enabling device 0000:00:01.0 (0140 -> 0141)
    > -scsi0 : pata_artop
    > -scsi1 : pata_artop
    > -ata1: PATA max UDMA/100 cmd 0x1050 ctl 0x1060 bmdma 0x1040 irq 28
    > -ata2: PATA max UDMA/100 cmd 0x1058 ctl 0x1064 bmdma 0x1048 irq 28
    > +pata_artop 0000:00:01.0: no available native port
    >  Using configured DiskOnChip probe address 0x50000000
    >  DiskOnChip found at 0x50000000
    >  NAND device: Manufacturer ID: 0x98, Chip ID: 0x73 (Toshiba NAND 16MiB 3,3V 8-bit)
    
    The specific change in 1f82de10 responsible
    for this failure turned out to be the following:
    
    > --- a/drivers/pci/probe.c
    > +++ b/drivers/pci/probe.c
    > @@ -193,7 +193,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
    >  		res->flags |= pci_calc_resource_flags(l) | IORESOURCE_SIZEALIGN;
    >  		if (type == pci_bar_io) {
    >  			l &= PCI_BASE_ADDRESS_IO_MASK;
    > -			mask = PCI_BASE_ADDRESS_IO_MASK & 0xffff;
    > +			mask = PCI_BASE_ADDRESS_IO_MASK & IO_SPACE_LIMIT;
    >  		} else {
    >  			l &= PCI_BASE_ADDRESS_MEM_MASK;
    >  			mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
    
    Every arch except arm's ixp4xx defines IO_SPACE_LIMIT as an all-bits-one
    bitmask, typically -1UL but sometimes only a 16-bit 0x0000ffff. But ixp4xx
    defines it as 0xffff0000, which is now causing the PCI failures.
    
    Russell King noted that ixp4xx has 64KB PCI IO space, so IO_SPACE_LIMIT
    should be 0x0000ffff. This patch makes that change, which fixes the PCI
    failures on my ixp4xx box.
    Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
    Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
    dee2b904
io.h 13.8 KB