[PATCH 03/14] clkdev: get rid of redundant clk_add_alias() prototype in linux/clk.h

[Russell King - ARM Linux]

On Mon, Apr 06, 2015 at 12:04:21PM -0700, Stephen Boyd wrote:
> On 04/04/15 05:43, Robert Jarzmik wrote:
> > Russell King <rmk+kernel at arm.linux.org.uk> writes:
> >
> >> clk_add_alias() is provided by clkdev, and is not part of the clk API.
> >> Howver, it is prototyped in two locations: linux/clkdev.h and
> >> linux/clk.h.  This is a mess.  Get rid of the redundant and unnecessary
> >> version in linux/clk.h.
> >>
> >> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> > Tested-by: Robert Jarzmik <robert.jarzmik at free.fr>
> >
> > Actually, this serie fixes a regression I've seen in linux-next, and which was
> > triggering the Oops in [1] on lubbock. With your serie, the kernel boots fine.
> >
> >
> 
> Is this with the lubbock_defconfig? Is it a regression in 4.0-rc series
> or is it due to some pending -next patches interacting with the per-user
> clock patches? It looks like the latter because __clk_get_hw() should be
> inlined on lubbock_defconfig where CONFIG_COMMON_CLK=n.

It's a regression with anything that uses clk_add_alias() or which
open codes the aliasing of clocks, or registration of clocks into
clkdev.  It's quite nasty.

The problem is that the way you updated clkdev, by adding __clk_get_hw()
at clk_get() time, the struct clk which we're passing in there could
well have been already clk_put()'d, and therefore freed, and no longer
valid.

It's a regression ever since the per-user clk patches went in, caused
_entirely_ by those patches.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.