linux-kernel - Re: [PATCH] ASoC: rt5682: Add jack kcontrol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <57747e9a-10e0-e4f6-0644-5225396802f9@gmail.com>
Date:   Fri, 8 Apr 2022 02:16:41 +0900
From:   Akihiko Odaki <akihiko.odaki@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
        Jaroslav Kysela <perex@...ex.cz>,
        Oder Chiou <oder_chiou@...ltek.com>,
        Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH] ASoC: rt5682: Add jack kcontrol

On 2022/04/08 1:37, Mark Brown wrote:
> j
> On Fri, Apr 08, 2022 at 01:11:22AM +0900, Akihiko Odaki wrote:
>> On 2022/04/08 1:00, Mark Brown wrote:
> 
>>> That bit is very common but there's still machine specific aspects - is
>>> the required hardware wired up, if it is wired up how exactly are things
>>> wired (separate microphone jack, headset jack, one of many jacks?).  A
>>> lot of the machine driver part of things is about labeling things so
>>> that it can be displayed in a way that's easy to connect to the physical
>>> system.  Generally the machine driver would define a jack and then
>>> connect the CODEC to it.
> 
>> Whether the required hardware wired is told from the user of the codec via
>> jack's type specified with snd_soc_card_jack_new(). The other details live
>> in the codec.
> 
> So I'm confused about what problem this patch is intended to fix.  It
> really sounds like there's some issue with the driver not using standard
> interfaces that you're trying to work around but the changelog is not at
> all clear.  The "doesn't use DAPM" bit is a bit of a warning sign, it
> sounds like the audio signals to and from the CODEC aren't being
> connected to the jack properly.
> 
> Look at how other devices with jack detection hardware handle this and
> follow a similar pattern.

The situation actually seems quite a mess. You can find many drivers not 
using DAPM pins by searching for snd_soc_card_jack_new() calls with 
num_pins argument is 0. ams-delta-audio is exceptional as it adds DAPM 
pins later with snd_soc_jack_add_pins().

They do not have kcontrols for the jacks. The only exception is 
skl_hda_dsp_generic which calls snd_jack_add_new_kctl() as my patch 
does. Looking at other devices is probably not helpful to find an 
alternative in this case.

Regards,
Akihiko Odaki