Re: Firmware class breaks udev

[Greg KH <greg@kroah.com>]

On Wed, Mar 16, 2005 at 09:25:54PM +0100, Kay Sievers wrote:
> On Wed, 2005-03-16 at 10:52 -0500, Jon Smirl wrote:
> > On Wed, 16 Mar 2005 08:27:38 +0100, Hannes Reinecke <hare@suse.de> 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 <corresponding module>
> > >      -> 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?

We have that already today.  The firmware code has an async interface,
it's just that no one uses it :)

> > 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.

I agree, there are too many drivers that are depending on the firmware
code today to easily switch them all over to an async interface.

I'm all for replacing the current firmware code, but it's way down on my
list of things to do.  If anyone else is looking for something to work
on... :)

thanks,

greg k-h


-------------------------------------------------------
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_id\x14396&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