Hi!
> > > > > > The meaning of the power states is unclear, particularly for
> > > > > > buses that don't support all the PCI states.
> > > > >
> > > > > Well, in suspend I'm currently only using 0/3, where 0 is on, and 3 is
> > > > > suspended.
> > >
> > > You should be using PM_SUSPEND_ON and PM_SUSPEND_DISK,
> > > not 0/3 ... PM_SUSPEND_MEM is used in other parts of suspend.
> > > See the attached patch, resolving a pmcore abuse of the
> > > PCI selective suspend routines ...
> >
> > You are patching against very old kernel. Take a look at -mm...
>
> Since when is "current Linus BK" getting called "very old" ?? :)
Since 2.6.9-test1-mm1 ;-)))))))))))))))))))))))))))))).
> > enum suspend_state {
> > PM_SUSPEND_ON = 0,
> > PM_SUSPEND_STANDBY = 1,
>
> With the next one being a problem, since it gets passed
> through the PCI layer as PCI D2 and interepreted globally.
> The enum values still need to be changed ...
Okay, plus I have a dirty hack there:
[EMAIL PROTECTED]:/usr/src/linux-mm/kernel/power$ grep -5 '(3)' *.c
main.c-
main.c- /* FIXME: this is suspend confusion biting us. If we pass
main.c- state, we'll pass 2 in suspend-to-RAM case; EHCI will
main.c- actually break suspend, because it interprets 2 as PCI_D2
main.c- state. Oops. */
main.c: if ((error = device_suspend(3)))
main.c- goto Finish;
main.c- return 0;
main.c- Finish:
main.c- if (pm_ops->finish)
main.c- pm_ops->finish(state);
> > > Too late for that. PCI drivers have been using it since 2.4 ... though
> > > not all of them. Just enough to make lots of trouble. :)
> >
> > Well, ok, but try not to create any new users. I believe that with
> > change above, we made all of them reasonably happy.
>
> Erm, no. Switching to enums is fine; but it's essentially just a doc
> fix. But the problems noted in the patch comments are going to
> be there until the enum VALUES get fixed ... you showed they aren't.
Okay, with that ugly hack above... it seems to more or less work.
> > > Changes the PM_SUSPEND_MEM (and PM_SUSPEND_DISK) enum values so that
> > > they make sense as PCI device power states.
> >
> > > (a) Fixes bugs whereby PCI drivers are being given bogus values.
> > > The should resolve OSDL bugid 2886 without changing the PCI
> > > API (its PM calls still act as on 2.4 kernels).
> > >
> > > (b) Doesn't change the awkward assumption in the 2.6 PMcore that
> > > the /sys/bus/*/devices/power/state, /proc/acpi/sleep,
> > > dev->power.power_state, and dev->detach_state files share
> > > the same numeric codes ... even for busses very unlike PCI,
> > > or systems with several "on" policies as well as STD and STR.
> > >
> > > Really we need to move away from "u32" codes that are easily confused
> > > with each other, towards typed values (probably struct pointers), but
> > > this is the simplest comprehensive fix for the PCI problem.
> > >
> > > Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> >
> > Please take a look at latest -mm kernel. It should have most issues
> > solved.
>
> Clearly not the "enum values" issue. You can't otherwise fix (a)
> without breaking (b), which makes for a lot of subtle bugs. I think
I do not think changing (b) should lead to any subtle bugs. It leads
to two ugly pieces in main.c (see above), but that should be it.
> Patrick had said he was going to merge the enum change (Linus
> liked the idea), but there was an armload of swsusp/pmdisk merge
> updates that were floating in Andrew's patches but which weren't
> yet merged in the bk-power.patch. I got the impression that would
> be an obstacle to merging the bk-power patchset into Linus' tree.
Basically -mm swsusp happened not to work on Linus' machine, and
that's obstacle for merging ;-).
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
