Patches to remove some old ifdefs, 2.2 comptability.
 then remove unused #include <linux/version.h>

applies cleanly to 2.6.8-rc2

From: Domen Puncer <domen@coderock.org>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>

That definitely duplicates a bunch of stuff in pending patches from various
folks, but since it's all trivial 0->NULL replacements and patches are still
not submitted and/or merged...
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Several network drivers have checks that they are only built with -O.
This breaks checking with sparse and other tools, and seems like a holdover from
when drivers were built out of tree and the kernel build system was less stable.
This patch gets rid of these.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>

From: Jeff Garzik

	Jeff's patch adds a helper for obtaining mii_ioctl_data from ifreq
and switches drivers to it.  It's almost a "move common expression into
inline helper", except that instead of

	(struct mii_ioctl_data *)&rq->ifr_ifru.ifru_data

it does

	(struct mii_ioctl_data *)&rq->ifr_ifru

- pointer to union instead of pointer to a field of union that has nothing
to do with mii_ioctl_data *and* adds confusion by being a pointer itself.

->ifr_data users annotated.

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

From:  a.othieno@bluewin.ch (Arthur Othieno)
From:  Vinay K Nallamothu <vinay-rc@naturesoft.net>

Remove various duplicated #includes

From:  Vinay K Nallamothu <vinay-rc@naturesoft.net>

        Use mod_timer in drivers_block_floppy98.c

From:  carbonated beverage <ramune@net-ronin.org>

        doc update for bk usage
        bk://... appears to be dead, use http://... instead.

From: "David S. Miller" <davem@redhat.com>

Currently, for an existing DMA mapping, there is a way to transfer buffer
ownership back to the cpu, yet there is no way to give it back to the device
again explicitly.  The latter really is needed on platforms where the PCI
subsystem does not snoop the cpu caches, MIPS is one example.

Many drivers were expecting the existing DMA sync interface to handle both
directions, which was wrong.

Now, with this change, we have explicit interfaces for DMA syncing to/from
the device and the cpu.

drivers/net/eepro100.c:545: warning: `poll_speedo' declared `static' but never defined

netpoll for eepro100

This was in Ingo's old original netconsole patches.

Simple one line substitution of kfree with free_netdev
for the bulk of the network drivers.

[ GregKH has already done this is USB and PCI core. ]

From: "Warren A. Layton" <zeevon@debian.org>

Based on a request from Matthew Wilcox, convert instances of
pci_dev->slot_name to use pci_name() instead:

  "In order to support PCI Domains, we have to stop using slot_name.
   It's related to driver model transition too since pci_dev->slot_name
   was redundant with pci_dev->dev.bus_id.  So I introduced the inline
   function pci_name().  Now there's about 300-400 places in the tree
   that're using slot_name which need to be converted to use pci_name().
   once that's done, we can remove the slot_name pointer in pci_dev and
   save a (void *) per pci_dev."

Fixes up drivers/net/*

Ignore earlier patch -- this one locks and free's as appropriate.
Tested on 2.5.72 with SMP.

Of course, it begs the question why have two (now three) versions of drivers for
the same hardware...

From: Tom Alsberg <alsbergt@cs.huji.ac.il>

Add support for a new eepro100 PCI ID.

Mostly updating to new irqreturn_t, but also includes some needed
SET_MODULE_OWNER and set_bit cleanups as well.

Affects: 8390, dgrs, eepro100, epic100, pcnet32, rcpci45,
sis900, tlan

Remove the unneeded forward declaration of eepro100_remove_one().

It is defeating the __attribute__(unused) tag on the definition of
eepro100_remove_one() and is causing a "defined but not used" warning.

Patch from Jason Lunz <lunz@falooley.org>

When support for the GSET and SSET ethtool ioctls was added to eepro100.c in
2.4.20, the tx lock was overloaded to serialize their use.  Unfortunately,
this lock is only initialized in dev->open(), causing ethtool to deadlock the
machine when used on an unconfigured eepro100 interface.

The fix is to initialize the spinlock at probe time.

This fixes:
    tranceiver -> transceiver

Some function names had this misspelling (e.g. e100_reset_tranceiver)
and I changed them, but I haven't tested it.

Fixes 34 occurrences in all.

this trivial patch adds EEPRO100_PIO config option, which forces eepro100.c
driver to use pio instead of mmio. This option is necessary to support
onboard i82557 on sgi visual workstation.

Contributed by Jonathan Shapiro

This removes the pci_dev "->name[]" field, and makes users use the
"struct device" name field instead.

It also trimps it down to 50 bytes and limited the length of the vendor
& device descriptions to 20 bytes each.  Now we have three cases:

 - unknown vendor & unknown device -> "PCI device %04x:%04x".
	Clearly limited to 21 chars.
 - known vendor, unknown device -> "PCI device %04x:%04x (%.20s)"
	24 + 20 chars
 - known vendor, known device -> "%.20s %.20s"
	20 + 1 + 20 + 1, EXCEPT:
 - multiple devices of the same type add " (#%d)"
	so 42 + 4 + 4 = 50.  This is the point where an IBMer tells me they
	intend to sell a machine with > 9999 PCI devices of the same type ;-)

This limits the PCI IDs to a reasonable amount of space.

For release, I think we do want to go back up to 80 for prettier output

* use netif_msg_xxx() instead of speedo_debug
* better default debug mask, proper use of debug module param
* add ETHTOOL_[GS]MSGLVL

* mii cleanups
* use mii_check_link()
* check link every timer

This is the smptimers patch plus the removal of old BHs and a rewrite of
task-queue handling.

Basically with the removal of TIMER_BH i think the time is right to get
rid of old BHs forever, and to do a massive cleanup of all related
fields.  The following five basic 'execution context' abstractions are
supported by the kernel:

  - hardirq
  - softirq
  - tasklet
  - keventd-driven task-queues
  - process contexts

I've done the following cleanups/simplifications to task-queues:

 - removed the ability to define your own task-queue, what can be done is
   to schedule_task() a given task to keventd, and to flush all pending
   tasks.

This is actually a quite easy transition, since 90% of all task-queue
users in the kernel used BH_IMMEDIATE - which is very similar in
functionality to keventd.

I believe task-queues should not be removed from the kernel altogether.
It's true that they were written as a candidate replacement for BHs
originally, but they do make sense in a different way: it's perhaps the
easiest interface to do deferred processing from IRQ context, in
performance-uncritical code areas.  They are easier to use than
tasklets.

code that cares about performance should convert to tasklets - as the
timer code and the serial subsystem has done already. For extreme
performance softirqs should be used - the net subsystem does this.

and we can do this for 2.6 - there are only a couple of areas left after
fixing all the BH_IMMEDIATE places.

i have moved all the taskqueue handling code into kernel/context.c, and
only kept the basic 'queue a task' definitions in include/linux/tqueue.h.
I've converted three of the most commonly used BH_IMMEDIATE users:
tty_io.c, floppy.c and random.c. [random.c might need more thought
though.]

i've also cleaned up kernel/timer.c over that of the stock smptimers
patch: privatized the timer-vec definitions (nothing needs it,
init_timer() used it mistakenly) and cleaned up the code. Plus i've moved
some code around that does not belong into timer.c, and within timer.c
i've organized data and functions along functionality and further
separated the base timer code from the NTP bits.

net_bh_lock: i have removed it, since it would synchronize to nothing. The
old protocol handlers should still run on UP, and on SMP the kernel prints
a warning upon use. Alexey, is this approach fine with you?

scalable timers: i've further improved the patch ported to 2.5 by wli and
Dipankar. There is only one pending issue i can see, the question of
whether to migrate timers in mod_timer() or not. I'm quite convinced that
they should be migrated, but i might be wrong. It's a 10 lines change to
switch between migrating and non-migrating timers, we can do performance
tests later on. The current, more complex migration code is pretty fast
and has been stable under extremely high networking loads in the past 2
years, so we can immediately switch to the simpler variant if someone
proves it improves performance. (I'd say if non-migrating timers improve
Apache performance on one of the bigger NUMA boxes then the point is
proven, no further though will be needed.)

when implementing ethtool media ioctls.

No behavior should change with this patch (except the ethtool media
ioctls now work, of course)

Also, re-format comments to the right of the private struct to line up.

to take 'struct net_device *' not 'long' as their first
argument.  This makes eepro100 compatible with the standard
MII ethtool API, preparing it for that support.

No functional changes should occur with this patch, if anything
changes at all it is a bug.  (and testing shows no changes...)