On Saturday 18 April 2009 06:51:11 leiming wrote: > On Fri, 17 Apr 2009 19:55:29 -0700 (PDT) > > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > @@ -742,7 +742,7 @@ static int uvc_alloc_urb_buffers(struct > > > uvc_video_device *video, > > > /* Buffers are already allocated, bail out. */ > > > if (video->urb_size) > > > - return 0; > > > + return DIV_ROUND_UP(video->urb_size, psize); > > > > I don't think this is right. It should round _down_. > > > > It's supposed to return 'npackets', but if you pass it a different > > packet size than it was passed originally, it can now return a > > potentially bigger number than the already allocated buffer, no? > > > > So I think it should round down (ie use a regular divide). No? > > Yes,you are correct, please ignore my last reply, and following is > the fixed patch. psize and video->urb_size shouldn't have changed before and after resume, otherwise we'll get into trouble anyway. A regular divide and a round-up divide should then return the same result. I'll take the regular divide, as it will be more efficient. > Thanks. > > 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 ? Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
