1. 11 Aug, 2009 1 commit
    • Mikael Pettersson's avatar
      IXP4xx: Fix IO_SPACE_LIMIT for 2.6.31-rc core PCI changes · dee2b904
      Mikael Pettersson authored
      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: default avatarMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: default avatarKrzysztof Hałasa <khc@pm.waw.pl>
      dee2b904
  2. 01 Aug, 2009 1 commit
  3. 31 Jul, 2009 19 commits
  4. 30 Jul, 2009 19 commits