From: Roger Quadros <roger.quadros@nokia.com>
To: ext Alan Stern <stern@rowland.harvard.edu>
Cc: <gregkh@suse.de>, <mina86@mina86.com>, <m-sonasath@ti.com>,
USB list <linux-usb@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] usb: gadget: composite: Allow function drivers to defer setup responses
Date: Thu, 21 Apr 2011 16:27:14 +0300 [thread overview]
Message-ID: <4DB030B2.7090801@nokia.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1104191001590.1835-100000@iolanthe.rowland.org>
On 04/19/2011 05:14 PM, ext Alan Stern wrote:
> On Tue, 19 Apr 2011, Roger Quadros wrote:
>
>> +/**
>> + * usb_composite_setup_continue() - Continue the delayed setup transfer
>
> You're should say "control transfer", not "setup transfer". Control
> transfers consist of a setup stage, an optional data stage, and a
> status stage. The setup stage has already ended by the time the
> function's setup handler is called.
Yes I will re-word the things and re-send the patches.
>
>> + * @cdev: the composite device who's setup transfer was delayed
>> + *
>> + * This function must be called by the USB function driver to continue
>> + * with the setup transfer's data/status phase in case it had requested to
>
> Data and Status are stages, not phases. See section 8.5.3 of the
> USB-2.0 spec.
>
> You made these mistakes in a few different places throughout the patch.
>
>> + * delay the status phase. A USB function's setup handler (e.g. set_alt())
>> + * can request the composite framework to delay the setup request's status phase
>> + * by returning USB_GADGET_DELAYED_STATUS.
>> + */
>> +void usb_composite_setup_continue(struct usb_composite_dev *cdev)
>> +{
>> + int value;
>> + struct usb_request *req = cdev->req;
>> + unsigned long flags;
>> +
>> + DBG(cdev, "%s\n", __func__);
>> + spin_lock_irqsave(&cdev->lock, flags);
>> +
>> + if (cdev->delayed_status == 0) {
>> + WARN(cdev, "%s: Unexpected call\n", __func__);
>> +
>> + } else if (--cdev->delayed_status == 0) {
>> + DBG(cdev, "%s: Completing delayed status\n", __func__);
>> + req->length = 0;
>> + req->zero = 1;
>
> There's no reason to set this flag. It has no effect when req->length
> is 0.
>
OK.
Thanks for review.
--
regards,
-roger
next prev parent reply other threads:[~2011-04-21 13:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 13:33 [PATCH 0/2] usb: gadget: Make mass_storage pass USBCV MSC Compliance tests Roger Quadros
2011-04-19 13:33 ` [PATCH 1/2] usb: gadget: composite: Allow function drivers to defer setup responses Roger Quadros
2011-04-19 14:14 ` Alan Stern
2011-04-21 13:27 ` Roger Quadros [this message]
2011-04-19 14:23 ` Michal Nazarewicz
2011-04-21 13:30 ` Roger Quadros
2011-05-09 9:42 ` Roger Quadros
2011-04-19 13:33 ` [PATCH 2/2] usb: gadget: f_mass_storage: Make us pass USBCV MSC Compliance tests Roger Quadros
2011-04-19 14:33 ` Michal Nazarewicz
2011-04-19 20:44 ` [PATCH 0/2] usb: gadget: Make mass_storage " Sonasath, Moiz
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=4DB030B2.7090801@nokia.com \
--to=roger.quadros@nokia.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=m-sonasath@ti.com \
--cc=mina86@mina86.com \
--cc=stern@rowland.harvard.edu \
/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