From: Adam Belay <ambx1@neo.rr.com>
To: Karol Kozimor <sziwan@hell.org.pl>
Cc: "Brown, Len" <len.brown@intel.com>,
Joseph Dunn <jdunn14@hotpop.com>,
linux-acpi@vger.kernel.org
Subject: Re: wake-on-lan
Date: Fri, 20 Jan 2006 16:56:36 -0500 [thread overview]
Message-ID: <20060120215636.GA13188@neo.rr.com> (raw)
In-Reply-To: <20060120065045.GC30662@hell.org.pl>
On Fri, Jan 20, 2006 at 07:50:45AM +0100, Karol Kozimor wrote:
> Thus wrote Adam Belay:
> > > Note also that there are very few explicit calls to pci_enable_wake() in
> > > the whole tree. Linux doesn't set the PME-Enable bit properly, which
> > > apparently results in WOL either working or not working. My understanding
> > > is that the final outcome depends on what BIOS does to the card during
> > > POST. Please see http://bugme.osdl.org/show_bug.cgi?id=3801 for a weird
> > > example.
> > I'm in the process of overhauling the PCI layer's power management event
> > support. Basically, I'd like to catch ACPI GPE events and then walk the
> > device tree in thier corresponding location to see if PME is set. If so
>
> Ouch. Registering a notify handler against the device's node is not enough?
> AFAIR, the spec requires devices that triggered wake-up to be notified and
> most DSDTs I've seen do it in one way or another (usually through _WAK).
Sure, there are a lot of requirements on the ACPI end. We also need to call
_DSW or _PSW (if it's available) when preparing a PCI device for wakeup.
>
> > a function like ->wake() will be called for the device driver that owns
> > the triggered device. This should allow for even runtime PME usage. I'm
> > expecting to have a patch available for the PCI end of these changes soon.
>
> What point is calling this when we're already up?
I think you're defining a scope that is too narrow for wake events.
Remember that they can be enabled during S0 (and there are many good
reasons to do so). In this case, a device is not going to turn on by
itself as ->resume will never be called. Rather, the driver will need
to evaluate the wake event and determine the proper course of action.
>
> Obviously, I haven't seen the whole picture, but from what I know we
> already have a .enable_wake callback that is ignored by both the core code
> and the drivers. Perhaps extending this callback with platform hooks to
> enable the corresponding GPE (die, /proc/acpi/wakeup, die!) and making sure
> it actually is called would suffice?
Yes, I'd like to use platform hooks. The API on the PCI end might look
like this: (in psuedo-code)
pci_arm_wakeup(struct pci_dev *dev,
struct power_state *lowest_state_we_might_enter,
struct system_state *target_system_suspend_state)
{
pci_enable_pme();
enable_platform_wakeup();
}
pci_disarm_wakeup(struct pci_dev *dev)
{
disable_platform_wakeup();
pci_disable_pme();
}
pci_enable_wake() would be deprecated.
Regards,
Adam
next prev parent reply other threads:[~2006-01-20 21:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-20 4:55 wake-on-lan Brown, Len
2006-01-20 5:16 ` wake-on-lan Karol Kozimor
2006-01-20 6:36 ` wake-on-lan Adam Belay
2006-01-20 6:50 ` wake-on-lan Karol Kozimor
2006-01-20 21:56 ` Adam Belay [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-07-15 9:27 wake-on-lan Michael J. Baars
2020-07-15 13:17 ` wake-on-lan Heiner Kallweit
2020-07-16 7:02 ` wake-on-lan Michael J. Baars
2020-07-15 13:39 ` wake-on-lan Michal Kubecek
2020-07-15 15:10 ` wake-on-lan Heiner Kallweit
2020-07-16 7:28 ` wake-on-lan Michael J. Baars
2020-07-16 16:09 ` wake-on-lan Heiner Kallweit
2020-07-17 8:36 ` wake-on-lan Michael J. Baars
2006-01-08 17:45 wake-on-lan Joseph Dunn
2006-01-20 8:24 ` wake-on-lan Satoru Takeuchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060120215636.GA13188@neo.rr.com \
--to=ambx1@neo.rr.com \
--cc=jdunn14@hotpop.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=sziwan@hell.org.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.