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