From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Mon, 08 Aug 2005 19:40:19 +0000 Subject: Re: [PATCH] add USB coldplay support into udevstart Message-Id: <20050808194019.GA1084@kroah.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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 > > > > 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