* Rajendra Nayak <rnayak@xxxxxx> [130314 05:44]: > OMAP clock inits happen quite early, even before the slab is available. > As part of the clock init, the common clock core tries to cache parent > pointers (if not passed by the caller registering the clock) which > fails in case of OMAP since the slab isn't initied. > Without CONFIG_DEBUG_SLAB enabled, this just results in the common clock core > retrying the caching attempt at some point later. > However with CONFIG_DEBUG_SLAB enabled this results in a BUG() as reported > in the link below by Tony.. > http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg85932.html > > Fix this by passing static parent pointers to the common clock core > while registering clocks. I wonder if we could easily fix this by initializing only some of the clocks that early? If we had a two stage initialization we could dynamically allocate the rest of the parent clocks without having to add all the static data. Regards, Tony -- 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
