linux-kernel - Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5726B180.9010205@synopsys.com>
Date:	Sun, 1 May 2016 18:46:40 -0700
From:	John Youn <John.Youn@...opsys.com>
To:	Felipe Balbi <balbi@...nel.org>,
	John Youn <John.Youn@...opsys.com>,
	"Du, Changbin" <changbin.du@...el.com>
CC:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off
 pullup

On 4/28/2016 11:12 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> John Youn <John.Youn@...opsys.com> writes:
>>> "Du, Changbin" <changbin.du@...el.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.
>>>
>>> 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 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.
>>>
>>
>> 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.
> 

But what if we do?

>> 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 ? :-)

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.

> 
>> 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.
> 

Ok thanks, that's less confusing than calling them gadgets :)

John