Firmware class breaks udev

Firmware class breaks udev

[Hannes Reinecke]

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

Re: Firmware class breaks udev

[Kay Sievers]

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

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

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.

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

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

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

Re: Firmware class breaks udev

[Hannes Reinecke]

Kay Sievers wrote:
> On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:
> 
[ .. ]
>>
>>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.

>>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.
> 
That's what i thought also. (That's why I named the variable 'timeout').

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

>>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. :)
> 
[ .. ]
> 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
-- 
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&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

Re: Firmware class breaks udev

[Kay Sievers]

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

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

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

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

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

> >>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.
> 
> >>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. :)
> > 
> [ .. ]
> > 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

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.

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



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

Re: Firmware class breaks udev

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

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.

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

Re: Firmware class breaks udev

[Hannes Reinecke]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

Kay Sievers wrote:
> On Tue, 2005-03-15 at 14:09 +0100, Hannes Reinecke wrote:
[ .. ]
>>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 :-(.

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

[-- Attachment #2: udev-053-udevd-override-timeout-events.patch --]
[-- Type: text/plain, Size: 1550 bytes --]

diff -pur udev-glibc/udevd.c udev-053/udevd.c
--- udev-glibc/udevd.c	2005-03-15 09:34:08.000000000 +0100
+++ udev-053/udevd.c	2005-03-15 09:37:13.000000000 +0100
@@ -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;
diff -pur udev-glibc/udevd.h udev-053/udevd.h
--- udev-glibc/udevd.h	2005-02-11 20:55:12.000000000 +0100
+++ udev-053/udevd.h	2005-03-15 09:34:50.000000000 +0100
@@ -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[];
 };

Re: Firmware class breaks udev

[Greg KH]

On Tue, Mar 15, 2005 at 02:09:17PM +0100, Hannes Reinecke wrote:
> Kay Sievers wrote:
> > On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:
> > 
> [ .. ]
> >>
> >>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.
> 
> >>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.
> > 
> That's what i thought also. (That's why I named the variable 'timeout').
> 
> >>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.
> 
> >>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. :)
> > 
> [ .. ]
> > 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

That can be changed, modprobe can return before the device is
initialized.  I can change the driver to do this, if you wish.

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


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

Re: Firmware class breaks udev

[Hannes Reinecke]

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

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

Re: Firmware class breaks udev

[Jon Smirl]

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

Re: Firmware class breaks udev

[Kay Sievers]

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?

> 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



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

Re: Firmware class breaks udev

[Greg KH]

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

Re: Firmware class breaks udev

[Greg KH]

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