On 3/5/2020 2:47 PM, Pierre-Louis Bossart wrote:
On 3/5/20 7:36 AM, Mark Brown wrote:
On Thu, Mar 05, 2020 at 07:06:15AM -0600, Pierre-Louis Bossart wrote:
The use of devm_gpiod_get() in a dailink .init() callback generates
issues
when unloading modules. The dependencies between modules are not well
handled and the snd_soc_rt5677 module cannot be removed:
In what way are the dependencies not well managed and why aren't we
requesting the GPIO on device model probe anyway?
there are a couple of machine drivers where the gpios are requested from
the machine driver. I have no idea what it is done this way, maybe the
codec exposes a gpiochip that's used later? I was hoping that Andy can
help, I don't fully get the acpi mapping and all.
see the code here for reference:
https://elixir.bootlin.com/linux/v5.6-rc4/source/sound/soc/intel/boards/bdw-rt5677.c#L250
The issue happens when running our test scripts, which do a set a rmmod
in a specific order: rmmod of the machine driver, then doing an rmmod of
the codec driver. Somehow the second fails with the 'module in use error'.
It's probably because the devm_ release does not happen when the card is
unregistered and the machine driver resources released since we use the
component device. There might very well be a bug somewhere in the devm_
handling, I just don't have a clue how to debug this - and the .exit()
makes sense regardless in other cases unrelated to GPIOs.
This sounds related to issue I've seen related to fact that there is
devm_snd_soc_register_component and devm_snd_soc_register_card and when
cleanup happens, one of them seems to release memory before other one
runs it cleanup functions. And then cleanup functions try to operate on
already released memory.
I haven't debugged this in depth, and just made simple patch to replace
problematic devm_kzalloc with kzalloc and kfree, but there seems
something weird happening related to how dynamic memory management works
in ASOC.
