On Thu, Mar 05, 2020 at 07:47:47AM -0600, 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 know the codebase, so, I was suggested this solution based on my experience. I can't answer right now why that had been done that way (especially that it had been done not by me or any my involvement at the time).
I don't fully get the acpi mapping and all.
This one is easy to explain. ACPI lacks of the proper labeling / mapping GPIO resources. _DSD() method helps there, but there are no Wintel firmware that supports it (Google basically is the first who utilizes it).
That's why the board code has mapping table to allow request GPIOs by label (connection ID in terms of GPIO suybsystem).
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.
Yes.