[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dd42f526-6da7-87f8-ad4c-bf18af41c665@axentia.se>
Date: Tue, 3 Sep 2024 15:17:14 +0200
From: Peter Rosin <peda@...ntia.se>
To: Thomas Richard <thomas.richard@...tlin.com>,
Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski
<brgl@...ev.pl>, Andy Shevchenko <andy@...nel.org>,
Tony Lindgren <tony@...mide.com>, Haojian Zhuang
<haojian.zhuang@...aro.org>, Vignesh R <vigneshr@...com>,
Aaro Koskinen <aaro.koskinen@....fi>,
Janusz Krzysztofik <jmkrzyszt@...il.com>, Andi Shyti
<andi.shyti@...nel.org>, Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof WilczyĆski <kw@...ux.com>,
Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
linux-i2c@...r.kernel.org, linux-phy@...ts.infradead.org,
linux-pci@...r.kernel.org, gregory.clement@...tlin.com,
theo.lebrun@...tlin.com, thomas.petazzoni@...tlin.com, u-kumar1@...com
Subject: Re: [PATCH v4 04/18] mux: add mux_chip_resume() function
Hi!
Sorry for being unresponsive.
2024-03-04 at 16:35, Thomas Richard wrote:
> The mux_chip_resume() function restores a mux_chip using the cached state
> of each mux.
>
> Signed-off-by: Thomas Richard <thomas.richard@...tlin.com>
> ---
> drivers/mux/core.c | 29 +++++++++++++++++++++++++++++
> include/linux/mux/driver.h | 1 +
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/mux/core.c b/drivers/mux/core.c
> index 775816112932..0742aa2a7c73 100644
> --- a/drivers/mux/core.c
> +++ b/drivers/mux/core.c
> @@ -215,6 +215,35 @@ void mux_chip_free(struct mux_chip *mux_chip)
> }
> EXPORT_SYMBOL_GPL(mux_chip_free);
>
> +/**
> + * mux_chip_resume() - restores the mux-chip state
> + * @mux_chip: The mux-chip to resume.
> + *
> + * Restores the mux-chip state.
> + *
> + * Return: Zero on success or a negative errno on error.
> + */
> +int mux_chip_resume(struct mux_chip *mux_chip)
> +{
> + int ret, i;
> +
> + for (i = 0; i < mux_chip->controllers; ++i) {
> + struct mux_control *mux = &mux_chip->mux[i];
> +
> + if (mux->cached_state == MUX_CACHE_UNKNOWN)
> + continue;
> +
> + ret = mux_control_set(mux, mux->cached_state);
mux_control_set() is an internal helper. It is called from
__mux_control_select() and mux_control_deselect() (and on init...)
In all those cases, there is no race to reach the mux_control_set()
function, by means of the mux->lock semaphore (or the mux not being
"published" yet).
I fail to see how resume is safe when mux->lock is ignored?
Cheers,
Peter
> + if (ret < 0) {
> + dev_err(&mux_chip->dev, "unable to restore state\n");
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(mux_chip_resume);
> +
> static void devm_mux_chip_release(struct device *dev, void *res)
> {
> struct mux_chip *mux_chip = *(struct mux_chip **)res;
> diff --git a/include/linux/mux/driver.h b/include/linux/mux/driver.h
> index 18824064f8c0..2a7e5ec5d540 100644
> --- a/include/linux/mux/driver.h
> +++ b/include/linux/mux/driver.h
> @@ -88,6 +88,7 @@ struct mux_chip *mux_chip_alloc(struct device *dev,
> int mux_chip_register(struct mux_chip *mux_chip);
> void mux_chip_unregister(struct mux_chip *mux_chip);
> void mux_chip_free(struct mux_chip *mux_chip);
> +int mux_chip_resume(struct mux_chip *mux_chip);
>
> struct mux_chip *devm_mux_chip_alloc(struct device *dev,
> unsigned int controllers,
>
Powered by blists - more mailing lists