> > - all usb-ethernet bridges (swapping over NFS)
>
> Kaweth needs load-at-init firmware, others (now in the
> Linux kernel anyway) don't.
>
> ... so I don't see _any_ special cases there
Two things.
Firstly we should not opt for a design that precludes optionally
handling such devices.
Secondly
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
>
> > It's my understanding that while folk can do things like that with
> > 8051-based chips like EZ-USB FX/FX2, they usually do it with
> > bank switching. So that if the firmware isn't in ROM, they'd
> > need a boot loader that knows how to populate each of the
> > various banks of memory.
>
>
> > 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 Fri, 14 Dec 2001, David Brownell wrote:
> > > > manage dynamic loading of different overlaid firmware
> > > > images at runtime
> > >
> > > Are there devices that really do that ?
> >
> > Yep. Right here in front of me ;-)
>
> But are there are _products_ that do this and don't bother to
I
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
> > > manage dynamic loading of different overlaid firmware
> > > images at runtime
> >
> > Are there devices that really do that ?
>
> Yep. Right here in front of me ;-)
But are there are _products_ that do this and don't bother to
implement it as regular bank switching hardware? Last time
I
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
22 matches
Mail list logo
