[RFC PATCH 2/3] ASoC: Intel: bdw-rt5677: fix module load/unload issues
Amadeusz Sławiński
amadeuszx.slawinski at linux.intel.com
Thu Mar 5 15:06:17 CET 2020
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.
More information about the Alsa-devel
mailing list