Re: [PATCH 02/16] mfd: omap-usb-tll: Clean up clock handling

[Roger Quadros <rogerq@ti.com>]

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