On Fri, Sep 12, 2008 at 10:23:06AM -0700, Brandeburg, Jesse wrote:
> we don't officially support eepromless designs in our normal drivers
> (most embedded users expect to modify their drivers).  I know that there
> is some test patches to allow the eepromless set up in our drivers, that
> our TME teams have been working on.

We (Debian) use same mainline based kernel sources for all supported
platforms, so modifying e1000 driver in this way is not really a option.
It risks breaking desktop users. Also, we want to avoid carrying patches
against upstream as much as possible. So we'd really like a
upstream-acceptable way.

> >>> code in the e1000 driver that deals with the EEPROM and MAC
> >>> addresses.  Is there any plan for cleanly handling no-EEPROM
> >>> platforms, or am I into "undiscovered territory" here?  I'm willing
> >>> to submit patches once I find a minimally-invasive and robust
> >>> solution, but I don't want to reinvent the wheel... 

> we don't want to support this in the default drivers, but maybe we could
> in the kernel with a Kconfig option that defaulted to off.

This could be acceptable, we would only turn that option on the iop32x
kernel. It's sub-optimal, as some iop32x boards have PCI slots.

Btw, I notice IGB driver supports eeprom-less operation one some
hardware revisions.

-- 
"rm -rf" only sounds scary if you don't have backups

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel

Reply via email to