summaryrefslogtreecommitdiffstats
path: root/arch/sparc64
Commit message (Collapse)AuthorAgeFilesLines
* Remove __attribute__((weak)) from sys_pipe/sys_pipe2Heiko Carstens2009-01-182-3/+3
| | | | | | | | | | | | | | | | commit 1134723e96f6e2abcf8bfd7a2d1c96fcc323ef35 upstream. Remove __attribute__((weak)) from common code sys_pipe implemantation. IA64, ALPHA, SUPERH (32bit) and SPARC (32bit) have own implemantations with the same name. Just rename them. For sys_pipe2 there is no architecture specific implementation. Cc: Richard Henderson <rth@twiddle.net> Cc: David S. Miller <davem@davemloft.net> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sparc64: Sync FPU state in VIS emulation handler.Hong H. Pham2008-12-131-0/+2
| | | | | | | | | | | | [ Upstream commit 410d2c8187ed969238ba98008c1d57307a56cfd8 ] Copy the FPU state to the task's thread_info->fpregs for the VIS emulation functions to access. Signed-off-by: Hong H. Pham <hong.pham@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sparc64: Fix VIS emulation bugsJoseph Myers2008-12-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 726c12f57d7e3ff43693d88e13b1ff02464c75d3 ] 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: Joseph Myers <joseph@codesourcery.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sparc64: Fix bug in PTRACE_SETFPREGS64 handling.Chris Torek2008-12-131-1/+1
| | | | | | | | | | | | | | | | [ Upstream commit 5769907ade8dda7002b304c03ef9e4ee5c1e0821 ] From: Chris Torek <chris.torek@windriver.com> >The SPARC64 kernel code for PTRACE_SETFPREGS64 appears to be an exact copy >of that for PTRACE_GETFPREGS64. This means that gdbserver and native >64-bit GDB cannot set floating-point registers. It looks like a simple typo. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sparc64: Fix PCI resource mapping on sparc64Max Dmitrichenko2008-12-131-1/+9
| | | | | | | | | | | | | | | | | | | [ Upstream commit 145e1c0023585e0e8f6df22316308ec61c5066b2 ] 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: Max Dmitrichenko <dmitrmax@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sparc64: Fix offset calculation in compute_size()David S. Miller2008-12-131-1/+1
| | | | | | | | | | | [ Upstream commit b270ee8a9fc9547eb781ce9ccd379450bcf9a204 ] The fault address is somewhere inside of the buffer, not before it. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sparc64: Fix race in arch/sparc64/kernel/trampoline.SAndrea Shepard2008-11-061-4/+14
| | | | | | | | | | | | | | | [ Upstream commit e0037df3852b4b60edbe01f70f4968e4a9fdb272 ] Make arch/sparc64/kernel/trampoline.S in 2.6.27.1 lock prom_entry_lock when calling the PROM. This prevents a race condition that I observed causing a hang on startup on a 12-CPU E4500. I am not subscribed to this list, so please CC me on replies. Signed-off-by: Andrea Shepard <andrea@persephoneslair.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sparc64: Fix missing devices due to PCI bridge test in of_create_pci_dev().David S. Miller2008-09-221-1/+1
| | | | | | | | | | | | | Just like in the arch/sparc64/kernel/of_device.c code fix commit 071d7f4c3b411beae08d27656e958070c43b78b4 ("sparc64: Fix SMP bootup with CONFIG_STACK_DEBUG or ftrace.") we have to check the OF device node name for "pci" instead of relying upon the 'device_type' property being there on all PCI bridges. Tested by Meelis Roos, and confirmed to make the PCI QFE devices reappear on the E3500 system. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Fix disappearing PCI devices on e3500.David S. Miller2008-09-201-5/+4
| | | | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
* sparc64: Fix SMP bootup with CONFIG_STACK_DEBUG or ftrace.David S. Miller2008-09-162-3/+5
| | | | | | | | | | | | | | | | | Based upon a report by Meelis Roos. Any function call can try to access the current thread register via the _mcount hooks when the kernel is built with -pg (via ftrace or STACK_DEBUG). That can't be setup properly very early on during the bootup of other cpus for sun4u and some early sun4v systems. So add notrace markers to these specific functions, so that _mcount doesn't get invoked too early. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Fix OOPS in psycho_pcierr_intr_other().David S. Miller2008-09-161-3/+5
| | | | | | | | | | | | We no longer put the top-level PCI controller device into the PCI layer device list. So pbm->pci_bus->self is always NULL. Therefore, use direct PCI config space accesses to get at the PCI controller's PCI_STATUS register. Tested by Meelis Roos. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc: Fix user_regset 'n' field values.David S. Miller2008-09-121-4/+4
| | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
* sparc64: Fix PCI error interrupt registry on PSYCHO.David S. Miller2008-09-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
* sparc64: Fix interrupt register calculations on Psycho and Sabre.David S. Miller2008-09-101-98/+6
| | | | | | | Use the IMAP offset calculation for OBIO devices as documented in the programmer's manual. Which is "0x10000 + ((ino & 0x1f) << 3)" Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Disable timer interrupts in fixup_irqs().David S. Miller2008-09-081-0/+2
| | | | | | | | | | | When a CPU is offlined, we leave the timer interrupts disabled because fixup_irqs() does not explicitly take care of that case. Fix this by invoking tick_ops->disable_irq(). Based upon analysis done by Paul E. McKenney. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Prevent sparc64 from invoking irq handlers on offline CPUsPaul E. McKenney2008-09-031-4/+4
| | | | | | | | | | Make sparc64 refrain from clearing a given to-be-offlined CPU's bit in the cpu_online_mask until it has processed pending irqs. This change prevents other CPUs from being blindsided by an apparently offline CPU nevertheless changing globally visible state. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Fix IPI call locking.David S. Miller2008-09-031-6/+4
| | | | | | | | | | When I switched sparc64 over to the generic helpers for smp_call_function(), I didn't convert the dinky call_lock we had. Use ipi_call_lock() and ipi_call_unlock(). Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: setup_valid_addr_bitmap_from_pavail() should be __initDavid S. Miller2008-08-301-1/+1
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc: Fix resource flags for PCI children in OF device tree.David S. Miller2008-08-281-6/+14
| | | | | | | | | | | | When a device is under an EBUS or ISA bus, the resource flags don't get set properly. Fix this by re-evaluating the resource flags at each level of bus as we apply ranges on the way to the root. And let PCI override any existing flags setting, but don't let the default flags calculator make such overrides. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Make NUMA depend upon SMP.David S. Miller2008-08-241-0/+1
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Fix cmdline_memory_size handling bugs.David S. Miller2008-08-141-8/+19
| | | | | | | | | | | | | | | | | | | | | | | First, lmb_enforce_memory_limit() interprets it's argument (mostly, heh) as a size limit not an address limit. So pass the raw cmdline_memory_size value into it. And we don't need to check it against zero, lmb_enforce_memory_limit() does that for us. Next, free_initmem() needs special handling when the kernel command line trims the available memory. The problem case is if the trimmed out memory is where the kernel image itself resides. When that memory is trimmed out, we don't add those physical ram areas to the sparsemem active ranges, amongst other things. Which means that this free_initmem() code will free up invalid page structs, resulting in either crashes or hangs. Just quick fix this by not freeing initmem at all if "mem=" was given on the boot command line. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Fix overshoot in nid_range().David S. Miller2008-08-141-0/+3
| | | | | | | If 'start' does not begin on a page boundary, we can overshoot past 'end'. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Handle stack trace attempts before irqstacks are setup.David S. Miller2008-08-132-20/+21
| | | | | | | | | | Things like lockdep can try to do stack backtraces before the irqstack blocks have been setup. So don't try to match their ranges so early on. Also, remove unused variable in save_stack_trace(). Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Implement IRQ stacks.David S. Miller2008-08-127-30/+157
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Fix recursion in stack overflow detection handling.David S. Miller2008-08-121-3/+14
| | | | | | | | | | | The calls down into prom_printf() when we detect an overflowed stack can recurse again since the overflow stack will be "below" the current kernel stack limit. Prevent this by just returning straight if we are on the stack overflow safe stack already. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Don't MAGIC_SYSRQ ifdef smp_fetch_global_regs and support code.David S. Miller2008-08-092-6/+0
| | | | | | | | | | | | Based upon a report and initial patch by Friedrich Oslage. The intention is to provide this facility for __trigger_all_cpu_backtrace even if MAGIC_SYSRQ is not set. The only part that should have MAGIC_SYSRQ ifdef protection is the sparc_globalreg_op sysrq regitration and immediate code. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Fix end-of-stack checking in save_stack_trace().David S. Miller2008-08-071-2/+4
| | | | | | | | | | Bug reported by Alexander Beregalov. Before we dereference the stack frame or try to peek at the pt_regs magic value, make sure the entire object is within the kernel stack bounds. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc: don't use asm/of_device.hStephen Rothwell2008-08-079-9/+9
| | | | | | | Use linux/of_device.h instead. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Use kernel/uid16.c helpers instead of own copy.David S. Miller2008-08-062-186/+10
| | | | | | Noticed by Adrian Bunk. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Remove all cpumask_t local variables in xcall dispatch.David S. Miller2008-08-041-24/+9
| | | | | | | | | All of the xcall delivery implementation is cpumask agnostic, so we can pass around pointers to const cpumask_t objects everywhere. The sad remaining case is the argument to arch_send_call_function_ipi(). Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Kill error_mask from hypervisor_xcall_deliver().David S. Miller2008-08-041-13/+7
| | | | | | | | It can eat up a lot of stack space when NR_CPUS is large. We retain some of it's functionality by reporting at least one of the cpu's which are seen in error state. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Build cpu list and mondo block at top-level xcall_deliver().David S. Miller2008-08-041-44/+69
| | | | | | | | | | Then modify all of the xcall dispatch implementations get passed and use this information. Now all of the xcall dispatch implementations do not need to be mindful of details such as "is current cpu in the list?" and "is cpu online?" Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Disable local interrupts around xcall_deliver_impl() invocation.David S. Miller2008-08-041-17/+15
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Make all xcall_deliver's go through common helper function.David S. Miller2008-08-041-4/+9
| | | | | | | This just facilitates the next changeset where we'll be building the cpu list and mondo block in this helper function. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Always allocate the send mondo blocks, even on non-sun4v.David S. Miller2008-08-041-3/+16
| | | | | | | The idea is that we'll use this cpu list array and mondo block even for non-hypervisor platforms. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Make smp_cross_call_masked() take a cpumask_t pointer.David S. Miller2008-08-041-7/+11
| | | | | | | | | | Ideally this could be simplified further such that we could pass the pointer down directly into the xcall_deliver() implementation. But if we do that we need to do the "cpu_online(cpu)" and "cpu != self" checks down in those functions. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Directly call xcall_deliver() in smp_start_sync_tick_client.David S. Miller2008-08-041-4/+2
| | | | | | We know the cpu is online and not the current cpu here. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Call xcall_deliver() directly in some cases.David S. Miller2008-08-041-23/+10
| | | | | | | | | | | | | | | | | | | | For these cases the callers make sure: 1) The cpus indicated are online. 2) The current cpu is not in the list of indicated cpus. Therefore we can pass a pointer to the mask directly. One of the motivations in this transformation is to make use of "&cpumask_of_cpu(cpu)" which evaluates to a pointer to constant data in the kernel and thus takes up no stack space. Hopefully someone in the future will change the interface of arch_send_call_function_ipi() such that it passes a const cpumask_t pointer so that this will optimize ever further. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Use cpumask_t pointers and for_each_cpu_mask_nr() in xcall_deliver.David S. Miller2008-08-041-18/+21
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Use xcall_deliver() consistently.David S. Miller2008-08-041-23/+17
| | | | | | | There remained some spots still vectoring to the appropriate *_xcall_deliver() function manually. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Use function pointer for cross-call sending.David S. Miller2008-08-041-6/+13
| | | | | | Initialize it using the smp_setup_processor_id() hook. Signed-off-by: David S. Miller <davem@davemloft.net>
* arch/sparc64/kernel/signal.c: removed duplicated #includeHuang Weiyi2008-08-041-1/+0
| | | | | | | | Removed duplicated #include <linux/tracehook.h> in arch/sparc64/kernel/signal.c. Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Need to disable preemption around smp_tsb_sync().David S. Miller2008-08-041-1/+4
| | | | | | | | | Based upon a bug report by Mariusz Kozlowski It uses smp_call_function_masked() now, which has a preemption-disabled requirement. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Do not clobber %g7 in setcontext() trap.David S. Miller2008-07-311-2/+4
| | | | | | | | | That's the userland thread register, so we should never try to change it like this. Based upon glibc bug nptl/6577 and suggestions by Jakub Jelinek. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Kill __show_regs().David S. Miller2008-07-313-28/+3
| | | | | | | | | | | | | | | The story is that what we used to do when we actually used smp_report_regs() is that if you specifically only wanted to have the current cpu's registers dumped you would call "__show_regs()" otherwise you would call show_regs() which also invoked smp_report_regs(). Now that we killed off smp_report_regs() there is no longer any reason to have these two routines, just show_regs() is sufficient. Also kill off a stray declaration of show_regs() in sparc64_ksym.c Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Kill smp_report_regs().David S. Miller2008-07-314-56/+0
| | | | | | | | All the call sites are #if 0'd out and we have a much more useful global cpu dumping facility these days. smp_report_regs() is way too verbose to be usable. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Kill VERBOSE_SHOWREGS code.David S. Miller2008-07-311-35/+0
| | | | | | | It just clutters everything up and even though I wrote that hack I can't remember having used it in the last 5 years or so. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Hook up trigger_all_cpu_backtrace().David S. Miller2008-07-301-2/+8
| | | | | | | We already have code that does this, but it is only currently attached to sysrq-'y'. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Make global reg dumping even more useful.David S. Miller2008-07-302-7/+36
| | | | | | | | | | Record one more level of stack frame program counter. Particularly when lockdep and all sorts of spinlock debugging is enabled, figuring out the caller of spin_lock() is difficult when the cpu is stuck on the lock. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Kill isa_bus_type.David S. Miller2008-07-291-5/+0
| | | | | | | I forgot to delete this when I removed the ISA bus layer from the sparc ports. Signed-off-by: David S. Miller <davem@davemloft.net>