lkml.org 
[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/2] small xhci cleanups
    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


    \
     
     \ /
      Last update: 2010-03-18 23:23    [W:0.026 / U:0.528 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site