Re: Firmware class breaks udev

[Jon Smirl <jonsmirl@gmail.com>]

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? 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().

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.

BenH definitely wants to kill synchronous request_firmware() because
of suspend/resume issues.

> 
> >>- hotplug events are sent when the device registers itself with sysfs
> >>  -> devices with firmware will then not be fully initialised
> >>  -> the current hotplug subsystem does not distinguish between
> >>     states 'device detected' and 'device initialised',
> >>     so you can't model the firmware behaviour directly onto
> >>     the linux hotplug subsystem.
> >
> > Kay has a patch for that, which I will add to the tree in a few hours.
> >
> > So, with your udev patch, is there still an immediate problem that needs
> > to be fixed?
> >
> Well, in principle.
> I'd still prefer a proper solution as outlined above.
> 
> Cheers,
> 
> Hannes
> --
> Dr. Hannes Reinecke                     hare@suse.de
> SuSE Linux AG                           S390 & zSeries
> Maxfeldstraße 5                         +49 911 74053 688
> 90409 Nürnberg                          http://www.suse.de
> 
> -------------------------------------------------------
> 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&opclick
> _______________________________________________
> 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
> 


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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Ìk
_______________________________________________
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