[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4630D154.7050708@intel.com>
Date: Thu, 26 Apr 2007 09:20:36 -0700
From: "Kok, Auke" <auke-jan.h.kok@...el.com>
To: Jeff Garzik <jeff@...zik.org>, Andrew Morton <akpm@...l.org>
CC: Jesse Brandeburg <jesse.brandeburg@...el.com>,
Lennert Buytenhek <buytenh@...tstofly.org>,
David Acker <dacker@...net.com>,
Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
Netdev List <netdev@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Russell King <rmk+lkml@....linux.org.uk>
Subject: Re: [RFT] e100 driver on ARM
Jeff Garzik wrote:
> Kok, Auke wrote:
>> Jeff, I think I should just push the IO patch and the sbit code to
>> Andrew and have it sit there. That is a vastly larger test resource than
>> we currently can generate for this. If needed we just let is sit there
>> for a whole release cycle before moving it to #upstream.
>
> The sbit code has been in -mm via netdev-2.6.git#ALL for many months
> now. I am certainly open to adding any number of "for -mm only" style
> patches that you wish to pass along, for /any/ driver: e100, e1000, ixgb.
I think we should then just bite the bullet and move it over to #upstream for
2.6.22, that gives us another full release cycle to monitor it.
I'll post 2 patches in a second. the first is for upstream and allows the driver
to run with an invalid mac address in case the user overrides the eeprom
checksum (in which case the mac address could likely be wrong). The second one
is the I/O mode patch and for Andrew (MM), allthough the I/O mode is disabled by
default, so it should be safe to put in upstream as well, but I leave that up to
you to decide.
Auke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists