* Igor Grinberg <grinberg@xxxxxxxxxxxxxx> [100811 14:29]: > On 08/11/10 13:27, Tony Lindgren wrote: > > * Premi, Sanjeev <premi@xxxxxx> [100811 12:45]: > > > >>> -----Original Message----- > >>> From: linux-omap-owner@xxxxxxxxxxxxxxx > >>> [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Tony Lindgren > >>> Sent: Wednesday, August 11, 2010 2:50 PM > >>> To: Igor Grinberg > >>> Cc: Stanley.Miao; linux-omap@xxxxxxxxxxxxxxx > >>> Subject: Re: [PATCH] OMAP2: Fix a cpu type check problem. > >>> > >>> * Igor Grinberg <grinberg@xxxxxxxxxxxxxx> [100810 17:25]: > >>> > >>>> On 08/10/10 15:36, Stanley.Miao wrote: > >>>> > >>>>> cpu_is_omap3517() and cpu_is_omap3505() are the subgroups > >>>>> > >>> of cpu_is_omap34xx(), > >>> > >>>>> so we should check cpu_is_omap3517() and > >>>>> > >>> cpu_is_omap3505() first, then check > >>> > >>>>> cpu_is_omap34xx(). > >>>>> > >>>>> Signed-off-by: Stanley.Miao <stanley.miao@xxxxxxxxxxxxx> > >>>>> > >>>>> > >>>> Tested-by: Igor Grinberg <grinberg@xxxxxxxxxxxxxx> > >>>> > >>>> I've just ran into this yesterday evening. > >>>> Having a patch for this on the next day made me :) > >>>> Tested on AM3517. > >>>> > >>> Can you please describe what breaks so we can merge this as a fix? > >>> > >>> > >> cpu_is_34xx() will be true for all OMAP3 based devices including > >> AM3517. So, if we want to perform operations specific to AM3517, the > >> check for AM3517 should be done first else you match for 34xx would > >> return true; and you wouldn't go far enough to check for am3517. > >> > > Understood, but we need some concrete error like "otherwise booting > > xyz board fails with non-working USB" or similar. > > > > Otherwise, All AM35XX (Sitara) clocks do not get registered and device > drivers > (ti_hecc, etc...) that depend on those clocks are failing to get the > clock and > end up with non working device. Thanks, adding to omap-fixes with updated description. 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
