1. 13 12月, 2008 3 次提交
    • R
      cpumask: convert struct clock_event_device to cpumask pointers. · 320ab2b0
      Rusty Russell 提交于
      Impact: change calling convention of existing clock_event APIs
      
      struct clock_event_timer's cpumask field gets changed to take pointer,
      as does the ->broadcast function.
      
      Another single-patch change.  For safety, we BUG_ON() in
      clockevents_register_device() if it's not set.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@elte.hu>
      320ab2b0
    • R
      cpumask: make irq_set_affinity() take a const struct cpumask · 0de26520
      Rusty Russell 提交于
      Impact: change existing irq_chip API
      
      Not much point with gentle transition here: the struct irq_chip's
      setaffinity method signature needs to change.
      
      Fortunately, not widely used code, but hits a few architectures.
      
      Note: In irq_select_affinity() I save a temporary in by mangling
      irq_desc[irq].affinity directly.  Ingo, does this break anything?
      
      (Folded in fix from KOSAKI Motohiro)
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
      Acked-by: NIngo Molnar <mingo@redhat.com>
      Cc: ralf@linux-mips.org
      Cc: grundler@parisc-linux.org
      Cc: jeremy@xensource.com
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      0de26520
    • R
      cpumask: centralize cpu_online_map and cpu_possible_map · 98a79d6a
      Rusty Russell 提交于
      Impact: cleanup
      
      Each SMP arch defines these themselves.  Move them to a central
      location.
      
      Twists:
      1) Some archs (m32, parisc, s390) set possible_map to all 1, so we add a
         CONFIG_INIT_ALL_POSSIBLE for this rather than break them.
      
      2) mips and sparc32 '#define cpu_possible_map phys_cpu_present_map'.
         Those archs simply have phys_cpu_present_map replaced everywhere.
      
      3) Alpha defined cpu_possible_map to cpu_present_map; this is tricky
         so I just manipulate them both in sync.
      
      4) IA64, cris and m32r have gratuitous 'extern cpumask_t cpu_possible_map'
         declarations.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
      Tested-by: NTony Luck <tony.luck@intel.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Mike Travis <travis@sgi.com>
      Cc: ink@jurassic.park.msu.ru
      Cc: rmk@arm.linux.org.uk
      Cc: starvik@axis.com
      Cc: tony.luck@intel.com
      Cc: takata@linux-m32r.org
      Cc: ralf@linux-mips.org
      Cc: grundler@parisc-linux.org
      Cc: paulus@samba.org
      Cc: schwidefsky@de.ibm.com
      Cc: lethal@linux-sh.org
      Cc: wli@holomorphy.com
      Cc: davem@davemloft.net
      Cc: jdike@addtoit.com
      Cc: mingo@redhat.com
      98a79d6a
  2. 05 12月, 2008 1 次提交
  3. 04 12月, 2008 1 次提交
    • J
      sparc64: Fix VIS emulation bugs · 726c12f5
      Joseph Myers 提交于
      This patch fixes some bugs in VIS emulation that cause the GCC test
      failure
      
      FAIL: gcc.target/sparc/pdist-3.c execution test
      
      for both 32-bit and 64-bit testing on hardware lacking these
      instructions.  The emulation code for the pdist instruction uses
      RS1(insn) for both source registers rs1 and rs2, which is obviously
      wrong and leads to the instruction doing nothing (the observed
      problem), and further inspection of the code shows that RS1 uses a
      shift of 24 and RD a shift of 25, which clearly cannot both be right;
      examining SPARC documentation indicates the correct shift for RS1 is
      14.
      
      This patch fixes the bug if single-stepping over the affected
      instruction in the debugger, but not if the testcase is run
      standalone.  For that, Wind River has another patch I hope they will
      send as a followup to this patch submission.
      Signed-off-by: NJoseph Myers <joseph@codesourcery.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      726c12f5
  4. 03 12月, 2008 1 次提交
  5. 01 12月, 2008 3 次提交
  6. 20 11月, 2008 1 次提交
  7. 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
  8. 31 10月, 2008 1 次提交
  9. 30 10月, 2008 1 次提交
  10. 23 10月, 2008 3 次提交
  11. 17 10月, 2008 4 次提交
  12. 16 10月, 2008 1 次提交
  13. 13 10月, 2008 2 次提交
  14. 23 9月, 2008 1 次提交
  15. 21 9月, 2008 1 次提交
    • D
      sparc64: Fix disappearing PCI devices on e3500. · 7ee766d8
      David S. Miller 提交于
      Based upon a bug report by Meelis Roos.
      
      The OF device layer builds properties by matching bus types and
      applying 'range' properties as appropriate, up to the root.
      
      The match for "PCI" busses is looking at the 'device_type' property,
      and this does work %99 of the time.
      
      But on an E3500 system with a PCI QFE card, the DEC 21153 bridge
      sitting above the QFE network interface devices has a 'name' of "pci",
      but it completely lacks a 'device_type' property.  So we don't match
      it as a PCI bus, and subsequently we end up with no resource values at
      all for the devices sitting under that DEC bridge.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ee766d8
  16. 17 9月, 2008 2 次提交
  17. 13 9月, 2008 3 次提交
    • D
      sparc: Fix user_regset 'n' field values. · 7d4ee289
      David S. Miller 提交于
      As noticed by Russell King, we were not setting this properly
      to the number of entries, but rather the total size.
      
      This results in the core dumping code allocating waayyyy too
      much memory.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d4ee289
    • D
      sparc64: Fix PCI error interrupt registry on PSYCHO. · 80a56ab6
      David S. Miller 提交于
      We need to pass IRQF_SHARED, otherwise we get things like:
      
      IRQ handler type mismatch for IRQ 33
      current handler: PSYCHO_UE
      Call Trace:
       [000000000048394c] request_irq+0xac/0x120
       [00000000007c5f6c] psycho_scan_bus+0x98/0x158
       [00000000007c2bc0] pcibios_init+0xdc/0x12c
       [0000000000426a5c] do_one_initcall+0x1c/0x160
       [00000000007c0180] kernel_init+0x9c/0xfc
       [0000000000427050] kernel_thread+0x30/0x60
       [00000000006ae1d0] rest_init+0x10/0x60
      
      on e3500 and similar systems.
      
      On a single board, the UE interrupts of two Psycho nodes
      are funneled through the same interrupt, from of_debug=3
      dump:
      
      /pci@b,4000: direct translate 2ee --> 21
       ...
      /pci@b,2000: direct translate 2ee --> 21
      
      Decimal "33" mentioned above is the hex "21" mentioned here.
      
      Thanks to Meelis Roos for dumps and testing.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80a56ab6
    • D
      sparc: Fix user_regset 'n' field values. · 3c503701
      David S. Miller 提交于
      As noticed by Russell King, we were not setting this properly
      to the number of entries, but rather the total size.
      
      This results in the core dumping code allocating waayyyy too
      much memory.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c503701
  18. 12 9月, 2008 10 次提交