On Wed, Oct 20, 2010 at 1:12 AM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > On Tue, Oct 19, 2010 at 3:02 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: ... >> i2c-omap, which is subsys_initcall (the I2C bus is shared between the >> A9 and the M3 on some OMAP4 boards). ... > Man. this is getting ugly. I think we need to discuss how to solve > this at the Plumbers micro-conference. It kind of fits in with the > whole embedded (ab)use of the device model topic anyway. Actually, > this particular case isn't bad, but the moving of i2c and spi busses > to an earlier initcall is just band-aiding the real problem of driver > probe order dependencies. +1 On Wed, Oct 20, 2010 at 1:53 AM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > Rather than moving towards having more drivers have to be built in (and > depend on their probe order) we need to be moving towards building all > these drivers as modules, including omap-i2c. +1 This whole thing is a mess, and today it's being solved in the wrong, non-scalable and error-prone way. The question is whether we want to gate hwspinlock until this issue is solved ? On Wed, Oct 20, 2010 at 3:20 AM, Ryan Mallon <ryan@xxxxxxxxxxxxxxxx> wrote: > The issue of probe order still needs to be resolved for those of us who > do want all the drivers built into the kernel. What about doing something similar to the way suspend/resume and the device hierarchy interact ? device_resume waits for its parent to be resumed before waking up the device - this sounds similar to what ->probe() should do: wait for its device dependency to probe first (so in this case, i2c-omap should wait for hwspinlock). Conversely, device_suspend waits for all its children to be suspended before continuing, which sounds just like what ->remove() should do (so again, in this case, the hwspinlock device should wait for all its users to be removed before bailing). This is just a quick thought, I haven't even began to think of all the use cases and requirements. -- 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
