On Wednesday 27 November 2013 07:17 PM, Daniel Mack wrote:
> Hi Sekhar,
>
> On 11/27/2013 02:35 PM, Sekhar Nori wrote:
>> On Monday 18 November 2013 03:49 AM, Daniel Mack wrote:
>
>>> +static int edma_pm_suspend(struct device *dev)
>>> +{
>>> + int j, r;
>>> +
>>> + r = pm_runtime_get_sync(dev);
>>> + if (IS_ERR_VALUE(r)) {
>>
>> So IS_ERR_VALUE() is only for functions which may return a negative
>> number outside of MAX_ERRNO as a success indication.
>> pm_runtime_get_sync() does not appear to be one of them so just use"
>>
>> if (r < 0) { .. }
>
> That's true. Thanks for catching this, I'll fix it. However, grepping
> through the tree, there are quite a lot places where the same mistake is
> made.
Yes, this is a common fallacy. Russell cleaned up a bunch of these a
while back.
>
>>> + /* Map the channel to param entry if channel mapping logic
>>> + * exist
>>> + */
>>
>> Please follow the multi-line commenting style.
>
> Can do. However, these lines in fact follow the style that is used
> throughout the entire file ;)
:) I did not compare the rest of the file, but hey the bar keep rising
all the time.
>
>> There are some checkpatch checks that result from lines like this.
>> Please fix these as well.
>>
>> CHECK: Alignment should match open parenthesis
>> #179: FILE: arch/arm/common/edma.c:1841:
>> + map_queue_tc(j, queue_tc_mapping[i][0],
>> + queue_tc_mapping[i][1]);
>
> If you say so, even though I disagree with checkpatch.pl here. The above
> is actually more readable, right? :)
In this particular case, I agree so I am okay if you keep it as is. The
rest of the two reports are valid though.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
