From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Neukum Date: Wed, 05 Jun 2002 14:32:51 +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 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