linux-kernel - RE: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

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]

Date:	Mon, 09 Feb 2015 19:06:02 +0100
From:	Krzysztof Opasiak <k.opasiak@...sung.com>
To:	'Alan Stern' <stern@...land.harvard.edu>,
	'Ruslan Bilovol' <ruslan.bilovol@...il.com>,
	'Peter Chen' <peter.chen@...escale.com>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	"'Balbi, Felipe'" <balbi@...com>, gregkh@...uxfoundation.org,
	Andrzej Pietrasiewicz <andrzej.p@...sung.com>
Subject: RE: [PATCH 1/2] usb: gadget: udc-core: independent registration of
 gadgets and gadget drivers

Hi,

(... snip ...)

> 
> > > You don't need all this stuff.  What's the point of keeping
> track of
> > > names?  If there are any unbound gadget drivers pending, a
> newly
> > > registered UDC should bind to the first one available.
> >
> > It's because gadget driver may be bound to usb_gadget in two
> ways:
> >  - standard way - in this case any available udc will be picked
> up
> >  - by name of udc, in this case only matching udc will be picked
> up
> 
> Where did this "by name" feature come from?  You did not mention it
> in
> the patch description.
> 
> Why bother matching by name?  Why not simply take the first
> available
> UDC?

Because you may have more than one udc. This would allow to pick one by
name just like using configfs interface.

> 
> > Main feature of my path is not only deferred binding of gadget
> driver,
> > but also possibility to register/unregister udc at any time.
> > This is useful for user who can load, for example, udc module
> > if needed and unload it safely, not touching gadget driver.
> 
> We can already do that with the existing code.  There's no need for
> a
> patch.
> 
> Also, it's not clear that the existing gadget drivers will work
> properly if they are unbound from one UDC and then bound again to
> another one.  They were not written with that sort of thing in
> mind.
> 

What you have described is one of basics configfs features.
You should be able to bind and unbind your gadget whenever you want
and it should work properly after doing:

## create gadget
$ echo "udc.0" > UDC
$ echo "" > UDC
$ echo "udc.1" > UDC

Function shouldn't care which udc it has been bound previously.
Only current one is important and on each unbind each function
should cleanup its state and prepare to be bound to another udc.
Configfs interface doesn't prohibit this and I haven't seen any
info about such restriction. If some function is not working in
such situation there is a bug in that function and it should be fixed.

I have tried to test this on my odroid with dwc2 and dummy_hcd.
Most of functions seems to be working but for example ecm isn't.
After some digging with Robert we found that it's always reusing
endpoints received in first bind(). Once again in my opinion it's
a bug which should be fixed and not treated as general assumption.

-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
k.opasiak@...sung.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/