From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755855Ab2DQDu6 (ORCPT ); Mon, 16 Apr 2012 23:50:58 -0400 Received: from na3sys009aog111.obsmtp.com ([74.125.149.205]:36067 "EHLO na3sys009aog111.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755791Ab2DQDu4 convert rfc822-to-8bit (ORCPT ); Mon, 16 Apr 2012 23:50:56 -0400 MIME-Version: 1.0 In-Reply-To: References: <1334192572-12499-1-git-send-email-mturquette@linaro.org> <1334192572-12499-14-git-send-email-mturquette@linaro.org> <20120412064920.GH2445@S2101-09.ap.freescale.net> From: "Turquette, Mike" Date: Mon, 16 Apr 2012 20:50:32 -0700 Message-ID: Subject: Re: [PATCH 13/13] clk: basic: improve parent_names & return errors To: Shawn Guo Cc: Andrew Lunn , Mark Brown , Russell King , patches@linaro.org, Sascha Hauer , Rajendra Nayak , linux-kernel@vger.kernel.org, Saravana Kannan , Olof Johansson , linaro-dev@lists.linaro.org, arnd.bergmann@linaro.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 16, 2012 at 6:46 PM, Shawn Guo wrote: > On 17 April 2012 07:10, Turquette, Mike wrote: > ... >> Yes, this was a braindead change on my part.  I'll remove the kstrdup >> in my next series (the rest of this patch will stay in). >> > Do you have an ETA on that?  A few platform porting are waiting for a > stable branch with all necessary fixup/cleanup integrated to publish > the patches. That is a good question. I think it is worth waiting on Saravana's patch which exposes non-private members of struct clk via struct clk_hw. This will have an effect on both platform clock data and code. I do not think that there is a point in pushing another series out until I get that in since it will shake things up for platforms trying to convert over. And due to the invasive nature I'm still not sure if this stuff will go into an -rc or some -next branch for 3.5. I don't see the harm in keeping it in a -next branch for 3.5 where all platforms can base on that branch since they will be queuing up for 3.5 anyway. Regards, Mike > Regards, > Shawn