- 01 Oct, 2007 8 commits
-
-
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 24 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>
-
Jochen Friedrich authored
The powerpc version of commproc.c exports cpm_dpram_addr twice and cpm_dpram_phys not at all due to a typo. This patch fixes this problem. CC arch/powerpc/sysdev/commproc.o arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kcrctab_cpm_dpram_addr' arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kcrctab_cpm_dpram_addr' was here arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kstrtab_cpm_dpram_addr' arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kstrtab_cpm_dpram_addr' was here arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__ksymtab_cpm_dpram_addr' arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__ksymtab_cpm_dpram_addr' was here make[1]: *** [arch/powerpc/sysdev/commproc.o] Error 1 make: *** [arch/powerpc/sysdev] Error 2 Signed-off-by: Jochen Friedrich <jochen@scram.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
-
Auke Kok authored
This blade-specific board form factor is identical to the 82571EB board. Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Stephen Hemminger authored
This should fix http://bugzilla.kernel.org/show_bug.cgi?id=8667 After resume, driver has reset the chip so the current state of transmit checksum offload state machine and DMA state machine will be undefined. The fix is to set the state so that first Tx will set MSS and offset values. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Stephen Hemminger authored
The FE+ workaround means the driver can no longer trust the status register to indicate VLAN tagged frames. The fix for this is to just disable VLAN acceleration for that chip version. Tested and works fine. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Stephen Hemminger authored
The Yukon FE+ chip appears to have a hardware glitch that causes bogus receive status values to be posted. The data in the packet is good, but the status value is random garbage. As a temporary workaround until the problem is better understood, implement the workaround the vendor driver used of ignoring the status value on this chip. Since this means trusting dodgy hardware values; add additional checking of the receive packet length. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds authored
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] Fix CONFIG_BUILD_ELF64 kernels with symbols in CKSEG0. [MIPS] IP32: Fix initialization of UART base addresses.
-
Dave Airlie authored
This code is ported from the DRM git tree and allows the vblank interrupts to function on the i965 hw. It also requires a change in Mesa's 965 driver to actually use them. [ Without this patch, my 965GM drops vblank interrupts - Jesse ] Signed-off-by: Dave Airlie <airlied@linux.ie> Acked-by: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 27 Sep, 2007 3 commits
-
-
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>
-
David S. Miller authored
This fixes kernel bugzilla #5731 It should generate an empty packet for datagram protocols when the socket is connected, for one. The check is doubly-wrong because all that a write() can be is a sendmsg() call with a NULL msg_control and a single entry iovec. No special semantics should be assigned to it, therefore the zero length check should be removed entirely. This matches the behavior of BSD and several other systems. Alan Cox notes that SuSv3 says the behavior of a zero length write on non-files is "unspecified", but that's kind of useless since BSD has defined this behavior for a quarter century and BSD is essentially what application folks code to. Based upon a patch from Stephen Hemminger. Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 26 Sep, 2007 1 commit
-
-
Linus Torvalds authored
This reverts commit 184c44d2. As noted by Dave Jones: "Linus, please revert the above cset. It doesn't seem to be necessary (it was added to fix a miscompile in 'make allnoconfig' which doesn't seem to be repeatable with it reverted) and actively breaks the ARM SA1100 framebuffer driver." Requested-by: Dave Jones <davej@redhat.com> Cc: Russell King <rmk+lkml@arm.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-