Re: Firmware class breaks udev

[Greg KH <greg@kroah.com>]

On Tue, Mar 15, 2005 at 10:20:24AM -0500, Jon Smirl wrote:
> Request_firmware should be generalized into request_initialization.
> For video cards I need to run a userspace vm86 posting program to init
> the card.

Ok, got patch?  :)

> Benh has also brought up that synchronous request_firmware() should be
> removed. All drivers would need to implement it asynchronously.
> Synchronous use has big problems coming back from suspend.

Agreed.  Anyone want to fix all the drivers that use this?

> This means that the driver probe model needs to be changed. We could
> add a new preprobe function that is only used to trigger the
> request_initialization(). After init is finished the real probe could
> be run.

That's tougher.  I'm working on allowing this kind of stuff, but we
don't need to have a preprobe function.  Basically the driver can bind
itself later, from outside the probe function.  But again, the core
locking needs to be fixed up, which is getting there...

> Another issue, a driver is loaded with a working card. Now another
> instance of the same card show up via hotplug.
> request_initialization() fail on this card for some reason. The user
> fixes the problem. Now how do I reprobe the card? I can't reload the
> driver without disrupting the first device.

Userspace can do this today with pci devices, they will be able to do
this for any device soon (see above comment about locking...)

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