Re: [PATCH] add USB coldplay support into udevstart

[Greg KH <greg@kroah.com>]

On Mon, Aug 08, 2005 at 12:28:40PM -0700, david-b@pacbell.net wrote:
> > Date: Mon, 8 Aug 2005 07:21:20 -0700
> > From: Greg KH <greg@kroah.com>
> >
> > On Mon, Aug 08, 2005 at 09:40:33AM -0700, david-b@pacbell.net wrote:
> > > (*) And come to think of it, I2C.  But I2C isn't going to
> > >     be hotpluggable ... there are too many devices that
> > >     can't safely be probed;
> >
> > But I'm working on providing this option.
> 
> You mean, "modalias" for I2C?

Yes.

> >	If you look, we pretty much
> > always do this today in the userspace scripts that people run to try to
> > determine what drivers to load for a specific system.
> 
> That won't work for drivers that need to be running in order for the
> kernel to boot far enough to run userspace.

Userspace starts up before _any_ device probing ever happens today.  So
this really isn't an issue.

> I have in mind power
> management chips ... things that do power switching and maybe voltage
> regulation.  Also, turnkey systems where it's unreasonable to expect
> any user to ever do such configuration.  Modular drivers aren't always
> going to be a system option, either... and requiring lots of extra
> kernel boot arguments (for I2C probe/force options) is error prone.

I don't want to change the way the code currently works at all, just
want to expose to userspace the device addresses the i2c drivers
support, so that userspace can, if they want to, load the proper drivers
without relying on trying them all, like they have to today.

> > Yes, some devices can't be probed, but they are in the minority.
> 
> Right, but that doesn't mean it's appropriate to ignore them!

I'm not going to, see above.

> Even if you can detect "Bus 2 address 3 has a chip of type X",
> probing is often unable to uncover the specific chip variant,
> which can be essential.  There needs to be some boot-time way 
> to get that information across.  It'd be nice if that didn't
> involve adding lots of board-specific code to device drivers,
> or error-prone manual configuration; for now, board-specific
> driver code seems to be the solution that works best.

Any proposals are walcome.

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel