Firmware class breaks udev

DISCUSSION Hannes Reinecke 4 participants 12 messages Mar 15, 2005 – Mar 17, 2005

Share & tools

Hannes Reinecke

author

2005-03-15 08:25 UTC #0 lore raw

Hi Kay,

The current implementation of the firmware class breaks a fundamental assumption in udev: that the physical device can be initialised fully prior to executing the next event for that device.

As the firmware is indeed _required_ to initialise the device we wait until the timeout is triggered and the try to execute the fimware event, which of course will fail.

If you have a look at the firmware class you'll see exactly what happens:
The class insists on sending their own firmware events during initialisation. This code is typically executed during device probing, so the modprobe for this device will still be running when the firmware event is triggered.

Which is also why you're seeing this only when using the events themselves, as when executing modprobe directly udev is only started for
the firmware event, which will succeed as no physical device event is
in the queue.

For now I'll be putting in a quick exit for firmware events (ie not wait for the devices initialisation to finish) but this is nevertheless _nasty_.

Currently the firmware class is definitely not compliant to the driver model. So either we should fix the firmware class or extend the driver model to allow for such beasts; Kay, your kobj hotplug extension might be a way to go.

Cheers,

Hannes

Signature · 15 lines

Dr. Hannes Reinecke			[email protected]
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_id396&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kay Sievers

2005-03-15 12:17 UTC #1 lore raw

Quoted 8 lines · Hannes Reinecke

The current implementation of the firmware class breaks a fundamental assumption in udev: that the physical device can be initialised fully prior to executing the next event for that device.
As the firmware is indeed _required_ to initialise the device we wait until the timeout is triggered and the try to execute the fimware event, which of course will fail.

Quoted 5 lines

If you have a look at the firmware class you'll see exactly what happens:
The class insists on sending their own firmware events during initialisation. This code is typically executed during device probing, so the modprobe for this device will still be running when the firmware event is triggered.

But as soon as modprobe finishes, which should happen in the same second, the class/firmware event should be started. How can this happen? We have usually 10 seconds to upload firmware.

Quoted 7 lines

Which is also why you're seeing this only when using the events themselves, as when executing modprobe directly udev is only started for
the firmware event, which will succeed as no physical device event is
in the queue.
For now I'll be putting in a quick exit for firmware events (ie not wait for the devices initialisation to finish) but this is nevertheless _nasty_.

The time I stumbled across a similar problem with the firmware class, I thought about adding a TIMEOUT= to the hotplug environment which udev can use to prioritize such events. But we should better replace class_firmware.

Quoted 2 lines

Currently the firmware class is definitely not compliant to the driver model.

Yes, it is a dirty ugly hack: It suppresses the kobj_add event with a hotplug filter, later switches off the hotplug filter and creates a new event by itself. I have several oopses recorded with the current firmware_class if we still access the data file while the timeout happens.

Quoted 3 lines

So either we should fix the firmware class or extend the driver model to allow for such beasts; Kay, your kobj hotplug extension might be a way to go.

I stumbled across this while trying a new way of loading userspace data into the kernel. And I wanted control over the hotplug events. The kobject/event split is a direct fallout of that. :)

I'm thinking of providing a function that adds a single file to a kobject in sysfs. That file may be named after the data it expects. We would send out a KOBJ_REQUEST_DATA hotplug event for that kobject and userspace can copy any data to that file.
If possible, the sysfs data file should use the default fs_operations, which will give us a ramfs based file and not the current vmalloc() hack and the "finished loading" attribute. And we would get the release() call if userspace closes the file, so there is no need for the loading attribute.
A good place for drivers to create such a file may be the module that requests data in the /sys/module/* directory.

That way we would get a generic way to request any data from userspace and events that belong to a specific driver or device and not some fake device in the firmware_class.

The power management guys talked about the need for a mandatory async model for firmware loading:
http://lists.osdl.org/pipermail/linux-pm/2004-November/000147.html

And I still need to understand the whole picture before I can start working on it. Any ideas?

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Hannes Reinecke

author

2005-03-15 13:09 UTC #2 lore raw

In reply to Hannes Reinecke

Quoted 2 lines · Kay Sievers

On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:

[ .. ]

Quoted 11 lines

Quoted 6 lines
If you have a look at the firmware class you'll see exactly what happens:
The class insists on sending their own firmware events during initialisation. This code is typically executed during device probing, so the modprobe for this device will still be running when the firmware event is triggered.
But as soon as modprobe finishes, which should happen in the same second, the class/firmware event should be started. How can this happen? We have usually 10 seconds to upload firmware.

This is not what happens.
modprobe will return _after_ device initialisation finished, ie after the firmware is loaded (or not, as the case might be).
The firmware event is triggered when modprobe is still running, so udev thinks the device is still initialising and waits until modprobe returns before executing that event.
As no firmware is loaded (the firmware event is still in the exec queue waiting for modprobe to return), firmware class eventually timeouts. Then modprobe returns, causing the firmware event to be executed. But by then the timeout has already been triggered and the upload will fail.

Increasing the timeout to '0' will only cause udev to wait forever.

Quoted 5 lines

Quoted 5 lines
Which is also why you're seeing this only when using the events themselves, as when executing modprobe directly udev is only started for the firmware event, which will succeed as no physical device event is in the queue.

Quoted 8 lines

Quoted 2 lines
For now I'll be putting in a quick exit for firmware events (ie not wait for the devices initialisation to finish) but this is nevertheless _nasty_.
The time I stumbled across a similar problem with the firmware class, I thought about adding a TIMEOUT= to the hotplug environment which udev can use to prioritize such events. But we should better replace class_firmware.

That's what i thought also. (That's why I named the variable 'timeout').

Quoted 9 lines

Quoted 2 lines
Currently the firmware class is definitely not compliant to the driver model.
Yes, it is a dirty ugly hack: It suppresses the kobj_add event with a hotplug filter, later switches off the hotplug filter and creates a new event by itself. I have several oopses recorded with the current firmware_class if we still access the data file while the timeout happens.

No wonder.

Quoted 8 lines

Quoted 3 lines
So either we should fix the firmware class or extend the driver model to allow for such beasts; Kay, your kobj hotplug extension might be a way to go.
I stumbled across this while trying a new way of loading userspace data into the kernel. And I wanted control over the hotplug events. The kobject/event split is a direct fallout of that. :)

[ .. ]

Quoted 4 lines

That way we would get a generic way to request any data from userspace and events that belong to a specific driver or device and not some fake device in the firmware_class.

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

Cheers,

Hannes

Signature · 15 lines

Dr. Hannes Reinecke			[email protected]
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_id396&op�k
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kay Sievers

2005-03-15 15:06 UTC #3 lore raw

In reply to Hannes Reinecke

Quoted 13 lines · Hannes Reinecke

Quoted 8 lines · Kay Sievers
Quoted 5 lines · Hannes Reinecke
If you have a look at the firmware class you'll see exactly what happens:
The class insists on sending their own firmware events during initialisation. This code is typically executed during device probing, so the modprobe for this device will still be running when the firmware event is triggered.
Quoted 4 lines
But as soon as modprobe finishes, which should happen in the same second, the class/firmware event should be started. How can this happen? We have usually 10 seconds to upload firmware.

Quoted 6 lines

This is not what happens.
modprobe will return _after_ device initialisation finished, ie after the firmware is loaded (or not, as the case might be).
The firmware event is triggered when modprobe is still running, so udev thinks the device is still initialising and waits until modprobe returns before executing that event.

Ick, I expected modprobe to return. This is what I saw the last time with the ipw2100 driver.

Quoted 6 lines

As no firmware is loaded (the firmware event is still in the exec queue waiting for modprobe to return), firmware class eventually timeouts. Then modprobe returns, causing the firmware event to be executed. But by then the timeout has already been triggered and the upload will fail.
Increasing the timeout to '0' will only cause udev to wait forever.

Cause modprobe will wait forever here? If modprobe is called from an udev process, udev will kill itself after 2 minutes. :)

Quoted 8 lines

Quoted 8 lines
Quoted 7 lines
Which is also why you're seeing this only when using the events themselves, as when executing modprobe directly udev is only started for the firmware event, which will succeed as no physical device event is in the queue.
For now I'll be putting in a quick exit for firmware events (ie not wait for the devices initialisation to finish) but this is nevertheless _nasty_.

Quoted 6 lines

Quoted 5 lines
The time I stumbled across a similar problem with the firmware class, I thought about adding a TIMEOUT= to the hotplug environment which udev can use to prioritize such events. But we should better replace class_firmware.
That's what i thought also. (That's why I named the variable 'timeout').

You have put that into the kernel hotplug env? Or udev itself?

Quoted 25 lines

Quoted 9 lines
Quoted 2 lines
Currently the firmware class is definitely not compliant to the driver model.
Yes, it is a dirty ugly hack: It suppresses the kobj_add event with a hotplug filter, later switches off the hotplug filter and creates a new event by itself. I have several oopses recorded with the current firmware_class if we still access the data file while the timeout happens.
No wonder.
Quoted 8 lines
Quoted 3 lines
So either we should fix the firmware class or extend the driver model to allow for such beasts; Kay, your kobj hotplug extension might be a way to go.
I stumbled across this while trying a new way of loading userspace data into the kernel. And I wanted control over the hotplug events. The kobject/event split is a direct fallout of that. :)
[ .. ]
Quoted 4 lines
That way we would get a generic way to request any data from userspace and events that belong to a specific driver or device and not some fake device in the firmware_class.

Quoted 6 lines

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

We may come up with a async model for that. Do you have an requirements/ideas here? I don't have the full picture here.

Quoted 6 lines

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

If we request the userspace data not to an artificial device, but instead request that into the module sysfs directory itself, that may work better?

Thanks,
Kay

Jon Smirl

2005-03-15 15:20 UTC #4 lore raw

In reply to Hannes Reinecke

Request_firmware should be generalized into request_initialization. For video cards I need to run a userspace vm86 posting program to init the card.

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.

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.

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.

Signature · 13 lines

Jon Smirl
[email protected]


-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Hannes Reinecke

author

2005-03-15 16:07 UTC #5 lore raw

In reply to Hannes Reinecke

Quoted 1 line · Kay Sievers

On Tue, 2005-03-15 at 14:09 +0100, Hannes Reinecke wrote:

[ .. ]

Quoted 10 lines

Quoted 6 lines
This is not what happens.
modprobe will return _after_ device initialisation finished, ie after the firmware is loaded (or not, as the case might be).
The firmware event is triggered when modprobe is still running, so udev thinks the device is still initialising and waits until modprobe returns before executing that event.
Ick, I expected modprobe to return. This is what I saw the last time with the ipw2100 driver.

Well, yes. After the timeout :-(.

Quoted 11 lines

Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
For now I'll be putting in a quick exit for firmware events (ie not wait for the devices initialisation to finish) but this is nevertheless _nasty_.
The time I stumbled across a similar problem with the firmware class, I thought about adding a TIMEOUT= to the hotplug environment which udev can use to prioritize such events. But we should better replace class_firmware.
That's what i thought also. (That's why I named the variable 'timeout').
You have put that into the kernel hotplug env? Or udev itself?

udev. This time I've attached the patch :-).
It might be not a bad idea to have a 'TIMEOUT' variable within the kernel, then we can set it to a proper value.

Cheers,

Hannes

Signature · 4 lines

Dr. Hannes Reinecke			[email protected]
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de

udevd.c +16 -0

diff -pur udev-glibc/udevd.c udev-053/udevd.c
@@ -113,6 +113,15 @@ static void msg_queue_insert(struct hotp
 		return;
 	}
 
+	/* Always execute messages with timeout directly */
+	if (msg->timeout > 0) {
+		info("move seq %llu with timeout %u to exec queue",
+		     msg->seqnum, msg->timeout);
+		list_add(&msg->node, &exec_list);
+		run_exec_q = 1;
+		return;
+	}
+
 	/* sort message by sequence number into list */
 	list_for_each_entry_reverse(loop_msg, &msg_list, node) {
 		if (loop_msg->seqnum < msg->seqnum)

@@ -293,6 +303,10 @@ static struct hotplug_msg *running_with_
 	if (msg->devpath == NULL)
 		return NULL;
 
+	/* Skip any events with a timeout set */
+	if (msg->timeout > 0)
+		return NULL;
+
 	list_for_each_entry(loop_msg, &running_list, node) {
 		if (loop_msg->devpath == NULL)
 			continue;

@@ -490,6 +503,9 @@ static struct hotplug_msg *get_udevsend_
 
 		if (strncmp(key, "PHYSDEVPATH=", 12) == 0)
 			msg->physdevpath = &key[12];
+
+		if (strncmp(key, "FIRMWARE=", 9) == 0)
+			msg->timeout = 10;
 	}
 	msg->envp[i++] = "UDEVD_EVENT=1";
 	msg->envp[i] = NULL;

udevd.h +1 -0

diff -pur udev-glibc/udevd.h udev-053/udevd.h
@@ -60,6 +60,7 @@ struct hotplug_msg {
 	char *subsystem;
 	unsigned long long seqnum;
 	char *physdevpath;
+	unsigned int timeout;
 	char *envp[HOTPLUG_NUM_ENVP+1];
 	char envbuf[];
 };

Greg KH

2005-03-15 16:20 UTC #6 lore raw

In reply to Hannes Reinecke

Quoted 68 lines · Hannes Reinecke

Quoted 2 lines · Kay Sievers
On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:
[ .. ]
Quoted 11 lines
Quoted 6 lines
If you have a look at the firmware class you'll see exactly what happens:
The class insists on sending their own firmware events during initialisation. This code is typically executed during device probing, so the modprobe for this device will still be running when the firmware event is triggered.
But as soon as modprobe finishes, which should happen in the same second, the class/firmware event should be started. How can this happen? We have usually 10 seconds to upload firmware.
This is not what happens.
modprobe will return _after_ device initialisation finished, ie after the firmware is loaded (or not, as the case might be).
The firmware event is triggered when modprobe is still running, so udev thinks the device is still initialising and waits until modprobe returns before executing that event.
As no firmware is loaded (the firmware event is still in the exec queue waiting for modprobe to return), firmware class eventually timeouts. Then modprobe returns, causing the firmware event to be executed. But by then the timeout has already been triggered and the upload will fail.
Increasing the timeout to '0' will only cause udev to wait forever.
Quoted 5 lines
Quoted 5 lines
Which is also why you're seeing this only when using the events themselves, as when executing modprobe directly udev is only started for the firmware event, which will succeed as no physical device event is in the queue.
Quoted 8 lines
Quoted 2 lines
For now I'll be putting in a quick exit for firmware events (ie not wait for the devices initialisation to finish) but this is nevertheless _nasty_.
The time I stumbled across a similar problem with the firmware class, I thought about adding a TIMEOUT= to the hotplug environment which udev can use to prioritize such events. But we should better replace class_firmware.
That's what i thought also. (That's why I named the variable 'timeout').
Quoted 9 lines
Quoted 2 lines
Currently the firmware class is definitely not compliant to the driver model.
Yes, it is a dirty ugly hack: It suppresses the kobj_add event with a hotplug filter, later switches off the hotplug filter and creates a new event by itself. I have several oopses recorded with the current firmware_class if we still access the data file while the timeout happens.
No wonder.
Quoted 8 lines
Quoted 3 lines
So either we should fix the firmware class or extend the driver model to allow for such beasts; Kay, your kobj hotplug extension might be a way to go.
I stumbled across this while trying a new way of loading userspace data into the kernel. And I wanted control over the hotplug events. The kobject/event split is a direct fallout of that. :)
[ .. ]
Quoted 4 lines
That way we would get a generic way to request any data from userspace and events that belong to a specific driver or device and not some fake device in the firmware_class.

Quoted 6 lines

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.

Quoted 6 lines

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

thanks,

greg k-h

Hannes Reinecke

author

2005-03-16 07:27 UTC #7 lore raw

In reply to Hannes Reinecke

Quoted 1 line · Greg KH

On Tue, Mar 15, 2005 at 02:09:17PM +0100, Hannes Reinecke wrote:

[ .. ]

Quoted 10 lines

Quoted 6 lines
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

Quoted 7 lines

Quoted 6 lines
- 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.

Quoted 5 lines

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

Signature · 15 lines

Dr. Hannes Reinecke			[email protected]
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_id396&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Jon Smirl

2005-03-16 15:52 UTC #8 lore raw

In reply to Hannes Reinecke

Quoted 23 lines · Hannes Reinecke

Quoted 1 line · Greg KH
On Tue, Mar 15, 2005 at 02:09:17PM +0100, Hannes Reinecke wrote:
[ .. ]
Quoted 10 lines
Quoted 6 lines
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

Quoted 7 lines

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

Quoted 35 lines

Quoted 8 lines
Quoted 7 lines
- 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.
Quoted 5 lines
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 [email protected]
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_id396&opclick
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Signature · 13 lines

Jon Smirl
[email protected]


-------------------------------------------------------
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Ìk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kay Sievers

2005-03-16 20:25 UTC #9 lore raw

In reply to Hannes Reinecke

Quoted 32 lines · Jon Smirl

Quoted 23 lines · Hannes Reinecke
Quoted 1 line · Greg KH
On Tue, Mar 15, 2005 at 02:09:17PM +0100, Hannes Reinecke wrote:
[ .. ]
Quoted 10 lines
Quoted 6 lines
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
Quoted 7 lines
-> event handling done
- handling firmware event
-> download firmware
-> device initialisation
     -> device_register()
        -> generate class device event
- handling class device event

Quoted 2 lines

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?

Quoted 5 lines

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?

Quoted 4 lines

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

Greg KH

2005-03-17 06:01 UTC #10 lore raw

In reply to Hannes Reinecke

Quoted 44 lines · Kay Sievers

Quoted 32 lines · Jon Smirl
Quoted 23 lines · Hannes Reinecke
Quoted 1 line · Greg KH
On Tue, Mar 15, 2005 at 02:09:17PM +0100, Hannes Reinecke wrote:
[ .. ]
Quoted 10 lines
Quoted 6 lines
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
Quoted 7 lines
-> event handling done
- handling firmware event
-> download firmware
-> device initialisation
     -> device_register()
        -> generate class device event
- handling class device event
Quoted 2 lines
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?
Quoted 5 lines
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().

Quoted 3 lines

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 :)

Quoted 9 lines

Quoted 4 lines
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

Greg KH

2005-03-17 06:03 UTC #11 lore raw

In reply to Hannes Reinecke

Quoted 3 lines · Jon Smirl

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? :)

Quoted 3 lines

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?

Quoted 4 lines

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

Quoted 5 lines

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