From: Tony Lindgren <tony@atomide.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: JeffyChen <jeffy.chen@rock-chips.com>,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
linux-pm@vger.kernel.org, shawn.lin@rock-chips.com,
briannorris@chromium.org, dianders@chromium.org,
devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>
Subject: Re: [RFC PATCH v11 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF
Date: Wed, 27 Dec 2017 07:08:00 -0800 [thread overview]
Message-ID: <20171227150800.GF3875@atomide.com> (raw)
In-Reply-To: <5491520.JsEYlZiECc@aspire.rjw.lan>
* Rafael J. Wysocki <rjw@rjwysocki.net> [171227 01:00]:
> On Tuesday, December 26, 2017 2:06:47 AM CET JeffyChen wrote:
> > Hi Rafael,
> >
> > Thanks for your reply :)
> >
> > On 12/26/2017 08:11 AM, Rafael J. Wysocki wrote:
> > >> >+
> > >> >+ dn = pci_device_to_OF_node(ppdev);
> > >> >+ if (!dn)
> > >> >+ return 0;
> > >> >+
> > >> >+ irq = of_irq_get_byname(dn, "wakeup");
> > > Why is this a property of the bridge and not of the device itself?
> >
> > That is suggested by Brian, because in that way, the wakeup pin would
> > not "tied to what exact device is installed (or no device, if it's a slot)."
>
> But I don't think it works when there are two devices using different WAKE#
> interrupt lines under the same bridge. Or how does it work then?
It won't work currently for multiple devices but adding more than
one wakeriq per device is doable. And I think we will have other
cases where multiple wakeirqs are connected to a single device, so
that issue should be sorted out sooner or later.
And if requesting wakeirq for the PCI WAKE# lines at the PCI
controller does the job, then maybe that's all we need to start with.
Then in addition to that, we could do the following to allow
PCI devices to request the wakeirq from the PCI controller:
1. PCI controller or framework implements a chained irq for
the WAKE# lines assuming it can mask/unmask the WAKE# lines
2. PCI devices then can just request the wakeirq from the PCI
controller
And that's about it. Optionally we could leave out the dependency
to having PCI devices implement PM runtime and just resume the
parent (PCI controller) if PCI devices has not implemented
PM runtime.
> > >> >+ if (irq == -EPROBE_DEFER)
> > > Braces here, please.
> > ok, will fix in the next version.
> >
> > >
> > >> >+ return irq;
> > >> >+ /* Ignore other errors, since a missing wakeup is non-fatal. */
> > >> >+ else if (irq < 0) {
> > >> >+ dev_info(&pdev->dev, "cannot get wakeup interrupt: %d\n", irq);
> > >> >+ return 0;
> > >> >+ }
> > >> >+
> > >> >+ device_init_wakeup(&pdev->dev, true);
> > > Why do you call this before dev_pm_set_dedicated_wake_irq()?
> >
> > hmmm, i thought so too, but it turns out the dedicated wake irq
> > framework requires device_init_wakeup(dev, true) before attach the wake irq:
> >
> > int device_wakeup_attach_irq(struct device *dev,
> > struct wake_irq *wakeirq)
> > {
> > struct wakeup_source *ws;
> >
> > ws = dev->power.wakeup;
> > if (!ws) {
> > dev_err(dev, "forgot to call device_init_wakeup?\n");
> > return -EINVAL;
> >
>
> Well, that's a framework issue, fair enough.
>
> That said, what if user space removes the wakeup source from under you
> concurrently via sysfs? Tony?
Hmm sounds racy, need to take a look. I think the only reason
to have the wakeirq pointer there was to save memory. It might
make sense to remove the wakeirq dependency here.
Regards,
Tony
next prev parent reply other threads:[~2017-12-27 15:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-25 11:47 [RFC PATCH v11 0/5] PCI: rockchip: Move PCIe WAKE# handling into pci core Jeffy Chen
2017-12-25 11:47 ` [RFC PATCH v11 1/5] dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq Jeffy Chen
2017-12-25 11:47 ` [RFC PATCH v11 2/5] of/irq: Adjust of_pci_irq parsing for multiple interrupts Jeffy Chen
2017-12-25 11:47 ` [RFC PATCH v11 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF Jeffy Chen
[not found] ` <20171225114742.18920-5-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2017-12-26 0:11 ` Rafael J. Wysocki
2017-12-26 1:06 ` JeffyChen
2017-12-27 0:57 ` Rafael J. Wysocki
2017-12-27 15:08 ` Tony Lindgren [this message]
2017-12-28 0:48 ` Rafael J. Wysocki
[not found] ` <CAJZ5v0iaHPGiZJURhqZb8wdJXHxrAEHVN=U6rNHWGf-FGemPJA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-28 4:22 ` Tony Lindgren
[not found] ` <20171228042205.GG3875-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2017-12-28 12:18 ` Rafael J. Wysocki
[not found] ` <CAJZ5v0hpK0_vjX3HinCpsFuKffVUn3d5EnqXdz0P893aRZgnRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-28 16:51 ` Tony Lindgren
2017-12-28 17:29 ` Rafael J. Wysocki
2017-12-28 17:43 ` Rafael J. Wysocki
[not found] ` <CAJZ5v0hSMqwitCvfi7D+sknuO0YFr5F-kdkV-cSoVp30Cmdaeg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-29 17:16 ` Tony Lindgren
2017-12-29 17:15 ` Tony Lindgren
2017-12-29 23:39 ` Rafael J. Wysocki
[not found] ` <CAJZ5v0icePurJoGdVtX06j=XHPdZSqXgm+vhL47ngv7OZoL3fw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-30 0:21 ` Rafael J. Wysocki
2018-01-03 20:00 ` Tony Lindgren
[not found] ` <6120485.xubBpvge6h-yvgW3jdyMHm1GS7QM15AGw@public.gmane.org>
2018-01-03 20:08 ` Tony Lindgren
2018-01-05 0:11 ` Rafael J. Wysocki
2018-01-05 0:41 ` Brian Norris
[not found] ` <20180105004130.GA151625-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2018-01-05 1:13 ` Rafael J. Wysocki
2018-01-25 1:22 ` Brian Norris
2018-01-25 16:40 ` Tony Lindgren
2018-01-25 16:54 ` Rafael J. Wysocki
[not found] ` <CAJZ5v0h7JvEFTV1mbqxtK8P0aoums2Cvjy3uU1gK4E26_rtZ5g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-25 17:47 ` Brian Norris
2017-12-25 11:47 ` [RFC PATCH v11 5/5] arm64: dts: rockchip: Move PCIe WAKE# irq to pcie port for Gru 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=20171227150800.GF3875@atomide.com \
--to=tony@atomide.com \
--cc=bhelgaas@google.com \
--cc=briannorris@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=frowand.list@gmail.com \
--cc=jeffy.chen@rock-chips.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=shawn.lin@rock-chips.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).