On Mon, Dec 17, 2001 at 05:55:26PM +0100, [EMAIL PROTECTED] wrote:
> > Suspend is quite different from power-cut as devices are still allowed to
> > draw up to 0.5mA from the suspended USB (see 9.2.3, USB spec.). While
> > being enough for a pm-aware microcontroler to keep its state information
>
> > Nope, it's a definition. Suspend/resume involves preserving
> > state. If they didn't keep power, they couldn't keep that state,
> > and they had to (re)initialize. Just like unplug/replug.
>
> This one I don't understand - why do you claim a buspowered device
> couldn't keep state over su
> Suspend is quite different from power-cut as devices are still allowed to
> draw up to 0.5mA from the suspended USB (see 9.2.3, USB spec.). While
> being enough for a pm-aware microcontroler to keep its state information
> (like fn-address, device-config, interface alternate setting) in the
> m
On Mon, Dec 17, 2001 at 11:19:31AM +0100, Martin Diehl wrote:
> > > Well, as explained in the other posting, suspend/resume is pretty much
> > > different from unplug/replug because a suspended device is still drawing
> > > some power from the suspended USB. This way even a buspowered device can
On Mon, 17 Dec 2001, Vojtech Pavlik wrote:
> > Well, as explained in the other posting, suspend/resume is pretty much
> > different from unplug/replug because a suspended device is still drawing
> > some power from the suspended USB. This way even a buspowered device can
> > keep its state and th
On Mon, Dec 17, 2001 at 10:38:17AM +0100, Martin Diehl wrote:
> > > Nope, it's a definition. Suspend/resume involves preserving
> > > state. If they didn't keep power, they couldn't keep that state,
> > > and they had to (re)initialize. Just like unplug/replug.
> > >
> > > If you want such de
On Sat, 15 Dec 2001, Vojtech Pavlik wrote:
> > Nope, it's a definition. Suspend/resume involves preserving
> > state. If they didn't keep power, they couldn't keep that state,
> > and they had to (re)initialize. Just like unplug/replug.
> >
> > If you want such devices to get initialized the
On Thu, 13 Dec 2001, David Brownell wrote:
> > Unfortunately they can't keep power, if the host powers down,
> > as they are buspowered. And simply call them nonresumable is an
> > excuse because you don't like the remedy which is a simple clean
> > device driver.
>
> Nope, it's a definition. S
On Thu, 13 Dec 2001 [EMAIL PROTECTED] wrote:
> > Absolutely. But note, that is not the only problem: If the driver has to
> > manage dynamic loading of different overlaid firmware images at runtime
>
> Are there devices that really do that ?
Yep. Right here in front of me ;-)
Note that the Cypr
> > What specific devices that have this problem?
>
> Any storage or communication device that is buspowered and needs
> a firmware download.
And for which bus power was removed by the suspend,
I think you meant to add. For example, ones connected
to bus-powered hubs.
> > Why are they discard
> And if your swap device is mounted over nfs through a ppp connection on
> a usb-serial device that needs firmware downloaded to it, you deserve
> any problems that this might cause :)
For a serial device you are probably right. For eg a DSL device you are
not right.
I'll join the discussion af
On Thu, 13 Dec 2001, David Brownell wrote:
> > To summarise, we can either have firmware handling in user
> > space or power management, but not both.
>
> What specific devices that have this problem?
Any storage or communication device that is buspowered and needs
a firmware download.
> They'd
On Thu, Dec 13, 2001 at 10:55:54AM +0100, [EMAIL PROTECTED] wrote:
> Hi people,
>
> it seems my explanation was too short.
>
> Firstly, let me clarify that the problem is with _reloading_ firmware
> due to resumption from power management.
I just talked with Pat Mochel about this (the person do
> To summarise, we can either have firmware handling in user
> space or power management, but not both.
What specific devices that have this problem?
They'd seem "broken". Are they important enough that
they deserve to torque the USB subsystem in this way?
Why are they discarding their firmware
On Thu, 13 Dec 2001, Martin Diehl wrote:
> On Thu, 13 Dec 2001 [EMAIL PROTECTED] wrote:
>
> > Firstly, let me clarify that the problem is with _reloading_ firmware
> > due to resumption from power management.
>
> Absolutely. But note, that is not the only problem: If the driver has to
> manage dy
On Thu, 13 Dec 2001 [EMAIL PROTECTED] wrote:
> Firstly, let me clarify that the problem is with _reloading_ firmware
> due to resumption from power management.
Absolutely. But note, that is not the only problem: If the driver has to
manage dynamic loading of different overlaid firmware images at
> > To summarise, we can either have firmware handling in user space or power
> > management, but not both.
> > More philosophically speaking, IMHO we have a classical layering violation
> > caused by wishful thinking.
> > To quote Dave: "There are many good reasons to have device handling in
> >
On Thu, Dec 13, 2001 at 10:55:54AM +0100, [EMAIL PROTECTED] wrote:
> it seems my explanation was too short.
>
> Firstly, let me clarify that the problem is with _reloading_ firmware
> due to resumption from power management.
>
> During resumption from power save, our ability to allocate memory
Hi people,
it seems my explanation was too short.
Firstly, let me clarify that the problem is with _reloading_ firmware
due to resumption from power management.
During resumption from power save, our ability to allocate memory is
severly constrained. We may allocate memory only with GFP_NOIO or
19 matches
Mail list logo
