linux-kernel - RE: Disable bus's drivers_autoprobe before rootfs has mounted

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: <fa47f0c3798b48c781bc0a8c344e6c57@BL2PR03MB226.namprd03.prod.outlook.com>
Date:	Fri, 13 Jun 2014 10:15:38 +0000
From:	Peter Chen <Peter.Chen@...escale.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Felipe Balbi <balbi@...com>, Greg KH <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: Disable bus's drivers_autoprobe before rootfs has mounted

 
> 
> > > Peter, correct me if this is wrong.  It sounds like you want to have
> > > a way for the user to control which gadget driver gets bound to
> > > which UDC driver when everything is compiled into the kernel,
> > > nothing is built as a separate module.  Is that the basic idea?
> >
> > Yes, I know it can be done by gadget-configfs, but how about the user
> > chooses other gadgets, eg: g_webcam, g_audio?
> >
> > I forget to introduce the background of this topic, I have this issue
> > when I implement gadget bus patch set.
> > (http://www.spinics.net/lists/linux-usb/msg107797.html)
> > The current behaviour for other gadgets is auto-binding, so I want to
> > keep auto-binding at my gadget bus implementation, but manual-binding
> > is also a feature we need to support for other gadgets, so I want
> > auto-binding is the default binding way, and the user can switch the
> > two binding ways, eg, module parameters or sys entry.
> >
> > But if both udc driver and gadget driver are built in, the user can't
> > let manual-binding work during the boot since the device-model will do
> > probe, and do auto-binding.
> >
> > My v1 patch set [3/4] do a tricky way to work around it, I would like
> > to know if it can be supported by device model framework?
> 
> I think we can keep everything a lot simpler.  Let's agree that the old
> non-composite gadget drivers (like g_ether, g_mass_storage, and so on)
> should only be used one at a time.  That is, there should never be more
> than one of them compiled into the kernel or loaded as a module, and they
> shouldn't be used if there is more than one unbound UDC.
> 
> If a user wants to work with more than one UDC or more than one gadget
> driver then he should use function drivers with the configfs interface
> (or functionfs or gadgetfs or whatever).
> 
> Does that seem reasonable?  It doesn't solve your problem so much as
> declare it an unsupported case, but I don't think there is any reasonable
> way to solve the problem without using something like configfs.
> 

OK, we can keep our g_xxx gadget driver just support the basic feature. But
the bug that causes gadget driver load fail due to udc is probed deferral should
be fixed, do you think so, we can't wait until configfs has total been ready.

Peter

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