[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170627070731.GA23083@google.com>
Date: Tue, 27 Jun 2017 00:07:33 -0700
From: Brian Norris <briannorris@...omium.org>
To: Tony Lindgren <tony@...mide.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Heiko Stuebner <heiko@...ech.de>,
Linus Walleij <linus.walleij@...aro.org>,
linux-rockchip@...ts.infradead.org,
Julia Cartwright <julia@...com>,
LKML <linux-kernel@...r.kernel.org>, linux-gpio@...r.kernel.org,
John Keeping <john@...anate.com>, linux-pm@...r.kernel.org,
Doug Anderson <dianders@...omium.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
"David.Wu" <david.wu@...k-chips.com>,
'黄涛' <huangtao@...k-chips.com>
Subject: Re: [PATCH for 4.12] Revert "pinctrl: rockchip: avoid hardirq-unsafe
functions in irq_chip"
On Mon, Jun 26, 2017 at 11:24:09PM -0700, Tony Lindgren wrote:
> Hmm so how come drivers/bluetooth/btusb.c can't use the generic
> dev_pm_set_dedicated_wake_irq()? Can you please take a look?
I took a look previously, and last time I did, there were too many bugs
for it to be useful. You may have fixed the ones I reported w.r.t.
assumptions about runtime PM.
I also recall there being some difficulty with supporting
level-triggered interrupts that way. (This signal has no device-level
mask, and it triggers for all sorts of BT activity. There may not be a
relevant "edge".)
> If there are issues remaining let's rather fix them so we can get rid
> of the custom tinkering of wake-up events in the drivers.
That's nice, but that doesn't answer my questions. Perhaps that's a side
project. The point is that we're clearly violating the documented APIs.
Brian
Powered by blists - more mailing lists