On 07/10/2015 18:03, Daniel Lezcano wrote: > On 10/07/2015 03:17 PM, Marc Gonzalez wrote: > >> I'm also confused that you've replaced panic() with pr_err/return. >> AFAIU, if I don't have a clocksource/sched_clock, the system is dead >> in the water. Might as well stop there, and wait for the operator to >> fix whatever needs fixing. (Several clksrc drivers do this.) > > Hmm, yeah that's true but also we have platforms with different > clocksources, so we don't want to panic if the next clocksource will > succeed. That's the logic behind not doing panic. There is some legacy > code still using panic but that should be fixed.
There's so much legacy code lying around that it's really hard to tell what the current best practices are :-( > I don't know if your platform can fall under this category, but it would > be a good practice to pr_err or pr_warn instead of panic in order to be > consistent with the current direction in the recent drivers. I think the system falls back to using the "jiffies clock" when it doesn't find anything better? However, on my system, the clockevent device is running at cpuclk/2, so once I add cpufreq DFS into the mix, I don't think the "jiffies" clock is a very good clocksource. Anyway, updated patch is on the way. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
