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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> > > Tested-by: Robert Jarzmik <robert.jarzmik@xxxxxxx> > > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
