Re: [PATCH 0/2] small xhci cleanups

[Greg KH <greg@kroah.com>]

On Thu, Mar 18, 2010 at 02:33:08PM -0700, Sarah Sharp wrote:
> On Tue, Mar 16, 2010 at 02:40:14PM -0700, Greg KH wrote:
> > On Tue, Mar 16, 2010 at 02:24:45PM -0700, Sarah Sharp wrote:
> > > Ok, I didn't see Greg's email about dynamic debugging.  I guess you
> > > shouldn't refresh the second patch.  I'm not sure how I would go about
> > > converting the xHCI driver to dynamic debugging, as I haven't looked
> > > into it.  Is there any documentation/simple examples?
> > 
> > Yes, just use 'dev_dbg' and you are finished.
> > 
> > Or pr_debug if you want to use different logging levels with your
> > macros.
> > 
> > > Greg, does the less-verbose patch with log levels still make sense if
> > > the driver got converted over to dynamic debugging?
> > 
> > I don't know what people really want to see.  In 6 months you will
> > probably only care about "debugging on or off" as the majority of the
> > messages only help you out when developing the driver, right?
> 
> "On" or "off" doesn't really help when you're trying to debug different
> parts of the driver.  If you're trying to debug a command, messages
> about wrapping rings or enqueueing transfers doesn't really matter.

Like Roland, I recommend the tracing interface for this.

> I think the end user doesn't want to see anything from the driver unless
> something serious has gone wrong.  But those cases use xhci_warn(),
> which translates down to dev_warn(), instead of xhci_dbg().

Yes, that's fine.  But you need/want something for when a user reports a
problem, and they can't rebuild their kernel.

> > So maybe par down some of the messages, or just live with seeing them
> > all, it will be easier in the end.
> 
> Yes, I did par down the duplicate/redundant messages, but I still want
> to see very detailed messages when I think there's a hardware problem.
> 
> What if I removed the debug config option for xHCI, allowed people to
> use dynamic debugging to enable debugging for specific xHCI files, but
> also allowed them to set the log level through a debugfs file?  That way
> people could still control the variety of messages that they see, but
> they can also change the level of debugging dynamically.

Sure, that might work, but I'd recommend tracing for the most part,
that's what it is there for :)

thanks,

greg k-h