From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Mon, 03 Jun 2002 23:05:53 +0000 Subject: Re: [linux-usb-devel] Re: hotplugging to deal with firmware download Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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