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: <Pine.LNX.4.44L0.1502091441390.26711-100000@netrider.rowland.org>
Date:	Mon, 9 Feb 2015 15:00:12 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Krzysztof Opasiak <k.opasiak@...sung.com>
cc:	'Ruslan Bilovol' <ruslan.bilovol@...il.com>,
	'Peter Chen' <peter.chen@...escale.com>,
	<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

On Mon, 9 Feb 2015, Krzysztof Opasiak wrote:

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

Clearly it would be more flexible to allow the user to do the matching, 
the way configfs does (sysfs too).

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

It's not prohibited, but it also was never required.  Therefore it may 
not be implemented in all gadget drivers.

>  If some function is not working in
> such situation there is a bug in that function and it should be fixed.

That's fine.  I wasn't pointing out a fundamental limitation, just a 
fact that will have to be taken into account.

Anyway, instead of going through all this, why not do what I suggested 
earlier (see http://marc.info/?l=linux-usb&m=139888691230119&w=2) and 
create a "gadget" bus type?  That would give userspace explicit control 
over which gadget driver was bound to which UDC.

Or maybe that's not a very good fit with the existing code, since most 
gadget drivers assume they will be bound to only one UDC at a time.  So 
instead, why not create a sysfs interface that allows userspace to 
control which gadget drivers are bound to which UDCs?

As I recall, the original problem people were complaining about was
deferred probing.  They didn't need fancy matching; all they wanted was
the ability to bind a gadget driver to a UDC some time after the gadget
driver was loaded and initialized.  Something simple like Robert
Baldyga's patch is enough to do that.

Alan Stern

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ