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. > Tony > > -- Regards, Igor. -- 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
