> > The first three cases must be dealt with like normal hotplugging
> > just deferred to the time we wake up.
>
> That deferring may not always be possible. As an example, take a system
> in use by a friend of mine, basically a laptop with the keyboard not
> part of the main unit, but on the end of a USB lead that has to be
> disconnected to get it in its carrycase - and it has FOUR USB ports on
> the main case. As it happens, Simon uses it exclusively under Win2K, and
> that doesn't care what port the keyboard is plugged into on resume. If
> he chose to run it under Linux, would that care?
Well it depends. I don't know about keyboards, but for a mouse he'd use
/dev/input/mice and all is well. Keyboards are or could well be handled
the same way.
He'd be equally angry if moving around his keyboard in the bus topology
while his computer is awake would hurt. Thus handling that hotplug events
should do the job.
> We also need to be able to recognise previously connected device types
> even if they're on different ports when we resume. That's a direct
> consequence of the social environment that USB operates in.
We can't do this if we have more than one device of the same type.
Even for one device only there's a danger. I am afraid the kernel has to
be conservative.
> Not in the slightest - or did you miss the fact that I said "to a known
> state" and NOT "to the state it was in when we suspended". Basically,
You are right. I missed it. And you are right, that proper initialisation
is absolutely necessary.
> there has to be interaction between the resume logic and the hotplug
> logic on resume, simply because of the fact that the hardware on resume
> isn't necessarily that present on suspend.
You got it the wrong way around. If we simply didn't care it might be the
same hardware, we could just do hotplug events for all devices.
Unfortunately this has severe consequences.
> In that case, there's also no way to determine that a device found at
> the same location is the same device. If so, then resume basically
> comprises the following as far as USB is concerned, and anything short
> of this is just plain buggy:
It doesn't matter, if devices cannot be told apart in principle. Any
device of the same type on the same location in the bus will do.
The problem is just that we can't tell apart devices. Thus we cannot know
whether restoring configuration is OK, if the bus location has changed.
> 2. Scan the USB bus for devices, and
> reconnect each one as it is found.
You'll potentially scramble eg the order of eth devices and kill any task
that has mmaped a file over nfs.
> Remember, one of the basic design aims of USB was that the location a
> device is plugged in is irrelevant to the user. The Linux USB drivers
> need to be totally transparent to where a particular device is plugged
> in, otherwise they're essentially useless.
I just can't see how this is to be done.
> > In addition not only must we assure that devices are in a known
> > state and preferably as close as possible to their state before
> > suspension, but we must do so seamlessly to all tasks running before
> > suspension.
>
> That has to be the primary purpose of the USB subsystem.
Then we must discuss the requirements needed to do this.
Devices still connected must be recognised as such and told apart from new
devices and removed devices must be noticed.
The usb core must walk its table of connected devices and compare them to
reality. If there's a match it must notify the device driver of this, so
that the device driver can restore state to the device and keep the
connection to open fds.
Optionally drivers may want to do extra checks, eg whether the serial
number has remained constant or somebody removed the medium from a drive.
After this done, hotplug events can be processed.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
