* Arnd Bergmann <arnd@xxxxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
