From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Wed, 16 Mar 2005 20:25:54 +0000 Subject: Re: Firmware class breaks udev Message-Id: <1111004755.9007.134.camel@localhost.localdomain> List-Id: References: <42369BE6.7020807@suse.de> In-Reply-To: <42369BE6.7020807@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Wed, 2005-03-16 at 10:52 -0500, Jon Smirl wrote: > On Wed, 16 Mar 2005 08:27:38 +0100, Hannes Reinecke wrote: > > Greg KH wrote: > > > On Tue, Mar 15, 2005 at 02:09:17PM +0100, Hannes Reinecke wrote: > > [ .. ] > > >>The main problem is that firmware downloading does not fit in well with > > >>the established functionalities: > > >> > > >>- modprobe returns after the device is fully initialised. > > >> -> firmware has to be loaded during modprobe, ie events have to > > >> be handled during modprobe > > > > > > That can be changed, modprobe can return before the device is > > > initialized. I can change the driver to do this, if you wish. > > > > > Oh, that would be good. > > We should fix the firmware_class / any firmware-dependend device to > > return (ie finish their probing) when the firmware device has been > > registered in sysfs. > > Then we have a chance to handle the firmware event, and on succesful > > downloading the proper device will appear in sysfs. Something like > > - handling pci event > > -> modprobe > > -> generates firmware event > > -> returns > > -> event handling done > > - handling firmware event > > -> download firmware > > -> device initialisation > > -> device_register() > > -> generate class device event > > - handling class device event > > Wouldn't the cleanest way to handle this be to have a pre-probe call > to the device structure? For what other than requesting data from userspace would we need this? > In pre-probe you would trigger the > request_initialization_nowait(). Then when user space indicates that > it is done it pokes a sysfs attribute. poking the attrib then causes > the normal probe() function to be called. If pre-probe() is null then > skip all this and call probe(). If we get something like a request_user_data() that works asynchronously, and a driver that need that functionality can just call it, wouldn't it be sufficient? > I'd like to rename everthing request_initialization instead of > firmware. I'd also like to hang the firmware sysfs directory off from > each device node as it is requested instead of having a firmware > subsys. That gets rid of the name conflicts. The class_firmware should go. Definitely! But we better add something new and don't rename that thing. It will be a lot different from the current stuff, I expect. And we can move the users of the firmware_class over one by one before we decide remove it. 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