- Alsa-devel - mailman.alsa-project.org

[PATCH v4 1/1] ASoC: dpcm: acquire dpcm_lock in dpcm_do_trigger()
by Gyeongtaek Lee 17 Feb '21

17 Feb '21

If stop by underrun and DPCM BE disconnection is run simultaneously, data abort can be occurred by the sequence below. CPU0 CPU1 dpcm_be_dai_trigger(): dpcm_be_disconnect(): for_each_dpcm_be(fe, stream, dpcm) { spin_lock_irqsave(&fe->card->dpcm_lock, flags); list_del(&dpcm->list_be); list_del(&dpcm->list_fe); spin_unlock_irqrestore(&fe->card->dpcm_lock, flags); kfree(dpcm); struct snd_soc_pcm_runtime *be = dpcm->be; <-- Accessing freed memory To prevent this situation, dpcm_lock should be acquired during iteration of dpcm list in dpcm_be_dai_trigger(). Signed-off-by: Gyeongtaek Lee <gt82.lee(a)samsung.com> Cc: stable(a)vger.kernel.org --- sound/soc/soc-pcm.c | 62 ++++++++++++++++++++++++++++++++------------- 1 file changed, 44 insertions(+), 18 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index ee51dc7fd893..718f6b3a309a 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -2074,12 +2074,17 @@ static int dpcm_fe_dai_hw_params(struct snd_pcm_substream *substream, return ret; } +static int dpcm_can_be_free_stop(struct snd_soc_pcm_runtime *fe, + struct snd_soc_pcm_runtime *be, int stream); + int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, int cmd) { struct snd_soc_dpcm *dpcm; + unsigned long flags; int ret = 0; + spin_lock_irqsave(&fe->card->dpcm_lock, flags); for_each_dpcm_be(fe, stream, dpcm) { struct snd_soc_pcm_runtime *be = dpcm->be; @@ -2102,7 +2107,7 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, ret = soc_pcm_trigger(be_substream, cmd); if (ret) - return ret; + break; be->dpcm[stream].state = SND_SOC_DPCM_STATE_START; break; @@ -2112,7 +2117,7 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, ret = soc_pcm_trigger(be_substream, cmd); if (ret) - return ret; + break; be->dpcm[stream].state = SND_SOC_DPCM_STATE_START; break; @@ -2122,7 +2127,7 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, ret = soc_pcm_trigger(be_substream, cmd); if (ret) - return ret; + break; be->dpcm[stream].state = SND_SOC_DPCM_STATE_START; break; @@ -2131,12 +2136,12 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED)) continue; - if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream)) + if (!dpcm_can_be_free_stop(fe, be, stream)) continue; ret = soc_pcm_trigger(be_substream, cmd); if (ret) - return ret; + break; be->dpcm[stream].state = SND_SOC_DPCM_STATE_STOP; break; @@ -2144,12 +2149,12 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START) continue; - if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream)) + if (!dpcm_can_be_free_stop(fe, be, stream)) continue; ret = soc_pcm_trigger(be_substream, cmd); if (ret) - return ret; + break; be->dpcm[stream].state = SND_SOC_DPCM_STATE_SUSPEND; break; @@ -2157,17 +2162,20 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START) continue; - if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream)) + if (!dpcm_can_be_free_stop(fe, be, stream)) continue; ret = soc_pcm_trigger(be_substream, cmd); if (ret) - return ret; + break; be->dpcm[stream].state = SND_SOC_DPCM_STATE_PAUSED; break; } + if (ret) + break; } + spin_unlock_irqrestore(&fe->card->dpcm_lock, flags); return ret; } @@ -2905,10 +2913,9 @@ static int snd_soc_dpcm_check_state(struct snd_soc_pcm_runtime *fe, struct snd_soc_dpcm *dpcm; int state; int ret = 1; - unsigned long flags; int i; - spin_lock_irqsave(&fe->card->dpcm_lock, flags); + lockdep_assert_held(&fe->card->dpcm_lock); for_each_dpcm_fe(be, stream, dpcm) { if (dpcm->fe == fe) @@ -2922,17 +2929,12 @@ static int snd_soc_dpcm_check_state(struct snd_soc_pcm_runtime *fe, } } } - spin_unlock_irqrestore(&fe->card->dpcm_lock, flags); /* it's safe to do this BE DAI */ return ret; } -/* - * We can only hw_free, stop, pause or suspend a BE DAI if any of it's FE - * are not running, paused or suspended for the specified stream direction. - */ -int snd_soc_dpcm_can_be_free_stop(struct snd_soc_pcm_runtime *fe, +static int dpcm_can_be_free_stop(struct snd_soc_pcm_runtime *fe, struct snd_soc_pcm_runtime *be, int stream) { const enum snd_soc_dpcm_state state[] = { @@ -2943,6 +2945,23 @@ int snd_soc_dpcm_can_be_free_stop(struct snd_soc_pcm_runtime *fe, return snd_soc_dpcm_check_state(fe, be, stream, state, ARRAY_SIZE(state)); } + +/* + * We can only hw_free, stop, pause or suspend a BE DAI if any of it's FE + * are not running, paused or suspended for the specified stream direction. + */ +int snd_soc_dpcm_can_be_free_stop(struct snd_soc_pcm_runtime *fe, + struct snd_soc_pcm_runtime *be, int stream) +{ + unsigned long flags; + int ret; + + spin_lock_irqsave(&fe->card->dpcm_lock, flags); + ret = dpcm_can_be_free_stop(fe, be, stream); + spin_unlock_irqrestore(&fe->card->dpcm_lock, flags); + + return ret; +} EXPORT_SYMBOL_GPL(snd_soc_dpcm_can_be_free_stop); /* @@ -2952,6 +2971,9 @@ EXPORT_SYMBOL_GPL(snd_soc_dpcm_can_be_free_stop); int snd_soc_dpcm_can_be_params(struct snd_soc_pcm_runtime *fe, struct snd_soc_pcm_runtime *be, int stream) { + unsigned long flags; + int ret; + const enum snd_soc_dpcm_state state[] = { SND_SOC_DPCM_STATE_START, SND_SOC_DPCM_STATE_PAUSED, @@ -2959,6 +2981,10 @@ int snd_soc_dpcm_can_be_params(struct snd_soc_pcm_runtime *fe, SND_SOC_DPCM_STATE_PREPARE, }; - return snd_soc_dpcm_check_state(fe, be, stream, state, ARRAY_SIZE(state)); + spin_lock_irqsave(&fe->card->dpcm_lock, flags); + ret = snd_soc_dpcm_check_state(fe, be, stream, state, ARRAY_SIZE(state)); + spin_unlock_irqrestore(&fe->card->dpcm_lock, flags); + + return ret; } EXPORT_SYMBOL_GPL(snd_soc_dpcm_can_be_params); -- 2.21.0

2 1

[PATCH v4 0/1] ASoC: dpcm: acquire dpcm_lock in dpcm_do_trigger()
by Gyeongtaek Lee 17 Feb '21

17 Feb '21

On 2021-01-06 at 12:41, Mark Brown wrote: >On Mon, Dec 28, 2020 at 08:23:16PM +0900, Gyeongtaek Lee wrote: >> If stop by underrun and DPCM BE disconnection is run simultaneously, >> data abort can be occurred by the sequence below. > >This doesn't apply against current code, please check and resend. Hi, Mark. I resend the patch after rebasing it on the latest of stable linux. Best regards, Gyeongtaek Lee Gyeongtaek Lee (1): ASoC: dpcm: acquire dpcm_lock in dpcm_do_trigger() sound/soc/soc-pcm.c | 62 ++++++++++++++++++++++++++++++++------------- 1 file changed, 44 insertions(+), 18 deletions(-) base-commit: f40ddce88593482919761f74910f42f4b84c004b -- 2.21.0

1 0

[PATCH 0/3] ASoC: soc-pcm: add soc_pcm_hw_update_xxx()
by Kuninori Morimoto 16 Feb '21

16 Feb '21

Hi Mark These adds soc_pcm_hw_update_xxx() and cleanup soc-pcm.c Kuninori Morimoto (3): ASoC: soc-pcm: add soc_pcm_hw_update_rate() ASoC: soc-pcm: add soc_pcm_hw_update_chan() ASoC: soc-pcm: add soc_pcm_hw_update_format() sound/soc/soc-pcm.c | 112 ++++++++++++++++++++++---------------------- 1 file changed, 56 insertions(+), 56 deletions(-) -- 2.25.1

4 14

[PATCH] ASoC: soc-pcm: fix hwparams min/max init for dpcm
by Kai Vehmanen 15 Feb '21

15 Feb '21

When runtime is initialized with dpcm_init_runtime_hw(), some of the min/max calculations assume that defaults are set. For example calculation of channel min/max values may be done using zero-initialized data and soc_pcm_hw_update_chan() will always return max-channels of 0 in this case. This will result in failure to open the PCM at all. Fix the issue by calling soc_pcm_hw_init() before calling any soc_pcm_hw_update_*() functions. Remove the conditional code on runtime->hw.formats as this field is anyways set in soc_pcm_hw_init(). Fixes: 6cb56a4549e9 ("ASoC: soc-pcm: add soc_pcm_hw_update_chan()") Reported-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/soc/soc-pcm.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) Notes: - This fixes regressions caught by SOF CI. Matching SOF CI test run with this patch applied is at: https://github.com/thesofproject/linux/pull/2756 diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index b7c90da1820e..37094aeff440 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1531,12 +1531,10 @@ static void dpcm_init_runtime_hw(struct snd_pcm_runtime *runtime, { struct snd_pcm_hardware *hw = &runtime->hw; + soc_pcm_hw_init(hw); soc_pcm_hw_update_rate(hw, stream); soc_pcm_hw_update_chan(hw, stream); - if (runtime->hw.formats) - runtime->hw.formats &= stream->formats; - else - runtime->hw.formats = stream->formats; + soc_pcm_hw_update_format(hw, stream); } static void dpcm_runtime_merge_format(struct snd_pcm_substream *substream, base-commit: debc71f26cdbd45798c63b0dcdabdea93d2f6870 -- 2.29.2

2 1

[PATCH] ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup
by Takashi Iwai 15 Feb '21

15 Feb '21

HP Spectre x360 14 model (PCI SSID 103c:87f7) seems requiring a unique setup for its external amp: the GPIO0 needs to be toggled on and off shortly at each device initialization via runtime PM. This patch implements that workaround as well as the model option string, so that users with other devices may try the same workaround more easily. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210633 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_realtek.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 52907506e16e..1927605f0f7e 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4291,6 +4291,28 @@ static void alc280_fixup_hp_gpio4(struct hda_codec *codec, } } +/* HP Spectre x360 14 model needs a unique workaround for enabling the amp; + * it needs to toggle the GPIO0 once on and off at each time (bko#210633) + */ +static void alc245_fixup_hp_x360_amp(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + + switch (action) { + case HDA_FIXUP_ACT_PRE_PROBE: + spec->gpio_mask |= 0x01; + spec->gpio_dir |= 0x01; + break; + case HDA_FIXUP_ACT_INIT: + /* need to toggle GPIO to enable the amp */ + alc_update_gpio_data(codec, 0x01, true); + msleep(100); + alc_update_gpio_data(codec, 0x01, false); + break; + } +} + static void alc_update_coef_led(struct hda_codec *codec, struct alc_coef_led *led, bool polarity, bool on) @@ -6277,6 +6299,7 @@ enum { ALC280_FIXUP_HP_DOCK_PINS, ALC269_FIXUP_HP_DOCK_GPIO_MIC1_LED, ALC280_FIXUP_HP_9480M, + ALC245_FIXUP_HP_X360_AMP, ALC288_FIXUP_DELL_HEADSET_MODE, ALC288_FIXUP_DELL1_MIC_NO_PRESENCE, ALC288_FIXUP_DELL_XPS_13, @@ -6982,6 +7005,10 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc280_fixup_hp_9480m, }, + [ALC245_FIXUP_HP_X360_AMP] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc245_fixup_hp_x360_amp, + }, [ALC288_FIXUP_DELL_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode_dell_alc288, @@ -7996,6 +8023,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x87c8, "HP", ALC287_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x87f4, "HP", ALC287_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x87f5, "HP", ALC287_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x87f7, "HP Spectre x360 14", ALC245_FIXUP_HP_X360_AMP), SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC), SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC282_FIXUP_ASUS_TX300), SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), @@ -8368,6 +8396,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {.id = ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, .name = "alc298-samsung-headphone"}, {.id = ALC255_FIXUP_XIAOMI_HEADSET_MIC, .name = "alc255-xiaomi-headset"}, {.id = ALC274_FIXUP_HP_MIC, .name = "alc274-hp-mic-detect"}, + {.id = ALC245_FIXUP_HP_X360_AMP, .name = "alc245-hp-x360-amp"}, {} }; #define ALC225_STANDARD_PINS \ -- 2.26.2

1 0

[PATCH v3 3/3] ASoC: rt715:add micmute led state control supports
by Perry Yuan 14 Feb '21

14 Feb '21

From: Perry Yuan <perry_yuan(a)dell.com> Some new Dell system is going to support audio internal micphone privacy setting from hardware level with micmute led state changing When micmute hotkey pressed by user, soft mute will need to be enabled firstly in case of pop noise, and codec driver need to react to mic mute event to EC(embedded controller) notifying that SW mute is completed Then EC will do the hardware mute physically within the timeout reached This patch allow codec rt715 driver to ack EC when micmute key pressed through this micphone led control interface like hda_generic provided ACPI method defined in dell-privacy micmute led trigger will be called for notifying the EC that software mute has been completed Signed-off-by: Perry Yuan <perry_yuan(a)dell.com> -------- v2 -> v3 * simplify the patch to reuse some val value * add more detail to the commit info v1 -> v2: * fix some format issue -------- --- sound/soc/codecs/rt715-sdca.c | 16 ++++++++++++++++ sound/soc/codecs/rt715-sdca.h | 1 + sound/soc/codecs/rt715.c | 14 ++++++++++++++ sound/soc/codecs/rt715.h | 1 + 4 files changed, 32 insertions(+) diff --git a/sound/soc/codecs/rt715-sdca.c b/sound/soc/codecs/rt715-sdca.c index b43ac8559e45..861a0d2a8957 100644 --- a/sound/soc/codecs/rt715-sdca.c +++ b/sound/soc/codecs/rt715-sdca.c @@ -12,6 +12,7 @@ #include <linux/version.h> #include <linux/kernel.h> #include <linux/init.h> +#include <linux/leds.h> #include <linux/pm_runtime.h> #include <linux/pm.h> #include <linux/soundwire/sdw.h> @@ -244,6 +245,7 @@ static int rt715_sdca_get_volsw(struct snd_kcontrol *kcontrol, unsigned int max = mc->max; int val; + pr_err("++++++rt715_sdca_get_volsw++\n"); val = snd_soc_component_read(component, mc->reg); if (val < 0) return -EINVAL; @@ -261,6 +263,7 @@ static int rt715_sdca_put_volsw(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct snd_soc_component *component = snd_kcontrol_chip(kcontrol); + struct rt715_sdca_priv *rt715 = snd_soc_component_get_drvdata(component); struct soc_mixer_control *mc = (struct soc_mixer_control *)kcontrol->private_value; unsigned int val, val2, loop_cnt = 2, i; @@ -268,6 +271,7 @@ static int rt715_sdca_put_volsw(struct snd_kcontrol *kcontrol, unsigned int reg2 = mc->rreg; unsigned int reg = mc->reg; unsigned int max = mc->max; + unsigned int val0, val1; int err; val = ucontrol->value.integer.value[0]; @@ -287,6 +291,18 @@ static int rt715_sdca_put_volsw(struct snd_kcontrol *kcontrol, return err; } +#if IS_ENABLED(CONFIG_DELL_PRIVACY) + /* dell privacy LED trigger state changed by muted/unmute switch */ + if (mc->invert) { + if (ucontrol->value.integer.value[0] || ucontrol->value.integer.value[1]) { + rt715->micmute_led = LED_OFF; + } else { + rt715->micmute_led = LED_ON; + } + ledtrig_audio_set(LED_AUDIO_MICMUTE, rt715->micmute_led); + } +#endif + return 0; } diff --git a/sound/soc/codecs/rt715-sdca.h b/sound/soc/codecs/rt715-sdca.h index 840c237895dd..f8988ab88f80 100644 --- a/sound/soc/codecs/rt715-sdca.h +++ b/sound/soc/codecs/rt715-sdca.h @@ -31,6 +31,7 @@ struct rt715_sdca_priv { int l_is_unmute; int r_is_unmute; int hw_sdw_ver; + bool micmute_led; }; struct rt715_sdw_stream_data { diff --git a/sound/soc/codecs/rt715.c b/sound/soc/codecs/rt715.c index cdcba70146da..b4e480744c94 100644 --- a/sound/soc/codecs/rt715.c +++ b/sound/soc/codecs/rt715.c @@ -13,6 +13,7 @@ #include <linux/init.h> #include <linux/delay.h> #include <linux/i2c.h> +#include <linux/leds.h> #include <linux/pm_runtime.h> #include <linux/pm.h> #include <linux/soundwire/sdw.h> @@ -88,6 +89,7 @@ static int rt715_set_amp_gain_put(struct snd_kcontrol *kcontrol, RT715_SET_GAIN_MIX_ADC2_L}; unsigned int addr_h, addr_l, val_h, val_ll, val_lr; unsigned int read_ll, read_rl, i, j, loop_cnt; + unsigned int val0, val1; if (strstr(ucontrol->id.name, "Main Capture Switch") || strstr(ucontrol->id.name, "Main Capture Volume")) @@ -95,6 +97,18 @@ static int rt715_set_amp_gain_put(struct snd_kcontrol *kcontrol, else loop_cnt = 1; +#if IS_ENABLED(CONFIG_DELL_PRIVACY) + /* Micmute LED state changed by muted/unmute switch */ + if (mc->invert) { + if (ucontrol->value.integer.value[0] || ucontrol->value.integer.value[1]) { + rt715->micmute_led = LED_OFF; + } else { + rt715->micmute_led = LED_ON; + } + ledtrig_audio_set(LED_AUDIO_MICMUTE, rt715->micmute_led); + } +#endif + for (j = 0; j < loop_cnt; j++) { /* Can't use update bit function, so read the original value first */ if (loop_cnt == 1) { diff --git a/sound/soc/codecs/rt715.h b/sound/soc/codecs/rt715.h index 009a8266f606..57c9af041181 100644 --- a/sound/soc/codecs/rt715.h +++ b/sound/soc/codecs/rt715.h @@ -22,6 +22,7 @@ struct rt715_priv { struct sdw_bus_params params; bool hw_init; bool first_hw_init; + bool micmute_led; }; struct sdw_stream_data { -- 2.25.1

8 13

amixer: Expand on channel docs in man page
by GitHub pull_request - opened 14 Feb '21

14 Feb '21

alsa-project/alsa-utils pull request #78 was opened from mcampbellizo: Add missing channel params to the amixer man page. Also call out that the channel param must come before the value to take effect. signed-off-by: Matthew Campbell <mcampbell(a)izotope.com> Request URL : https://github.com/alsa-project/alsa-utils/pull/78 Patch URL : https://github.com/alsa-project/alsa-utils/pull/78.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH] ALSA: usb-audio: Add implicit fb quirk for BOSS GP-10
by Takashi Iwai 14 Feb '21

14 Feb '21

BOSS GP-10 with 0582:0185 requires the similar quirk to make the implicit feedback working like other BOSS devices. Reported-by: Keith Milner <kamilner(a)superlative.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/usb/implicit.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/usb/implicit.c b/sound/usb/implicit.c index 521cc846d9d9..bba54430e6d0 100644 --- a/sound/usb/implicit.c +++ b/sound/usb/implicit.c @@ -73,6 +73,7 @@ static const struct snd_usb_implicit_fb_match playback_implicit_fb_quirks[] = { /* No quirk for playback but with capture quirk (see below) */ IMPLICIT_FB_SKIP_DEV(0x0582, 0x0130), /* BOSS BR-80 */ IMPLICIT_FB_SKIP_DEV(0x0582, 0x0171), /* BOSS RC-505 */ + IMPLICIT_FB_SKIP_DEV(0x0582, 0x0185), /* BOSS GP-10 */ IMPLICIT_FB_SKIP_DEV(0x0582, 0x0189), /* BOSS GT-100v2 */ IMPLICIT_FB_SKIP_DEV(0x0582, 0x01d6), /* BOSS GT-1 */ IMPLICIT_FB_SKIP_DEV(0x0582, 0x01d8), /* BOSS Katana */ @@ -86,6 +87,7 @@ static const struct snd_usb_implicit_fb_match playback_implicit_fb_quirks[] = { static const struct snd_usb_implicit_fb_match capture_implicit_fb_quirks[] = { IMPLICIT_FB_FIXED_DEV(0x0582, 0x0130, 0x0d, 0x01), /* BOSS BR-80 */ IMPLICIT_FB_FIXED_DEV(0x0582, 0x0171, 0x0d, 0x01), /* BOSS RC-505 */ + IMPLICIT_FB_FIXED_DEV(0x0582, 0x0185, 0x0d, 0x01), /* BOSS GP-10 */ IMPLICIT_FB_FIXED_DEV(0x0582, 0x0189, 0x0d, 0x01), /* BOSS GT-100v2 */ IMPLICIT_FB_FIXED_DEV(0x0582, 0x01d6, 0x0d, 0x01), /* BOSS GT-1 */ IMPLICIT_FB_FIXED_DEV(0x0582, 0x01d8, 0x0d, 0x01), /* BOSS Katana */ -- 2.26.2

1 0

[PATCH v3 2/3] x86/platform/dell-privacy-wmi: add document for dell privacy driver
by Perry Yuan 14 Feb '21

14 Feb '21

From: Perry Yuan <perry_yuan(a)dell.com> Describe the Dell Privacy feature capabilities and devices state class exposed by BIOS Signed-off-by: Perry Yuan <perry_yuan(a)dell.com> --- .../testing/sysfs-platform-dell-privacy-wmi | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi new file mode 100644 index 000000000000..3dbc2d25b60e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi @@ -0,0 +1,31 @@ +What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/devices_supported +Date: Jan 2021 +KernelVersion: 5.11 +Contact: "perry_yuan(a)dell.com>" +Description: + Display which dell hardware level privacy devices are supported + “Dell Privacy” is a set of HW, FW, and SW features to enhance + Dell’s commitment to platform privacy for MIC, Camera, and + ePrivacy screens. + The supported privacy haredware privacy devices are: + * 0x0 - None, + * 0x1 - Microphone, + * 0x2 - Camera, + * 0x4 - ePrivacy Screen + +What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/current_state +Date: Jan 2021 +KernelVersion: 5.11 +Contact: "perry_yuan(a)dell.com>" +Description: + Allow user space to check current dell privacy device state. + Describes the Device State class exposed by BIOS which can be + consumed by various applications interested in knowing the Privacy + feature capabilities + There are three Bits for available states: + * 0 -> Off + * 1 -> On + * Bit0 -> Microphone + * Bit1 -> Camera + * Bit2 -> ePrivacyScreen + -- 2.25.1

3 3

mixer controls not updating when changed in another process for ASoC aux devices
by Matt Campbell 13 Feb '21

13 Feb '21

I am using the snd-soc-simple-card driver to glue together a DAI, Codec, and a few aux devices that have custom drivers for pre-amp control. When I have two instances of alsamixer open and change the output control (a control that is part of the main Codec driver) that change immediately shows in the second instance of alsamixer. However, when changing any of the controls that come from an aux device, these changes do not show up in the second instance. Exiting and re-launching the second alsamixer will then show the changes. I would expect these controls to behave the same as the main codec master output level with immediate update in all instances. I'm speculating that the aux devices might be treated differently in a way that is causing the unexpected behavior. I haven't been able to identify anything through a few hours of code inspection, but I'm far from an expert on the internals of ASoC. I'm hoping someone on this list might be able to confirm or deny that suspicion and possibly help me get to the bottom of this. A few other possibly relevant details: * This happens both with snd-soc-simple-driver and a different custom in-house platform driver that uses aux devs. * I am on an older version of the kernel (4.14.2). I scanned logs between the head of master and that version for ASoC changes and nothing popped out to me as relevant. * The aux dev causing this is an in-house driver for the THAT 5xx3 series of pre-amplifier controller that we intend to upstream. I'm happy to share code from that if it helps. Best, ~Matt -- Matthew Campbell Principal Engineer mcampbell(a)izotope.com iZotope, Inc. www.izotope.com

1 0