On Mon, 19 Mar 2012 17:49:02 +0100, Lothar WaÃmann <[email protected]> wrote: > Hi, > > Grant Likely writes: > > On Mon, 19 Mar 2012 07:54:33 +0100, Lothar WaÃmann > > <[email protected]> wrote: > > > Grant Likely writes: > > > > On Fri, 16 Mar 2012 11:01:35 +0800, Dong Aisheng > > > > <[email protected]> wrote: > > > > > On Thu, Mar 15, 2012 at 07:22:04PM +0800, Lothar WaÃmann wrote: > > > > > > Dong Aisheng writes: > > > > > > > On Thu, Mar 15, 2012 at 02:53:29PM +0800, Lothar WaÃmann wrote: > > > > > > Anyway there is no definite spec how the MAC address(es) are stored > > > > > > in the fuse map. Thus reading the MAC from there is more or less > > > > > > platform specific. > > > > > > > > > > > It's just provide one more option since there are customers storing > > > > > the MAC > > > > > in the fuse map. > > > > > > > > That should be straight forward to support; have a property that > > > > specifies the method used for fetching/calculating the MAC. > > > > > > > Executable code stored inside a DT blob? ;) > > > > I know you're joking here, but I'm going to answer seriously > > anyway... Absolutely not. What I'm suggesting is a property that > > specifies the method used to determine the mac address. Something > > like (off the top of my head): > > > > local-mac-address = [01 02 03 00 00 00]; > > local-mac-mask = [0xff 0xff 0xff 0 0 0]; > > mac-encoding = "append-serial-number"; > > > That still does not specify where the remaining part of the MAC is > stored and how it should be retrieved.
I'm suggesting that you define a string that means something specific; that hopefully can be shared by multiple platforms. For example, "append-serial-number" might mean start with the values selected by AND of local-mac-address and local-mac-mask, and OR in the board's serial number. You would need to define something that worked if this was the solution you used. > > Okay, if so then it would be wise to have a reliable function for the > > MAC driver to call to lookup it's address as determined by platform > > code. Alternately, the platform code can write the correct mac > > address into the device tree node at init time (see > > prom_update_property() and prom_add_property()). > > > That sounds good. Didn't know about those functions. That could be > used to mimic the current behaviour of supplying the MAC via > platform_data. I'm okay with doing this; but make sure you remove the bogus local-mac-address from the .dts file. g.
_______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
