On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote: > >Let's look at mc13892-regulator driver. There are 23 regulators defined > >in array mc13892_regulators. Needless to say, there is a dev behind > >mc13892-regulator driver. And when getting probed, this driver will > >call regulator_register() to register those 23 regulators individually. > >That said, for non-dt world, we have 1 + 23 'dev' with that 1 as the > >parent of all other 23 'dev' (wrapped by regulator_dev). But with the > >current DT implementation, we will have at least 1 + 23 * 2 'dev'. > >These extra 23 'dev' is totally new with DT. > > > > but thats only because the mc13892-regulator driver is implemeted in > such a way that all the regulators on the platform are bundled in as > *one* device. I did not look into too many regulator drivers, but I expect this is way that most regulator drivers are implemented in. Having mc13892-regulator being probed 23 times to register these 23 regulators just makes less sense to me. > It would again depend on how you would pass these from > the DT, if you indeed stick to the same way of bundling all regulators > as one device from DT, the mc13892-regulator probe would just get called > once and there would be one device associated, no? > Yes, I indeed would stick to the same way of bundling the registration of all regulators with mc13892-regulator being probed once. The problem I have with the current regulator core DT implementation is that it assumes the device_node of rdev->dev (dev wrapped in regulator_dev) is being attached to rdev->dev.parent rather than itself. Back to mc13892-regulator example, that said, it requires the dev of mc13892-regulator have the device_node of individual regulator attached to. IOW, the current implementation forces mc13892-regulator to be probed 23 times to register those 23 regulators. This is wrong to me. -- Regards, Shawn -- 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
