On Wed, Nov 21, 2012 at 10:00 AM, Alex Courbot [off-list ref] wrote:

On Wednesday 21 November 2012 16:48:45 Tomi Valkeinen wrote:

quoted

If the power-off sequence disables a regulator that was supposed to be
enabled by the power-on sequence (but wasn't enabled because of an
error), the regulator_disable is still called when the driver runs the
power-off sequence, isn't it? Regulator enables and disables are ref
counted, and the enables should match the disables.

And there collapses my theory.

quoted

quoted

Failures might be better handled if sequences have some "recovery policy"
about what to do when they fail, as mentioned in the link above. As you
pointed out, the driver might not always know enough about the resources
involved to do the right thing.

Yes, I think such recovery policy would be needed.

Indeed, from your last paragraph this makes even more sense now.

Oh, and I noticed I forgot to reply to this:

quoted

This I didn't understand. Doesn't "<&pwm 2 xyz>" point to a single
device, no matter where and how many times it's used?

That's true - however when dereferencing the phandle, the underlying framework
will try to acquire the PWM, which will result in failure if the same resource
is referenced several times.

One could compare the phandles to avoid this, but in your example you must
know that for PWMs the "xyz" part is not relevant for comparison.

This makes referencing of resources by name much easier to implement and more
elegant with respect to frameworks leveraging.

I would rather (at least for how the DT bindings settle out) see the
design separate the resource references from the sequence. ie. Declare
which resources are used by a device's sequences all in one place and
have the commands index into that.

g.