From: Felipe Balbi <balbi@kernel.org>
To: John Youn <John.Youn@synopsys.com>,
        "Du\, Changbin" <changbin.du@intel.com>
Cc: "gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup
In-Reply-To: <572266F9.7000204@synopsys.com>
References: <1461745745-3954-1-git-send-email-changbin.du@intel.com> <87wpnjmm7u.fsf@intel.com> <0C18FE92A7765D4EB9EE5D38D86A563A05D1E1A7@SHSMSX103.ccr.corp.intel.com> <87vb32kz7s.fsf@intel.com> <572266F9.7000204@synopsys.com>
User-Agent: Notmuch/0.21+96~g9bbc54b (http://notmuchmail.org) Emacs/25.0.90.3 (x86_64-pc-linux-gnu)
Date: Fri, 29 Apr 2016 09:10:36 +0300
Message-ID: <87bn4tj677.fsf@intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4189
Lines: 107

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hi,

John Youn <John.Youn@synopsys.com> writes:
>> "Du, Changbin" <changbin.du@intel.com> writes:
>>> Hi, Balbi,
>>>
>>> The step to reproduce this issue is:
>>> 1) connect device to a host and wait its enumeration.
>>> 2) trigger software disconnect by calling function
>>>     usb_gadget_disconnect(), which finally call
>>>    dwc3_gadget_pullup(false). Do not reconnect device
>>>   (I mean no enumeration go on, keep bit Run/Stop 0.).
>>>
>>> At here, gadget driver's disconnect callback should be
>>> Called, right? We has been disconnected. But no, as
>>> You said " not generating disconnect IRQ after you
>>> drop Run/Stop is expected".
>>>
>>> And I am testing on an Android device, Android only
>>> use dwc3_gadget_pullup(false) to issue a soft disconnection.
>>> This confused user that the UI still show usb as connected
>>> State, caused by missing a disconnect event.
>>=20
>> okay, so I know what this is. This is caused by Android gadget itself
>> not notifying the gadget that a disconnect has happened. Just look at
>> udc-core's soft_connect implementation for the sysfs interface, and
>> you'll see what I mean.
>>=20
>> This should be fixed at Android gadget itself. The only thing we could
>> do is introduce a new usb_gadget_soft_connect()/disconnect() to wrap the
>> logic so it's easier for Android gadget to use; but even that I'm a
>> little bit reluctant to do because Android should be using our
>> soft_connect interface instead of reimplementing it (wrongly) by its
>> own.
>>=20
>
> We've run in to the same issue with our usb_gadget_driver.
>
> If the usb_gadget_disconnect() API function, which seems like it is
> intended to be called by the gadget_driver, does cause the gadget to
> disconnect, it seems reasonable to expect the gadget or the UDC core
> to notify the gadget_driver via the callback.

Well, the API is supposed to disconnect D+ pullup and that's about it.

> As you mentioned this is handled in the soft_disconnect sysfs. Why
> shouldn't usb_gadget_disconnect() do the same thing, if not the gadget

because there might be cases where we don't need/want the gadget to know
about this disconnect.

> itself? Exposing the sysfs as an API function would work too. Though

it already _is_ exported. I just don't know why people are re-inventing
the same solution :-)

> both functions are "soft" disconnects and both are called
> "disconnect".
>
> In our gadget_driver we do the workaround where we notify ourself that
> we called the usb_gadget_disconnect() and that we should now be

you could just rely on the sysfs interface, right ? :-)

> disconnected. It just seems more correct that we shouldn't have to
> handle that.
>
> By the way, I'm not completely sure of the correct terminology, but
> I'm referring to the struct usb_gadget (dwc3, dwc2, etc) as the
> "gadget" and the struct usb_gadget_driver as the "gadget_driver"
> (normally this would be the composite gadget framework, but we are
> using our own driver in this case). Is there a less confusing way to
> refer to these :)

what I've been doing is that I refer to dwc3, dwc3, etc as UDC (as in
USB Device Controller) and g_mass_storage, g_ether, g_zero, etc as
gadget driver.

=2D-=20
balbi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXIvrdAAoJEIaOsuA1yqREDx8P/14Y+ikGv/R3AVP8pQR9wNPz
shuy3OkofENe0oNsNJeND2PCF8IbzWB5hvgFpMKwfH7Z7ZvezGnFEblSlosGa93P
XnV0waQ/TfiamEciY4geukf3TWx+mZsKkwLbCD6S+87PYEzZmRClGI9LqE6fXho9
RVr5KZfKRUQMT4MqftOvwq0XW2ieAeAFqZsqSrCOL5X2Oma3ZjngF7UrRTMcG+dq
RPY7DUdPUtuxPwo9G/uRukqAhFD08C+UWMyNpzHhld+bkHpbA+QCm8LylYHYRGbF
n2c0XiypUpyiNMuaSlaaampWGks1H/z8kY9LOxS0+NdBdSRQhxjRcBNqm/aisZh5
lcsLXhdgj2A0EvEM/ToURd0depSQyHlW8q8ZXnDs0RJi12GPCtOBqN+2s5n0YHRN
4yRUN3ywL9N1rB3TtxUncRu+wHb5OiLt65bUftm99QpZaJs+ABQSIe3T/9jp7FYt
7ND5mQ0HyCXJqMCx82vabzJRyZfzBFg3c6ECxD4U07feNzq4Ps63z26rb0mByCjK
5crtG6D4DJW00rkTqVzSQPEeU2Ihb/YiYpeRIxA/g6PZSkdLNejyYC7tWXAiRzKP
3tKr8KweFPGQyzu2Rv6151oSgW6ZrodzmiB7dxfrjyDBkoxYk3deDCQwfkhFJGY1
LhJqgkFk7wAtkjZ7bNSX
=T5lo
-----END PGP SIGNATURE-----
--=-=-=--