Hi Mark, On 20.12.2019 13:01, Mark Brown wrote: > On Fri, Dec 20, 2019 at 10:05:52AM +0100, Marek Szyprowski wrote: >> On 20.12.2019 09:28, Marek Szyprowski wrote: >>> I've tried initially to cherry-pick it to v5.4, but the the code >>> didn't compile due to lack of some macros, so I've gave up trying. I >>> will check that now and backport needed macros too if you think this >>> would help. >> Same issue. I've tried backporting it to each kernel release: 5.4, 5.3, >> 5.2, 5.1 and 5.0 (with additional backporting "ASoC: core: add >> SND_SOC_BYTES_E" and "ASoC: Define a set of DAPM pre/post-up events"). >> In all cases the lockdep warning and oops is the same. Backporting to >> v4.9 requires more changes to get it even compiled, so I gave up. > OK, thanks - that's definitely not the recent refactorings then but > something that's been a problem for a long time. I'm surprised nobody > else ran into anything if that's the case... It took me a while to get back into this issue and investigate it in details. It turned out to be an incorrect helper to get component object in max98090_dapm_put_enum_double() function. Following patches: https://lkml.org/lkml/2020/1/8/358 fix this and (independent) lockdep issues. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland