into nuts.ninka.net:/home/davem/src/BK/net-2.5

Also use kernel-doc for struct cycx_hw

. remove whitespaces
. use tabs instead of sequences of 8 spaces
. remove the wrappers for write{b,w} & friends
. align case entries with corresponding switch statement

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

fake_sep_struct is no longer used.

This is a bit neater.

From: Bernardo Innocenti <bernie@develer.com>

the following patch fixes a bug in the CS89xx net device which would set
new MAC address through SIOCSIFHWADDR _only_ when net_debug is set, which
is obviously not what it was meant to do.  The original code bogusly
interpreted the addr argument as a buffer containing the MAC address
instead of a struct sockaddr.

From: Andy Wihitcroft <apw@shadowen.org>

The generic-subarch patch broke visws builds.

From: Christoph Hellwig <hch@lst.de>

memory_lseek() should return a loff_t.

From: Christoph Hellwig <hch@lst.de>

Remove smp.h leftovers.  From the ia64 tree.

From: Paul Fulghum <paulkf@microgate.com>

* Remove PCMCIA release from timer context
* Add irqreturn_t to ISR
* Add dosyncppp module parameter

It needs fs.h for struct inode.

From Badari Pulavarti.

Fixes lots of error-path memleaks which the Stanford guys found.

From: Petr Vandrovec <vandrove@vc.cvut.cz>

While I was trying to hunt down problem with spin_lock_irq in
send_sig_info, I noticed that debugging spinlocks are a bit unusable.

The problem is that these spinlocks first print warning, and then
decrement babble.  So if the lock is used by printk code (like runqueue
lock was), we get nothing, just a lockup or a double fault...  When we
first decrement babble and then print the error message we can break
this unfortunate situation and the error message (5 of the same...)
appear on screen.

From: john stultz <johnstul@us.ibm.com>

I've been having problems with ACPI on a box here in our lab.  Some of our
more recent hardware requires that SMIs are routed through the IOAPIC, thus
when we clear_IO_APIC() at boot time, we clear the BIOS initialized SMI
pin.  This basically clobbers the SMI so we can then never make the
transition into ACPI mode.

This patch simply reads the apic entry in clear_IO_APIC to make sure the
delivery_mode isn't dest_SMI.  If it is, we leave the apic entry alone and
return.

With this patch, the box boots and SMIs function properly.

From: Faik Uygur <faikuygur@ttnet.net.tr>:

mtrr_file_del() is using the wrong thing for fcount.  This causes it to
print mtrr: MTRR 2 not used" twice when exiting X.

From: Rusty Russell <rusty@rustcorp.com.au>

loop.c has one of those places where manipulating own refcounts is safe: to
get into the ioctl handler you need to have the device open, so that holds a
refcount already (verified that this actually happens).

The compile warning is irritating.

From: Dave Olien <dmo@osdl.org>

I'm forwarding this patch to the DAC9690 driver from Christoph.  I've
applied it to the 2.5.69 DAC960 driver, compiled it, and ran it through
some tests on both V1 and V2 type controllers.  It looks good.

From: norbert_wolff@t-online.de (Norbert Wolff)

In arch/i386/mm/hugetlbpage.c htlbzone_pages and htlbpage_freelist are
declared static at the Top of the File and later in set_hugetlb_mem_size()
as extern.

gcc-3.4 does not accept this conflict.

put_dirty_page() currently assumes PAGE_COPY for the stack page's ptes.  But
for x86_64 (at least) this is not the case.

The patch adds the extra arg to put_dirty_page(), updates all callers and fixes
x86_64.

From: Hal Duston <hduston@speedscript.com>

This fixes a bug that appears to have crept in between 2.5.69-mm1 and
2.5.69-mm2 with the "switch most remaining drivers over to devfs_mk_bdev"
patch

CPU flags are unsigned long.

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

Originally from Matt Dobson. I've been running with this for a while
in -dj, with no noticable side-effects.

Matt:

node_zonelists looks like it should really be declared of size
MAX_NR_ZONES, not GFP_ZONEMASK.  GFP_ZONEMASK is currently 15, making
node_zonelists an array of 16 elements.  The extra zonelists are all
just duplicates of the *real* zonelists, namely the first 3 entries.
Again, if anyone can explain to me why I'm wrong in my thinking, I'd
love to know.  There's certainly no way you could bitwise-and something
with any combination of the GFP_DMA and GFP_HIGHMEM flags to refer to
the 12th zonelist or some such!  Or am I crazy?

Syncs up with 2.4

From 2.4 long long ago.