[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb
Subject:    Re: [PATCH] [USB] UAS: eliminate infinite loop; add debug print
From:       Luben Tuikov <ltuikov () yahoo ! com>
Date:       2010-11-08 17:57:48
Message-ID: 513136.91622.qm () web31804 ! mail ! mud ! yahoo ! com
[Download RAW message or body]

--- On Mon, 11/8/10, Greg KH <greg@kroah.com> wrote:
> On Mon, Nov 08, 2010 at 09:27:22AM
> -0800, Luben Tuikov wrote:
> > --- On Mon, 11/8/10, Matthew Wilcox <willy@linux.intel.com>
> wrote:
> > > -0700, Luben Tuikov wrote:
> > > > Eliminate an infinite loop whereby the SCSI
> layer
> > > > would reissue a command (which would be
> failed by
> > > > the driver) ad infinitum. (Invariably due to
> the
> > > > driver's profuse use of the
> > > > SCSI_MLQUEUE_DEVICE_BUSY returned result in
> its
> > > > queuecommand() method.)
> > > > 
> > > > Also add a debug option and a few debug
> prints.
> > > 
> > > Why have you added your own debug scheme instead
> of using
> > > dev_dbg?
> > 
> > Because, this debug "scheme" produces copious and
> otherwise
> > unnecessary volume of debug information in a working
> driver. And
> > because you can turn it on/off just for this driver.
> It is intended to
> > be used only for debugging this driver and the UAS
> device(s) to which
> > the driver communicates. 99.9% of the time, this
> setting will be a 'N'
> > out there.  And this is what the Kconfig help
> entry says: "If unsure,
> > say 'N'."
> 
> dev_dbg() is able to be turned on and off dynamically when
> the kernel is
> running without rebuilding anything, which is what you
> really want to
> have happen for a driver being used by normal users.
> 
> It also produces the output in a standard manner that we
> have all agreed
> to follow.

I'll modify the code in my tree and resubmit what I have now using dev_dbg. I'll also \
integrate the hint from Michal.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]