accessing SD_3V3 in drivers/mmc/host/s3cmci.c

[Werner Almesberger]

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