All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	Ganapathi Bhat <gbhat@marvell.com>,
	Jeffy Chen <jeffy.chen@rock-chips.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Devicetree List <devicetree@vger.kernel.org>,
	Xinming Hu <huxinming820@gmail.com>,
	"<netdev@vger.kernel.org>" <netdev@vger.kernel.org>,
	linux-pm <linux-pm@vger.kernel.org>,
	"<linux-wireless@vger.kernel.org>"
	<linux-wireless@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Amitkumar Karwar <amitkarwar@gmail.com>,
	linux-rockchip@lists.infradead.org,
	Nishant Sarmukadam <nishants@marvell.com>,
	Rob Herring <robh+dt@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Lorenz
Subject: Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes
Date: Wed, 27 Feb 2019 12:57:55 -0800	[thread overview]
Message-ID: <20190227205754.GF174696@google.com> (raw)
In-Reply-To: <CAKv+Gu_fZK7dUqrrVPCejAZNWyUeMUX2ojQ=vQ3hiMkGF6e6tw@mail.gmail.com>

Hi Ard,

On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
> On Wed, 27 Feb 2019 at 11:02, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On 26/02/2019 23:28, Brian Norris wrote:
> > > You're not the first person to notice this. All the motivations are not
> > > necessarily painted clearly in their cover letter, but here are some
> > > previous attempts at solving this problem:
> > >
> > > [RFC PATCH v11 0/5] PCI: rockchip: Move PCIe WAKE# handling into pci core
> > > https://lkml.kernel.org/lkml/20171225114742.18920-1-jeffy.chen@rock-chips.com/
> > > http://lkml.kernel.org/lkml/20171226023646.17722-1-jeffy.chen@rock-chips.com/
> > >
> > > As you can see by the 12th iteration, it wasn't left unsolved for lack
> > > of trying...
> >
> > I wasn't aware of this. That's definitely a better approach than my
> > hack, and I would really like this to be revived.
> >
> 
> I don't think this approach is entirely sound either.

(I'm sure there may be problems with the above series. We probably
should give it another shot though someday, as I think it's closer to
the mark.)

> From the side of the PCI device, WAKE# is just a GPIO line, and how it
> is wired into the system is an entirely separate matter. So I don't
> think it is justified to overload the notion of legacy interrupts with
> some other pin that may behave in a way that is vaguely similar to how
> a true wake-up capable interrupt works.

I think you've conflated INTx with WAKE# just a bit (and to be fair,
that's exactly what the bad binding we're trying to replace did,
accidentally). We're not trying to claim this WAKE# signal replaces the
typical PCI interrupts, but it *is* an interrupt in some sense --
"depending on your definition of interrupt", per our IRC conversation ;)

> So I'd argue that we should add an optional 'wake-gpio' DT property
> instead to the generic PCI device binding, and leave the interrupt
> binding and discovery alone.

So I think Mark Rutland already shot that one down; it's conceptually an
interrupt from the device's perspective. We just need to figure out a
good way of representing it that doesn't stomp on the existing INTx
definitions.

Brian

WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	Ganapathi Bhat <gbhat@marvell.com>,
	Jeffy Chen <jeffy.chen@rock-chips.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Devicetree List <devicetree@vger.kernel.org>,
	Xinming Hu <huxinming820@gmail.com>,
	"<netdev@vger.kernel.org>" <netdev@vger.kernel.org>,
	linux-pm <linux-pm@vger.kernel.org>,
	"<linux-wireless@vger.kernel.org>"
	<linux-wireless@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Amitkumar Karwar <amitkarwar@gmail.com>,
	linux-rockchip@lists.infradead.org,
	Nishant Sarmukadam <nishants@marvell.com>,
	Rob Herring <robh+dt@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	"David S. Miller" <davem@davemloft.net>,
	Kalle Valo <kvalo@codeaurora.org>,
	Tony Lindgren <tony@atomide.com>,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes
Date: Wed, 27 Feb 2019 12:57:55 -0800	[thread overview]
Message-ID: <20190227205754.GF174696@google.com> (raw)
In-Reply-To: <CAKv+Gu_fZK7dUqrrVPCejAZNWyUeMUX2ojQ=vQ3hiMkGF6e6tw@mail.gmail.com>

Hi Ard,

On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
> On Wed, 27 Feb 2019 at 11:02, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On 26/02/2019 23:28, Brian Norris wrote:
> > > You're not the first person to notice this. All the motivations are not
> > > necessarily painted clearly in their cover letter, but here are some
> > > previous attempts at solving this problem:
> > >
> > > [RFC PATCH v11 0/5] PCI: rockchip: Move PCIe WAKE# handling into pci core
> > > https://lkml.kernel.org/lkml/20171225114742.18920-1-jeffy.chen@rock-chips.com/
> > > http://lkml.kernel.org/lkml/20171226023646.17722-1-jeffy.chen@rock-chips.com/
> > >
> > > As you can see by the 12th iteration, it wasn't left unsolved for lack
> > > of trying...
> >
> > I wasn't aware of this. That's definitely a better approach than my
> > hack, and I would really like this to be revived.
> >
> 
> I don't think this approach is entirely sound either.

(I'm sure there may be problems with the above series. We probably
should give it another shot though someday, as I think it's closer to
the mark.)

> From the side of the PCI device, WAKE# is just a GPIO line, and how it
> is wired into the system is an entirely separate matter. So I don't
> think it is justified to overload the notion of legacy interrupts with
> some other pin that may behave in a way that is vaguely similar to how
> a true wake-up capable interrupt works.

I think you've conflated INTx with WAKE# just a bit (and to be fair,
that's exactly what the bad binding we're trying to replace did,
accidentally). We're not trying to claim this WAKE# signal replaces the
typical PCI interrupts, but it *is* an interrupt in some sense --
"depending on your definition of interrupt", per our IRC conversation ;)

> So I'd argue that we should add an optional 'wake-gpio' DT property
> instead to the generic PCI device binding, and leave the interrupt
> binding and discovery alone.

So I think Mark Rutland already shot that one down; it's conceptually an
interrupt from the device's perspective. We just need to figure out a
good way of representing it that doesn't stomp on the existing INTx
definitions.

Brian

WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Tony Lindgren <tony@atomide.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Amitkumar Karwar <amitkarwar@gmail.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	linux-rockchip@lists.infradead.org,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Devicetree List <devicetree@vger.kernel.org>,
	linux-pm <linux-pm@vger.kernel.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Jeffy Chen <jeffy.chen@rock-chips.com>,
	Nishant Sarmukadam <nishants@marvell.com>,
	Rob Herring <robh+dt@kernel.org>,
	Kalle Valo <kvalo@codeaurora.org>,
	Ganapathi Bhat <gbhat@marvell.com>,
	Xinming Hu <huxinming820@gmail.com>,
	"<netdev@vger.kernel.org>" <netdev@vger.kernel.org>,
	"<linux-wireless@vger.kernel.org>"
	<linux-wireless@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes
Date: Wed, 27 Feb 2019 12:57:55 -0800	[thread overview]
Message-ID: <20190227205754.GF174696@google.com> (raw)
In-Reply-To: <CAKv+Gu_fZK7dUqrrVPCejAZNWyUeMUX2ojQ=vQ3hiMkGF6e6tw@mail.gmail.com>

Hi Ard,

On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
> On Wed, 27 Feb 2019 at 11:02, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On 26/02/2019 23:28, Brian Norris wrote:
> > > You're not the first person to notice this. All the motivations are not
> > > necessarily painted clearly in their cover letter, but here are some
> > > previous attempts at solving this problem:
> > >
> > > [RFC PATCH v11 0/5] PCI: rockchip: Move PCIe WAKE# handling into pci core
> > > https://lkml.kernel.org/lkml/20171225114742.18920-1-jeffy.chen@rock-chips.com/
> > > http://lkml.kernel.org/lkml/20171226023646.17722-1-jeffy.chen@rock-chips.com/
> > >
> > > As you can see by the 12th iteration, it wasn't left unsolved for lack
> > > of trying...
> >
> > I wasn't aware of this. That's definitely a better approach than my
> > hack, and I would really like this to be revived.
> >
> 
> I don't think this approach is entirely sound either.

(I'm sure there may be problems with the above series. We probably
should give it another shot though someday, as I think it's closer to
the mark.)

> From the side of the PCI device, WAKE# is just a GPIO line, and how it
> is wired into the system is an entirely separate matter. So I don't
> think it is justified to overload the notion of legacy interrupts with
> some other pin that may behave in a way that is vaguely similar to how
> a true wake-up capable interrupt works.

I think you've conflated INTx with WAKE# just a bit (and to be fair,
that's exactly what the bad binding we're trying to replace did,
accidentally). We're not trying to claim this WAKE# signal replaces the
typical PCI interrupts, but it *is* an interrupt in some sense --
"depending on your definition of interrupt", per our IRC conversation ;)

> So I'd argue that we should add an optional 'wake-gpio' DT property
> instead to the generic PCI device binding, and leave the interrupt
> binding and discovery alone.

So I think Mark Rutland already shot that one down; it's conceptually an
interrupt from the device's perspective. We just need to figure out a
good way of representing it that doesn't stomp on the existing INTx
definitions.

Brian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-02-27 20:57 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-24 14:04 [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes Marc Zyngier
2019-02-24 14:04 ` Marc Zyngier
2019-02-24 14:04 ` [PATCH 1/4] dt-bindings/marvell-8xxx: Allow wake-up interrupt to be placed in a separate node Marc Zyngier
2019-02-24 14:04   ` Marc Zyngier
2019-02-24 14:04 ` [PATCH 2/4] mwifiex: Fetch wake-up interrupt from 'wake-up' subnode when it exists Marc Zyngier
2019-02-24 14:04   ` Marc Zyngier
2019-02-24 14:04 ` [PATCH 3/4] mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late Marc Zyngier
2019-02-24 14:04   ` Marc Zyngier
2019-02-26 23:31   ` Brian Norris
2019-02-26 23:31     ` Brian Norris
2019-02-26 23:34     ` Brian Norris
2019-02-26 23:34       ` Brian Norris
2019-04-04 10:22   ` Kalle Valo
2019-04-04 10:22     ` Kalle Valo
2019-04-04 10:22   ` Kalle Valo
2019-04-04 10:22   ` Kalle Valo
2019-02-24 14:04 ` [PATCH 4/4] arm64: dts: rockchip: gru: Move wifi wake-up interrupt into its own subnode Marc Zyngier
2019-02-24 14:04   ` Marc Zyngier
2019-02-25 12:45 ` [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes Ard Biesheuvel
2019-02-25 12:45   ` Ard Biesheuvel
2019-02-25 14:52   ` Marc Zyngier
2019-02-25 14:52     ` Marc Zyngier
     [not found]     ` <5310b73b-4821-6dff-b9c0-34c59fb7fd72-5wv7dgnIgG8@public.gmane.org>
2019-02-26 16:21       ` Ard Biesheuvel
2019-02-26 16:21         ` Ard Biesheuvel
2019-02-26 16:21         ` Ard Biesheuvel
2019-02-26 17:14         ` Marc Zyngier
2019-02-26 17:14           ` Marc Zyngier
2019-02-26 23:44           ` Brian Norris
2019-02-26 23:44             ` Brian Norris
2019-02-26 23:44             ` Brian Norris
2019-02-27  9:27             ` Marc Zyngier
2019-02-27  9:27               ` Marc Zyngier
2019-02-27  9:27               ` Marc Zyngier
2019-02-26 23:28 ` Brian Norris
2019-02-26 23:28   ` Brian Norris
2019-02-27 10:02   ` Marc Zyngier
2019-02-27 10:02     ` Marc Zyngier
     [not found]     ` <d67512fe-42b4-513f-d27a-fed85c19e9c2-5wv7dgnIgG8@public.gmane.org>
2019-02-27 10:16       ` Ard Biesheuvel
2019-02-27 10:16         ` Ard Biesheuvel
2019-02-27 10:16         ` Ard Biesheuvel
2019-02-27 10:16         ` Ard Biesheuvel
2019-02-27 20:57         ` Brian Norris [this message]
2019-02-27 20:57           ` Brian Norris
2019-02-27 20:57           ` Brian Norris
2019-02-27 23:03           ` Rafael J. Wysocki
2019-02-27 23:03             ` Rafael J. Wysocki
2019-02-27 23:03             ` Rafael J. Wysocki
     [not found]             ` <CAJZ5v0gZFDdtbKQ6y52x+X8yoiPhP6BhGYZO=R_varx2nwuv5g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-02-28  2:29               ` Brian Norris
2019-02-28  2:29                 ` Brian Norris
2019-02-28  2:29                 ` Brian Norris
2019-02-28 11:03                 ` Rafael J. Wysocki
2019-02-28 11:03                   ` Rafael J. Wysocki
2019-02-28 11:03                   ` Rafael J. Wysocki
2019-02-27 20:51     ` Brian Norris
2019-02-27 20:51       ` Brian Norris
     [not found] ` <20190224140426.3267-1-marc.zyngier-5wv7dgnIgG8@public.gmane.org>
2019-03-08  8:26   ` Kalle Valo
2019-03-08  8:26     ` Kalle Valo
2019-03-08  8:26     ` Kalle Valo
2019-03-08  9:02     ` Marc Zyngier
2019-03-08  9:02       ` Marc Zyngier
2019-03-08  9:36       ` Kalle Valo
2019-03-08  9:36         ` Kalle Valo

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=20190227205754.GF174696@google.com \
    --to=briannorris@chromium.org \
    --cc=amitkarwar@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=enric.balletbo@collabora.com \
    --cc=gbhat@marvell.com \
    --cc=heiko@sntech.de \
    --cc=huxinming820@gmail.com \
    --cc=jeffy.chen@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=nishants@marvell.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@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.