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>
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>
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>
This reverts commit e669dae614, since it
is incomplete, and clashes with fuller patches and the sparc 32/64
unification effort.
Requested-by: David Miller <davem@davemloft.net>
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
switch to __init for those; unlike powerpc sparc has no hotplug support
for that stuff and their ->probe() tends to call __init functions while
being declared __devinit.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds the sparc syscall hookups.
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Ulrich Drepper <drepper@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
sparc64: Add missing null terminating entry to bq4802_match[].
sparc: use the new byteorder headers
rtc-m48t59: shift zero year to 1968 on sparc (rev 2)
dbri: check dma_alloc_coherent errors
sparc64: remove byteshifting from out* helpers
Shift the first year to 1968 for Sun SPARC machines.
Move this logic from platform specific files to rtc driver
as this fixes problems with calculating a century bit.
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Tested-by: Alexander Beregalov
Signed-off-by: David S. Miller <davem@davemloft.net>
The entire file of ftrace.c in the arch code needs to be marked
as notrace. It is much cleaner to do this from the Makefile with
CFLAGS_REMOVE_ftrace.o.
[ powerpc already had this in its Makefile. ]
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The arch dependent function ftrace_mcount_set was only used by the daemon
start up code. This patch removes it.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
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>
This is a preparation patch for introducing a generic iommu_num_pages function.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Acked-by: David S. Miller <davem@davemloft.net>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Nothing arch specific in get/settimeofday. The details of the timeval
conversion varied a little from arch to arch, but all with the same
results.
Also add an extern declaration for sys_tz to linux/time.h because externs
in .c files are fowned upon. I'll kill the externs in various other files
in a sparate patch.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net> [ sparc bits ]
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Kyle McMartin <kyle@mcmartin.ca>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Grant Grundler <grundler@parisc-linux.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
struct stat / compat_stat is the same on all architectures, so
cp_compat_stat should be, too.
Turns out it is, except that various architectures have slightly and some
high2lowuid/high2lowgid or the direct assignment instead of the
SET_UID/SET_GID that expands to the correct one anyway.
This patch replaces the arch-specific cp_compat_stat implementations with
a common one based on the x86-64 one.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net> [ sparc bits ]
Acked-by: Kyle McMartin <kyle@mcmartin.ca> [ parisc bits ]
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As policy->governor is already set to CPUFREQ_DEFAULT_GOVERNOR in the
(always built-in) cpufreq core, we do not need to set it in the drivers.
This fixes the sparc64 allmodconfig build failure.
Also, remove a totally useles setting of ->policy in cpufreq-pxa3xx.c.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Otherwise GCC can try to do the register read before the guarding test
on us3mc_platform() being true.
If that happens we can take an exception, because %ver register reads
are not allowed in privileged more on hypervisor platforms.
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit e545a6140b ("kernel/cpu.c: create
a CPU_STARTING cpu_chain notifier") added a notify_cpu_starting()
notifier event, and hit every arch except sparc64.
Fix that missed case.
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
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>
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>
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>
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>
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>
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>
1) Declare pci_poke_* in pci_impl.h
2) of_create_pci_dev() should be static
3) ->setup_msi_irq() wants an unsigned int pointer not a plain
int one
4) void value expression return in arch_teardown_msi_irq()
Signed-off-by: David S. Miller <davem@davemloft.net>
1) Using "clock" as a local variable shadows a global variable of
the same name declared in linux/clocksource.h
2) rtc_cmos_resource should be static
Signed-off-by: David S. Miller <davem@davemloft.net>
Lots of shadowed local variables and global_reg_snapshot[] needs
an extern declaration in asm/ptrace_64.h.
Signed-off-by: David S. Miller <davem@davemloft.net>
The IOMMU and streaming cache error interrogation is moved here
as well as the PCI error interrupt handler.
Signed-off-by: David S. Miller <davem@davemloft.net>
These are very similar chips, in fact they are identical in some
macro blocks.
So start commonizing code which they can share. We begin with
the IOMMU initialization sequence.
Signed-off-by: David S. Miller <davem@davemloft.net>
It is just used as a parent to encapsulate two PBM objects.
But that layout is only really relevant and necessary for
psycho PCI controllers, which unlike all the others share
a single IOMMU instance between sibling PCI busses.
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
