On Thu, Jan 9, 2020 at 7:09 PM Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > On 09.01.2020 06:36, Tzung-Bi Shih wrote: > > On Wed, Jan 8, 2020 at 7:50 PM Marek Szyprowski > > <m.szyprowski@xxxxxxxxxxx> wrote: > >> Fix this by introducing a separate mutex only for serializing the SHDN > >> hardware register related operations. > > This fix makes less sense to me. We used dapm_mutex intentionally > > because: both DAPM and userspace mixer control would change SHDN bit > > at the same time. We should not use a separate lock. Either mixer control or DAPM would change the SHDN bit. The patch overlooks the calling path from DAPM. As a result, DAPM can change the bit in the middle of mixer control. > Nope. This is just a lockdep warning about possible hypothetical > situation on the test system during the normal boot. It doesn't mean > that the circular dependency actually happens (if so, it would end in > deadlock). It also doesn't mean that such circular dependency can be > really triggered, because some other dependencies that not known to > lockdep engine might protect against it. However the easiest way to fix > it is to use fine-grained locking instead of reusing some framework > locks for other purposes. Such approach is also usually a good practice. If the possible circular locking is a hypothetical situation, shall we ignore it since we are very sure userspace cannot see the control devices when building the sound card?
