On Wed, 22 Apr 2009 01:21:10 +0200 Laurent Pinchart <laurent.pinchart@xxxxxxxxx> wrote: > Hi, > > On Tuesday 21 April 2009 03:47:34 Ming Lei wrote: > > 2009/4/21 Laurent Pinchart <laurent.pinchart@xxxxxxxxx>: > > > On Saturday 18 April 2009 06:51:11 leiming wrote: > > >> From a3b3d72cdd57a0699fb643b41b78eb7beb211ff5 Mon Sep 17 > > >> 00:00:00 2001 From: Ming Lei <tom.leiming@xxxxxxxxx> > > >> Date: Wed, 15 Apr 2009 22:32:51 +0800 > > >> Subject: [PATCH] V4L/DVB:usbvideo:fix uvc resume failed(v2) > > >> > > >> Now urb buffers is not freed before suspend, so > > >> uvc_alloc_urb_buffers should return packet counts allocated > > >> originally during uvc resume , instead of zero. > > >> > > >> This version uses round down to return packet counts on Linus's > > >> suggestions, or else may lead to buffer destructed if packet size > > >> is changed before calling uvc_alloc_urb_buffers() in this kind of > > >> case. > > > > > > The comment is misleading. If the packet size changes we need to > > > reallocate the buffers anyway. Have you checked if the packet > > > size (which depends on the endpoint being selected) can be > > > changed between suspend and resume, either by the uvcvideo driver > > > (I don't think it can) or the USB core ? > > > > The packet size does not change between suspend and resume. I mean > > uvc_alloc_urb_buffers() still can be used in other cases if buffers > > was not freed and is reuesed in future. It seems there is no such > > cases in uvcvideo now, but uvc_alloc_urb_buffers() really __can__ > > work in such case, isn't it? > > > > IMHO It is only used to allocate or reserve UVC_URBS usb buffers, > > which size is video->urb_size, and npackets can be shortened or > > enlarged if psize is changed, after all. > > You're right. Patch applied, thanks. Rc5 has been released today, why isn't this patch accepted by upstream now? It is really a bug fix. Thanks. > > Best regards, > > Laurent Pinchart > -- Lei Ming -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
