hotplugging to deal with firmware download

The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

Quoted 12 lines

Am Sonntag, 2. Juni 2002 01:16 schrieben Sie:

Quoted 10 lines · Oliver Neukum

Quoted 2 lines

The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

How is this a problem? You simply need to bring the driver up before you remount the nfs filesystem. If you assume that your firmware is on that filesystem, then you couldn't have mounted it in the first place.

What am I missing here?

Quoted 3 lines

Paging. As soon as user space is running, dirty pages may be written out And in order to run a user space firmware loader, user space must be functional, or am I overlooking something?

The software support option requires swap to store to, right? That had better be on a local disk, or it doesn't matter whether the firmware is in userspace or not. Realistically, swap over a network block device isn't a problem worth trying to solve.

Quoted 2 lines

Thus as soon as you do something that allocates memory from user space, you may deadlock IMHO.

If you are going to get the firmware from disk (per your alternative suggestion), how is that going to help avoid the malloc?

Quoted 2 lines

The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

How is this a problem? You simply need to bring the driver up before you remount the nfs filesystem. If you assume that your firmware is on that filesystem, then you couldn't have mounted it in the first place.

What am I missing here?

Am Sonntag, 2. Juni 2002 01:16 schrieben Sie:

Quoted 8 lines · Oliver Neukum

Quoted 2 lines

The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

How is this a problem? You simply need to bring the driver up before you remount the nfs filesystem. If you assume that your firmware is on that filesystem, then you couldn't have mounted it in the first place.

Quoted 1 line

What am I missing here?

Paging. As soon as user space is running, dirty pages may be written out And in order to run a user space firmware loader, user space must be functional, or am I overlooking something?

Thus as soon as you do something that allocates memory from user space, you may deadlock IMHO.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

If the goal is to boot a diskless Linux box (who supports those?) using a USB networking device that needs firmware download before it can be used ... that'd be _exactly_ analagous to needing to boot from a disk controller that needs firmware downloaded before it will work. In both cases, if the boot ROM doesn't download it, then the system won't boot.

Am Sonntag, 2. Juni 2002 13:11 schrieb Brad Hards:

Quoted 17 lines · Oliver Neukum

Quoted 15 lines

Am Sonntag, 2. Juni 2002 01:16 schrieben Sie:

Quoted 10 lines · Oliver Neukum

Quoted 2 lines

The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

How is this a problem? You simply need to bring the driver up before you remount the nfs filesystem. If you assume that your firmware is on that filesystem, then you couldn't have mounted it in the first place.

What am I missing here?

Paging. As soon as user space is running, dirty pages may be written out And in order to run a user space firmware loader, user space must be functional, or am I overlooking something?

Quoted 4 lines

The software support option requires swap to store to, right? That had better be on a local disk, or it doesn't matter whether the firmware is in userspace or not. Realistically, swap over a network block device isn't a problem worth trying to solve.

Not only swap, but any file opened for writing may be written to if you allocate memory.

Quoted 3 lines

Not only swap, but any file opened for writing may be written to if you allocate memory.

If a file is opened for writing, it doesn't matter whether you allocate memory or not, it still may be written to. Sync, journalling, that process dirtying more pages, whatever.

So at present it would have to be something called as a hotplug script in the usual way ?
The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

Would you consider a firmware loading driver that takes firmware from disk ?

Quoted 7 lines

So at present it would have to be something called as a hotplug script in the usual way ?
The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

Would you consider a firmware loading driver that takes firmware from disk ?

No, this should be done from userspace.

Am Montag, 3. Juni 2002 19:52 schrieb Greg KH:

Quoted 6 lines · Oliver Neukum

Quoted 5 lines

So at present it would have to be something called as a hotplug script in the usual way ?
The problem is that this cannot simply work, because a filesystem may be mounted by nfs.

Quoted 4 lines

Quoted 2 lines

Would you consider a firmware loading driver that takes firmware from disk ?

No, this should be done from userspace.

Very well then, how ?
I see no plan to do it with the present power management system.

The devices are simply assumed to switch from suspended to working in kernel space. Suspended may mean off here.

I see no plan to do it with the present power management system. The devices are simply assumed to switch from suspended to working in kernel space. Suspended may mean off here.

Quoted 5 lines

Quoted 2 lines

No, this should be done from userspace.

Very well then, how ?
I see no plan to do it with the present power management system.

I agree. That's why people are still working on the power management system :)

Quoted 2 lines

The devices are simply assumed to switch from suspended to working in kernel space. Suspended may mean off here.

If "suspended" means off, then the device should start up in the powered off state, and re-enumerate as a new usb device on powerup.

If you _have_ to handle this today, then just leave the firmware within the kernel driver, like all of the usb-serial devices have done :)

If you wait a while, the rest of the power management sections of the kernel will hopefully come together, allowing the various states of shutdown to work properly, and be enumerated by _userspace_ tools.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

No, this should be done from userspace.

Very well then, how ?
I see no plan to do it with the present power management system.

I agree. That's why people are still working on the power management system :)

Well, time is not infinite. I doubt the work'll be finished soon enough.

Quoted 5 lines

Quoted 2 lines

The devices are simply assumed to switch from suspended to working in kernel space. Suspended may mean off here.

If "suspended" means off, then the device should start up in the powered off state, and re-enumerate as a new usb device on powerup.

That exactly you cannot do. The result is file system corruption, interfaces assigned wrong adresses, cameras being switched. You need to retain device<->node correspondences.

Quoted 6 lines

If you _have_ to handle this today, then just leave the firmware within the kernel driver, like all of the usb-serial devices have done :)

If you wait a while, the rest of the power management sections of the kernel will hopefully come together, allowing the various states of shutdown to work properly, and be enumerated by _userspace_ tools.

Shutdown I don't worry about, resumption is anothere matter.

Quoted 3 lines

I see no plan to do it with the present power management system. The devices are simply assumed to switch from suspended to working in kernel space. Suspended may mean off here.

Well, the usb device drivers _do_ need individual suspend()/resume() callbacks. The "new device model" stuff exists in part to ensure that devices get those calls appropriately.

For example, suspending a bus-powered hub would need to morph into disconnecting the devices it could no longer power ... and in your case, suspending a network device that discards its firmware would also need to morph into a disconnect.

Quoted 3 lines

I see no plan to do it with the present power management system. The devices are simply assumed to switch from suspended to working in kernel space. Suspended may mean off here.

Well, the usb device drivers _do_ need individual suspend()/resume() callbacks. The "new device model" stuff exists in part to ensure that devices get those calls appropriately.

For example, suspending a bus-powered hub would need to morph into disconnecting the devices it could no longer power ... and in your case, suspending a network device that discards its firmware would also need to morph into a disconnect.

Quoted 6 lines

Quoted 3 lines

I agree. That's why people are still working on the power management system :)

Well, time is not infinite. I doubt the work'll be finished soon enough.

Heh, pessimist :)

Quoted 9 lines

Quoted 5 lines

Quoted 2 lines

The devices are simply assumed to switch from suspended to working in kernel space. Suspended may mean off here.

If "suspended" means off, then the device should start up in the powered off state, and re-enumerate as a new usb device on powerup.

That exactly you cannot do. The result is file system corruption, interfaces assigned wrong adresses, cameras being switched. You need to retain device<->node correspondences.

Ok, let's state this right now then:
If you have a USB device that needs firmware downloaded to it in order to work properly, do NOT mount any filesystems on that type of device and expect software suspend to work properly. In fact, do not expect software suspend to work properly at all with these types of devices, and remove them before enabling software suspend.

Is that acceptable?

Does any other operating systems handle this any better?

Quoted 4 lines

Quoted 4 lines

If you _have_ to handle this today, then just leave the firmware within the kernel driver, like all of the usb-serial devices have done :)

Quoted 6 lines

Quoted 4 lines

If you wait a while, the rest of the power management sections of the kernel will hopefully come together, allowing the various states of shutdown to work properly, and be enumerated by _userspace_ tools.

Shutdown I don't worry about, resumption is anothere matter.

Resumption is part of the userspace solution too.

Quoted 13 lines

Quoted 4 lines

That exactly you cannot do. The result is file system corruption, interfaces assigned wrong adresses, cameras being switched. You need to retain device<->node correspondences.

Ok, let's state this right now then:
If you have a USB device that needs firmware downloaded to it in order to work properly, do NOT mount any filesystems on that type of device and expect software suspend to work properly. In fact, do not expect software suspend to work properly at all with these types of devices, and remove them before enabling software suspend.

Quoted 1 line

Is that acceptable?

Nope. I happen to have one ;-).
I can make it work, provided I keep the firmware in kernel space. It's no principal problem. It's just ugly.

And the problem is not limited to devices with firmware.
If you have two USB disks, sda must remain sda and not interchange with sdb after resumption, even if sdb would be reenumerated later than sda. To do that you need to reidentify devices after resumption, you cannot equate suspension with disconnection and resumption with reenumeration.
This applies to all drivers which work with more than one device of a kind. For disks the results are just more drastic, being two very dead filesystems.

Quoted 1 line

Does any other operating systems handle this any better?

How am I suposed to know. Do you imply that I use other operating systems ;-) ?

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

If you _have_ to handle this today, then just leave the firmware within the kernel driver, like all of the usb-serial devices have done :)

If you wait a while, the rest of the power management sections of the kernel will hopefully come together, allowing the various states of shutdown to work properly, and be enumerated by _userspace_ tools.

Quoted 3 lines

Quoted 1 line

Shutdown I don't worry about, resumption is anothere matter.

Resumption is part of the userspace solution too.

Which makes me wonder whether you are designing a really complicated monster. Some kind of resumptionramdisk ?

Quoted 10 lines

And the problem is not limited to devices with firmware.
If you have two USB disks, sda must remain sda and not interchange with sdb after resumption, even if sdb would be reenumerated later than sda. To do that you need to reidentify devices after resumption, you cannot equate suspension with disconnection and resumption with reenumeration.
This applies to all drivers which work with more than one device of a kind. For disks the results are just more drastic, being two very dead filesystems.

No, I do not want to get drug into a device naming thread right now! :) That is a independent issue of getting the device up and running. Major/minor allocations are separate from usb enumeration. The fact that today's kernel happens to tie them together tightly is not the issue either. A few very good proposals on how to split this up have been proposed on lkml recently, I'd suggest you take them up with their authors...

It was just the tip of the iceberg.
You need the ability to reidentify for simple things like setting the correct IP on the correct network adapter, or correct resolution on the correct camera.

You cannot avoid the issue I am afraid.

Quoted 4 lines

It was just the tip of the iceberg.
You need the ability to reidentify for simple things like setting the correct IP on the correct network adapter, or correct resolution on the correct camera.

I agree. Then use something unique in the device like I said in a different message: device physical path, serial number, mac address, fs label, etc.

But only use the physical path if that's your last resort, as it's the most unstable. This is the main reason the USB printer spec started specifying that all USB printers need to have a serial number. To help uniquely identify them.

Quoted 1 line

You cannot avoid the issue I am afraid.

But I keep trying to :)

Quoted 3 lines

You need the ability to reidentify for simple things like setting the correct IP on the correct network adapter, or correct resolution on the correct camera.

I agree. Then use something unique in the device like I said in a different message: device physical path, serial number, mac address, fs label, etc.

But only use the physical path if that's your last resort, as it's the most unstable. This is the main reason the USB printer spec started specifying that all USB printers need to have a serial number. To help uniquely identify them.

Quoted 7 lines

Quoted 3 lines

I see no plan to do it with the present power management system. The devices are simply assumed to switch from suspended to working in kernel space. Suspended may mean off here.

Well, the usb device drivers _do_ need individual suspend()/resume() callbacks. The "new device model" stuff exists in part to ensure that devices get those calls appropriately.

I agree. But usbcore should help as far as possible.

Quoted 4 lines

For example, suspending a bus-powered hub would need to morph into disconnecting the devices it could no longer power ... and in your case, suspending a network device that discards its firmware would also need to morph into a disconnect.

That's exactly what you must _not_ do, you need to retain the information which devices was on which port to resume correctly.

Quoted 2 lines

I agree. But usbcore should help as far as possible.

What were you thinking would transform the "device model" level suspend/resume calls into USB level ones? :)

Quoted 7 lines

Quoted 4 lines

For example, suspending a bus-powered hub would need to morph into disconnecting the devices it could no longer power ... and in your case, suspending a network device that discards its firmware would also need to morph into a disconnect.

That's exactly what you must _not_ do, you need to retain the information which devices was on which port to resume correctly.

Why would that be? In those cases, the device MUST re-enumerate from scratch, there will be no USB state to resume. In those cases the devices can't suspend; they can only disconnect/reconnect.

And it'd be pointless, since if any device driver wants to save information about devices across reconnects -- like usb-storage does today -- it has all the tools it needs to do that already. There's no need to bloat the core with such stuff.

Given that userspace tools can already be used to make network device names be pseudo-stable ("eth2" is always the one with address NN), and network drivers can even request specific names ("eth3") I don't see any reason any network device driver should want such functionality.

Quoted 4 lines

Quoted 1 line

I agree. But usbcore should help as far as possible.

What were you thinking would transform the "device model" level suspend/resume calls into USB level ones? :)

OK, but where do we handle the case where resumption is impossible because the device has been unplugged ?

Quoted 8 lines

Quoted 7 lines

Quoted 4 lines

For example, suspending a bus-powered hub would need to morph into disconnecting the devices it could no longer power ... and in your case, suspending a network device that discards its firmware would also need to morph into a disconnect.

That's exactly what you must _not_ do, you need to retain the information which devices was on which port to resume correctly.

Quoted 8 lines

Why would that be? In those cases, the device MUST re-enumerate from scratch, there will be no USB state to resume. In those cases the devices can't suspend; they can only disconnect/reconnect.

And it'd be pointless, since if any device driver wants to save information about devices across reconnects -- like usb-storage does today -- it has all the tools it needs to do that already. There's no need to bloat the core with such stuff.

That is not the entire truth.
The hub will be told to resume first. If we than scan the physical bus and initiate initialisation of the devices found, there'll be chaos once the "driverfs" layer tells devices to resume.

Quoted 4 lines

Given that userspace tools can already be used to make network device names be pseudo-stable ("eth2" is always the one with address NN), and network drivers can even request specific names ("eth3") I don't see any reason any network device driver should want such functionality.

How about keeping up connections ?

The point of suspend/resume cycles is that the system is restored to the state it had. IP, mac, filtering etc... must be restored, not only names.

In fact, if we have persistent names we don't need to care about names.

Quoted 7 lines · Oliver Neukum

Quoted 4 lines

Quoted 1 line

I agree. But usbcore should help as far as possible.

What were you thinking would transform the "device model" level suspend/resume calls into USB level ones? :)

OK, but where do we handle the case where resumption is impossible because the device has been unplugged ?

If that's not already handled, it'd be a bug in the hub driver.

Quoted 17 lines

Quoted 16 lines

Quoted 7 lines

Quoted 4 lines

For example, suspending a bus-powered hub would need to morph into disconnecting the devices it could no longer power ... and in your case, suspending a network device that discards its firmware would also need to morph into a disconnect.

That's exactly what you must _not_ do, you need to retain the information which devices was on which port to resume correctly.

Why would that be? In those cases, the device MUST re-enumerate from scratch, there will be no USB state to resume. In those cases the devices can't suspend; they can only disconnect/reconnect.

And it'd be pointless, since if any device driver wants to save information about devices across reconnects -- like usb-storage does today -- it has all the tools it needs to do that already. There's no need to bloat the core with such stuff.

Quoted 4 lines

That is not the entire truth.
The hub will be told to resume first. If we than scan the physical bus and initiate initialisation of the devices found, there'll be chaos once the "driverfs" layer tells devices to resume.

You said "initiate initialisation"; that's normally called "enumeration". Which by definition is NOT done for a USB device being resumed!!!!

Quoted 3 lines

The point of suspend/resume cycles is that the system is restored to the state it had. IP, mac, filtering etc... must be restored, not only names.

Then there's always reality to deal with. Like when a network link gets removed during suspend.

Quoted 1 line

In fact, if we have persistent names we don't need to care about names.

Erm, that doesn't make sense. Having them persistent means someone is caring a heck of a lot about names and assignment policies.

Quoted 4 lines

Quoted 2 lines

OK, but where do we handle the case where resumption is impossible because the device has been unplugged ?

If that's not already handled, it'd be a bug in the hub driver.

Well, how will we handle it with respect to the resume function ? Do we report failure if there's no longer a device at the physical location ? IMHO we do.

Now I am puzzeled. There must be some misunderstanding. Could you please outline, how we deal with a resumption if the devices lost power under the new scheme ?

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

OK, but where do we handle the case where resumption is impossible because the device has been unplugged ?

If that's not already handled, it'd be a bug in the hub driver.

Well, how will we handle it with respect to the resume function ? Do we report failure if there's no longer a device at the physical location ? IMHO we do.

Report it to what? And in what sense would it ever be an "error" to remove a device -- even during suspend?

Quoted 3 lines

Now I am puzzeled. There must be some misunderstanding. Could you please outline, how we deal with a resumption if the devices lost power under the new scheme ?

By definition, this is "(re)enumeration", not resumption.

Am Mittwoch, 5. Juni 2002 16:54 schrieb David Brownell:

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

OK, but where do we handle the case where resumption is impossible because the device has been unplugged ?

If that's not already handled, it'd be a bug in the hub driver.

Well, how will we handle it with respect to the resume function ? Do we report failure if there's no longer a device at the physical location ? IMHO we do.

Quoted 2 lines

Report it to what? And in what sense would it ever be an "error" to remove a device -- even during suspend?

The genric layer that did request the resumption must be told that this was impossible and the device should be purged.

Quoted 5 lines

Quoted 3 lines

Now I am puzzeled. There must be some misunderstanding. Could you please outline, how we deal with a resumption if the devices lost power under the new scheme ?

By definition, this is "(re)enumeration", not resumption.

But how is the state restored ?

I seem to recall pointing you at usb-storage once already, as the only USB driver today which needs to do such stuff. It has a notion of device identity, based ISTR on serial numbers, and saves that state. UTSL.

Quoted 3 lines

The genric layer that did request the resumption must be told that this was impossible and the device should be purged.

Last time I did suspend/resume of a system with USB, the hub driver _already_ handled that. Presumably it still does.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

Now I am puzzeled. There must be some misunderstanding. Could you please outline, how we deal with a resumption if the devices lost power under the new scheme ?

Quoted 3 lines

Quoted 1 line

By definition, this is "(re)enumeration", not resumption.

But how is the state restored ?

I seem to recall pointing you at usb-storage once already, as the only USB driver today which needs to do such stuff. It has a notion of device identity, based ISTR on serial numbers, and saves that state. UTSL.

Quoted 4 lines

I seem to recall pointing you at usb-storage once already, as the only USB driver today which needs to do such stuff. It has a notion of device identity, based ISTR on serial numbers, and saves that state. UTSL.

You quote this as an example of how to do things.
I am not especially happy with the results.

My experience: take a handful of compact flash card readers, plug them randomly into some hubs, take a handful of compact flash cards, plug them randomly into some readers. Now remove and repeat. I find it impossible to predict which device will get which name. Sometimes the name goes with the card, sometimes with the reader, sometimes neither of the two, sometimes both(!).

(Yes, it happens that I access the same card both via sdc and sde.) Probably things would become clear if I would read the code, but I haven't done so yet.

Andries

[Names that go with the card are really confusing. It is as if one has A:/B:, that is fd0/fd1, and the name of the floppy reader depends on the floppy inserted, so that one has to remember the history. Bad.]

Named media is one of the standard models for volume management,