[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5067055-1470-4386-8839-b4ec2527872e@bootlin.com>
Date: Wed, 4 Sep 2024 11:18:13 +0200
From: Thomas Richard <thomas.richard@...tlin.com>
To: Peter Rosin <peda@...ntia.se>
Cc: linux-kernel@...r.kernel.org, gregory.clement@...tlin.com,
theo.lebrun@...tlin.com, thomas.petazzoni@...tlin.com, u-kumar1@...com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 1/2] mux: add mux_chip_resume() function
On 9/3/24 15:22, Peter Rosin wrote:
> Hi!
>
> Sorry for being unresponsive. And for first writing this in the older v4
> thread instead of here.
>
> 2024-06-13 at 15:07, 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 78c0022697ec..0858cacae845 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?
I think I should use mux_control_select() to use the lock.
If I ignore the lock, I could have a cache coherence issue.
I'll send a new version which use mux_control_select().
But if I use mux_control_select(), I have to clean the cache before to
call it, if not nothing happen [1].
[1]
https://elixir.bootlin.com/linux/v6.11-rc6/source/drivers/mux/core.c#L319
Regards,
Thomas
Powered by blists - more mailing lists