Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191206075209.18068-1-hslester96@gmail.com> <20191209162417.GD5483@sirena.org.uk>
 <CANhBUQ0zwQG-=C12v02cf5kfvJba=5_=0JkZA45DDhxOzTBY6A@mail.gmail.com> <20191209170030.GH5483@sirena.org.uk>
In-Reply-To: <20191209170030.GH5483@sirena.org.uk>
From:   Chuhong Yuan <hslester96@gmail.com>
Date:   Tue, 10 Dec 2019 09:32:12 +0800
Message-ID: <CANhBUQ0-jEG2W=sby1SyPphxK3CSPinFF5zkLq9jsKCZM5hYjw@mail.gmail.com>
Subject: Re: [PATCH] ASoC: cs42l42: add missed regulator_bulk_disable in
 remove and fix probe failure
To:     Mark Brown <broonie@kernel.org>
Cc:     Brian Austin <brian.austin@cirrus.com>,
        Paul Handrigan <Paul.Handrigan@cirrus.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>,
        James Schulman <james.schulman@cirrus.com>,
        alsa-devel@alsa-project.org, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Dec 10, 2019 at 1:00 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Dec 10, 2019 at 12:52:30AM +0800, Chuhong Yuan wrote:
>
> > I have a question that what if CONFIG_PM is not defined?
> > Since I have met runtime PM before in the patch
> > a31eda65ba21 ("net: fec: fix clock count mis-match").
> > I learned there that in some cases CONFIG_PM is not defined so runtime PM
> > cannot take effect.
> > Therefore, undo operations should still exist in remove functions.
>
> There's also the case where runtime PM is there and the device is active
> at suspend - it's not that there isn't a problem, it's that we can't
> unconditionally do a disable because we don't know if there was a
> matching enable.  It'll need to be conditional on the runtime PM state.

How about adding a check like #ifndef CONFIG_PM?
I use this in an old version of the mentioned patch.
However, that is not accepted since it seems not symmetric with enable
in the probe.
But I don't find an explicit runtime PM call in the probe here so the
revision pattern of
("net: fec: fix clock count mis-match") seems not applicable.
So I think adding a check is acceptable here, at least it solves the problem.