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...