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>

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>

Follow the mach-harp changes to get the simulator support building.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

Get the ST50-HARP building again.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

This is already enabled through lib/Kconfig.debug, kill off the
architecture specific one.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

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>

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>

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>

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>

* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
  mv643xx_eth: Check ETH_INT_CAUSE_STATE bit

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>

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>

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>

* '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.

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>

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>

* '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

* '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

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>

* '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.

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>

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>

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

* '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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

* '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.

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>

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>

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

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>

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>