On Fri, 2 Jul 2004, David Brownell wrote:
> > We also need some way to tell usb drivers that they are resuming from a
> > power-off state.
>
> True, "start to be possible". Likewise something is going
> to need to look at devices to see if they're "the same" as
> what was there before; otherwis
Alan Stern wrote:
On Fri, 2 Jul 2004, David Brownell wrote:
So I'm updating the latest suspend patch so that'll start to
be possible (especially with your hub driver changes):
- usb_suspend(udev,state) syntax ... but currently maps
poweroff to suspend (needs selective port power on/off
i
On Fri, 2 Jul 2004, David Brownell wrote:
> So I'm updating the latest suspend patch so that'll start to
> be possible (especially with your hub driver changes):
>
>- usb_suspend(udev,state) syntax ... but currently maps
> poweroff to suspend (needs selective port power on/off
> in
Alan Stern wrote:
I don't see why we can't try to provide partial support for a power-off
suspend mode. While it clearly wouldn't work for every device, it would
work for a great many.
In fact I recall arguing both sides of that myself ... :)
I think it'd be rather painful to try to make _every_
On Wed, 30 Jun 2004, David Brownell wrote:
> Alan Stern wrote:
>
> >>That's because there _is_ only one kind of "suspend"; the other
> >>is power-off!
> >
> >
> > Merely semantics. If you want to suspend your computer by storing the
> > state and turning everything off (suspend-to-disk), is t
I don't see why we can't try to provide partial support for a power-off
suspend mode. While it clearly wouldn't work for every device, it would
work for a great many.
To continue the analogy I made earlier, consider what difference there is
between power-off suspend of a device and reset of it
Alan Stern wrote:
That's because there _is_ only one kind of "suspend"; the other
is power-off!
Merely semantics. If you want to suspend your computer by storing the
state and turning everything off (suspend-to-disk), is that a suspend or a
shutdown? As far as the individual devices are concer
Oliver Neukum wrote:
The current implementation of power management is elegant and simple.
You mean in drivers/base/power, yes?
I would never doubt that. However I still believe it flawed, because IMHO
it does not implement features the power management specs of ACPI
require.
And it doesn't provid
Oliver Neukum wrote:
Doubtlessly the ACPI spec is a standard. ...
The kernel is very close to this standard. ...
Nothing I've said is incompatible with ACPI models, including
the USB portions of the ACPI 2.0 spec. It explicitly allows
"full initialization and load" as the "restore" method after D3
> Why not just accept that "some form of" doesn't involve USB suspend?
>
> Your "some form of..." adds memory to USB, but it's a curiously
> selective sort. If I unplug a disk drive and plug it into another
> port, why shouldn't that "just work"? After all, the same mechanism
> that somehow ded
Am Mittwoch, 30. Juni 2004 19:26 schrieb David Brownell:
> Not an error; it's as Alan said. If we stick to "USB suspend" as
> the only suspend state, we don't have to re-architect anything and
> try "improve on" (== diverge from) this industry standard spec.
Doubtlessly the ACPI spec is a standar
USB recognizes three different power states: power-on, suspended, and
power-off. The question is: Should it be possible to use the power-off
state as a surrogate for an extremely low-power suspend state (like
suspend-to-disk)? Unfortunately the current API doesn't allow for such
Erm, "suspend-to-
Oliver Neukum wrote:
That is not a fundamental difference. The reset logic also has a device
morphed code path.
The reset logic doesn't have a "load firmware path" though.
That's why there's a resume() among other things.
Actually, drivers do that in probe() not resume(). And as
Alan noted, there
On Wed, 30 Jun 2004, Oliver Neukum wrote:
> > But it does mean that it's effectively impossible to do a power-off
> > resume on such a device. When the power gets restored the device will
> > have "morphed" and so the hub driver will call usb_disconnect(). Perhaps
> > you believe this is acce
Am Mittwoch, 30. Juni 2004 16:58 schrieben Sie:
> On Wed, 30 Jun 2004, Oliver Neukum wrote:
>
> > Am Mittwoch, 30. Juni 2004 01:57 schrieb David Brownell:
> > > Alan Stern wrote:
> > >
> > > > Come to think of it, there really is almost no difference between an
> > > > unsolicited device reset an
> > That is not a fundamental difference. The reset logic also has a device
> > morphed code path.
>
> The reset logic doesn't have a "load firmware path" though.
That's why there's a resume() among other things.
> You really don't like the notion that losing VBUS power is
> the least bit signi
On Wed, 30 Jun 2004, David Brownell wrote:
> Alan Stern wrote:
>
> > Unfortunately the current API doesn't allow for such
> > distinctions; the suspend() method in usb_driver doesn't include an
> > argument to indicate which sort of suspend is about to occur. Oddly
>
> That's because there
Alan Stern wrote:
Unfortunately the current API doesn't allow for such
distinctions; the suspend() method in usb_driver doesn't include an
argument to indicate which sort of suspend is about to occur. Oddly
That's because there _is_ only one kind of "suspend"; the other
is power-off!
enou
On Wed, 30 Jun 2004, Oliver Neukum wrote:
> Am Mittwoch, 30. Juni 2004 01:57 schrieb David Brownell:
> > Alan Stern wrote:
> >
> > > Come to think of it, there really is almost no difference between an
> > > unsolicited device reset and a power-off suspend (except that one is
> > > quicker than t
Oliver Neukum wrote:
Am Mittwoch, 30. Juni 2004 01:57 schrieb David Brownell:
Alan Stern wrote:
Come to think of it, there really is almost no difference between an
unsolicited device reset and a power-off suspend (except that one is
quicker than the other). No difference at all as far as anythin
Am Mittwoch, 30. Juni 2004 01:57 schrieb David Brownell:
> Alan Stern wrote:
>
> > Come to think of it, there really is almost no difference between an
> > unsolicited device reset and a power-off suspend (except that one is
> > quicker than the other). No difference at all as far as anything in
Oliver Neukum wrote:
In considering the current state of affairs to be correct you are
implicitly saying that there are two classes of busses. Those that
implement full suspend() semantics and those that do not.
Well, there's hotplug busses and non-hotplug ones; hotplug always
allows disconnect (ev
Alan Stern wrote:
Come to think of it, there really is almost no difference between an
unsolicited device reset and a power-off suspend (except that one is
quicker than the other). No difference at all as far as anything in the
USB stack is concerned, it seems to me.
Actually there is a differen
Am Dienstag, 29. Juni 2004 23:10 schrieben Sie:
> On Tue, 29 Jun 2004, Oliver Neukum wrote:
>
> >
> > > This has nothing to do with considering disconnect() as anything other
> > > than a binding change. And you certainly don't want to switch to
> > > altsetting 0 immediately after the suspend
On Tue, 29 Jun 2004, Oliver Neukum wrote:
>
> > This has nothing to do with considering disconnect() as anything other
> > than a binding change. And you certainly don't want to switch to
> > altsetting 0 immediately after the suspend() callback returns, because
> > that will confuse the driv
Am Dienstag, 29. Juni 2004 19:08 schrieben Sie:
> Come to think of it, there really is almost no difference between an
> unsolicited device reset and a power-off suspend (except that one is
> quicker than the other). No difference at all as far as anything in the
> USB stack is concerned, it seems
> This has nothing to do with considering disconnect() as anything other
> than a binding change. And you certainly don't want to switch to
> altsetting 0 immediately after the suspend() callback returns, because
> that will confuse the driver in the common case where it remains bound to
> th
On Tue, 29 Jun 2004, Oliver Neukum wrote:
> > It would even be possible to detect connect changes during a power-off
> > suspend, by comparing the "before" and "after" states of the hubs. Once
> > the power has been restored for (say) 5 seconds, khubd could check whether
> > any previously-connec
On Tue, 29 Jun 2004, Oliver Neukum wrote:
> Am Montag, 28. Juni 2004 17:33 schrieb Alan Stern:
> > > Hmm, I see. Tradeoff time. I'd say take whichever causes
> > > least impact to device drivers ... didn't you originally
> > > suggest taking the device out of suspend before unbind? :)
> >
> >
> > We should seek to limit the limitations.
> > The only absolute limitation I see is not large
> > - you cannot do remote wake up
> > - you cannot detect pluggings during such suspension
> > - you cannot resume devices which have state unknown to the driver (sg etc.)
>
> I think this could be
Am Montag, 28. Juni 2004 17:33 schrieb Alan Stern:
> > Hmm, I see. Tradeoff time. I'd say take whichever causes
> > least impact to device drivers ... didn't you originally
> > suggest taking the device out of suspend before unbind? :)
>
> I don't remember suggesting that. It isn't practical i
On Mon, 28 Jun 2004, Oliver Neukum wrote:
> Yes, but why would it be impossible to restore the state the device had
> before the suspension? And equally important, why do we need to treat
> a physical reinitialisation like a logical disconnect()/probe()
> The more logical model would seem to be an
On Mon, 28 Jun 2004, David Brownell wrote:
> >>Hmm, I see. Tradeoff time. I'd say take whichever causes
> >>least impact to device drivers ... didn't you originally
> >>suggest taking the device out of suspend before unbind? :)
> >
> >
> > I don't remember suggesting that. It isn't practical
Am Montag, 28. Juni 2004 19:11 schrieb David Brownell:
> Oliver Neukum wrote:
>
> > That state of affairs is unsatisfactory. It means that the deeper suspension
> > modes lose a lot of their usefulness. Ideally the system after resumption is
> > just like at suspension (minus system clock). It see
Oliver Neukum wrote:
That state of affairs is unsatisfactory. It means that the deeper suspension
modes lose a lot of their usefulness. Ideally the system after resumption is
just like at suspension (minus system clock). It seems to me that to reach
that goal you must never call disconnect() unless
Am Montag, 28. Juni 2004 18:48 schrieb David Brownell:
> > Is powering down a bus a suspension or a disconnect?
>
> For almost all busses, including USB, it's not a suspension
> unless there's still power to preserve essential state.
> And as I said, when USB VBUS drops, that's disconnect.
> (In f
Am Montag, 28. Juni 2004 18:40 schrieb David Brownell:
> > In my opinion, the best approach is to agree that the hub driver's
> > disconnect() method is allowed to use ep0 (provided of course that
> > the hub is still plugged in). We could even go so far as to allow all
> > drivers to do that,
Oliver Neukum wrote:
The "prepare for suspend" doesn't mean "you're gonna
get a resume, buddy". It means "shut down, but keep
enough state to make restarting be fast ... in case
you get a resume() instead of disconnect()". That's
true for any hot-unpluggable device.
So can you resume() from a sl
Alan Stern wrote:
In my opinion, the best approach is to agree that the hub driver's
disconnect() method is allowed to use ep0 (provided of course that
the hub is still plugged in). We could even go so far as to allow all
drivers to do that, but the hub driver is the only one which really
_nee
Am Montag, 28. Juni 2004 17:50 schrieb Alan Stern:
> On Mon, 28 Jun 2004, Oliver Neukum wrote:
>
> > > > Then we must refuse any sleep states that want to power down the bus.
> > >
> > > No, if the bus powers off the call sequence seen by that driver
> > > will be suspend()->disconnect() rather t
On Mon, 28 Jun 2004, Oliver Neukum wrote:
> > > Then we must refuse any sleep states that want to power down the bus.
> >
> > No, if the bus powers off the call sequence seen by that driver
> > will be suspend()->disconnect() rather than suspend()->resume().
>
> This will do horrible things if t
On Sun, 27 Jun 2004, David Brownell wrote:
> Hmm, maybe usbcore (== hub driver, wearing usbcore hat!) should
> just set_configuration(hub,0) before disconnect() in at least
> this special case.
That might raise other problems...
> Thing is, the "don't talk to devices" applies _after_ disconnect(
Am Montag, 28. Juni 2004 01:11 schrieb David Brownell:
> >>No, if the bus powers off the call sequence seen by that driver
> >>will be suspend()->disconnect() rather than suspend()->resume().
> >
> >
> > This will do horrible things if the attached device has considerable state.
>
> Only if the
Then we must refuse any sleep states that want to power down the bus.
No, if the bus powers off the call sequence seen by that driver
will be suspend()->disconnect() rather than suspend()->resume().
This will do horrible things if the attached device has considerable state.
Only if the suspend()
Am Sonntag, 27. Juni 2004 21:50 schrieb David Brownell:
> Oliver Neukum wrote:
> >>>Isn't a driver that's not switching to altsetting 0 in its suspend() buggy?
> >>
> >>No. When the device resumes it will be in the same altsetting as it was
> >>when it suspended. The driver doesn't need to switc
Alan Stern wrote:
I'm not sure I see the issue. The hub disconnect() routine should
shut down all (hub-managed) children before it returns, and disconnect
all those devices from the usb device trees.
Yes it should. On the other hand, disconnect() routines aren't supposed
to talk to their device
Oliver Neukum wrote:
It's a "we're about to enter USB suspend". The "save state"
is not necessary (since the device isn't allowed to lose state!).
The "quiet down" is driver-specific. And usbcore will prevent
any further requests from getting to the device.
There seems to be major confusion on m
Oliver Neukum wrote:
Isn't a driver that's not switching to altsetting 0 in its suspend() buggy?
No. When the device resumes it will be in the same altsetting as it was
when it suspended. The driver doesn't need to switch altsettings.
Then we must refuse any sleep states that want to power down
On Sun, 27 Jun 2004, Oliver Neukum wrote:
> > Is it? It would require changes to the write method for the
> > "configuration" attribute in sysfs, and the USBDEVFS_SETCONFIGURATION
> > and USBDEVFS_DISCONNECT ioctls in usbfs. Plus continued vigilance to make
> > sure that no other backdoors ar
[..]
> You mean, don't disable the ports as well? Disabling the in-use ports
> doesn't constitute differentiating between soft and hard unplug, because
> with a hard unplug no ports will be in-use. But if you don't disable them
> for a soft disconnect then the child devices will remain on the bus
On Sat, 26 Jun 2004, Oliver Neukum wrote:
> > It's a "we're about to enter USB suspend". The "save state"
> > is not necessary (since the device isn't allowed to lose state!).
> > The "quiet down" is driver-specific. And usbcore will prevent
> > any further requests from getting to the device.
>
On Sat, 26 Jun 2004, David Brownell wrote:
> > Exactly what is needed.
>
> Except for the semantics. With suspend(), the expectation
> is that the device is NOT going away.
>
> The call before a reset should be disconnect().
No it shouldn't. Disconnect() would imply breaking things like files
On Sat, 26 Jun 2004, Oliver Neukum wrote:
> [..]
> > If the hub driver is unbound, then the system won't be able to use the
> > hub very well. In particular, connect changes won't be detected. On
> > the other hand, devices that were plugged into the hub may still be
> > electronically accessibl
On Sat, 26 Jun 2004, David Brownell wrote:
> Alan Stern wrote:
> > I've pretty much reached the end of the changes originally lined up
> > for the hub driver, but there are two areas that still need
> > attention: unbinding and error recovery. The problems and solutions
>
> And suspend/resume (w
> It's a "we're about to enter USB suspend". The "save state"
> is not necessary (since the device isn't allowed to lose state!).
> The "quiet down" is driver-specific. And usbcore will prevent
> any further requests from getting to the device.
There seems to be major confusion on my part.
Are
Oliver Neukum wrote:
Am Samstag, 26. Juni 2004 20:04 schrieb David Brownell:
Oliver Neukum wrote:
Isn't a driver that's not switching to altsetting 0 in its suspend() buggy?
Why would it want to? It's supposed to come back into the same
state that it was before the suspend, including config+altse
Am Samstag, 26. Juni 2004 20:04 schrieb David Brownell:
> Oliver Neukum wrote:
>
> > Isn't a driver that's not switching to altsetting 0 in its suspend() buggy?
>
> Why would it want to? It's supposed to come back into the same
> state that it was before the suspend, including config+altsettings
Oliver Neukum wrote:
Isn't a driver that's not switching to altsetting 0 in its suspend() buggy?
Why would it want to? It's supposed to come back into the same
state that it was before the suspend, including config+altsettings.
(In principle we could get around this. If there were an addition to
[..]
> If the hub driver is unbound, then the system won't be able to use the
> hub very well. In particular, connect changes won't be detected. On
> the other hand, devices that were plugged into the hub may still be
> electronically accessible. The cleanest way to handle this is to
> disable a
Alan Stern wrote:
I've pretty much reached the end of the changes originally lined up
for the hub driver, but there are two areas that still need
attention: unbinding and error recovery. The problems and solutions
And suspend/resume (which I think is in-hand for the moment, but
surely deserves mor
I've pretty much reached the end of the changes originally lined up
for the hub driver, but there are two areas that still need
attention: unbinding and error recovery. The problems and solutions
aren't entirely well defined and some discussion might help clarify
what needs to be done. There are
61 matches
Mail list logo
