Re: [PATCH] ASoC: cs42l43-jack: Remove manual pm_runtime get/put from tip_sense_work

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

On 16/03/2026 16:27, Charles Keepax wrote:
> On Mon, Mar 16, 2026 at 02:49:24PM +0200, Peter Ujfalusi wrote:
>> When a jack is inserted the forced pm_runtime_get() will keep the codec,
>> soundwire bus and it's parent active as long as the jack is connected.
>> This makes for example the DSP and firmware booted up on Intel platforms.
>>
>> If the module is removed while the jack is connected we will also have
>> unbalanced runtime PM state.
>>
>> Without the manual get/put, the button detection still works correctly and
>> the system can reach lower power state while the jack is connected like
>> in the case when there is no jack connected.
>>
>> Fixes: fc918cbe874e ("ASoC: cs42l43: Add support for the cs42l43")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
>> ---
>>  sound/soc/codecs/cs42l43-jack.c | 8 ++------
>>  1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/sound/soc/codecs/cs42l43-jack.c b/sound/soc/codecs/cs42l43-jack.c
>> index 3e04e6897b14..d90a13a55845 100644
>> --- a/sound/soc/codecs/cs42l43-jack.c
>> +++ b/sound/soc/codecs/cs42l43-jack.c
>> @@ -756,10 +756,8 @@ void cs42l43_tip_sense_work(struct work_struct *work)
>>  	ring = (sts >> CS42L43_RINGSENSE_PLUG_DB_STS_SHIFT) & CS42L43_JACK_PRESENT;
>>  
>>  	if (tip == CS42L43_JACK_PRESENT) {
>> -		if (cs42l43->sdw && !priv->jack_present) {
>> +		if (cs42l43->sdw && !priv->jack_present)
>>  			priv->jack_present = true;
>> -			pm_runtime_get(priv->dev);
>> -		}
> 
> Hmm... yes, I have this feeling this was in here for a reason I
> should probably have left a comment here. I somewhat agree it
> looks a bit mad with fresh eyes. The variable is also only used
> for tracking this pm_runtime_get so you can drop the jack_present
> variable from the struct as well, if we take the patch forward.

That was my thinking as well, but then when the headset buttons did
worked after the patch on an idle system (ARL laptop) then I thought
that this might no longer be needed?

Fwiw, I have been banging my head on why the DSP is not suspending ever
on the laptop and the system is not hitting lower C state because of
this when I had some spare time and studied the code and then removed
the jack and boom, the DSP suspended right away :o

> Best I can come up with was it was some interaction with the
> Intel host's doing a bus reset when coming out of clock stop. I
> think that might have caused something important to get
> clobbered in some situations. But anyway will do some testing and
> thinking and report back.

Sure, but draining battery when the jack is connected is not a great
added feature of a codec driver.
The type-Cs are on the other side of the laptop, so taping the jack and
power together is not a workable solution - to disconnect jack if power
is removed ;)

It would be great if you can find the reason for forcing the system up
if jack is connected.
Even then there is the issue of unbalance in runtime get on module
removal when the jack is connected...

-- 
Péter