Skip to contentSkip to conversation

add TIMEOUT to firmware_class hotplug event

PATCH Applied Kay Sievers 2 participants 5 messages Mar 17, 2005 – Mar 18, 2005 Driver core

lore
Share & tools
lore

Kay Sievers

author
#0 lore raw

PATCH 1/1 add TIMEOUT to firmware_class hotplug event

Quoted 3 lines · Hannes Reinecke

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

Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key.

Signed-off-by Kay Sievers <[email protected]>

===== drivers/base/firmware_class.c 1.25 vs edited =====

drivers/base/firmware_class.c +3 -0
@@ -102,6 +102,9 @@
 	if (add_hotplug_env_var(envp, num_envp, &i, buffer, buffer_size, &len,
 			"FIRMWARE=%s", fw_priv->fw_id))
 		return -ENOMEM;
+	if (add_hotplug_env_var(envp, num_envp, &i, buffer, buffer_size, &len,
+			"TIMEOUT=%i", loading_timeout))
+		return -ENOMEM;
 
 	envp[i] = NULL;
#1 lore raw
Quoted 8 lines · Kay Sievers
Quoted 3 lines · Hannes Reinecke

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

Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key.

Can't you just trigger off of the FIRMWARE variable instead?

thanks,

greg k-h

author
#2 lore raw
Quoted 11 lines · Greg KH
Quoted 8 lines · Kay Sievers
Quoted 3 lines · Hannes Reinecke

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

Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key.

Can't you just trigger off of the FIRMWARE variable instead?

Sure, that will work too. I just thought it would be nice to give userspace a hint about the event behavior the kernel expects, instead of adding an exception to the udevd event management?

Thanks,
Kay

#3 lore raw
Quoted 11 lines · Kay Sievers
Quoted 10 lines · Greg KH
Quoted 8 lines · Kay Sievers
Quoted 3 lines · Hannes Reinecke

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

Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key.

Quoted 5 lines
Quoted 1 line

Can't you just trigger off of the FIRMWARE variable instead?

Sure, that will work too. I just thought it would be nice to give userspace a hint about the event behavior the kernel expects, instead of adding an exception to the udevd event management?

Hm, so by adding the TIMEOUT value, we are telling userspace that we better act on this operation soon, right? That's a special case too :)

Anyway, sure, this is fine, I'll go add this to the driver-bk tree.

thanks,

greg k-h

Applied
#4 lore raw
In reply to Kay Sievers
Quoted 10 lines · Kay Sievers
Quoted 3 lines · Hannes Reinecke

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

Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key.

Signed-off-by Kay Sievers <[email protected]>

Applied, thanks.

greg k-h