On Thu, 26 Jul 2012, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 25, 2012 at 02:53:00PM +0200, Rajaram REGUPATHY wrote:
> > The short_not_ok field is used by class drivers to indicate udc whether short packet is expected during a particular transfer.
> > In case of mass storage, during command and status phase this field is set as false and set to true during data phase.
> > musb driver uses this field to decide whether to program DMA for mode1.
> > This code is essential for musb driver to program DMA.
> >
> > Signed-off-by: Balakumar Rajendran <balakumar.rajendran@xxxxxxxxxxxxxx>
> > Signed-off-by: Rajaram R <ragupathy.rajaram@xxxxxxxxxxxxxx>
> > ---
> > drivers/usb/gadget/f_mass_storage.c | 9 +++++++++
> > 1 files changed, 9 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c
> > index f67b453..db8bf4a 100644
> > --- a/drivers/usb/gadget/f_mass_storage.c
> > +++ b/drivers/usb/gadget/f_mass_storage.c
> > @@ -878,6 +878,7 @@ static int do_write(struct fsg_common *common)
> > unsigned int amount;
> > ssize_t nwritten;
> > int rc;
> > + struct usb_gadget *gadget = common->cdev->gadget;
> >
> > if (curlun->ro) {
> > curlun->sense_data = SS_WRITE_PROTECTED; @@ -960,6 +961,8 @@ static int do_write(struct fsg_common *common)
> > * the bulk-out maxpacket size.
> > */
> > set_bulk_out_req_length(common, bh, amount);
> > + if (!gadget_is_superspeed(gadget))
> > + bh->outreq->short_not_ok = 1;
>
> I'm not sure if this entirely correct. We are now setting req->length
> aligned to wMaxPacketSize, which means that if we're to receive CBW of
> 31 bytes, req->length will be set to 512. In this case a short packet
> _is_ ok. It's the only way for us to know that the transfer has ended.
It's okay. This particular section of code applies only to the data
phase of a transfer. The CBW is sent in the command phase, and there
the patch sets short_not_ok to 0.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
