aboutsummaryrefslogtreecommitdiff
path: root/arch/sparc64/kernel
AgeCommit message (Collapse)Author
2007-04-26[SPARC64]: Kill PBM ranges software state.David S. Miller
It is only used in one spot and we can just fetch the OF property right there. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Kill PBM intmap software state.David S. Miller
Set but never used. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Consolidate PCI mem/io resource determination.David S. Miller
It can be done for every PCI configuration using OF properties. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Fix sabre pci controllers with new probing scheme.David S. Miller
The SIMBA APB bridge is strange, it is a PCI bridge but it lacks some standard OF properties, in particular it lacks a 'ranges' property. What you have to do is read the IO and MEM range registers in the APB bridge to determine the ranges handled by each bridge. So fill in the bus resources by doing that. Since we now handle this quirk in the generic PCI and OF device probing layers, we can flat out eliminate all of that code from the sabre pci controller driver. In fact we can thus eliminate completely another quirk of the sabre driver. It tried to make the two APB bridges look like PBMs but that makes zero sense now (and it's questionable whether it ever made sense). So now just use pbm_A and probe the whole PCI hierarchy using that as the root. This simplification allows many future cleanups to occur. Also, I've found yet another quirk that needs to be worked around while testing this. You can't use the 'class-code' OF firmware property, especially for IDE controllers. We have to read the value out of PCI config space or else we'll see the value the device was showing before it was programmed into native mode. I'm starting to think it might be wise to just read all of the values out of PCI config space instead of using the OF properties. :-/ Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Fix obppath pci device sysfs creation.David S. Miller
Need to traverse recursively down child busses else we only get the file created under devices at the top-level. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Minor cleanups to schizo pci controller driver.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Internalize pci_memspace_mask.David S. Miller
The only user was bus_dvma_to_mem() which is no longer used by any driver, so kill that, and the export of pci_memspace_mask. The only user now is the PCI mmap support code. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Probe PCI bus using OF device tree.David S. Miller
Almost entirely taken from the 64-bit PowerPC PCI code. This allowed to eliminate a ton of cruft from the sparc64 PCI layer. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64] isa: Convert to use pci_device_to_OF_node().David S. Miller
Also, do not try to compute resources by hand, instead use the pre-computed ones in the of_device. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64] ebus: Convert to use pci_device_to_OF_node().David S. Miller
Also, we don't need to store or use the PBM so kill that from the linux_ebus. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC]: Use strcasecmp for OFW property name comparisons.David S. Miller
This allows us to simplify sharing code with powerpc which has properties that have various forms of capitalization when on the sparc64 side the property is all lower-case. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC/64]: constify of_get_property returnStephen Rothwell
Finally, we actually change the functions themselves. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: constify of_get_property return: arch/sparc64Stephen Rothwell
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Small cleanups time.cTony Breeds
- Removes days_in_mo[], as it's almost identical to month_days[] - Use the leapyear() macro - Line length wrapping. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Fix sparc64_next_event() error return.David S. Miller
It should return an error code not a boolean. Based upon an hpet timer fix by Thomas Gleixner. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Add clocksource/clockevents support.David S. Miller
I'd like to thank John Stul and others for helping me along the way. A lot of cleanups fell out of this. For example, the get_compare() tick_op was totally unused, so was deleted. And the most often used tick_op members were grouped together for cache-friendlyness. The sparc64 TSC is given to the kernel as a one-shot timer. tick_ops->init_timer() simply turns off the privileged bit in the tick register (when possible), and disables the interrupt by setting bit 63 in the compare register. The ->disable_irq() op also sets this bit. tick_ops->add_compare() is changed to: 1) Add the given delta to "tick" not to "compare" 2) Return a boolean which, if true, means that the tick value read after writing the compare value was found to have incremented past the initial tick value. This mirrors logic used in the HPET driver's ->next_event() method. Each tick_ops implementation also now provides a name string. And we feed this into the clocksource and clockevents layers. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Add tick_nohz_{stop,restart}_sched_tick() calls to cpu_idle().David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Unify timer interrupt handler.David S. Miller
Things were scattered all over the place, split between SMP and non-SMP. Unify it all so that dyntick support is easier to add. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Synchronize RTC clock via timer just like x86.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-13[SPARC64]: Fix inline directive in pci_iommu.cTom "spot" Callaway
While building a test kernel for the new esp driver (against git-current), I hit this bug. Trivial fix, put the inline declaration in the right place. :) Signed-off-by: Tom "spot" Callaway <tcallawa@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-13[SPARC64]: Fix arg passing to compat_sys_ipc().David S. Miller
Do not sign extend args using the sys32_ipc stub, that is buggy and unnecessary. Based upon an excellent report by Mikael Pettersson. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-12[SPARC]: Fix section mismatch warnings in pci.c and pcic.cRobert Reif
Fix section mismatch in arch/sparc/kernel/pcic.c and arch/sparc64/kernel/pci.c. Signed-off-by: Robert Reif <reif@earthlink.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-12[SPARC]: avoid CHILD_MAX and OPEN_MAX constantsRoland McGrath
I don't figure anyone really cares about SunOS syscall emulation, and I certainly don't. But I'm getting rid of uses of the OPEN_MAX and CHILD_MAX compile-time constant, and these are almost the only ones. OPEN_MAX is a bogus constant with no meaning about anything. The RLIMIT_NOFILE resource limit is what sysconf (_SC_OPEN_MAX) actually wants to return. The CHILD_MAX cases weren't actually using anything I want to get rid of, but I noticed that they are there and are wrong too. The CHILD_MAX value is not really unlimited as a -1 return from sysconf indicates. The RLIMIT_NPROC resource limit is what sysconf (_SC_CHILD_MAX) wants to return. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-11[SPARC64]: Fix SBUS IOMMU allocation code.David S. Miller
There are several IOMMU allocator bugs. Instead of trying to fix this overly complicated code, just mirror the PCI IOMMU arena allocator which is very stable and well stress tested. I tried to make the code as identical as possible so we can switch sun4u PCI and SBUS over to a common piece of IOMMU code. All that will be need are two callbacks, one to do a full IOMMU flush and one to do a streaming buffer flush. This patch gets rid of a lot of hangs and mysterious crashes on SBUS sparc64 systems, at least for me. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-03-19[SPARC64]: store-init needs trailing membar.David S. Miller
The manual says that it is required and we actually have crash reports where loads see stale data due to not having membars here. In one case the networking does: memset(skb, 0, offsetof(struct sk_buff, truesize)); and then some code later checks skb->nohdr for zero, but it's still the value that was there before the memset(). Note that arch/sparc64/lib/xor.S already got this right. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-03-16[SPARC64]: Get DEBUG_PAGEALLOC working again.David S. Miller
We have to make sure to use base-pagesize TLB entries even during the early transition period where we need TLB miss handling but don't have the kernel page tables setup yet for the linear region. Also, it is necessary therefore to not use the 4MB TSB for these translations, and instead use the normal kernel TSB. This allows us to also get rid of the 4MB tsb for debug builds which shrinks the kernel a little bit. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-03-12[SPARC]: Hook up missing syscalls.David S. Miller
sys_mbind sys_get_mempolicy sys_set_mempolicy sys_kexec_load sys_move_pages sys_getcpu sys_epoll_pwait This work is largely a result of David Woodhouse's most excellent missing syscalls patch. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-03-10[SPARC64]: Fix atomicity of TIF update in flush_thread()Mathieu Desnoyers
Fix atomicity of TIF update in flush_thread() for sparc64 Fixes correctly the race by using *_ti_thread_flag. Race : parent process executing : sys_ptrace() (lock_kernel()) (ptrace_get_task_struct(pid)) arch_ptrace() ptrace_detach() ptrace_disable(child); clear_singlestep(child); clear_tsk_thread_flag(child, TIF_SINGLESTEP); (which clears the TIF_SINGLESTEP flag atomically from a different process) (put_task_struct(child)) (unlock_kernel()) And at the same time, in the child process : sys_execve() do_execve() search_binary_handler() load_elf_binary() flush_old_exec() flush_thread() doing a non-atomic thread flag update Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-03-02[SPARC]: Provide pci_device_to_OF_node() just like powerpc.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-03-02[SPARC]: Handle unresolvable resources better in of_device.cDavid S. Miller
Just leave them as zero if we couldn't calculate it. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-03-02[SPARC]: Fix bus handling in build_device_resources().David S. Miller
We mistakedly modify 'bus' in the innermost loop. What should happen is that at each register index iteration, we start with the same 'bus'. So preserve it's value at the top level, and use a loop local variable 'dbus' for iteration. This bug causes registers other than the first to be decoded improperly. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-27[SPARC64]: Fix PCI interrupts on E450 et al.David S. Miller
When the PCI controller OBP node lacks an interrupt-map and interrupt-map-mask property, we need to form the INO by hand. The PCI swizzle logic was not doing that properly. This was a regression added by the of_device code. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-26[SPARC64]: Fix arch_teardown_msi_irq().David S. Miller
Need to use get_irq_msi() not get_irq_data(). Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-26[SPARC64]: virt_irq_free only needed when CONFIG_PCI_MSIDavid S. Miller
Noticed by Meelis Roos. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-12[SPARC]: Re-export saved_command_line to modules.David S. Miller
This reverts some bogosity from the dynamic command-line changes made on sparc32 and sparc64. Drivers such as drivers/sbus/char/openprom.c reference saved_command_line, and can be modular. The boot_command_line is __initdata, yet the dynamic command-line changes add modular exports of that symbol, obviously wrong. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-12[PATCH] mark struct file_operations const 2Arjan van de Ven
Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch accidental writes at compile time to these shared resources. [akpm@osdl.org: sparc64 fix] Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-12[PATCH] Dynamic kernel command-line: sparc64Alon Bar-Lev
Rename saved_command_line into boot_command_line. Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-12[PATCH] signal: use kill_pgrp not kill_pg in the sunos compatibility codeEric W. Biederman
I am slowly moving to a model where all process killing is struct pid based instead of pid_t based. The sunos compatibility code is one of the last users of the old pid_t based kill_pg in the kernel. By being complete I allow for the future removal of kill_pg from the kernel, which will ensure I don't miss something. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-11Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6: [SPARC64]: Update defconfig. [SPARC64]: Add PCI MSI support on Niagara. [SPARC64] IRQ: Use irq_desc->chip_data instead of irq_desc->handler_data [SPARC64]: Add obppath sysfs attribute for SBUS and PCI devices. [PARTITION]: Add whole_disk attribute.
2007-02-11[PATCH] Common compat_sys_sysinfoKyle McMartin
I noticed that almost all architectures implemented exactly the same sys32_sysinfo... except parisc, where a bug was to be found in handling of the uptime. So let's remove a whole whack of code for fun and profit. Cribbed compat_sys_sysinfo from x86_64's implementation, since I figured it would be the best tested. This patch incorporates Arnd's suggestion of not using set_fs/get_fs, but instead extracting out the common code from sys_sysinfo. Cc: Christoph Hellwig <hch@infradead.org> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-11[PATCH] consolidate line discipline number definitionsTilman Schmidt
The line discipline numbers N_* are currently defined for each architecture individually, but (except for a seeming mistake) identically, in asm/termios.h. There is no obvious reason why these numbers should be architecture specific, nor any apparent relationship with the termios structure. The total number of these, NR_LDISCS, is defined in linux/tty.h anyway. So I propose the following patch which moves the definitions of the individual line disciplines to linux/tty.h too. Three of these numbers (N_MASC, N_PROFIBUS_FDL, and N_SMSBLOCK) are unused in the current kernel, but the patch still keeps the complete set in case there are plans to use them yet. Signed-off-by: Tilman Schmidt <tilman@imap.cc> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-11[PATCH] disable init/initramfs.c: architecturesJean-Paul Saman
Update all arch/*/kernel/vmlinux.lds.S to not include space for initramfs when CONFIG_BLK_DEV_INITRAMFS is not selected. This saves another 4 kbytes on most platfoms (some reserve PAGE_SIZE for initramfs). Signed-off-by: Jean-Paul Saman <jean-paul.saman@nxp.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10[SPARC64]: Add PCI MSI support on Niagara.David S. Miller
This is kind of hokey, we could use the hardware provided facilities much better. MSIs are assosciated with MSI Queues. MSI Queues generate interrupts when any MSI assosciated with it is signalled. This suggests a two-tiered IRQ dispatch scheme: MSI Queue interrupt --> queue interrupt handler MSI dispatch --> driver interrupt handler But we just get one-level under Linux currently. What I'd like to do is possibly stick the IRQ actions into a per-MSI-Queue data structure, and dispatch them form there, but the generic IRQ layer doesn't provide a way to do that right now. So, the current kludge is to "ACK" the interrupt by processing the MSI Queue data structures and ACK'ing them, then we run the actual handler like normal. We are wasting a lot of useful information, for example the MSI data and address are provided with ever MSI, as well as a system tick if available. If we could pass this into the IRQ handler it could help with certain things, in particular for PCI-Express error messages. The MSI entries on sparc64 also tell you exactly which bus/device/fn sent the MSI, which would be great for error handling when no registered IRQ handler can service the interrupt. We override the disable/enable IRQ chip methods in sun4v_msi, so we have to call {mask,unmask}_msi_irq() directly from there. This is another ugly wart. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-10[SPARC64] IRQ: Use irq_desc->chip_data instead of irq_desc->handler_dataDavid S. Miller
Otherwise we can't use the generic MSI code. Furthermore, properly use the {get,set}_irq_foo() abstracted interfaces instead of direct accesses to irq_desc[]->foo. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-10[SPARC64]: Add obppath sysfs attribute for SBUS and PCI devices.Fabio Massimo Di Nitto
Signed-off-by: Fabio Massimo Di Nitto <fabbione@ubuntu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-01-26[SPARC64]: Set g4/g5 properly in sun4v dtlb-prot handling.David S. Miller
Mirror the logic in the sun4u handler, we have to update both registers even when we branch out to window fault fixup handling. The way it works is that if we are in etrap processing a fault already, g4/g5 holds the original fault information. If we take a window spill fault while doing etrap, then we put the window spill fault info into g4/g5 and this is what the top-level fault handler ends up processing first. Then we retry the originally faulting instruction, and process the original fault at that time. This is all necessary because of how constrained the trap registers are in these code paths. These cases trigger very rarely, so even if there is some performance implication it's doesn't happen very often. In fact the rarity is why it took so long to trigger and find this particular bug. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-01-11[PATCH] Change cpu_up and co from __devinit to __cpuinitGautham R Shenoy
Compiling the kernel with CONFIG_HOTPLUG = y and CONFIG_HOTPLUG_CPU = n with CONFIG_RELOCATABLE = y generates the following modpost warnings WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between '_cpu_up' (at offset 0xc0141b7d) and 'cpu_up' WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between '_cpu_up' (at offset 0xc0141b9c) and 'cpu_up' WARNING: vmlinux - Section mismatch: reference to .init.text:__cpu_up from .text between '_cpu_up' (at offset 0xc0141bd8) and 'cpu_up' WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between '_cpu_up' (at offset 0xc0141c05) and 'cpu_up' WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between '_cpu_up' (at offset 0xc0141c26) and 'cpu_up' WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between '_cpu_up' (at offset 0xc0141c37) and 'cpu_up' This is because cpu_up, _cpu_up and __cpu_up (in some architectures) are defined as __devinit AND __cpu_up calls some __cpuinit functions. Since __cpuinit would map to __init with this kind of a configuration, we get a .text refering .init.data warning. This patch solves the problem by converting all of __cpu_up, _cpu_up and cpu_up from __devinit to __cpuinit. The approach is justified since the callers of cpu_up are either dependent on CONFIG_HOTPLUG_CPU or are of __init type. Thus when CONFIG_HOTPLUG_CPU=y, all these cpu up functions would land up in .text section, and when CONFIG_HOTPLUG_CPU=n, all these functions would land up in .init section. Tested on a i386 SMP machine running linux-2.6.20-rc3-mm1. Signed-off-by: Gautham R Shenoy <ego@in.ibm.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-31[SPARC64]: Handle ISA devices with no 'regs' property.David S. Miller
And this points out that the return value from isa_dev_get_resource() and the 'pregs' arg to isa_dev_get_irq() are totally unused. Based upon a patch from Richard Mortimer <richm@oldelvet.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-12-31[SPARC64]: Fix of_iounmap() region release.David S. Miller
We need to pass in the resource otherwise we cannot release the region properly. We must know whether it is an I/O or MEM resource. Spotted by Eric Brower. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-12-17[SPARC64]: Mirror x86_64's PERCPU_ENOUGH_ROOM definition.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>