On Sat, Feb 04, 2017 at 10:19:21AM -0800, Dmitry Torokhov wrote:
> Instead of returning both regulator_dev structure as return value and
> auxiliary error code in 'ret' argument, let's switch to using ERR_PTR
> encoded values. This makes it more obvious what is going on at call sites.
I did apply
On Sat, Feb 04, 2017 at 10:19:21AM -0800, Dmitry Torokhov wrote:
> Instead of returning both regulator_dev structure as return value and
> auxiliary error code in 'ret' argument, let's switch to using ERR_PTR
> encoded values. This makes it more obvious what is going on at call sites.
I did apply
On Sat, Feb 04, 2017 at 10:19:21AM -0800, Dmitry Torokhov wrote:
> V2: replaced "return r ? r : ERR_PTR(-ENODEV);" with expanded "if"
> statement.
Please don't send new versions of patches as replies into the middle of
existing patch serieses, especially not by replying to individual
patches and
On Sat, Feb 04, 2017 at 10:19:21AM -0800, Dmitry Torokhov wrote:
> V2: replaced "return r ? r : ERR_PTR(-ENODEV);" with expanded "if"
> statement.
Please don't send new versions of patches as replies into the middle of
existing patch serieses, especially not by replying to individual
patches and
Instead of returning both regulator_dev structure as return value and
auxiliary error code in 'ret' argument, let's switch to using ERR_PTR
encoded values. This makes it more obvious what is going on at call sites.
Also, let's not unlock the mutex in the middle of a loop, but rather break
out and
Instead of returning both regulator_dev structure as return value and
auxiliary error code in 'ret' argument, let's switch to using ERR_PTR
encoded values. This makes it more obvious what is going on at call sites.
Also, let's not unlock the mutex in the middle of a loop, but rather break
out and
6 matches
Mail list logo
