- Jul 18, 2007
-
-
Tony Breeds authored
This fixes the fallout from the recent powerpc merge (commit 489de302): CC arch/powerpc/kernel/pci-common.o arch/powerpc/kernel/pci-common.c:160: error: conflicting types for 'pcibios_add_platform_entries' include/linux/pci.h:889: error: previous declaration of 'pcibios_add_platform_entries' was here Signed-off-by:
Tony Breeds <tony@bakeyournoodle.com> Tested-by:
Bret Towe <magnade@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jul 17, 2007
-
-
Alexey Dobriyan authored
Identical implementations of PTRACE_POKEDATA go into generic_ptrace_pokedata() function. AFAICS, fix bug on xtensa where successful PTRACE_POKEDATA will nevertheless return EPERM. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Cc: <linux-arch@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Alexey Dobriyan authored
Identical implementations of PTRACE_PEEKDATA go into generic_ptrace_peekdata() function. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Cc: <linux-arch@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Pavel Emelianov authored
If the kernel OOPSed or BUGed then it probably should be considered as tainted. Thus, all subsequent OOPSes and SysRq dumps will report the tainted kernel. This saves a lot of time explaining oddities in the calltraces. Signed-off-by:
Pavel Emelianov <xemul@openvz.org> Acked-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> [ Added parisc patch from Matthew Wilson -Linus ] Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jul 16, 2007
-
-
Heiko Carstens authored
The current generic bug implementation has a call to dump_stack() in case a WARN_ON(whatever) gets hit. Since report_bug(), which calls dump_stack(), gets called from an exception handler we can do better: just pass the pt_regs structure to report_bug() and pass it to show_regs() in case of a warning. This will give more debug informations like register contents, etc... In addition this avoids some pointless lines that dump_stack() emits, since it includes a stack backtrace of the exception handler which is of no interest in case of a warning. E.g. on s390 the following lines are currently always present in a stack backtrace if dump_stack() gets called from report_bug(): [<000000000001517a>] show_trace+0x92/0xe8) [<0000000000015270>] show_stack+0xa0/0xd0 [<00000000000152ce>] dump_stack+0x2e/0x3c [<0000000000195450>] report_bug+0x98/0xf8 [<0000000000016cc8>] illegal_op+0x1fc/0x21c [<00000000000227d6>] sysc_return+0x0/0x10 Acked-by:
Jeremy Fitzhardinge <jeremy@goop.org> Acked-by:
Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Andi Kleen <ak@suse.de> Cc: Kyle McMartin <kyle@parisc-linux.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jul 11, 2007
-
-
Auke Kok authored
Currently there are 97 occurrences where drivers need the pci revision ID. We can do this once for all devices. Even the pci subsystem needs the revision several times for quirks. The extra u8 member pads out nicely in the pci_dev struct. Signed-off-by:
Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Michael Ellerman authored
Currently pcibios_add_platform_entries() returns void, but could fail, so instead have it return an int and propagate errors up to pci_create_sysfs_dev_files(). Fixes: arch/powerpc/kernel/pci_64.c: In function 'pcibios_add_platform_entries': arch/powerpc/kernel/pci_64.c:878: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result arch/powerpc/kernel/pci_32.c: In function 'pcibios_add_platform_entries': arch/powerpc/kernel/pci_32.c:1043: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mike Wolf authored
This adds a new oprofile cpu type for Power 5 revision 3 chips. The new name is ppc64/power5++ and is used so that the performance counters can be set up correctly. Signed-off-by:
Mike Wolf <mjw@us.ibm.com> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
- Jul 10, 2007
-
-
Mathieu Desnoyers authored
Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Sonny Rao authored
Check to make sure ppc_md.init_IRQ has been set before calling it. Signed-off-by:
Sonny Rao <sonny@burdell.org> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Johannes Berg authored
With !CONFIG_NUMA, these are static inlines in the header file so don't generate exports for them in that case. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Tony Breeds authored
Signed-off-by:
Tony Breeds <tony@bakeyournoodle.com> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Tony Breeds authored
When booting a current kernel with CONFIG_PRINTK_TIME enabled you'll see messages like: [ 0.000000] time_init: decrementer frequency = 188.044000 MHz [ 0.000000] time_init: processor frequency = 1504.352000 MHz [3712914.436297] Console: colour dummy device 80x25 This cause by the initialisation of tb_to_ns_scale in time_init(), suddenly the multiplication in sched_clock() now does something :). This patch modifies sched_clock() to report the offset since the machine booted so the same printk's now look like: [ 0.000000] time_init: decrementer frequency = 188.044000 MHz [ 0.000000] time_init: processor frequency = 1504.352000 MHz [ 0.000135] Console: colour dummy device 80x25 Effectivly including the uptime in printk()s. This patch makes tb_to_ns_scale and tb_to_ns_shift static and read_mostly for good measure. Signed-off-by:
Tony Breeds <tony@bakeyournoodle.com> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Michael Ellerman authored
The prom.c debugging code creates a "powerpc" directory in debugfs, which is nice, but doesn't allow any other debugging code to stick things under "powerpc" in debugfs. So make it global. While we're there we should make the prom.c debugging code depend on CONFIG_DEBUG_FS, because it doesn't work otherwise. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Wade Farnsworth authored
The device tree for the MPC8641 HPCN does not implement the device type property for I8042 nodes. In addition to checking the I8042 node's device type, also match the keyboard and/or mouse nodes' compatible property. Signed-off-by:
Wade Farnsworth <wfarnsworth@mvista.com> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Michael Ellerman authored
When the refcount for a device node goes to 0, we call the destructor - of_node_release(). This should only happen if we've already detached the node from the device tree. So add a flag OF_DETACHED which tracks detached-ness, and if we find ourselves in of_node_release() without it set, issue a warning and don't free the device_node. To avoid warning continuously reinitialise the kref to a sane value. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Michael Ellerman authored
The struct device_node currently has a _flags variable, although it's only used for one flag - OF_DYNAMIC. Generalise the flag accessors so we can use them with other flags in future. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Michael Ellerman authored
It's not sensible to call of_detach_node() on the root node, but we should check for it just to be safe. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Roland Dreier authored
When adding the cputable entry for 440SPe Rev. B, we also need to adjust the existing entries for 440SP Rev. A and 440SPe Rev. B so that they look more bits of the PVR. The 440SPe Rev. B has PVR 53421891, which would match the current 440SP Rev. A pattern of 53xxx891. To distinguish between 440SP and 440SPe, we need to use the first three digits of the PVR, which are respectively 532 and 534. Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Christoph Hellwig authored
do_signal is never used in modular code (obviously), and no other architecture exports it either. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Kumar Gala authored
Use the eieio function so we can redefine what eieio does rather than direct inline asm. This is part code clean up and partially because not all PPCs have eieio (book-e has mbar that maps to eieio). Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
- Jul 03, 2007
-
-
Kumar Gala authored
pcibios_enable_resources isn't used anywhere and not exported. Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Jon Loeliger authored
Remove uses of hack GET_64BIT() property macro and use the more general of_read_number() function from prom.h as suggested by Milton. Signed-off-by:
Jon Loeliger <jdl@freescale.com> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
- Jul 02, 2007
-
-
Olof Johansson authored
Uninline virq_to_hw and export it so modules can use it. The alternative would be to export the irq_map array instead, but it's an infrequently called function, and keeping the array unexported seems considerably cleaner. This is needed so that the pasemi_mac driver can be compiled as a module. Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
- Jun 30, 2007
-
-
Will Schmidt authored
The vdso64 portion of patch 74609f45 for fixing problems with NULL gettimeofday input mistakenly checks for a null tz field twice, when it should be checking for null tz once, and null tv once; by way of a r10/r11 typo. Any application calling gettimeofday(&tv,NULL) will "fail". This corrects that typo, and makes my G5 happy. Tested on G5. Signed-off-by:
Will Schmidt <will_schmidt@vnet.ibm.com> Cc: Tony Breeds <tony@bakeyournoodle.com> Forwarded-by:
Ben Herrenschmidt <benh@kernel.crashing.org> [ Ben says: "I checked the 32 bits part of the change is correct. You can probably blame me for originally writing the 2 versions with inversed usage of r10 and r11, thus confusing Tony :-)" Ben duly blamed. - Linus ] Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jun 29, 2007
-
-
Kumar Gala authored
Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Kumar Gala authored
Use the ppc64 style list management and allocation functions for pci_controllers. This makes the pci_controller structs just a bit more common between ppc32 & ppc64. Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Kumar Gala authored
Moved the low hanging fruit that was either identical or close to it between ppc32 & ppc64 for PCI into pci-common.c Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Kumar Gala authored
In the places we can move to using pci_bus_to_host, this allows us to make pci_bus_to_host static and remove its export. Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Kumar Gala authored
Make the ppc32 pcibios_alloc_controller take a device node to match the ppc64 prototypes and have it set arch_data. Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Kumar Gala authored
Make the pci_controller struct use global_number for the PHB domain number instead of index to match what ppc64 does and reuse its pci_domain_nr code. Introduced a pci-common.c to handle shared code between ppc32 & ppc64. Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Kumar Gala authored
There are no in kernel users of any off these functions and some of them were not even EXPORT_SYMBOL: - pci_bus_io_base() - pci_bus_io_base_phys() - pci_bus_mem_base_phys() - pci_resource_to_bus() - phys_to_bus() - pci_phys_to_bus() - pci_bus_to_phys() - pci_init_resource() - resource_fixup() Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
York Sun authored
In pcibios_fixup_bus(), bridges that are subordinate to transparent bridges were still relocating their IORESOURCE_IO and IO_RESOURCE_MEM start and end values. Fix this by preventing the transparent bridge from relocating the start and end values, thus allowing the subordinate non-transparent bridge full molestation rights. Signed-off-by:
York Sun <yorksun@freescale.com> Signed-off-by:
Andy Fleming <afleming@freescale.com> Signed-off-by:
Jon Loeliger <jdl@freescale.com> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
- Jun 28, 2007
-
-
David Woodhouse authored
Not all the world is an i386. Many architectures need 64-bit arguments to be aligned in suitable pairs of registers, and the original sys_sync_file_range(int, loff_t, loff_t, int) was therefore wasting an argument register for padding after the first integer. Since we don't normally have more than 6 arguments for system calls, that left no room for the final argument on some architectures. Fix this by introducing sys_sync_file_range2(int, int, loff_t, loff_t) which all fits nicely. In fact, ARM already had that, but called it sys_arm_sync_file_range. Move it to fs/sync.c and rename it, then implement the needed compatibility routine. And stop the missing syscall check from bitching about the absence of sys_sync_file_range() if we've implemented sys_sync_file_range2() instead. Tested on PPC32 and with 32-bit and 64-bit userspace on PPC64. Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Acked-by:
Russell King <rmk+kernel@arm.linux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Michael Ellerman authored
Commit 3d5134ee left debugging turned on in arch/powerpc/kernel/pci_64.c. This turns it off again. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Tony Breeds authored
Currently iSeries will recalibrate the cputime_factors in the first settimeofday() call. It seems the reason for doing this is to ensure a resaonable time delta after time_init(). On current kernels (with udev), this call is made 40-60 seconds into the boot process, by moving it to a late initcall it is called approximately 5 seconds after time_init() is called. This is sufficient to recalibrate the timebase. Signed-off-by:
Tony Breeds <tony@bakeyournoodle.com> CC: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Geoff Levand authored
Remove references to pSeries and OpenFirmware in the __secondary_hold usage comment. __secondary_hold is a generic routine and can be used by other platforms. Signed-off-by:
Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Geoff Levand authored
Add a printout of the params value to early_init_devtree. This value is handy to have for comparison when debugging the bootwrapper code. Signed-off-by:
Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
- Jun 26, 2007
-
-
Paul Mackerras authored
This fixes a bug which can cause corruption of the floating-point state on return from a signal handler. If we have a signal handler that has used the floating-point registers, and it happens to context-switch to another task while copying the interrupted floating-point state from the user stack into the thread struct (e.g. because of a page fault, or because it gets preempted), the context switch code will think that the FP registers contain valid FP state that needs to be copied into the thread_struct, and will thus overwrite the values that the signal return code has put into the thread_struct. This can occur because we clear the MSR bits that indicate the presence of valid FP state after copying the state into the thread_struct. To fix this we just move the clearing of the MSR bits to before the copy. A similar potential problem also occurs with the Altivec state, and this fixes that in the same way. Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Tony Breeds authored
Consider the prototype for gettimeofday(): int gettimofday(struct timeval *tv, struct timezone *tz); Although it is valid to call with /either/ tv or tz being NULL, and the C version of sys_gettimeofday() supports this, the current version of gettimeofday() in the VDSO will SEGV if called with a NULL tv. This adds a check for tv being NULL so that it doesn't SEGV. Signed-off-by:
Tony Breeds <tony@bakeyournoodle.com> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-