Re: context_loss_count error value

[Kevin Hilman <khilman@ti.com>]

Hi Tomi,

Tomi Valkeinen <tomi.valkeinen@ti.com> writes:

> On Wed, 2011-05-18 at 17:41 +0300, Tomi Valkeinen wrote:
>> On Wed, 2011-05-18 at 16:24 +0200, Kevin Hilman wrote:
>> 
>> > Looking closer at the code, a zero return happens only when
>> > 
>> > 1) no hwmod associated to omap_device
>> > 2) no power domain associated to hwmod
>> > 3) power domain has not (yet) lost context
>> > 
>> > None of these are actually error conditions per-se, and in all cases, it
>> > indidates that context has not been lost (or we can't tell if context
>> > has been lost.) 
>> 
>> If the pm code cannot tell whether the context has been lost or not, the
>> driver must assume it has been lost, do you agree? If so, the driver
>> must handle zero return value differently, and always restore context.
>> 
>> > So I think the current code is correct.
>> 
>> How is it correct if it returns an error even if no error has happened
>> =)? Either the code or the documentation is wrong.
>> 
>> How about the wrap-around case? Does the loss count go back to zero?
>
> Any conclusion on this?

Sorry for the lag... been travelling, and finally back home...

You're right, the code is just wrong here and would lead to strange
return value checking in the callers to be correct.

I think the best fix for this problem is to use a signed return value
which can wrap as expected, and then use return negative error codes
(e.g. -ENODEV).

Care to send a patch?  or do you have any other suggestions for a fix?

Thanks,

Kevin