[PATCH 2/5] ASoC: Intel: bdw-rt5677: fix module load/unload issues

Cezary Rojewski cezary.rojewski at intel.com
Wed Jun 24 22:26:57 CEST 2020


On 2020-06-24 10:06 PM, Pierre-Louis Bossart wrote:
> On 6/24/20 2:14 PM, Cezary Rojewski wrote:
>> On 2020-06-22 5:42 PM, Pierre-Louis Bossart wrote:
>>> The mainline code currently prevents modules from being removed.
>>>
>>> The BE dailink .init() function calls devm_gpiod_get() using the codec
>>> component device as argument. When the machine driver is removed, the
>>> references to the gpiod are not released, and it's not possible to
>>> remove the codec driver module - which is the only entity which could
>>> free the gpiod.
>>>
>>> This conceptual deadlock can be avoided by invoking gpiod_get() in the
>>> .init() callback, and calling gpiod_put() in the exit() callback.
>>>
>>> Tested on SAMUS Chromebook with SOF driver.
>>>
>>
>> As /intel/haswell is the go-to driver for BDW platforms, please test 
>> and confirm with legacy driver first. SOF is optional and thus 
>> non-blocking.
> 
> I'll retest when you've fixed the go-to legacy driver, I am not even 
> going to try module load/unload tests when the platform code has known 
> issues requiring reverts.

??

Judging by recent comments from the revert thread, you already had build 
with patch-reverted ready. Shouldn't be a problem to retest with that one.

Power transition update is unavoidable if that's what you're asking. 
Without it, hardware *may* achieve a power state, but that's certainly 
not a D3 one.

Czarek


More information about the Alsa-devel mailing list