From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Date: Mon, 04 Jan 2016 14:56:52 +0000 Subject: Re: [PATCH 2/4] PCI: rcar: Support runtime PM link state L1 handling in pcie-rcar Message-Id: List-Id: References: <1450358557-28376-1-git-send-email-phil.edworthy@renesas.com> <1450358557-28376-3-git-send-email-phil.edworthy@renesas.com> <20151217133058.GA20372@katana> <20151218140412.GA4595@katana> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Phil Edworthy Cc: Wolfram Sang , Simon Horman , Bjorn Helgaas , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-sh@vger.kernel.org" Hi Phil, On Mon, Jan 4, 2016 at 3:18 PM, Phil Edworthy wrote: > On 21 December 2015 13:17, Geert Uytterhoeven wrote: >> On Mon, Dec 21, 2015 at 11:52 AM, Phil Edworthy >> wrote: >> > On 18 December 2015 14:04, Wolfram Sang wrote: >> >> > Since the hardware doesn't support hot plug, I believe this loop will >> >> > always exit very quickly. Unless someone has taken a hammer to the HW >> >> > of course. >> >> >> >> I know what you mean. But since readl_poll_timeout() makes it easy, we >> >> should better be safe than sorry. >> > Hmm, I changed the code, but now it doesn't come out of suspend unless >> > sleep_us passed to readl_poll_timeout is 0. Any reason you can think of? >> >> Timers or interrupts disabled? >> >> Does the might_sleep_if() scream if CONFIG_DEBUG_ATOMIC_SLEEP=y? > Yes, it does indeed scream. Would you recommend to still use readl_poll_timeout > with sleep_us set to 0? Seems like people hit this before: use readl_poll_timeout_atomic(). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds