From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757732AbcEDKmd (ORCPT ); Wed, 4 May 2016 06:42:33 -0400 Received: from mga03.intel.com ([134.134.136.65]:32702 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751700AbcEDKmc (ORCPT ); Wed, 4 May 2016 06:42:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,576,1455004800"; d="asc'?scan'208";a="945946990" From: Felipe Balbi To: John Youn , John Youn , "Du\, Changbin" Cc: "gregkh\@linuxfoundation.org" , "linux-usb\@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: <5726B180.9010205@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> <87bn4tj677.fsf@intel.com> <5726B180.9010205@synopsys.com> User-Agent: Notmuch/0.21+96~g9bbc54b (http://notmuchmail.org) Emacs/25.0.90.3 (x86_64-pc-linux-gnu) Date: Wed, 04 May 2016 13:40:21 +0300 Message-ID: <87pot2ds2y.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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, John Youn writes: >> John Youn writes: >>>> "Du, Changbin" 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. >>>> >>>> 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. >>>> >>>> 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 t= he >>>> 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. >>>> >>> >>> 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. >>=20 >> Well, the API is supposed to disconnect D+ pullup and that's about it. >>=20 >>> 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 >>=20 >> because there might be cases where we don't need/want the gadget to know >> about this disconnect. >>=20 > > But what if we do? well, if the gadget is the one faking a disconnect, then it ought to cancel requests and do all the other necessary steps, right ? :-) >>> itself? Exposing the sysfs as an API function would work too. Though >>=20 >> it already _is_ exported. I just don't know why people are re-inventing >> the same solution :-) >>=20 >>> 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 >>=20 >> you could just rely on the sysfs interface, right ? :-) > > Not from the gadget driver, at least I don't think so. The gadget > driver itself is the one that wants to initiate the soft disconnect. I need to understand this requirement of yours a little better. Can you describe exactly what your gadget is doing ? Also, any chance of showing the code for that gadget ? I don't mind carrying an extra function driver if it helps you validate your IP :-) =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXKdGWAAoJEIaOsuA1yqREqbYP+gM2lLxdZlKRb7Z9o8xB8zud XebCfi+m5wezn5Us0QpDML7EE+kbtRD07bhtoEipXgf8smvpJ9jouWr1NzsSiZfg Zez3RqtuVOcxMu5lIQk68dd2u/crbUT+7sSGboUs2i08q3a+BuJ0ChK/e2C6rO5V 6tw80R+AJFASIVpSlBu8vnY3omOIqfGtrCgirzE4q4xsx/4FjXuGHPNX/d9AgY6M aGswROYbPqgznr62WWkI/vQMB55p7yHKO/Tq4HwKUNUrbamqy/dFesmZsr2n94W1 Xjc3FsRqC773STxbMCwOJhunyKByrwWw0p3at5mj7BEsto0sZ15wbkUHbDafrH9u wfeYzVpZi+fCiSoOO9xqwML0spSuZcOLgYSOqvDXWSvAhpTCDBK+PUHl9B5BdBDq qLxHpPqxXj8NsfE5ei0PK+0emLd0z0P2Lr2Y3ATm87P7wH3bTle2yeLYD7cylkK2 Km5FKeDI0mSf/d+H3hOQ4TAxi5Hyn8sXrBNsKohFrJy5iBKfDoiK5MgIuP1RhuBs uZghE6VOBaDzb1pm/a2Ab2e4WuDG7RVKgSr2l63AHKRvbwLhOyJczveVv2C/3XFu D08MpWHCAUNtY7pyFwKN5GNGxJIfsa2Ua8+RLFBTvG2xl3heKXM65n7pSsosz1B7 EKuofCUIAvtcQfXOcP+A =cBsQ -----END PGP SIGNATURE----- --=-=-=--