Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <cover.1648551070.git.tonyhuang.sunplus@gmail.com> <46aad49867912fc57b669fc54fdb28638cccfcd9.1648551070.git.tonyhuang.sunplus@gmail.com>
In-Reply-To: <46aad49867912fc57b669fc54fdb28638cccfcd9.1648551070.git.tonyhuang.sunplus@gmail.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Tue, 29 Mar 2022 17:10:03 +0200
Message-ID: <CAK8P3a0CLA33CTerXJ=bK+myhyHp_utoLnTX-NzMgjeb7icAGg@mail.gmail.com>
Subject: Re: [PATCH v5 2/2] mmc: Add mmc driver for Sunplus SP7021
To:     Tony Huang <tonyhuang.sunplus@gmail.com>
Cc:     Ulf Hansson <ulf.hansson@linaro.org>,
        Rob Herring <robh+dt@kernel.org>, lhjeff911@gmail.com,
        linux-mmc <linux-mmc@vger.kernel.org>,
        DTML <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        =?UTF-8?B?V2VsbHMgTHUg5ZGC6Iqz6aiw?= <wells.lu@sunplus.com>,
        Tony Huang <tony.huang@sunplus.com>, lh.kuo@sunplus.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Mar 29, 2022 at 4:42 PM Tony Huang <tonyhuang.sunplus@gmail.com> wrote:
>
> Add mmc driver for Sunplus SP7021
>
> Signed-off-by: Tony Huang <tonyhuang.sunplus@gmail.com>

There should be a description of the device in the changelog, not just the same
text as the subject.

> +static void spmmc_request(struct mmc_host *mmc, struct mmc_request *mrq)
> +{
> +       struct spmmc_host *host = mmc_priv(mmc);
> +       struct mmc_data *data;
> +       struct mmc_command *cmd;
> +       int ret;
> +
> +       ret = mutex_lock_interruptible(&host->mrq_lock);
> +       if (ret)
> +               return;

I don't think it's valid to just return here when you get a signal. If
nothing can
handle the signal, doesn't it just hang?

It also appears that you don't release the mutex until the tasklet runs,
but it is not valid to release a mutex from a different context.

You should get a warning about this when running a kernel with lockdep
enabled at compile time. Please rework the locking to make this work.

> +#endif /* ifdef CONFIG_PM_RUNTIME */
> +
> +static const struct dev_pm_ops spmmc_pm_ops = {
> +       SET_SYSTEM_SLEEP_PM_OPS(spmmc_pm_suspend, spmmc_pm_resume)
> +#ifdef CONFIG_PM_RUNTIME
> +       SET_RUNTIME_PM_OPS(spmmc_pm_runtime_suspend, spmmc_pm_runtime_resume, NULL)
> +#endif
> +};
> +#endif /* ifdef CONFIG_PM */

It's better to use SYSTEM_SLEEP_PM_OPS/RUNTIME_PM_OPS instead
of the SET_ version, then you can remove all the #ifdef checks.

       Arnd