From: NeilBrown <neilb@cse.unsw.edu.au>

Updated version which uses ascii-encoding of messages, from
http://www.citi.umich.edu/u/marius/linux-2.5.70-idmap-server-new.diff as of
October 14, 2003.

From: NeilBrown <neilb@cse.unsw.edu.au>

Doesn't actually add integrity support on the server yet; just adapts
server-side code to the gss api changes necessary to get integrity working on
the client.

From: NeilBrown <neilb@cse.unsw.edu.au>

From: "J. Bruce Fields" <bfields@fieldses.org>

Note that the user (or exportfs, on the user's behalf) allows a gss
pseudoflavor to be used to access an export by exporting to a special client
named "gss/pseudoflavor-name", e.g., "gss/krb5" or "gss/lipkey-i".

From: Neil Brown <neilb@cse.unsw.edu.au>

Make sure nfsd doesn't modify group_info structures as they might be
shared.

From: Neil Brown <neilb@cse.unsw.edu.au>

Tidy up new groups handling in nfsd.

Set up the group_info structure when decoding the RPC packet instead of in
nfsd.

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

ppc64 uses its own range allocator for ioremap (in order to allocate
things in a different space than normal vmalloc).  This is historic stuff,
we may get rid of it, but in the meantime, here's a patch turning the
spinlock in there into a semaphore so it doesn't blow up when doing
kmallocs.

From: Anton Blanchard <anton@samba.org>

From: Stephen Rothwell <sfr@canb.auug.org.au>

This moves the sg_dma_* macros to asm/scatterlist.h where they belong (and
where almost every other architecture has them).

From: olof@austin.ibm.com

Use the new kallsyms_lookup_name() in xmon on ppc64.  Ben said he might
backport these changes to ppc32 as well.

From: Rusty Russell <rusty@au1.ibm.com>

Attached patch adds a kallsyms_lookupname() function for lookups of a
symbol name to an address.  Debuggers such as ppc[64] xmon can use this.

It's intentionally not exported as a symbol for module use, since it
can be used to circumvent other symbol export restrictions.

From: Stephen Rothwell <sfr@canb.auug.org.au>

Add the PPC64 iSeries virtual disk driver

into ppc970.osdl.org:/home/torvalds/v2.5/linux

This helps avoid doing push/pop pairs on register contents that we just
don't care about. After we've done the xor, the pointers are dead anyway.

into ppc970.osdl.org:/home/torvalds/v2.5/linux

into kernel.bkbits.net:/home/davem/net-2.6

Since we do push/pops, a stack-based memory argument would
do the wrong thing by using the wrong offsets.

The x86-64 implementation of csum-partial.c causes it to compute the
checksum incorrectly.

As a result, multicast doesn't work.  It looks as though iptables is
also affected.

Here's a simple patch.

This patch is the first of several planned fixes for the cyclades
multiserial cards driver.

Its mostly a sync with in-house driver:

- Prevent users from opening non-existing Z ports
- Implement special XON/XOFF character handling in Z cards
- Prevent data-loss on Z cards
- Throttling fix for Z card
- Only throttle if CTS/RTS are set
- Fix accounting of received data

Kudos to Cyclades R&D

From: William Lee Irwin III <wli@holomorphy.com>

PRD_ENTRIES is specified to be precisely 256; on platforms where
PAGE_SIZE varies from 4KB the calculation in the current expression
defining it is inaccurate, which may cause crashes. This patch changes
it to the constant literal 256.

From: Andrew Morton <akpm@osdl.org>

Use sector_t for the block number.

Noticed by Marcel Cotta <mc123@mail.ru>.

ide_init() always initializes system_bus_speed variable
so system_bus_clock() should never call ide_system_bus_speed()
and no driver is calling ide_system_bus_speed() directly.

Bug was that if no IDE kernel parameter was given during boot
system_bus_speed will be zeroed in init_ide_data().

This patch should fix the problem
(as a bonus -> no need to zero these variables they are static).

From: Vojtech Pavlik <vojtech@suse.cz>

Add UDMA6 support to ALi PCI IDE driver.
Forward port from 2.4 and a patch from ALi.

Was in -mm for a long time...

Fix from jgarzik's sata_sil.c libata driver.

This was in -mm for a long time...