On Mon, May 21, 2018 at 10:38:25AM +0200, Johan Hovold wrote: > 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@xxxxxxxxx> > > Cc: Samuel Ortiz <sameo@xxxxxxxxxxxxxxx> > > Cc: Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx> > > Cc: stable <stable@xxxxxxxxxxxxxxx> > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > --- > > 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 > > Your changes look correct now so feel free to add: > > Reviewed-by: Johan Hovold <johan@xxxxxxxxxx> Thanks for the review. > It seems we could end up returning an errno from probe with active urbs > (if pn533_finalize_setup() fails) in which case the ack buffer would > leak. But freeing the urbs while active would then be the bigger > problem, and that wasn't introduced by this patch. Yeah, this whole thing is a mess and I really don't want to do much more to the driver without having the hardware to test with it. So I'll just leave it as-is for now :) greg k-h
