On Sun, Feb 6, 2022 at 1:04 PM Sven Schwermer <sven@xxxxxxxxxxxxxxxx> wrote: > > > Skipping mutex destruction is not critical, but in general if you wish > > to free allocated resource, it should be done in reversed order... > As far as I can tell, the ordering is already reversed: I can't see it. What I see is that mutex_destroy() is called before the LED class unregisters (along with PWM and memory allocation). It means potentially it may be the issue when during ->probe() error path or ->remove() somebody calls for LED functions which rely on mutex presence (while it has been already destroyed). Easiest way to fix this is to wrap mutex_destroy() to be a devm_*() kind of function. > > +destroy_mutex: > > + mutex_destroy(&priv->lock); > > > > > > Wrong ordering here and in ->remove(). > > > > Don't mix devm_* with non-devm_* calls. > > > > What do you mean by this? > > > > > > ...which is exactly the issue with this code because of the use of > > devm_*() calls mixed with non-devm_*() ones. > > > > TL;DR: ordering is broken here. And to fix it you need either a) to > > convert all calls to be devm_*(), or b) make them all non-devm, or c) > > regroup resource allocation so that all devm followed by non-devm ones.Which non-devm calls are you referring to? -- With Best Regards, Andy Shevchenko
