>>>> Instead of changing the suspend sequence, can we please try to modify
>>>> the max98373_io_init() routine to unconditionally flag the cache as
>>>> dirty, maybe this points to a problem with the management of the
>>>> max98373->first_hw_init flag.
>>>
>>> A quick survey of other drivers suggests that this pattern should be
>>> factored out into some helpers as it looks like there's several ways
>>> of implementing it that look very similar but not quite the same...
>>
>> No disagreement here, we tried really hard to enforce a common pattern for
>> suspend-resume, but i just noticed that the maxim amp driver is different on
>> suspend (resume is consistent with the rest).
>
> OK. I believe it was similar before. But it looks like 'regcache_mark_dirty' is being
> disappeared on suspend function.
Not sure what you are trying to say?
> static int __maybe_unused rt5682_dev_suspend(struct device *dev)
> {
> struct rt5682_priv *rt5682 = dev_get_drvdata(dev);
>
> if (!rt5682->hw_init)
> return 0;
>
> cancel_delayed_work_sync(&rt5682->jack_detect_work);
>
> regcache_cache_only(rt5682->regmap, true);
> regcache_mark_dirty(rt5682->regmap);
>
> return 0;
> }
That last line is also not needed. If you look at rt5682-sdw.c, you'll
see a regcache_mark_dirty() when the device is re-initialized.
But now I am starting to wonder if this is due to Chrome kernel
differences and possibly a missing backport patch? I no longer believe
in coincidences, these two devices are ONLY used in Chromebooks so far...
