Balaji Rao wrote: > In mach-gta02.c, when we define SD_3V3, we also have to specify which > device is the consumer - which means the supply namespace is not global > and it depends on the device and not the platform.
Yes, that's why it works. But I'm somewhat doubtful whether this is really how regulator_get is meant to be used. Perhaps Mark can comment ? (Copied him.) > So, I think it's > reasonable to assume that any regulator that supplies it will be > named SD_3V3 ? Ah, but who says that there will be a regulator ? Or something that's electronically a regulator but for some reason doesn't use the regulator API ? Or something that needs a chain of things to be set up, maybe involving a regulator ? The point is that we already have a perfectly fine mechanism for controlling power to the MMC interface and that's the set_power callback. If you think a platform-specific set_power function that handles the regulator is not enough and we need a generic regulator interface for MMC, then you can always introduce that as a new component and just call it from the machine-specific code. That way, you don't have to widen the interface between s3cmci and platform data but still get all the functionality. This is a very common design pattern in the kernel: if you need to make something aware of a context-specific exception to the rule, don't code that exception but think of a general way of handling any exception of this kind. Otherwise, everyone who needs to have some little tweak would add their own extension and you quickly end up with a thicket of similar but subtly different and overlapping mechanisms. If you believe that making s3cmci directly call the regulator API is the only sane way to do this, have you asked Ben Dooks what he thinks about it ? He's the owner of the driver, so you'd need his blessing to introduce such an architectural changes. - Werner
