Linux USB
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Elson Serrao <quic_eserrao@quicinc.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"balbi@kernel.org" <balbi@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"quic_wcheng@quicinc.com" <quic_wcheng@quicinc.com>,
	"quic_jackp@quicinc.com" <quic_jackp@quicinc.com>
Subject: Re: [PATCH v8 5/5] usb: gadget: f_ecm: Add suspend/resume and remote wakeup support
Date: Tue, 14 Mar 2023 20:16:44 +0000	[thread overview]
Message-ID: <20230314201636.mfmjrgluckyk5xhy@synopsys.com> (raw)
In-Reply-To: <7064988c-9975-64c3-25c6-e1330ed723a4@quicinc.com>

On Tue, Mar 14, 2023, Elson Serrao wrote:
> 
> 
> On 3/13/2023 1:27 PM, Thinh Nguyen wrote:
> > On Mon, Mar 13, 2023, Elson Roy Serrao wrote:
> > > When host sends a suspend notification to the device, handle
> > > the suspend callbacks in the function driver. Enhanced super
> > > speed devices can support function suspend feature to put the
> > > function in suspend state. Handle function suspend callback.
> > > 
> > > Depending on the remote wakeup capability the device can either
> > > trigger a remote wakeup or wait for the host initiated resume to
> > > start data transfer again.
> > > 
> > > Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
> > > ---
> > >   drivers/usb/gadget/function/f_ecm.c   | 68 +++++++++++++++++++++++++++++++++++
> > >   drivers/usb/gadget/function/u_ether.c | 63 ++++++++++++++++++++++++++++++++
> > >   drivers/usb/gadget/function/u_ether.h |  4 +++
> > >   3 files changed, 135 insertions(+)
> > > 
> > > diff --git a/drivers/usb/gadget/function/f_ecm.c b/drivers/usb/gadget/function/f_ecm.c
> > > index a7ab30e..d50c1a4 100644
> > > --- a/drivers/usb/gadget/function/f_ecm.c
> > > +++ b/drivers/usb/gadget/function/f_ecm.c
> > > @@ -633,6 +633,8 @@ static void ecm_disable(struct usb_function *f)
> > >   	usb_ep_disable(ecm->notify);
> > >   	ecm->notify->desc = NULL;
> > > +	f->func_suspended = false;
> > > +	f->func_wakeup_armed = false;
> > >   }
> > >   /*-------------------------------------------------------------------------*/
> > > @@ -885,6 +887,68 @@ static struct usb_function_instance *ecm_alloc_inst(void)
> > >   	return &opts->func_inst;
> > >   }
> > > +static void ecm_suspend(struct usb_function *f)
> > > +{
> > > +	struct f_ecm *ecm = func_to_ecm(f);
> > > +	struct usb_composite_dev *cdev = ecm->port.func.config->cdev;
> > > +
> > > +	if (f->func_suspended) {
> > > +		DBG(cdev, "Function already suspended\n");
> > > +		return;
> > > +	}
> > > +
> > > +	DBG(cdev, "ECM Suspend\n");
> > > +
> > > +	gether_suspend(&ecm->port);
> > > +}
> > > +
> > > +static void ecm_resume(struct usb_function *f)
> > > +{
> > > +	struct f_ecm *ecm = func_to_ecm(f);
> > > +	struct usb_composite_dev *cdev = ecm->port.func.config->cdev;
> > > +
> > > +	/*
> > > +	 * If the function is in USB3 Function Suspend state, resume is
> > > +	 * canceled. In this case resume is done by a Function Resume request.
> > > +	 */
> > > +	if (f->func_suspended)
> > > +		return;
> > > +
> > > +	DBG(cdev, "ECM Resume\n");
> > > +
> > > +	gether_resume(&ecm->port);
> > > +}
> > > +
> > > +static int ecm_get_status(struct usb_function *f)
> > > +{
> > > +	return (f->func_wakeup_armed ? USB_INTRF_STAT_FUNC_RW : 0) |
> > > +		USB_INTRF_STAT_FUNC_RW_CAP;
> > 
> > Need to check the usb configuration is if it's wakeup_capable.
> > 
> > > +}
> > > +
> > > +static int ecm_func_suspend(struct usb_function *f, u8 options)
> > > +{
> > > +	struct f_ecm *ecm = func_to_ecm(f);
> > > +	struct usb_composite_dev *cdev = ecm->port.func.config->cdev;
> > > +
> > > +	DBG(cdev, "func susp %u cmd\n", options);
> > > +
> > > +	f->func_wakeup_armed = !!(options & (USB_INTRF_FUNC_SUSPEND_RW >> 8));
> > 
> > Same here. Check config's bmAttributes if it's remote wakeup capable
> > before arming for remote wakeup.
> > 
> Done. I will add that check for above two cases.
> > > +
> > > +	if (options & (USB_INTRF_FUNC_SUSPEND_LP >> 8)) {
> > > +		if (!f->func_suspended) {
> > > +			ecm_suspend(f);
> > > +			f->func_suspended = true;
> > > +		}
> > > +	} else {
> > > +		if (f->func_suspended) {
> > > +			f->func_suspended = false;
> > > +			ecm_resume(f);
> > > +		}
> > > +	}
> > > +
> > > +	return 0;
> > 
> > Need to return negative error if SetFeature fails. We should fix the
> > composite layer to allow for protocal STALL here. Host needs to know if
> > it should proceed to put the function in suspend.
> > 
> > Thanks,
> > Thinh
> > 
> 
> Could you please clarify what SetFeature fail here means? The host puts the
> function in function suspend state through this SetFeature request.
> If the device is not configured for remote wakeup (bmAtrributes wakeup bit),
> like you mentioned above we should not arm the function for remote wakeup.
> But the host is free to put the function in function suspend state and wake
> it up through host initiated function resume right?
> 

I mean if we want to tell the host that a feature cannot be set or that
it doesn't exist, we should respond with a protocol STALL. How the host
respond to the rejected SetFeature request is up to the host. But we
should at least let the host know that.

I'm suggesting to remove the setting of value = 0 in composite.c:

-- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -2000,7 +2000,6 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
                                ERROR(cdev,
                                      "func_suspend() returned error %d\n",
                                      value);
-                               value = 0;
                        }
                        break;
                }


i.e. we should allow the return value to go through.

Thanks,
Thinh

  reply	other threads:[~2023-03-14 20:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-13 18:24 [PATCH v8 0/5] Add function suspend/resume and remote wakeup support Elson Roy Serrao
2023-03-13 18:24 ` [PATCH v8 1/5] usb: gadget: Properly configure the device for remote wakeup Elson Roy Serrao
2023-03-13 18:24 ` [PATCH v8 2/5] usb: dwc3: Add remote wakeup handling Elson Roy Serrao
2023-03-13 20:29   ` Thinh Nguyen
2023-03-13 18:24 ` [PATCH v8 3/5] usb: gadget: Add function wakeup support Elson Roy Serrao
2023-03-13 18:24 ` [PATCH v8 4/5] usb: dwc3: Add function suspend and " Elson Roy Serrao
2023-03-13 18:24 ` [PATCH v8 5/5] usb: gadget: f_ecm: Add suspend/resume and remote " Elson Roy Serrao
2023-03-13 20:27   ` Thinh Nguyen
2023-03-14 19:36     ` Elson Serrao
2023-03-14 20:16       ` Thinh Nguyen [this message]
2023-03-14 20:45         ` Thinh Nguyen
2023-03-14 21:03           ` Elson Serrao
2023-03-14 21:34             ` Thinh Nguyen

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=20230314201636.mfmjrgluckyk5xhy@synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=quic_eserrao@quicinc.com \
    --cc=quic_jackp@quicinc.com \
    --cc=quic_wcheng@quicinc.com \
    /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