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: <20140612063104.GB18009@shlinux1.ap.freescale.net>
Date:	Thu, 12 Jun 2014 14:31:05 +0800
From:	Peter Chen <peter.chen@...escale.com>
To:	Alan Stern <stern@...land.harvard.edu>, Felipe Balbi <balbi@...com>
CC:	Greg KH <gregkh@...uxfoundation.org>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: Disable bus's drivers_autoprobe before rootfs has mounted

On Wed, Jun 11, 2014 at 03:27:13PM -0400, Alan Stern wrote:
> On Wed, 11 Jun 2014, Greg KH wrote:
> 
> > We can't break existing systems, so I don't understand the issue here.
> > Just don't configure your kernel for a system you don't have / want,
> > right?
> > 
> > > > > From what I read code, we can't implement above feature, but I may
> > > > > be wrong, if you have some solutions, give me some hints please.
> > > > > If there is no solution for above feature, do we agree with exporting
> > > > > .drivers_autoprobe for bus driver or something similar?
> > > > 
> > > > I don't understand what you mean by this, care to show me with code?
> > > 
> > > I mean the individual bus driver can't change bus->p->drivers_autoprobe?
> > > bus->p->drivers_autoprobe is handled at drivers/base/bus.c.
> > > 
> > > If the individual bus driver can change bus->p->drivers_autoprobe, we
> > > can disable autoprobe (auto-binding) during booting.
> > 
> > No, that's a core only thing.
> 
> 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?

> 
> This shouldn't be a problem if you use configfs or libusbg.
> 
> Alan Stern
> 

-- 

Best Regards,
Peter Chen
--
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/