From mboxrd@z Thu Jan 1 00:00:00 1970 From: jeffy Subject: Re: [RESEND PATCH 1/2] spi: rockchip: Convert to late and early system PM callbacks Date: Sat, 14 Oct 2017 02:19:28 +0800 Message-ID: <59E103B0.8060705@rock-chips.com> References: <20171013104138.3216-1-jeffy.chen@rock-chips.com> <20171013104138.3216-2-jeffy.chen@rock-chips.com> <20171013155120.GA137489@google.com> <20171013164235.thgqha7sl5tdptwv@sirena.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Anderson , "linux-kernel@vger.kernel.org" , Heiko Stuebner , linux-spi , "open list:ARM/Rockchip SoC..." , "linux-arm-kernel@lists.infradead.org" , Dmitry Torokhov To: Mark Brown , Brian Norris Return-path: In-Reply-To: <20171013164235.thgqha7sl5tdptwv@sirena.co.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-spi.vger.kernel.org Hi guys, it looks like the suspend sequence depends on the dt node sequence, and we are putting display-subsystem dt node above spi dt node, so it would be earlier in the device list, then got suspended later than spi device. the pwm backlight and cros_ec_spi pwm are very interesting, not only about suspend dependency... if we unbind cros_ec_spi pwm, the pwm backlight would still hold a reference to it, and crash the kernel later. On 10/14/2017 12:42 AM, Mark Brown wrote: > On Fri, Oct 13, 2017 at 08:51:21AM -0700, Brian Norris wrote: > >> Yes, this does seem odd to me too. This looks like an arms race hack >> that should be avoided unless we know a legit root cause. Also, >> "probe order implies suspend order" doesn't quite work for async suspend >> anyway, so we'd probably want to express the dependency properly >> anyway. > > Yeah, it's the same stuff as we get with initcall ordering. This sort > of thing does happen with things like PMICs which tend to have hardware > that the system wants to manipulate in the IRQs off part of suspend. > Ideally the dependency annotation stuff would figure things out though > I'm not sure what the status of that is. > >> Any chance this is related? Seems like that might break the parent/child >> relationship for master/slave: > >> commit d7e2ee257038baeb03baef602500368a51ee9eef >> Author: Linus Walleij >> Date: Mon Apr 11 13:51:03 2016 +0200 > >> spi: let SPI masters ignore their children for PM > > That's for runtime PM, I'd not expect it to affect system suspend. >