From: Karol Kozimor <sziwan@hell.org.pl>
To: Adam Belay <ambx1@neo.rr.com>
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 07:50:45 +0100 [thread overview]
Message-ID: <20060120065045.GC30662@hell.org.pl> (raw)
In-Reply-To: <20060120063637.GC27435@neo.rr.com>
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).
> 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?
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?
Best regards,
--
Karol 'sziwan' Kozimor
sziwan@hell.org.pl
next prev parent reply other threads:[~2006-01-20 6:50 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 ` Karol Kozimor [this message]
2006-01-20 21:56 ` wake-on-lan Adam Belay
-- 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=20060120065045.GC30662@hell.org.pl \
--to=sziwan@hell.org.pl \
--cc=ambx1@neo.rr.com \
--cc=jdunn14@hotpop.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
/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.