From: Brian Norris <briannorris@chromium.org>
To: jeffy <jeffy.chen@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
Tony Lindgren <tony@atomide.com>,
linux-pci@vger.kernel.org, shawn.lin@rock-chips.com,
linux-kernel@vger.kernel.org, dianders@chromium.org,
linux-rockchip@lists.infradead.org, bhelgaas@google.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq
Date: Tue, 22 Aug 2017 18:57:15 -0700 [thread overview]
Message-ID: <20170823015714.GA129497@google.com> (raw)
In-Reply-To: <599CDB37.3070307@rock-chips.com>
Hi Jeffy,
On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote:
> and for eage irq, maybe we should enable it right after(or before)
> the driver activate wake function(for example activate WOWLAN or
> WOLAN), otherwise would it be possible to miss some irqs(triggered
> before we actually enable the wake irq)?
I already mentioned this: for the PCI case, the specification explicitly
says that the WAKE# pin must remain asserted until the system wakes and
resets the link. So we don't have this problem.
But it is probably still useful to make sure there's a well-defined
point at which these interrupts are armed, so that if a device driver
does care, it can account for that. Just before suspend_noirq (as it is
today) is probably fine, so if there's some device-level handling that
needs to happen before we get to suspend (but after the wakeirq is
armed), it can go in the device or bus {suspend,resume}_noirq callbacks.
Brian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2017-08-23 1:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-17 12:04 [RFC PATCH v2 0/3] PCI: rockchip: Move PCIE_WAKE handling into rockchip pcie driver Jeffy Chen
2017-08-17 12:04 ` [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq Jeffy Chen
2017-08-18 7:23 ` Shawn Lin
2017-08-18 8:32 ` jeffy
2017-08-18 17:01 ` Brian Norris
2017-08-18 17:07 ` Brian Norris
2017-08-18 17:47 ` jeffy
2017-08-18 18:28 ` Tony Lindgren
2017-08-18 18:14 ` Tony Lindgren
2017-08-18 20:05 ` jeffy
2017-08-22 17:26 ` Tony Lindgren
2017-08-23 1:32 ` jeffy
2017-08-23 1:57 ` Brian Norris [this message]
2017-08-23 2:16 ` jeffy
2017-12-19 0:48 ` Brian Norris
2017-12-20 19:19 ` Tony Lindgren
2017-12-22 23:20 ` Brian Norris
2017-12-23 16:36 ` Tony Lindgren
2017-08-17 12:04 ` [RFC PATCH v2 2/3] dt-bindings: " Jeffy Chen
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=20170823015714.GA129497@google.com \
--to=briannorris@chromium.org \
--cc=bhelgaas@google.com \
--cc=dianders@chromium.org \
--cc=heiko@sntech.de \
--cc=jeffy.chen@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=shawn.lin@rock-chips.com \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).