[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171102215501.GD28152@atomide.com>
Date: Thu, 2 Nov 2017 14:55:01 -0700
From: Tony Lindgren <tony@...mide.com>
To: Rob Herring <robh@...nel.org>
Cc: Brian Norris <briannorris@...omium.org>,
Jeffy Chen <jeffy.chen@...k-chips.com>,
linux-kernel@...r.kernel.org, bhelgaas@...gle.com,
linux-pm@...r.kernel.org, shawn.lin@...k-chips.com,
rjw@...ysocki.net, dianders@...omium.org,
devicetree@...r.kernel.org, linux-pci@...r.kernel.org,
Mark Rutland <mark.rutland@....com>
Subject: Re: [RFC PATCH v10 1/7] dt-bindings: PCI: Add definition of PCIe
WAKE# irq and PCI irq
* Rob Herring <robh@...nel.org> [171101 21:07]:
> On Fri, Oct 27, 2017 at 01:45:17PM -0700, Brian Norris wrote:
> > IMO, since you're trying to augment a standardized binding, you need to
> > be a lot clearer here. I expect you should mention the existing standard
> > (that devices may optionally include an 'interrupts' property that
> > represents the legacy PCI interrupt) and how you're augmenting it (that
> > additional interrupts can be supported optionally, but they require a
> > corresponding 'interrupt-names' property).
>
> There's an additional complication that I'd guess the wakeup is
> typically a GPIO line and hence a different parent. We have 2 options
> there. The first is interrupts-extended which is generally implicitly
> supported (i.e. we only document interrupts). The second is we already
> have interrupt-map if we have legacy interrupts and can map to different
> parents. For this to work, we'd have to use a number >4 for the wakeup
> interrupts.
The wakeup interrupt can also be a separate always on interrupt
controller in addition to GPIOs. Anyways, the interrupts-extended
binding works well for these. And the interrupt-names we seem
to have standardized on are "irq" and "wakeup".
Regards,
Tony
Powered by blists - more mailing lists