From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 22 Mar 2005 10:55:14 +0000 Subject: Re: Rework of request firmware Message-Id: <1111488915.6050.32.camel@localhost.localdomain> List-Id: References: <9e473391050319200625032789@mail.gmail.com> In-Reply-To: <9e473391050319200625032789@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Tue, 2005-03-22 at 11:27 +0300, Roman Kagan wrote: > On Mon, Mar 21, 2005 at 10:06:30PM -0500, Jon Smirl wrote: > > You could probably cancel an event. Canceling an event would remove it > > from sysfs and make sure probe() never gets called. Status would stay > > at offline. The only way to reactivate the device would be to remove > > the driver. > > This looks like defeating the whole purpose of the discussed changes. > Unloading the driver has undesired side effects, like unbinding other > devices handled by the same driver, and takeover of the device by > another matching driver. I agree. > I suspect most of the problems you are trying to solve can be worked > around by a generic interface to bind / unbind a driver to a device. If > probe() fails, the device is left unbound, just like it is now. That sounds reasonable and it leaves the kernel in a clean state. Thanks, Kay ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ 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