Re: [linux-usb-devel] Re: hotplugging to deal with firmware download

Re: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Brad Hards]

On Sun, 2 Jun 2002 02:07, Oliver Neukum wrote:
> 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?

Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

Am Sonntag, 2. Juni 2002 13:11 schrieb Brad Hards:
> On Mon, 3 Jun 2002 00:44, Oliver Neukum wrote:
> > Am Sonntag, 2. Juni 2002 01:16 schrieben Sie:
> > > On Sun, 2 Jun 2002 02:07, Oliver Neukum wrote:
> > > > 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?
>
> 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.

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

If I load the firmware in kernel I can allocate memory with GFP_NOFS.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

Am Sonntag, 2. Juni 2002 01:16 schrieben Sie:
> On Sun, 2 Jun 2002 02:07, Oliver Neukum wrote:
> > 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?
Thus as soon as you do something that allocates memory from user
space, you may deadlock IMHO.

	Regards
		Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Brad Hards]

On Mon, 3 Jun 2002 00:44, Oliver Neukum wrote:
> Am Sonntag, 2. Juni 2002 01:16 schrieben Sie:
> > On Sun, 2 Jun 2002 02:07, Oliver Neukum wrote:
> > > 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?
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.

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

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[David Brownell]

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





_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

Am Sonntag, 2. Juni 2002 19:16 schrieb David Brownell:
> >>>>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.

Hi,

getting the firmware is not the problem, but getting the firmware
to the device can deadlock if you cause writing to the device
by allocating memory for the downloading.
Any memory allocation from user space can case writing to any
filesystem with dirty pages in cache.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Brad Hards]

On Sun, 2 Jun 2002 15:50, Oliver Neukum wrote:
> Am Sonntag, 2. Juni 2002 13:11 schrieb Brad Hards:
> > On Mon, 3 Jun 2002 00:44, Oliver Neukum wrote:
> > > Am Sonntag, 2. Juni 2002 01:16 schrieben Sie:
> > > > On Sun, 2 Jun 2002 02:07, Oliver Neukum wrote:
> > > > > 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?
> >
> > 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.
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.

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

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

Exactly. But you deadlock only if the firmware download blocks on such a
write.
Ordinarily you can just wait until the firmware has been downloaded.
That this is currently not implemented is unfortunately true and warrants a 
seperate discussion.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Greg KH]

On Sat, Jun 01, 2002 at 06:07:34PM +0200, Oliver Neukum wrote:
> 
> 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.

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

Am Montag, 3. Juni 2002 19:52 schrieb Greg KH:
> On Sat, Jun 01, 2002 at 06:07:34PM +0200, Oliver Neukum wrote:
> > 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.

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.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Greg KH]

On Mon, Jun 03, 2002 at 11:00:03PM +0200, Oliver Neukum wrote:
> Am Montag, 3. Juni 2002 19:52 schrieb Greg KH:
> > On Sat, Jun 01, 2002 at 06:07:34PM +0200, Oliver Neukum wrote:
> > > 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.
> 
> 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 :)

> 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.
That's the whole driving force behind driverfs, which I think people
forget.

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[David Brownell]

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

- Dave



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

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

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

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

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Greg KH]

On Tue, Jun 04, 2002 at 12:26:31AM +0200, Oliver Neukum wrote:
> 
> > > > 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.

Heh, pessimist :)

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

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

Resumption is part of the userspace solution too.

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Greg KH]

On Mon, Jun 03, 2002 at 03:02:46PM -0700, David Brownell wrote:
> >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.

Exactly.  The drivers for devices that need firmware to be downloaded to
them, will properly disconnect and shutdown the device before the system
shuts down.  This enables them to be powered up from a clean state when
the power is resumed.

This is very different from the software suspend model that just blindly
freezes memory and hopes all hardware will work properly when power is
reapplied (not to take away from this lovely hack, but it does not work
for all types of hardware, but is quite useful for those types that it
does work on.)

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

Am Dienstag, 4. Juni 2002 00:02 schrieb David Brownell:
> > 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.

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

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

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

Yes, I admit it :-)

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

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.

> Does any other operating systems handle this any better?

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

> > > 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.
>
> Resumption is part of the userspace solution too.

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

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Greg KH]

On Tue, Jun 04, 2002 at 12:58:00AM +0200, Oliver Neukum wrote:
> > >
> > > 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?
> 
> 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.

I agree it's ugly, but it works today, right?  And if you look at other
os's, I think that's how they solve the problem too.

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

> > Does any other operating systems handle this any better?
> 
> How am I suposed to know. Do you imply that I use other
> operating systems ;-) ?

Heh, no I was just looking for other solutions :)

> > > > 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.
> >
> > Resumption is part of the userspace solution too.
> 
> Which makes me wonder whether you are designing a really
> complicated monster. Some kind of resumptionramdisk ?

I do know know that portion of the proposed solution at all, perhaps
someone who does know it will pipe up?

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

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

OK, names are radioactive hazardous issues.

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.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Greg KH]

On Tue, Jun 04, 2002 at 01:30:23AM +0200, Oliver Neukum wrote:
> 
> 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.

> You cannot avoid the issue I am afraid.

But I keep trying to :)

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

Am Dienstag, 4. Juni 2002 01:40 schrieb Greg KH:
> On Tue, Jun 04, 2002 at 01:30:23AM +0200, Oliver Neukum wrote:
> > 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.

Let's face it, most USB devices are marketing driven crap.
Most drivers will have to go for physical location.
Besides it's the lowest common denominator, thus it should
go into usbcore. Besides knowledge about physical location should not have 
to go to the drivers.

> > You cannot avoid the issue I am afraid.
>
> But I keep trying to :)

Repent, for thou art wayward.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[David Brownell]

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

For network devices this is exposed through struct ethtool_drvinfo;
there's a bus_info field.  In 2.5 most of the USB networking drivers
(it should be/become all!) use this to advantage; there's a new
API, usb_make_path(), that provides a stable physical path.

Admittedly many userspace tools ignore that, as well as the ethernet
address, in favor of nasty unstable names like "eth0".  But I know
that somewhere there's a tool that'll rename interfaces, so that those
tools which expect "eth0" style names to be stable won't need to break
too badly ... :)


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

Actually in the "typical" suspend/resume case (like powerdown overnight,
or over lunch) I think the physical path is unlikely to change.

Though there are certainly cases like suspend, carry laptop to new site,
hook up to new printer ... so it's certainly true that it's a good idea
to use the physical path in conjunction with other data (like device
vendor and product IDs) if that's all you have to work with.

- Dave





_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[David Brownell]

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

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


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

- Dave



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

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

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

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.

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

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[David Brownell]

Oliver Neukum wrote:
>>>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.


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


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

If that happens, it's a bonus.


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


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

- Dave



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

Am Mittwoch, 5. Juni 2002 16:19 schrieb David Brownell:
> Oliver Neukum wrote:
> >>>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.

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.
Do we have checks in the core for identity, or do we leave that
to the driver ? I am not sure.

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

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 ?

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

Yes, that should concern the network layer, not a device driver.
But the device driver must reset MAC and IP at least.

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

We meaning device driver maintainers ;-)

	Regards
		Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[David Brownell]

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

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

- Dave



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

Am Mittwoch, 5. Juni 2002 16:54 schrieb David Brownell:
> >>>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?

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

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

	Regards
		Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[David Brownell]

Oliver Neukum wrote:
> Am Mittwoch, 5. Juni 2002 16:54 schrieb David Brownell:
> 
>>>>>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?
>
> 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.


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

- Dave



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Andries.Brouwer]

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

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

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

Sadly I cannot test that. The ohci driver crashes on resumption
on this laptop.
But if we want this to continue we'd have to cope with the new
model. Currently we reenumerate. In that sense we don't
resume anything.
If we under the new model claim that resumption was done,
the current behaviour will not be retained IMHO.

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

UTSL ?

Storage is very much a special case.
IMHO we don't want to see this kind of code replicated.

In a way storage does not really have to retain device state.
Storage devices, aside from door locking, don't really have state.
Other types of devices, eg. video or network, do have state at the
device level.
Currently these devices will not resume correctly.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Oliver Neukum]

Well, to defend Matt, he's doing the best that can be done under the circumstances.
A device driver is asked to do things that a higher layer should do.

But this should point us to not using this code unless really necessary.
If the bus is physically detached and reattached we can do nothing.
If the issue is suspension than we can resonably assume that if a device
that looks like the device previously at that physical location is at that
location it really is the same device.
We should under no circumstances throw away that information, which
we currently do.

	Regards
		Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[David Brownell]

Andries.Brouwer@cwi.nl wrote:
>>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 point was only that when asked for an example,
I had already provided one ... :)

You're saying you don't like the model adopted by
usb-storage, which is your prerogative.  The person
to talk to about that is Matt Dharm.


> 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(!).

That does seem troublesome.  It should be one or the other,
consistently.  And "both" seems buglike.


> (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,
and I'm used to seeing that be done without regard to low-level
device naming.  For USB, there's an additional issue of being able
to assign names to the devices ... like (external) "fd0" is "fd0"
no matter which connector it's plugged in to, if it's got a serial
number providing some notion of identity.

- Dave




_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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: [linux-usb-devel] Re: hotplugging to deal with firmware download

[Andries.Brouwer]

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

Yes, but the names used by usb-storage are sda, sdb, ...
Names that are quite unrelated to the media.
If I put card 1 in reader 1, and then card 2 in reader 1,
and then card 1 in reader 2 what do you want to happen?

No, names should only follow the media when the names are related
to the media.

Andries

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
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