linux-kernel - Re: [PATCH 13/13] clk: basic: improve parent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Apr 2012 20:50:32 -0700
From:	"Turquette, Mike" <mturquette@...com>
To:	Shawn Guo <shawn.guo@...aro.org>
Cc:	Andrew Lunn <andrew@...n.ch>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Russell King <linux@....linux.org.uk>, patches@...aro.org,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Rajendra Nayak <rnayak@...com>, linux-kernel@...r.kernel.org,
	Saravana Kannan <skannan@...eaurora.org>,
	Olof Johansson <olof@...om.net>, linaro-dev@...ts.linaro.org,
	arnd.bergmann@...aro.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 13/13] clk: basic: improve parent_names & return errors

On Mon, Apr 16, 2012 at 6:46 PM, Shawn Guo <shawn.guo@...aro.org> wrote:
> On 17 April 2012 07:10, Turquette, Mike <mturquette@...com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/