[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=X6pkaY3t=ceh3QEUws+_gqRGMN9zveW0fXR1noF1T6ew@mail.gmail.com>
Date: Fri, 13 Oct 2017 08:32:12 -0700
From: Doug Anderson <dianders@...omium.org>
To: Jeffy Chen <jeffy.chen@...k-chips.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Brian Norris <briannorris@...omium.org>,
Mark Brown <broonie@...nel.org>,
Heiko Stuebner <heiko@...ech.de>,
linux-spi <linux-spi@...r.kernel.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RESEND PATCH 1/2] spi: rockchip: Convert to late and early
system PM callbacks
Hi,
On Fri, Oct 13, 2017 at 3:41 AM, Jeffy Chen <jeffy.chen@...k-chips.com> wrote:
> Currently we are suspending the spi master in it's ->suspend callback,
> which is racy as some other drivers may still want to transmit messages
> on the bus(e.g. spi based pwm backlight).
>
> Convert to late and early system PM callbacks to avoid the race.
>
> Signed-off-by: Jeffy Chen <jeffy.chen@...k-chips.com>
> ---
>
> drivers/spi/spi-rockchip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
It shouldn't hurt to do this, but I'm curious if you did any digging
about why this happens? As I understood it suspend order is supposed
to be opposite of probe order. Thus anything that was able to get a
reference to the cros-ec PWM at its probe time should get suspended
before cros-ec suspends.
-Doug
Powered by blists - more mailing lists