On Mon, Jul 08, 2013 at 09:36:14AM +0100, Mark Brown wrote: > On Sun, Jul 07, 2013 at 09:15:01AM +0200, Maxime Ripard wrote: > > On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote: > > > > We also have a bunch of OTP drivers spread around the kernel, it probably > > > makes sense to consolidate them at the same time, at least on the DT binding > > > side if not the device drivers. > > > From a quick grep, the only one I've seen so far are: > > - imx6q, that has a hook at machine start to poke into its OCOTP to > > retrieve some frequency scaling parameters it seems. I'm not sure > > how the current solution could improve the situation for this > > use-case, but the DT bindings of the OCOTP is just a DT node, with > > no clients, so we have nothing to worry about here. > > - imx28, that has a hook at machine start to look up the MAC address > > values and patch the ethernet controller nodes to add the right > > local-mac-address property. This one could benefit from the new > > bindings, but we already mentionned it, and I intended to develop > > with an imx28 board anyway. > > - picoxcell-pc3x3 DTSI has a node for a OTP device, but they don't > > seem to be doing anything with it, nor do they seem to have a driver > > for it. So I guess we don't care about migrating for this one > > either. > > > Did you have other cases in mind? > > We have some OTP support in the ab8500 and wm831x MFD drivers too but > they just expose the data. I guess you mean ab8100, right? Anyway, thanks for pointing this out Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
