Note:  this is based off of Linus's latest commit

(5d9c4a7de64d398604a978d267a6987f1f4025b7), since all my previous

submissions are now upstream (thanks!).
Please pull from 'upstream-davem' branch of

master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem
to receive the following updates:
 MAINTAINERS                        |   11 +-

 drivers/net/cs89x0.c               |   12 +-

 drivers/net/ehea/ehea.h            |   34 +++++-

 drivers/net/ehea/ehea_main.c       |  281 +++++++++++++++++++++++++++++++++---

 drivers/net/fs_enet/fs_enet-main.c |    7 +-

 drivers/net/gianfar.c              |   14 +-

 drivers/net/igb/igb_main.c         |   15 +--

 drivers/net/pcmcia/pcnet_cs.c      |   10 +-

 drivers/net/phy/mdio_bus.c         |    4 +-

 drivers/net/sis190.c               |   15 ++-

 drivers/net/tlan.c                 |   64 ++++----

 drivers/net/tulip/uli526x.c        |   12 ++-

 drivers/net/virtio_net.c           |    2 +-

 drivers/s390/net/claw.c            |   39 +++---

 14 files changed, 399 insertions(+), 121 deletions(-)
Adrian Bunk (1):

      net/phy/mdio_bus.c: fix a check-after-use
Andy Gospodarek (1):

      igb: fix legacy mode irq issue
Becky Bruce (1):

      gianfar: don't pass NULL dev ptr to DMA ops
Bill Hayes (1):

      igb: Fix panic with NICs with 1000BASE-SX PHY
Christian Borntraeger (1):

      virtio_net: Fix oops on early interrupts - introduced by virtio reset code
Francois Romieu (1):

      sis190: read the mac address from the eeprom first
Grant Grundler (2):

      update TULIP MAINTAINERS

      uli526x partially recognizing interface
Harvey Harrison (1):

      tlan: add static to function definitions
Julia Lawall (1):

      claw: make use of DIV_ROUND_UP
Komuro (1):

      pcnet_cs: if AX88190-based card, printk "use axnet_cs instead" message.
Leonardo Potenza (1):

      drivers/net/cs89x0.c: compilation warning fix
Scott Wood (1):

      fs_enet: Don't call phy_mii_ioctl() in atomic context...
[ message continues ]

From: Jeff Garzik <jeff@garzik.org>
The whole point of my not rebasing net-2.6 is so that you can always

use it as a base.
With what you've giving me now I either have to:
1) Pull in Linus's tree to net-2.6, then pull from you.
2) Pull in directly from you to get it all.
The whole point of my not touching or rebasing net-2.6 is so that

everyonce can simply use it as a base and just keep working relative

to it.
If you have some need for upstream stuff outside networking (f.e.

some ACPI bug prevents interrupts from working or there is some build

failure), you can clone Linus's tree and pull net-2.6 and your driver

bits into there for building and testing.
Thanks for your consideration, I'm trying to show you mine by

giving everyone a relatively stable tree in which all networking

development can occur.
--

Why are either of those a problem?
--b.

--

From: "J. Bruce Fields" <bfields@fieldses.org>
Because it forces me to pull Linus's upstream into net-2.6,

I don't have any choice in the matter.

--

David Miller <davem@davemloft.net> :
Jeff's choice is a bit surprizing. That being said, it would had been nice

to fast-forward net-2.6 from a442585952f137bd4cdb1f2f3166e4157d383b82

to Linus's upstream before applying the content of

12aa343add3eced38a44bdb612b35fdf634d918c in order to keep the drift

with Linus's branch to a minimum during the bugfix cycle.
--

Ueimor

--

From: Francois Romieu <romieu@fr.zoreil.com>
Keep in mind there are also pending fixes in my net-2.6 tree which

Linus hasn't pulled in yet as well.
I watch Linus's tree closely, and I'll see any potential merge issue

long before it matters, and I always double check before pushing

stuff out to him.
My job as tree master is to deal with all the merge hassles, should

they occur.  But up until now everything networking has gone through

my tree and everything is fine.
The net-2.6 tree isn't even a week old.  I planned to pull Linus's

tree in right before I leave for a short trip tomorrow afternoon.

I'm really not being allowed to make that choice by how these

changes are being merged to me.
Heck, Jeff even thanked me for making my net-2.6 tree stable and not

rebasing, so his method of merging this stuff is doubly surprising for

me.
Jeff, I really don't want to pull that tree in.  Please trust me as

your upstream to handle merging issues, as needed.
Thanks!

--

I trust you...  Otherwise I wouldn't have volunteered to move my

upstream from Linus to you :)
My main issues/motivations were:
* quite simply, just force of habit:  I'm used to basing off of a recent

Linus tree, to guarantee build&boot testing against the latest.
* worry about testing against a too-old tree, where non-networking fixes

may have a relevant impact on my to-be-pushed netdrvr fixes.
But in this case it's fair to say there are no such issues, and it was

mainly just out of habit.
So (as you saw in last email)... rebased and resend.
	Jeff
--

From: Jeff Garzik <jeff@garzik.org>
Thanks :)

--

Right.  I'm wondering what the problems are that you see with that.
The advantages include earlier warning of merge problems, and avoidance

of duplicate commits--if Jeff's done work that depends on patches that

already upstream, then he either does that work against upstream, or

includes backported patches in the branch he asks you to pull, and you

end up with both the original and the backported patch.  Which isn't the

end of the world, but the resulting history seems messier than

necessary.
Or I guess you could both wait to do this merge until you're ready to

pull in Linus's latest?
For non-git-using testers there may be an advantage to always keeping a

tree based on the latest tagged release, as it may simplify providing

them with patches in some cases.  But if the goal is to provide a basis

for other maintainer's work, I'd've thought the best policy would be

just to track the tip of every relevant branch (which includes Linus's

in this case).
--b.

--

From: "J. Bruce Fields" <bfields@fieldses.org>
I do a test pull and build of net-2.6 into Linus's current tree

before I send Linus a pull request.
If any non-trivial merges are necessary, which hasn't happened yet at

all, I would then do a merge into my net-2.6 tree and resolve the

conflicts.
There is no reason for someone downstream of net-2.6 to do this.
--