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