Re: [PATCH 1/2] mux: add mux_chip_resume() function

[Peter Rosin]

Hi!

2024-09-04 at 11:18, Thomas Richard wrote:
> 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@xxxxxxxxxxx>
>>> ---
>>>  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

No, calling mux_control_select() in resume context is not an
option IIUC. That would dead-lock if there is a long-time client
who has locked the mux in some desired state.

I see no trivial solution to integrate suspend/resume, and do
not have enough time to think about what a working solutions
would look like. Sorry.

Cheers,
Peter