[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA8EJprysL1Tn_SzyKaDgzSxzwDTdJo5Zx4jUEmE88qJ66vdFg@mail.gmail.com>
Date: Fri, 20 Sep 2024 15:05:13 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Stephan Gerhold <stephan.gerhold@...aro.org>
Cc: Jinjie Ruan <ruanjinjie@...wei.com>, stephan@...hold.net, loic.poulain@...aro.org,
ryazanov.s.a@...il.com, johannes@...solutions.net, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] net: wwan: qcom_bam_dmux: Fix missing pm_runtime_disable()
On Fri, 20 Sept 2024 at 14:44, Stephan Gerhold
<stephan.gerhold@...aro.org> wrote:
>
> On Fri, Sep 20, 2024 at 01:48:15PM +0300, Dmitry Baryshkov wrote:
> > On Fri, Sep 20, 2024 at 06:07:11PM GMT, Jinjie Ruan wrote:
> > > It's important to undo pm_runtime_use_autosuspend() with
> > > pm_runtime_dont_use_autosuspend() at driver exit time.
> > >
> > > But the pm_runtime_disable() and pm_runtime_dont_use_autosuspend()
> > > is missing in the error path for bam_dmux_probe(). So add it.
> >
> > Please use devm_pm_runtime_enable(), which handles autosuspend.
> >
>
> This would conflict with the existing cleanup in bam_dmux_remove(),
> which probably needs to stay manually managed since the tear down order
> is quite important there.
Hmm, the setup and teardown code makes me wonder now. Are we
guaranteed that the IRQs can not be delivered after suspending the
device?
Also is there a race between IRQs being enabled, manual check of the
IRQ state and the pc_ack / power_off calls?
>
> I think this looks reasonable, except that pm_runtime_set_suspended()
> should be redundant since it's the default runtime PM state.
>
> Thanks,
> Stephan
--
With best wishes
Dmitry
Powered by blists - more mailing lists