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

[Greg KH <greg@kroah.com>]

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