linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Samuel Ortiz <sameo@linux.intel.com>
Cc: Arend van Spriel <arend.vanspriel@broadcom.com>,
	Carlos Manuel Santos <cmmpsantos@gmail.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v4] NFC: pn533: don't send USB data off of the stack
Date: Sat, 9 Jun 2018 16:01:39 +0200	[thread overview]
Message-ID: <20180609140139.GA28854@kroah.com> (raw)
In-Reply-To: <20180609095401.GB25115@caravaggio.jf.intel.com>

On Sat, Jun 09, 2018 at 11:54:01AM +0200, Samuel Ortiz wrote:
> Greg,
> 
> On Sun, May 20, 2018 at 03:19:46PM +0200, Greg Kroah-Hartman wrote:
> > It's amazing that this driver ever worked, but now that x86 doesn't
> > allow USB data to be sent off of the stack, it really does not work at
> > all.  Fix this up by properly allocating the data for the small
> > "commands" that get sent to the device off of the stack.
> > 
> > We do this for one command by having a whole urb just for ack messages,
> > as they can be submitted in interrupt context, so we can not use
> > usb_bulk_msg().  But the poweron command can sleep (and does), so use
> > usb_bulk_msg() for that transfer.
> > 
> > Reported-by: Carlos Manuel Santos <cmmpsantos@gmail.com>
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > Cc: Stephen Hemminger <stephen@networkplumber.org>
> > Cc: stable <stable@vger.kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > v4: don't use urb transfer buffer flags as the memory is tied to the urb
> >     (thanks to Johan)  Now we have a new static urb, and we use
> >     usb_bulk_msg() for the other message.
> > v3: actually use the correct buffer (thanks to Arend van Spriel)
> >     use kmemdup (thanks to Johannes Berg and Julia Lawall)
> > v2: set the urb flags correctly
> > 
> >  drivers/nfc/pn533/usb.c |   42 ++++++++++++++++++++++++++++++------------
> >  1 file changed, 30 insertions(+), 12 deletions(-)
> I can take that one through nfc-next, and the few subsequent patches
> from Hans and Julia. Please let me know what's more convenient for you.

This patch is already in Linus's tree, along with whatever applied from
Julia's patch series.  Hans needs to rebase and resend anyway, so either
tree is fine once 4.18-rc1 is out.

thanks,

greg k-h

      reply	other threads:[~2018-06-09 14:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-20 13:19 [PATCH v4] NFC: pn533: don't send USB data off of the stack Greg Kroah-Hartman
2018-05-21  8:38 ` Johan Hovold
2018-05-31 10:38   ` Greg Kroah-Hartman
2018-06-01  4:06     ` Mark Greer
2018-06-01  8:03       ` Greg Kroah-Hartman
2018-06-09  9:54 ` Samuel Ortiz
2018-06-09 14:01   ` Greg Kroah-Hartman [this message]

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=20180609140139.GA28854@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arend.vanspriel@broadcom.com \
    --cc=cmmpsantos@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=stephen@networkplumber.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).