>> Sorry for not being descriptive in commit message. >> >> a) Avoids unnecessary re-parenting cycle for orphan clock's with invalid parent for every clock >> > > True, but this is a minor optimisation. If this is a big optimization > for you then you really need to fix your bootloader. We shouldn't be > optimizing slow error paths just because we refuse to fix the errors. Got it! Should be fixed in boot-loader. > >> b) With patch [1/3], after a clk with invalid parent was encountered, for every clk registered thereafter seeing following logs. >> <Snippet> >> [ 0.000000] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent >> [ 0.000000] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent >> [ 0.000000] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent >> [ 0.000000] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent >> [ 0.000000] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent >> [ 0.000000] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent >> [ 0.000000] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent >> [ 0.000000] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent >> >> Please advice, if can be handled better. >> > > First off, I don't think we should create new structures to work around > bugs that should be fixed. pr_err_once() will let us know something is > wrong and won't flood the log. Even then I'm inclined to say that > flooding the log is OK and will motivate you to fix up your bootloader. > Error prints are there for a reason. > > Secondly, I spent like 10 minutes looking at this code and I'm still > confused. For a clock with invalid parent programming, are you adding > it to BOTH the orphan list and the has_invalid_parent list? Why? Is > this just avoid the spurious prints? For everyone clock registered we > walk the list of orphans to see if that orphan can be reparented. This > patch adds another nested list walk (likely a short list) for each of > those orphans in the first list walk, so it starts to look like O(n^2). > I don't like it. > > I think the first two patches in the series look good, but unless I am > misunderstanding this patch I feel that it can be dropped entirely. > Thanks for your time! Will drop this patch and send V2 for first 2 patches. Regards, Ambresh -- 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
