[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPTae5KEBNyVJOwa3Ft2BVUU_SOGArxfcujdc7L+eHi8kbcKjw@mail.gmail.com>
Date: Fri, 2 Jun 2023 10:34:14 -0700
From: Badhri Jagan Sridharan <badhri@...gle.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: gregkh@...uxfoundation.org, colin.i.king@...il.com,
xuetao09@...wei.com, quic_eserrao@...cinc.com,
water.zhangjiantao@...wei.com, francesco@...cini.it,
alistair@...stair23.me, stephan@...hold.net, bagasdotme@...il.com,
luca@...tu.xyz, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v5 2/3] usb: gadget: udc: core: Invoke usb_gadget_connect
only when started
On Wed, May 31, 2023 at 3:55 PM Alan Stern <stern@...land.harvard.edu> wrote:
>
> On Wed, May 31, 2023 at 03:40:26PM -0700, Badhri Jagan Sridharan wrote:
> > On Wed, May 31, 2023 at 10:55 AM Alan Stern <stern@...land.harvard.edu> wrote:
> > >
> > > On Wed, May 31, 2023 at 04:02:02AM +0000, Badhri Jagan Sridharan wrote:
> > > > usb_udc_connect_control() does not check to see if the udc has already
> > > > been started. This causes gadget->ops->pullup to be called through
> > > > usb_gadget_connect() when invoked from usb_udc_vbus_handler() even
> > > > before usb_gadget_udc_start() is called. Guard this by checking for
> > > > udc->started in usb_udc_connect_control() before invoking
> > > > usb_gadget_connect().
> > >
> > > After a merged version of patches 1/3 and 3/3 have been applied, it
> > > seems like most of this will not be needed any more. Maybe not any of
> > > it.
> >
> > Without the connect_lock introduced in this patch, wouldn't the
> > usb_gadget_connect()/
> > usb_gadget_disconnect() through soft_connect_store() race against
> > usb_gadget_connect()/ usb_gadget_disconnect() through
> > usb_udc_connect_control() ?
>
> Okay, yes, that's a good point. It needs to be mentioned in the patch
> description so that people will understand it is the real reason for
> this change.
Thanks Alan !
I had posted the v6 version of the series with 1/3 and 3/3 of v5
squashed together. I have made changes to address your concerns in v5.
Instead of adding a new lock, I used the connect_lock in this patch to
protect the allow_connect flag.
Eager to know your thoughts !
Regards,
Badhri
>
> Alan Stern
Powered by blists - more mailing lists