From mboxrd@z Thu Jan  1 00:00:00 1970
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
Date: Fri, 29 Mar 2013 16:23:59 +0530
Subject: [PATCH 4/9] ARM: OMAP4: cpuidle: fix wrong driver initialization
In-Reply-To: <515570DF.5010608@linaro.org>
References: <1364553095-25110-1-git-send-email-daniel.lezcano@linaro.org>
 <1364553095-25110-4-git-send-email-daniel.lezcano@linaro.org>
 <51556F1D.5030208@ti.com> <515570DF.5010608@linaro.org>
Message-ID: <515572C7.1030309@ti.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Friday 29 March 2013 04:15 PM, Daniel Lezcano 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 ?
> 
Fisrtly patches get posted to right mailing list based on where the
code resides. So one must keep a watch on LAKML for the patches.

Talking specific to OMAP idle code, there is plan to move
to drivers/idle/* but for that to happen there are some PRM/CM
dependency for which also driver movement is planned. Once
that happen, OMAP idle will find its way in drivers/idle/*