linux-kernel - Re: [PATCH] ASoC: fsl_sai: remove reset code from dai

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAA+D8ANuUWne1nzGH6=V4nj7YMRczuZ+pH--eJ+ghiGWfo_0sQ@mail.gmail.com>
Date:   Fri, 19 Mar 2021 12:10:48 +0800
From:   Shengjiu Wang <shengjiu.wang@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Viorel Suman <viorel.suman@....com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "timur@...nel.org" <timur@...nel.org>,
        "Xiubo.Lee@...il.com" <Xiubo.Lee@...il.com>,
        "festevam@...il.com" <festevam@...il.com>,
        "S.j. Wang" <shengjiu.wang@....com>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "nicoleotsuka@...il.com" <nicoleotsuka@...il.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ASoC: fsl_sai: remove reset code from dai_probe

Hi Mark

On Tue, Mar 16, 2021 at 9:51 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Tue, Mar 16, 2021 at 01:42:40PM +0000, Viorel Suman wrote:
>
> > To me it makes sense to manage the clocks and reset from the same place.
> > Currently we have the clocks management moved completely into runtime PM
> > fsl_sai_runtime_resume and fsl_sai_runtime_suspend callbacks.
>
> Usually the pattern is to have probe() leave everything powered up then
> let runtime PM power things down if it's enabled, you can often do the
> power up by having an open coded call to the resume callback in probe().

It seems some drivers very depend on runtime PM, if the CONFIG_PM=n,
the drivers should not work.  What's the strategy for this?
Do we need to support both cases, or only one case is also acceptable?

Best regards
Wang Shengjiu