All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: matt mooney <mfm@muteddisk.com>
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk with dev_ and pr_
Date: Thu, 19 May 2011 17:00:13 -0700	[thread overview]
Message-ID: <20110520000013.GA8908@kroah.com> (raw)
In-Reply-To: <2db81796703063c0816d0d99040c6fbd6da50007.1305847719.git.mfm@muteddisk.com>

On Thu, May 19, 2011 at 04:47:32PM -0700, matt mooney wrote:
> This switches all of the usbip_u{dbg,err,info} and printk statements to
> dev_<level>, if possible, or pr_<level> macros. And removes a few
> unnecessary debug statements.
> 
> Signed-off-by: matt mooney <mfm@muteddisk.com>
> ---
> Hi Greg,
> 
> Not as many of these could be changed to dev_* as I had initially
> thought. A few were not changed to dev_* that could have possibly been
> due to the struct device being deeply embedded within another
> structure. I did not want to introduce any null pointer deferences, so
> I played it safe for the time being. But as development continues I
> will modify these.

Ok, that's fine.

> I also wonder if anybody is currently using usbip because I get a kernel
> crash on the remote side everytime I try to attach an exported device.
> Of course, I am running the remote and host machines through kvm, but I
> don't think that should make a difference. Anyway, I thought you should
> know so that if this comes up, you know that it was in this state before
> any of my changes ;)

I have gotten a few reports of it not working right now, but no one
stepped up and debugged it.

If you could do that now, that would be great, as it would be nice to
have a working base to go off of :)

Also, the merge window for the .40 tree for the staging tree is now
closed, so I'll only take bugfixes for the usbip code for now.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: matt mooney <mfm@muteddisk.com>
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk
Date: Fri, 20 May 2011 00:00:13 +0000	[thread overview]
Message-ID: <20110520000013.GA8908@kroah.com> (raw)
In-Reply-To: <2db81796703063c0816d0d99040c6fbd6da50007.1305847719.git.mfm@muteddisk.com>

On Thu, May 19, 2011 at 04:47:32PM -0700, matt mooney wrote:
> This switches all of the usbip_u{dbg,err,info} and printk statements to
> dev_<level>, if possible, or pr_<level> macros. And removes a few
> unnecessary debug statements.
> 
> Signed-off-by: matt mooney <mfm@muteddisk.com>
> ---
> Hi Greg,
> 
> Not as many of these could be changed to dev_* as I had initially
> thought. A few were not changed to dev_* that could have possibly been
> due to the struct device being deeply embedded within another
> structure. I did not want to introduce any null pointer deferences, so
> I played it safe for the time being. But as development continues I
> will modify these.

Ok, that's fine.

> I also wonder if anybody is currently using usbip because I get a kernel
> crash on the remote side everytime I try to attach an exported device.
> Of course, I am running the remote and host machines through kvm, but I
> don't think that should make a difference. Anyway, I thought you should
> know so that if this comes up, you know that it was in this state before
> any of my changes ;)

I have gotten a few reports of it not working right now, but no one
stepped up and debugged it.

If you could do that now, that would be great, as it would be nice to
have a working base to go off of :)

Also, the merge window for the .40 tree for the staging tree is now
closed, so I'll only take bugfixes for the usbip code for now.

thanks,

greg k-h

  reply	other threads:[~2011-05-20  0:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 23:47 [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk with dev_ and pr_ matt mooney
2011-05-19 23:47 ` matt mooney
2011-05-20  0:00 ` Greg KH [this message]
2011-05-20  0:00   ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk Greg KH
2011-05-20  0:17   ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk with dev_ and pr_ matt mooney
2011-05-20  0:17     ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk matt mooney
2011-05-20  0:24     ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk with dev_ and pr_ Greg KH
2011-05-20  0:24       ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk Greg KH
2011-05-20  2:30       ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk with dev_ and pr_ matt mooney
2011-05-20  2:30         ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk matt mooney
2011-05-20  4:12         ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk with dev_ and pr_ Greg KH
2011-05-20  4:12           ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk Greg KH
2011-05-20  4:31           ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk with dev_ and pr_ matt mooney
2011-05-20  4:31             ` [PATCH] staging: usbip: replace usbip_u{dbg,err,info} and printk matt mooney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110520000013.GA8908@kroah.com \
    --to=greg@kroah.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfm@muteddisk.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.