1. 23 2月, 2010 2 次提交
  2. 21 2月, 2010 1 次提交
  3. 18 2月, 2010 1 次提交
  4. 15 12月, 2009 1 次提交
  5. 05 11月, 2009 1 次提交
  6. 10 8月, 2009 1 次提交
  7. 18 6月, 2009 1 次提交
  8. 09 1月, 2009 1 次提交
  9. 07 1月, 2009 1 次提交
    • S
      sparc64: Use unsigned long long for u64. · 90181136
      Sam Ravnborg 提交于
      Andrew Morton wrote:
      
          People keep on doing
      
                  printk("%llu", some_u64);
      
          testing it only on x86_64 and this generates a warning storm on
          powerpc, sparc64, etc.  Because they use `long', not `long long'.
      
          Quite a few 64-bit architectures are using `long' for their
          s64/u64 types.  We should convert them all to `long long'.
      
      Update types.h so we use unsigned long long for u64 and
      fix all warnings in sparc64 code.
      Tested with an allnoconfig, defconfig and allmodconfig builds.
      
      This patch introduces additional warnings in several drivers.
      These will be dealt with in separate patches.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90181136
  10. 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
  11. 02 11月, 2008 1 次提交
    • M
      sparc64: Fix PCI resource mapping on sparc64 · 5769907a
      Max Dmitrichenko 提交于
      There is a problem discovered in recent versions of ATI Mach64 driver
      in X.org on sparc64 architecture. In short, the driver fails to mmap
      MMIO aperture (PCI resource #2).
      
      I've found that kernel's __pci_mmap_make_offset() returns EINVAL. It
      checks whether user attempts to mmap more than the resource length,
      which is 0x1000 bytes in our case. But PAGE_SIZE on SPARC64 is 0x2000
      and this is what actually is being mmaped. So __pci_mmap_make_offset()
      failed for this PCI resource.
      Signed-off-by: NMax Dmitrichenko <dmitrmax@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5769907a
  12. 23 9月, 2008 1 次提交
  13. 12 9月, 2008 1 次提交
  14. 11 9月, 2008 2 次提交
  15. 02 9月, 2008 1 次提交
  16. 30 8月, 2008 8 次提交
  17. 26 8月, 2008 1 次提交
  18. 22 7月, 2008 1 次提交
  19. 08 7月, 2008 1 次提交
  20. 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
  21. 27 4月, 2008 1 次提交
  22. 24 4月, 2008 1 次提交
  23. 19 2月, 2008 1 次提交
  24. 27 12月, 2007 1 次提交
  25. 23 10月, 2007 1 次提交
  26. 14 10月, 2007 1 次提交
  27. 12 9月, 2007 1 次提交
  28. 31 8月, 2007 1 次提交
    • D
      [SPARC64]: Fix several bugs in MSI handling. · 5f92c329
      David S. Miller 提交于
      1) sun4{u,v}_build_msi() have improper return value handling.
      
         We should always return negative error codes, instead of
         using the magic value "0" which could in fact be a valid
         MSI number.
      
      2) sun4{u,v}_build_msi() should return -ENOMEM instead of
         calling prom_prom() halt with kzalloc() of the interrupt
         data fails.
      
      3) We 'remembered' the MSI number using a singleton in the
         struct device archdata area, this doesn't work for MSI-X
         which can cause multiple MSIs assosciated with one device.
      
         Delete that archdata member, and instead store the MSI
         number in the IRQ chip data area.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f92c329
  29. 30 7月, 2007 2 次提交
    • D
      [SPARC64]: Fix conflicts in SBUS/PCI/EBUS/ISA DMA handling. · ad7ad57c
      David S. Miller 提交于
      Fully unify all of the DMA ops so that subordinate bus types to
      the DMA operation providers (such as ebus, isa, of_device) can
      work transparently.
      
      Basically, we just make sure that for every system device we
      create, the dev->archdata 'iommu' and 'stc' fields are filled
      in.
      
      Then we have two platform variants of the DMA ops, one for SUN4U which
      actually programs the real hardware, and one for SUN4V which makes
      hypervisor calls.
      
      This also fixes the crashes in parport_pc on sparc64, reported by
      Meelis Roos.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad7ad57c
    • D
      [SPARC64]: Fix sun4u PCI config space accesses on sun4u. · a2d6ea01
      David S. Miller 提交于
      Don't provide fake PCI config space for sun4u.
      
      Also, put back the funny host controller space handling that
      at least Sabre needs.  You have to read PCI host controller
      registers at their nature size otherwise you get zeros instead
      of correct values.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2d6ea01
  30. 12 7月, 2007 1 次提交