- 09 Oct, 2007 5 commits
-
-
Paul Mundt authored
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
Kill off the __div_table reference, modern compilers don't have it, and old compilers can't build the sh64 kernel anyways. __copy_user also needs to be exported to satisfy module builds. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
Use more of the generic section helpers, and get the alignment for some of the sections reduced. Follows the sh change. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
This is just dead code, kill it off.. Reported-by: Robert P. J. Day <rpjday@mindspring.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
- 03 Oct, 2007 1 commit
-
-
Thomas Gleixner authored
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
- 01 Oct, 2007 13 commits
-
-
Paul Mundt authored
There's no supported GDB stub in the kernel, kill off the dead config option for it. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
Dependency cleanup. The non-cayman boards don't have the mach callbacks for this and build error badness ensues. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
defconfigs for the simulator and ST50-HARP. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
Now that the ROM-RAM and generic boards are killed off, refactor the dependencies accordingly. Those were the only special cases, so all of the Kconfig dependency hell gets much cleaner as a result. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
The consistent DMA stuff was evolved from the old PCI DMA mapping functions. As this has been overhauled, it's something that is used by the generic DMA mapping code, and thus, has no intrinsic PCI dependence. Move the routines somewhere more sensible (same place as sh), and fix up the build for CONFIG_PCI=n in the process. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
This fixes up misc build issues that were hit on the non-cayman boards. Additionally, quite a few symbols needed to be exported to fix the module build. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
Follow the mach-harp changes to get the simulator support building. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
Get the ST50-HARP building again. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
This is already enabled through lib/Kconfig.debug, kill off the architecture specific one. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
The generic board stubs were never added, and the ROM-RAM boards never made it in to the wild. Neither one has any users, and both are utterly broken in-tree (likely since 2.4). Kill them both off. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
There were quite a few left over includes from code that was removed long ago, rip out the stuff we no longer need. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
These were implemented using an ugly macro for just simple wrapping, so we just make the wrapping explicit and move it to io.h instead. Also fixes up some modules: CC [M] drivers/net/8390.o In file included from drivers/net/8390.c:6: drivers/net/lib8390.c: In function 'ei_start_xmit': drivers/net/lib8390.c:329: error: implicit declaration of function 'outb_p' drivers/net/lib8390.c: In function '__ei_interrupt': drivers/net/lib8390.c:457: error: implicit declaration of function 'inb_p' make[2]: *** [drivers/net/8390.o] Error 1 make[1]: *** [drivers/net] Error 2 Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
- 29 Sep, 2007 4 commits
-
-
Jan Lübbe authored
The new behaviour of CFS exposes a race which occurs if a switch is requested when vt_mode.mode is VT_PROCESS. The process with vc->vt_pid is signaled before vc->vt_newvt is set. This causes the switch to fail when triggered by the monitoing process because the target is still -1. [ If the signal sending fails, the subsequent "reset_vc(vc)" will then reset vt_newvt to -1, so this works for that case too. - Linus ] Signed-off-by: Jan Lübbe <jluebbe@lasnet.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6: mv643xx_eth: Check ETH_INT_CAUSE_STATE bit
-
Nick Piggin authored
The comment being removed by this patch is incorrect and misleading. In the following situation: 1. load ... 2. store 1 -> X 3. wmb 4. rmb 5. load a <- Y 6. store ... 4 will only ensure ordering of 1 with 5. 3 will only ensure ordering of 2 with 6. Further, a CPU with strictly in-order stores will still only provide that 2 and 6 are ordered (effectively, it is the same as a weakly ordered CPU with wmb after every store). In all cases, 5 may still be executed before 2 is visible to other CPUs! The additional piece of the puzzle that mb() provides is the store/load ordering, which fundamentally cannot be achieved with any combination of rmb()s and wmb()s. This can be an unexpected result if one expected any sort of global ordering guarantee to barriers (eg. that the barriers themselves are sequentially consistent with other types of barriers). However sfence or lfence barriers need only provide an ordering partial ordering of memory operations -- Consider that wmb may be implemented as nothing more than inserting a special barrier entry in the store queue, or, in the case of x86, it can be a noop as the store queue is in order. And an rmb may be implemented as a directive to prevent subsequent loads only so long as their are no previous outstanding loads (while there could be stores still in store queues). I can actually see the occasional load/store being reordered around lfence on my core2. That doesn't prove my above assertions, but it does show the comment is wrong (unless my program is -- can send it out by request). So: mb() and smp_mb() always have and always will require a full mfence or lock prefixed instruction on x86. And we should remove this comment. Signed-off-by: Nick Piggin <npiggin@suse.de> Cc: Paul McKenney <paulmck@us.ibm.com> Cc: David Howells <dhowells@redhat.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Dale Farnsworth authored
Commit 468d09f8 masked the "state" interrupt (bit 20 of the cause register). This results in Radstone's PPC7D repeatedly re-entering the interrupt routine, locking up the board. The following patch returns the required handling for this interrupt. Signed-off-by: Martyn Welch <martyn.welch@radstone.co.uk> Signed-off-by: Dale Farnsworth <dale@farnsworth.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
- 28 Sep, 2007 17 commits
-
-
Benjamin Herrenschmidt authored
Linas reported me that some machines were crashing at boot in quirk_e100_interrupt. It appears that this quirk is doing an ioremap directly on a PCI BAR value, which isn't legal and will cause all sorts of bad things to happen on architectures where PCI BARs don't directly match processor bus addresses. This fixes it by using the proper PCI resources instead which is possible since the quirk has been moved by a previous commit to happen late enough for that. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Linas Vepstas <linas@austin.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [TCP]: Fix MD5 signature handling on big-endian. [NET]: Zero length write() on socket should not simply return 0.
-
Dmitry Torokhov authored
Input: xpad - fix dependancy on LEDS class The driver can not be built-in when LEDS class is a module. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Trond Myklebust authored
It doesn't look as if the NFS file name limit is being initialised correctly in the struct nfs_server. Make sure that we limit whatever is being set in nfs_probe_fsinfo() and nfs_init_server(). Also ensure that readdirplus and nfs4_path_walk respect our file name limits. Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
* 'for-2.6.23' of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc: [POWERPC] mpc8349emitx.dts: Setup USB-DR for peripheral mode. [POWERPC] Fix mpc834x USB-MPH configuration. [POWERPC] Fix cpm_uart driver for cpm1 machines [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem [POWERPC] Fix copy'n'paste typo in commproc.c
-
Linus Torvalds authored
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6: e1000: Add device IDs of blade version of the 82571 quad port sky2: fix transmit state on resume sky2: FE+ vlan workaround sky2: sky2 FE+ receive status workaround
-
David S. Miller authored
Based upon a report and initial patch by Peter Lieven. tcp4_md5sig_key and tcp6_md5sig_key need to start with the exact same members as tcp_md5sig_key. Because they are both cast to that type by tcp_v{4,6}_md5_do_lookup(). Unfortunately tcp{4,6}_md5sig_key use a u16 for the key length instead of a u8, which is what tcp_md5sig_key uses. This just so happens to work by accident on little-endian, but on big-endian it doesn't. Instead of casting, just place tcp_md5sig_key as the first member of the address-family specific structures, adjust the access sites, and kill off the ugly casts. Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds authored
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] Fix fallocate on o32 binary compat ABI [MIPS] Fix CONFIG_BUILD_ELF64 kernels with symbols in CKSEG0. [MIPS] IP32: Fix initialization of UART base addresses.
-
Kyle McMartin authored
MIPS was mistakenly forgetting to use the fallocate compat wrapper, which I noticed while cleaning up all the duplicate fallocate wrappers. Signed-off-by: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
The __pa() for those did assume that all symbols have XKPHYS values and the math fails for any other address range. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setupLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup: [x86 setup] Correct the SMAP check for INT 0x15, AX=0xe820
-
H. Peter Anvin authored
The e820 probe code was checking %edx, not %eax, for the SMAP signature on return. This worked on *almost* all systems, since %edx still contained SMAP from the call on entry, but on a handful of systems it failed -- plus, we would have missed real mismatches. The error output is "=d" to make sure gcc knows %edx is clobbered here. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
-
jacmet@sunsite.dk authored
Setup dr_mode for USB-DR to peripheral as the default (host mode) doesn't make much sense for the mini-AB connector on the ITX board. Peripheral mode is preferable to OTG as the fsl_usb2_udc.c driver doesn't yet properly support it. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
-
jacmet@sunsite.dk authored
mpc834x USB-MPH configuration got broken by commit 6f442560021aecf08658e26ed9a37e6928ef0fa1. The selection bits in SICRL should be cleared rather than set to configure the USB MUXes for the MPH. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
-
Jochen Friedrich authored
in cpm_uart_cpm1.h, DPRAM_BASE is assigned an address derived from cpmp. On ARC=ppc, this is a physical address with 1:1 DMA mapping which can't be used for arithmetric compare operations with virtual addresses returned by cpm_dpram_addr. This patch changes the assignment to use cpm_dpram_addr as well, like in cpm_uart_cpm2.h. Signed-off-by: Jochen Friedrich <jochen@scram.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
-
Jochen Friedrich authored
cpm_dpram_addr returns physical memory of the DP RAM instead of iomapped virtual memory. As there usually is a 1:1 MMU map of the IMMR area, this is often not noticed. However, cpm_dpram_phys assumes this iomapped virtual memory and returns garbage on the 1:1 mapped memory causing CPM1 uart console to fail. This patch fixes the problem (copied from the powerpc tree). Signed-off-by: Jochen Friedrich <jochen@scram.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
-