On Tue, Sep 3, 2013 at 10:25 PM, Stephen Warren wrote:
>> chip = desc->chip;
>> if (!chip->set || !chip->set_debounce) {
>> pr_warn("%s: missing set() or set_debounce() operations\n",
>> __func__);
>> + return -EIO;
>> }
>
> BTW, I'm not sure
On 09/03/2013 04:39 AM, Thierry Reding wrote:
> Return an error if neither the ->set() nor the ->set_debounce() function
> is implemented by the chip. Furthermore move locking further down so the
> lock doesn't have to be unlocked on error. This is safe to do because at
> this point the lock doesn'
[+Olof who had mentioned lock recursion BUG in -next]
On Tue, Sep 3, 2013 at 5:10 AM, Linus Walleij wrote:
> On Tue, Sep 3, 2013 at 12:39 PM, Thierry Reding
> wrote:
>
>> Return an error if neither the ->set() nor the ->set_debounce() function
>> is implemented by the chip. Furthermore move lock
On Tue, Sep 3, 2013 at 12:39 PM, Thierry Reding
wrote:
> Return an error if neither the ->set() nor the ->set_debounce() function
> is implemented by the chip. Furthermore move locking further down so the
> lock doesn't have to be unlocked on error. This is safe to do because at
> this point the
Return an error if neither the ->set() nor the ->set_debounce() function
is implemented by the chip. Furthermore move locking further down so the
lock doesn't have to be unlocked on error. This is safe to do because at
this point the lock doesn't protect anything.
Signed-off-by: Thierry Reding
--
5 matches
Mail list logo