"Mark A. Greer" <[email protected]> writes: > On Mon, Mar 30, 2009 at 05:07:52PM -0700, Kevin Hilman wrote: >> "Mark A. Greer" <[email protected]> writes: >> >> > From: Mark A. Greer <[email protected]> >> > >> > Several of davinci platforms have their mac address >> > at the same location in the same type of i2c eeprom >> > so factor out the code to extract that mac address. >> > Also factor out the code that fixes up a bogus mac >> > address. >> > >> > Signed-off-by: Mark A. Greer <[email protected]> >> >> This along with 12/18 I'm not so crazy about since it doesn't scale >> well to custom boards with different EEPROMs or NVRAMs etc. >> >> I'd rather see the board-specific EEPROM access funcions left intact >> in the board files and those could be passed into the common code for >> reading the MAC addr. Right now, the "common" code assumes an at24 >> EEPROM. > > This one was only factoring out common code. Identical code, actually. > I broke my rule in that it wasn't necessary to wedge in the da830. > I still think the factoring is worthwhile especially since the code > is identical and can be included on a board-by-board basis. > > It can always evolve as new boards appear. >
What I didn't like was the at24 stuff in the new "common" code. However, as I think about it, once I move to the new memory_accessor series (which I will push shortly) the common code only has the memory_accessor struct, not the at24_iface struct so that should be fine. IOW, once you rebase this on top of the memory_accessor series, it should be fine. For you it should mostly be s/at24_iface/memory_accessor/ Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
