[PATCH 2/3] OMAP2+ devices add mac address allocation register api

Tony Lindgren tony at atomide.com
Sun Jul 1 04:58:42 EDT 2012


* Arnd Bergmann <arnd at arndb.de> [120629 08:09]:
> On Friday 29 June 2012, Tony Lindgren wrote:
> > 
> > OK. So how about we do the following:
> > 
> > 1. Make Andy's notifier part into a generic mac notifier
> >    driver that can take platform data for the driver name
> >    mac address pair. Devicetree binding could be added as
> >    needed.
> 
> I don't think the devicetree bindign should be part of that
> driver but instead should go into the individual network
> device drivers, otherwise it sounds ok to me.
> Obviously, this still needs buy-in from the networking
> people.

Yes you're right. The fixed bootloader generated mac address
should be passed directly to the ethernet driver in question.
 
> > 2. Pass the Panda mac information as platform data to this
> >    driver for now with a comment on the usb path naming being
> >    potentially wrong in the loadable modules case.
> 
> IMHO code outside of the platform driver world would be more
> appropriate here. It's not actually a platform device because
> it's more of an abstract concept to define a mac address than
> physical hardware.

Well we still need to also pass the mac address generated by
the SoC specific kernel init code. It seems that platform data
would be the obvious way to pass that. Or do you have some other
way in mind for that?
 
> A new file with a single global function in net/ethernet/
> that you can use to register a callback sounds like the
> easiest approach to me.

Yes I agree this should live under net/ethernet somewhere.
 
> > 3. Add devicetree support to the driver once the USB binding
> >    is available.
> 
> Here you mean the smsc95xx driver, not the new code, right?

Yes you're right, we only need the mac address binding for the
smsc95xx driver. And in addition to that we need to support passing
the SoC init code generated mac address somewhere to the whatever
this new soft-mac driver will be called.

Regards,

Tony 



More information about the linux-arm-kernel mailing list