On Thu, Jul 05, 2012 at 04:43:27PM +0900, Alex Courbot wrote:

On 07/05/2012 03:47 PM, Sascha Hauer wrote:

quoted

quoted

I thought about just checking if devm_get_regulator returned -ENODEV
and happily continue if that was the case, assuming no regulator was
declared.

And that's the problem. The get_regulator won't return -ENODEV. It will
return -EPROBE_DEFER which tells you nothing about whether a regulator
will ever be available or not.

Having a flag in platform data would be fine with me, but I know other
people think differently.

BTW in devicetree this flag implicitely exists with the power-supply
property.

One could actually question whether the whole regulator/gpio thing
should be supported at all with platform data. The platform
interface can use the function hooks in order to implement whatever
behavior it wants when the light needs to be powered on and off. The
reason for introducing optional regulator/gpio parameters is because
the DT cannot use these. Since I have no plan to remove these
function hooks, making the regulator/gpio option available in
platform data might be redundant. Any thought about this?

I agree. Non-DT platforms have always used the callbacks to execute this
kind of code. As you've said before there are situations where it isn't
just about setting a GPIO or enabling a regulator but it also requires a
specific timing. Representing this in the platform data would become
tedious.

So I think for the DT case you can parse the power-on and power-off
sequences directly and execute code based on it, while in non-DT cases
the init and exit callbacks should be used instead. I think it even
makes sense to reuse the platform data's init and exit functions in the
DT case and implement the parser/interpreter within those.

quoted

Right now the regulator core will just return -EPROBE_DEFER in both
cases. This could easily be changed in the regulator core.

Could this be because the regulator core cannot make the difference
between a not-yet-available regulator and a missing one?

I case where the regulator comes from a DT it should assume that it will
become available at some point, so -EPROBE_DEFER is correct. However if
the DT doesn't even contain the power-supply property, then EPROBE_DEFER
will never work because there's no regulator to become available.

Thierry