[PATCH 4/9] ARM: OMAP4: cpuidle: fix wrong driver initialization

[santosh.shilimkar@ti.com (Santosh Shilimkar)]

On Friday 29 March 2013 06:20 PM, Amit Kucheria wrote:
> On Fri, Mar 29, 2013 at 5:50 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> On Friday 29 March 2013 05:26 PM, Amit Kucheria wrote:
>>> On Fri, Mar 29, 2013 at 4:15 PM, Daniel Lezcano
>>> <daniel.lezcano@linaro.org> wrote:
>>>> On 03/29/2013 11:38 AM, Santosh Shilimkar wrote:
>>>>> On Friday 29 March 2013 04:01 PM, Daniel Lezcano wrote:
>>>>>> The driver is initialized several times. This is wrong and if the
>>>>>> return code of the function was checked, it will return -EINVAL.
>>>>>>
>>>>>> Move this initialization out of the loop.
>>>>>>
>>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>>> ---
>>>>> Fix for this is already and v2 of the patch is here [1]
>>>>
>>>> Ah, ok. Thanks for reviewing the patch.
>>>>
>>>> Can we find a solution to have a single entry point to sumbit patches
>>>> for all the cpuidle drivers ?
>>>>
>>>> Otherwise, consolidating them is a pain: a patch for the samsung tree,
>>>> another one for the at91 tree, etc ... and wait for all the trees to
>>>> sync before continuing to consolidate the code.
>>>>
>>>> Wouldn't be worth to move these drivers under the PM umbrella instead of
>>>> the SoC specific code ?
>>>>
>>>> Any idea to simplify the cpuidle consolidation and maintenance ?
>>>
>>> Adding Arnd and Olof to this discussion since atleast the ARM drivers
>>> go through their arm-soc tree.
>>>
>>> Given the work you're putting in to consolidate the drivers, perhaps
>>> they can insist that idle drivers get acked by you?
>>>
>> Not to create controversy but as a general rule there is nothing
>> like *insisting* ack on patches for merge apart from the official
>> maintainers(gate keepers).
>>
>> Having said that, its always good to get more reviews and acks so
>> that better code gets merged.
>>
>> This just my personal opinion.
> 
> I'm not asking for special treatment here. :) I'm requesting one set
> of maintainers (arm-soc maintainers) to push back on changes that
> don't get platform idle drivers in sync with the consolidation work
> that is currently ongoing.
> 
> This will speed up the process since it is hard to track every
> SoC-specific list for these changes. Some platform maintainers might
> not even be aware of it (those that Daniel hasn't modified yet). A
> similar approach seems to have worked for common clock, DT, pinmux,
> etc.
> 
Every patch gets pulled into arm-soc/arm-core has to be posted on
LAKML. So as long as everybody follows that rule, there is no need to
track every SoC lists. And what I have seen so far every this rule
has been followed well.

Regards,
Santosh