On 11/21/2012 09:39 PM, Felipe Balbi wrote: > Hi, > > On Wed, Nov 21, 2012 at 05:39:57PM +0200, Roger Quadros wrote: >> On 11/21/2012 04:03 PM, Felipe Balbi wrote: >>> Hi, >>> >>> On Wed, Nov 21, 2012 at 02:36:48PM +0200, Roger Quadros wrote: >>>>>> break; >>>>>> default: >>>>>> - dev_err(dev, "TLL version failed\n"); >>>>>> - ret = -ENODEV; >>>>>> - goto err_ioremap; >>>>>> + tll->nch = DEFAULT_TLL_CHANNEL_COUNT; >>>>>> + dev_info(dev, >>>>>> + "USB TLL Rev : 0x%x not recognized, assuming %d channels\n", >>>>>> + ver, tll->nch); >>>>> >>>>> this hsould be dev_dbg(). >>>>> >>>> >>>> I think it should be more of a warning because it signals a problem. >>>> There is another pr_info in the success path which could probably be a >>>> dev_dbg. >>> >>> it's not a problem at all. It just means that a newer OMAP has come to >>> market and perhaps we don't need extra code to support it. A revision >>> detection should *never* be grounds to failure. When we can't understand >>> the revision, we default to the highest possible value we know. >>> >>> that's not an error. >> >> Agreed. I'm not treating it as an error. We still continue probe and the >> driver should work for newer revisions. Just prints a line on the >> console about the new revision. Thought it would be useful to us, but if >> you think it is a problem I don't mind removing it :). > > that's the thing. It _is_ useful to *us*, kernel/device-driver > engineers. But for the end user it just ends up as yet another > meaningless print in dmesg ;-) > Okay, makes sense. I'll convert it to dev_dbg(). -- cheers, -roger -- 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
