1. 30 10月, 2015 1 次提交
    • Y
      sparc/PCI: Add mem64 resource parsing for root bus · af86fa40
      Yinghai Lu 提交于
      David reported that a T5-8 sparc system failed to boot with:
      
        pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00
        pci_bus 0000:00: root bus resource [io  0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff])
        pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff])
        pci 0000:00:01.0: can't claim BAR 15 [mem 0x100000000-0x4afffffff pref]: no compatible bridge window
      
      Note that we don't know about a host bridge aperture that contains
      BAR 15.  OF does report a MEM64 aperture, but before this patch,
      pci_determine_mem_io_space() ignored it.
      
      Add support for host bridge apertures with 64-bit PCI addresses.  Also
      set IORESOURCE_MEM_64 for PCI device and bridge resources in PCI 64-bit
      memory space.
      
      Sparc doesn't actually print the device and bridge resources, but after
      this patch, we should have the equivalent of this:
      
        pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00
        pci_bus 0000:00: root bus resource [io  0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff])
        pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff])
        pci_bus 0000:00: root bus resource [mem 0x800100000000-0x8007ffffffff] (bus address [0x100000000-0x7ffffffff])
        pci 0000:00:01.0:   bridge window [mem 0x800100000000-0x8004afffffff 64bit pref]
      
      [bhelgaas: changelog, URL to David's report]
      Fixes: d63e2e1f ("sparc/PCI: Clip bridge windows to fit in upstream windows")
      Link: http://lkml.kernel.org/r/5514391F.2030300@oracle.comReported-by: NDavid Ahern <david.ahern@oracle.com>
      Tested-by: NDavid Ahern <david.ahern@oracle.com>
      Tested-by: NKhalid Aziz <khalid.aziz@oracle.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      af86fa40
  2. 19 5月, 2014 1 次提交
  3. 17 11月, 2012 1 次提交
  4. 14 6月, 2012 1 次提交
  5. 17 3月, 2011 1 次提交
  6. 24 7月, 2010 1 次提交
  7. 05 12月, 2008 1 次提交
    • S
      sparc,sparc64: unify kernel/ · a88b5ba8
      Sam Ravnborg 提交于
      o Move all files from sparc64/kernel/ to sparc/kernel
        - rename as appropriate
      o Update sparc/Makefile to the changes
      o Update sparc/kernel/Makefile to include the sparc64 files
      
      NOTE: This commit changes link order on sparc64!
      
      Link order had to change for either of sparc32 and sparc64.
      And assuming sparc64 see more testing than sparc32 change link
      order on sparc64 where issues will be caught faster.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a88b5ba8
  8. 12 9月, 2008 1 次提交
  9. 11 9月, 2008 2 次提交
  10. 02 9月, 2008 1 次提交
  11. 02 5月, 2008 1 次提交
    • D
      sparc64: Stop creating dummy root PCI host controller devices. · c26d3c01
      David S. Miller 提交于
      It just creates confusion, errors, and bugs.
      
      For one thing, this can cause dup sysfs or procfs nodes to get
      created:
      
      [    1.198015] proc_dir_entry '00.0' already registered
      [    1.198036] Call Trace:
      [    1.198052]  [00000000004f2534] create_proc_entry+0x7c/0x98
      [    1.198092]  [00000000005719e4] pci_proc_attach_device+0xa4/0xd4
      [    1.198126]  [00000000007d991c] pci_proc_init+0x64/0x88
      [    1.198158]  [00000000007c62a4] kernel_init+0x190/0x330
      [    1.198183]  [0000000000426cf8] kernel_thread+0x38/0x48
      [    1.198210]  [00000000006a0d90] rest_init+0x18/0x5c
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c26d3c01
  12. 24 4月, 2008 2 次提交
  13. 14 10月, 2007 2 次提交
  14. 09 5月, 2007 5 次提交
  15. 26 4月, 2007 4 次提交
  16. 24 6月, 2006 1 次提交
  17. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4