On Mon, 21 Jun 2010, Paul Walmsley wrote: > On Sat, 19 Jun 2010, Gadiyar, Anand wrote: > > > Gadiyar, Anand wrote: > > > We need to wait on the IDLEST bit after the clocks are enabled > > > before attempting to access any register. > > > > > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait, > > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the > > > i-clock is enabled first, the clkops_omap2_dflt_wait is > > > short-circuited as the companion f-clock is not enabled. > > > This can cause a data abort if the IDLEST has not transitioned, > > > and we try to access a USBTLL register. > > > > > > Since the USBTLL i-clock and f-clock could be enabled in any order, > > > this is a bug. Fix it by changing the clkops for the f-clock. > > > > > > Signed-off-by: Anand Gadiyar <gadiyar@xxxxxx> > > It looks fine to me. I will queue it for a -rc branch. Will requeue this for 2.6.36 merge window since it is not a regression, and it seems that Linus wants regression fixes for the -rc series... - Paul -- 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
