Messages in this thread | | | Date | Sat, 6 Jul 2013 10:28:04 +0200 | From | Maxime Ripard <> | Subject | Re: MTD EEPROM support and driver integration |
| |
On Sat, Jul 06, 2013 at 12:33:13AM +0200, Arnd Bergmann wrote: > On Saturday 06 July 2013, Maxime Ripard wrote: > > > My first thought is that it should be more generic than that and not > > > have the mac address hardcoded as the purpose. We could possibly use > > > regmap as the in-kernel interface, and come up with a more generic > > > way of referring to registers in another device node. > > > > Hmm, I maybe wasn't as clear as I wanted. Here mac-storage was just an > > example. It should indeed be completely generic, and a device could have > > several "storage source" defined, each driver knowing what property it > > would need, pretty much like what's done currently for the regulators > > for example. > > > > We will have such a use case anyway for the Allwinner stuff, since the > > fuses can be used for several thing, including storing the SoC ID, > > serial numbers, and so on. > > Ah, I see. In general, we have two ways of expressing the same thing > here: > > a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names > > regmap = <&at25 0xstart 0xlen>; > regmap-names = "mac-address"; > > b) like gpio, regulator: variable property names > > mac-storage = <&at25 0xstart 0xlen>; > > It's unfortunate that we already have examples of both. They are largely > equivalent, but the tendency is towards the first.
I don't have a strong feeling for one against another, so whatever works best. Both solutions will be a huge improvement anyway :)
Just out of curiosity, is there any advantages besides having a fixed property name to the first solution?
Thanks, Maxime
-- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com [unhandled content-type:application/pgp-signature] | |