linux-kernel - Re: [RFC PATCH v11 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180103200009.GO3875@atomide.com>
Date:   Wed, 3 Jan 2018 12:00:09 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     JeffyChen <jeffy.chen@...k-chips.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Brian Norris <briannorris@...omium.org>,
        Doug Anderson <dianders@...omium.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Linux PCI <linux-pci@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>
Subject: Re: [RFC PATCH v11 4/5] PCI / PM: Add support for the PCIe WAKE#
 signal for OF

* Rafael J. Wysocki <rafael@...nel.org> [171230 00:24]:
> On Sat, Dec 30, 2017 at 12:39 AM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> > No, you need a wakeirq properly for the child *device* and that
> > property will be consumed by the PCI layer.
> 
> Or, if you use the convention mentioned in another message in this
> thread, you can make the wakeirq be a property of a bridge (port) with
> the clarification of the assumption that WAKE# is shared by all
> functions below the bridge.  So the presence of the "wakeirq" property
> for a bridge (in addition to providing the wakeup IRQ) will mean that
> it applies to all devices below the bridge.

Yes that makes sense from device tree point of view.

> In the case of parallel PCI (not PCIe), there may be multiple "slots"
> (or "PCI devices" consisting each of multiple functions) under one
> bridge and in theory each of them may use a different IRQ for WAKE#
> signaling, so the above convention will not work then.

OK. In that case the wakeirq would have to be mapped to each
PCI device if there is no other way to describe where the slot
WAKE# line is wired to. I guess the PCI controller could go
through the child devices and map the wakeirqs that way if
needed.

Regards,

Tony