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

Re: [PATCH v8 1/2] ASoC: sunxi: Add Allwinner H6 Digital MIC driver
by 班涛 23 Aug '22

23 Aug '22

Amadeusz Sławiński <amadeuszx.slawinski(a)linux.intel.com> 于2022年8月12日周五 23:20写道： > On 8/11/2022 4:49 PM, Ban Tao wrote: > > The Allwinner H6 and later SoCs have an DMIC block > > which is capable of capture. > > > > Signed-off-by: Ban Tao <fengzheng923(a)gmail.com> > > --- > > ... > > > + > > +#define SUN50I_DMIC_RATES (SNDRV_PCM_RATE_8000_48000) > > Seeing supported rates in hw_params callback, you probably want to take > a look at SNDRV_PCM_RATE_KNOT? > No, I don't need SNDRV_PCM_RATE_KNOT. Dmic does not support unknown rates. > > > +#define SUN50I_DMIC_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | > SNDRV_PCM_FMTBIT_S24_LE) > > + > > +static struct snd_soc_dai_driver sun50i_dmic_dai = { > > + .capture = { > > + .channels_min = 1, > > + .channels_max = 8, > > + .rates = SUN50I_DMIC_RATES, > > + .formats = SUN50I_DMIC_FORMATS, > > + .sig_bits = 21, > > + }, > > + .probe = sun50i_dmic_soc_dai_probe, > > + .ops = &sun50i_dmic_dai_ops, > > + .name = "dmic", > > +}; > > + > > ... > >

1 0

[PATCH] ALSA: hda: intel-nhlt: Correct the handling of fmt_config flexible array
by Peter Ujfalusi 23 Aug '22

23 Aug '22

The struct nhlt_format's fmt_config is a flexible array, it must not be used as normal array. When moving to the next nhlt_fmt_cfg we need to take into account the data behind the ->config.caps (indicated by ->config.size). Fixes: a864e8f159b13 ("ALSA: hda: intel-nhlt: verify config type") Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Jaska Uimonen <jaska.uimonen(a)linux.intel.com> --- sound/hda/intel-nhlt.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/hda/intel-nhlt.c b/sound/hda/intel-nhlt.c index 9db5ccd9aa2d..13bb0ccfb36c 100644 --- a/sound/hda/intel-nhlt.c +++ b/sound/hda/intel-nhlt.c @@ -55,16 +55,22 @@ int intel_nhlt_get_dmic_geo(struct device *dev, struct nhlt_acpi_table *nhlt) /* find max number of channels based on format_configuration */ if (fmt_configs->fmt_count) { + struct nhlt_fmt_cfg *fmt_cfg = fmt_configs->fmt_config; + dev_dbg(dev, "found %d format definitions\n", fmt_configs->fmt_count); for (i = 0; i < fmt_configs->fmt_count; i++) { struct wav_fmt_ext *fmt_ext; - fmt_ext = &fmt_configs->fmt_config[i].fmt_ext; + fmt_ext = &fmt_cfg->fmt_ext; if (fmt_ext->fmt.channels > max_ch) max_ch = fmt_ext->fmt.channels; + + /* Move to the next nhlt_fmt_cfg */ + fmt_cfg = (struct nhlt_fmt_cfg *)(fmt_cfg->config.caps + + fmt_cfg->config.size); } dev_dbg(dev, "max channels found %d\n", max_ch); } else { -- 2.37.2

2 1

data-race in snd_seq_oss_midi_check_exit_port / snd_seq_oss_midi_setup
by Abhishek Shah 23 Aug '22

23 Aug '22

Hi all, We found a race involving the *max_midi_devs* variable. We see an interleaving where the following check here <https://elixir.bootlin.com/linux/v5.18-rc5/source/sound/core/seq/oss/seq_os…> passes before the *snd_seq_oss_midi_check_exit_port*() finishes, but this check should not pass if *max_midi_devs* will become zero, but we are not sure of its implications in terms of security impact. Please let us know what you think. Thanks! *-------------------Report---------------------* *write* to 0xffffffff88382f80 of 4 bytes by task 6541 on cpu 0: snd_seq_oss_midi_check_exit_port+0x1a6/0x270 sound/core/seq/oss/seq_oss_midi.c:237 receive_announce+0x193/0x1b0 sound/core/seq/oss/seq_oss_init.c:143 snd_seq_deliver_single_event+0x30d/0x4e0 sound/core/seq/seq_clientmgr.c:640 deliver_to_subscribers sound/core/seq/seq_clientmgr.c:695 [inline] snd_seq_deliver_event+0x38c/0x490 sound/core/seq/seq_clientmgr.c:830 snd_seq_kernel_client_dispatch+0x189/0x1a0 sound/core/seq/seq_clientmgr.c:2339 snd_seq_system_broadcast+0x98/0xd0 sound/core/seq/seq_system.c:86 snd_seq_ioctl_delete_port+0x9a/0xc0 sound/core/seq/seq_clientmgr.c:1356 snd_seq_ioctl+0x198/0x2d0 sound/core/seq/seq_clientmgr.c:2173 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xe1/0x150 fs/ioctl.c:856 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae *read* to 0xffffffff88382f80 of 4 bytes by task 6542 on cpu 1: snd_seq_oss_midi_setup+0x1b/0x40 sound/core/seq/oss/seq_oss_midi.c:273 snd_seq_oss_open+0x364/0x900 sound/core/seq/oss/seq_oss_init.c:198 odev_open+0x55/0x70 sound/core/seq/oss/seq_oss.c:128 soundcore_open+0x315/0x3a0 sound/sound_core.c:593 chrdev_open+0x373/0x3f0 fs/char_dev.c:414 do_dentry_open+0x543/0x8f0 fs/open.c:824 vfs_open+0x47/0x50 fs/open.c:958 do_open fs/namei.c:3476 [inline] path_openat+0x1906/0x1dc0 fs/namei.c:3609 do_filp_open+0xef/0x200 fs/namei.c:3636 do_sys_openat2+0xa5/0x2a0 fs/open.c:1213 do_sys_open fs/open.c:1229 [inline] __do_sys_openat fs/open.c:1245 [inline] __se_sys_openat fs/open.c:1240 [inline] __x64_sys_openat+0xf0/0x120 fs/open.c:1240 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 6542 Comm: syz-executor2-n Not tainted 5.18.0-rc5+ #107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 *Reproducing Inputs* Input CPU 0: r0 = openat$sndseq(0xffffffffffffff9c, &(0x7f0000000040)='/dev/snd/seq\x00', 0x0) ioctl$SNDRV_SEQ_IOCTL_CREATE_PORT(r0, 0xc0a85320, &(0x7f0000000240)={{0x80}, 'port1\x00', 0x10}) ioctl$SNDRV_SEQ_IOCTL_SET_CLIENT_POOL(r0, 0x40a85321, &(0x7f0000000100)={0x80}) Input CPU 1: r0 = openat$sequencer2(0xffffff9c, &(0x7f0000000000)='/dev/sequencer2\x00', 0x0, 0x0) ioctl$SNDCTL_SYNTH_INFO(r0, 0xc08c5102, &(0x7f0000000200)={"02961a3ce6d4828f8b5559726313251b55fa11d8d65406f1f33c9af8e3f8", 0xffffffff})

3 4

[PATCH 0/5] ALSA: Drop hackish GFP giveaway for CONTINUOUS pages
by Takashi Iwai 23 Aug '22

23 Aug '22

Hi, this is a series of cleanup patches for dropping the current hackish way of passing the GFP_* flags for CONTINOUS and VMALLOC memory allocations. There are only three users for this legacy feature, and all of them seem superfluous. And, if any driver requires the memory restriction in future, it can now pass the proper device pointer for specifying the DMA mask. Takashi === Takashi Iwai (5): ALSA: vx: Drop superfluous GFP setup ALSA: pdaudiocf: Drop superfluous GFP setup ASoC: Intel: sst: Switch to standard device pages ALSA: memalloc: Drop special handling of GFP for CONTINUOUS allocation ALSA: doc: Drop snd_dma_continuous_data() usages .../kernel-api/writing-an-alsa-driver.rst | 21 ++-- include/sound/memalloc.h | 3 - sound/core/memalloc.c | 113 ++++++++---------- sound/drivers/vx/vx_pcm.c | 3 +- sound/pcmcia/pdaudiocf/pdaudiocf_pcm.c | 3 +- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 7 +- 6 files changed, 61 insertions(+), 89 deletions(-) -- 2.35.3

2 6

[PATCH v2 0/4] ASoC platform driver for Apple MCA
by Martin Povišer 23 Aug '22

23 Aug '22

Hi all, this is v2 of the ASoC platform driver for MCA peripheral on Apple M1, to be followed by a machine driver later for sound support on the new Apple devices. This time I attached a DTS patch for t8103 (M1), which I guess should go through Marcan's (in CC) tree. Martin Changes since v1: - reflect the set_fmt provider/consumer change in 6.0-rc1 - fix the probe function requesting optional reset - unroll 'dma-names' in schema - fix binding schema/code discrepancy in register ranges - minor things Changes since 'macaudio RFC v2' [0]: - addition of locking (extra commit) - transition to set_bclk_ratio (instead of getting the bclk ratio from set_sysclk) - using shared reset control and documenting the reset in binding - formatting, comments, and a minor fix to hw driving [0] https://lore.kernel.org/asahi/20220606191910.16580-1-povik+lin@cutebit.org/ Martin Povišer (4): dt-bindings: sound: Add Apple MCA I2S transceiver arm64: dts: apple: t8103: Add MCA and its support ASoC: apple: mca: Start new platform driver ASoC: apple: mca: Add locks on foreign cluster access .../devicetree/bindings/sound/apple,mca.yaml | 131 ++ MAINTAINERS | 8 + arch/arm64/boot/dts/apple/t8103.dtsi | 70 + sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/apple/Kconfig | 9 + sound/soc/apple/Makefile | 3 + sound/soc/apple/mca.c | 1170 +++++++++++++++++ 8 files changed, 1393 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/apple,mca.yaml create mode 100644 sound/soc/apple/Kconfig create mode 100644 sound/soc/apple/Makefile create mode 100644 sound/soc/apple/mca.c -- 2.33.0

4 19

DSD hardware quirks and usb vendor id hardcoding
by GitHub issues - opened 23 Aug '22

23 Aug '22

alsa-project/alsa-lib issue #266 was opened from soholt: I am using tinyusb for UAC2 audio class and line 492 https://github.com/hathach/tinyusb/blob/master/src/class/audio/audio.h allows: "AUDIO_DATA_FORMAT_TYPE_I_RAW_DATA = 0x80000000" cat /proc/asound/ reports it as "Format: SPECIAL", but I wanted to be "SPECIAL DSD_U32_xx", so for fun I tried: 0x80000001 which reported as = S32_LE SPECIAL, 0x80000002 = U8 SPECIAL, 0x80000003 = U8 S32_LE SPECIAL 0x800000ff = U8 S32_LE FLOAT_LE MU_LAW A_LAW SPECIAL - seem to recursively add more Then I found quirks line 1582 https://github.com/torvalds/linux/blob/master/sound/usb/quirks.c "The UAC standards don't have a designated bit field to denote DSD-capable interfaces, hence all hardware that is known to support this format has to be listed here." So if I change my usb vendor id to XMOS 0x20b1, only then "Format: SPECIAL" becomes "Format: SPECIAL DSD_U32_BE" I have no idea if range 0x80000001++ is used for anything or if it could be used for DSD formats like: 0x80000001 = SPECIAL DSD_U8 0x80000002 = SPECIAL DSD_U16_LE 0x80000003 = SPECIAL DSD_U16_BE 0x80000004 = SPECIAL DSD_U32_LE 0x80000005 = SPECIAL DSD_U32_BE so no future hardcoding is required. Thanks, Gin Issue URL : https://github.com/alsa-project/alsa-lib/issues/266 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ALSA: hda: cleanup definitions for multi-link registers
by Pierre-Louis Bossart 23 Aug '22

23 Aug '22

For some reason two masks are used without the AZX prefix, and the pattern MLCLT should be ML_LCTL for consistency. Pure rename, no functionality change. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)intel.com> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- include/sound/hda_register.h | 20 +++++++++++--------- sound/hda/ext/hdac_ext_controller.c | 16 ++++++++-------- sound/pci/hda/hda_intel.c | 14 +++++++------- 3 files changed, 26 insertions(+), 24 deletions(-) diff --git a/include/sound/hda_register.h b/include/sound/hda_register.h index ad8b71b1dbb67..d37cf43546eba 100644 --- a/include/sound/hda_register.h +++ b/include/sound/hda_register.h @@ -260,7 +260,18 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO1, SDO2, SDO3 }; #define AZX_REG_ML_LCAP 0x00 #define AZX_REG_ML_LCTL 0x04 + +#define AZX_ML_LCTL_CPA BIT(23) +#define AZX_ML_LCTL_CPA_SHIFT 23 +#define AZX_ML_LCTL_SPA BIT(16) +#define AZX_ML_LCTL_SPA_SHIFT 16 +#define AZX_ML_LCTL_SCF GENMASK(3, 0) + #define AZX_REG_ML_LOSIDV 0x08 + +/* bit0 is reserved, with BIT(1) mapping to stream1 */ +#define AZX_ML_LOSIDV_STREAM_MASK 0xFFFE + #define AZX_REG_ML_LSDIID 0x0C #define AZX_REG_ML_LPSOO 0x10 #define AZX_REG_ML_LPSIO 0x12 @@ -268,15 +279,6 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO1, SDO2, SDO3 }; #define AZX_REG_ML_LOUTPAY 0x20 #define AZX_REG_ML_LINPAY 0x30 -/* bit0 is reserved, with BIT(1) mapping to stream1 */ -#define ML_LOSIDV_STREAM_MASK 0xFFFE - -#define ML_LCTL_SCF_MASK 0xF -#define AZX_MLCTL_SPA (0x1 << 16) -#define AZX_MLCTL_CPA (0x1 << 23) -#define AZX_MLCTL_SPA_SHIFT 16 -#define AZX_MLCTL_CPA_SHIFT 23 - /* registers for DMA Resume Capability Structure */ #define AZX_DRSM_CAP_ID 0x5 #define AZX_REG_DRSM_CTL 0x4 diff --git a/sound/hda/ext/hdac_ext_controller.c b/sound/hda/ext/hdac_ext_controller.c index a42f66f561f57..80876b9a87f46 100644 --- a/sound/hda/ext/hdac_ext_controller.c +++ b/sound/hda/ext/hdac_ext_controller.c @@ -170,7 +170,7 @@ static int check_hdac_link_power_active(struct hdac_ext_link *link, bool enable) { int timeout; u32 val; - int mask = (1 << AZX_MLCTL_CPA_SHIFT); + int mask = (1 << AZX_ML_LCTL_CPA_SHIFT); udelay(3); timeout = 150; @@ -178,10 +178,10 @@ static int check_hdac_link_power_active(struct hdac_ext_link *link, bool enable) do { val = readl(link->ml_addr + AZX_REG_ML_LCTL); if (enable) { - if (((val & mask) >> AZX_MLCTL_CPA_SHIFT)) + if (((val & mask) >> AZX_ML_LCTL_CPA_SHIFT)) return 0; } else { - if (!((val & mask) >> AZX_MLCTL_CPA_SHIFT)) + if (!((val & mask) >> AZX_ML_LCTL_CPA_SHIFT)) return 0; } udelay(3); @@ -197,7 +197,7 @@ static int check_hdac_link_power_active(struct hdac_ext_link *link, bool enable) int snd_hdac_ext_bus_link_power_up(struct hdac_ext_link *link) { snd_hdac_updatel(link->ml_addr, AZX_REG_ML_LCTL, - AZX_MLCTL_SPA, AZX_MLCTL_SPA); + AZX_ML_LCTL_SPA, AZX_ML_LCTL_SPA); return check_hdac_link_power_active(link, true); } @@ -209,7 +209,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_link_power_up); */ int snd_hdac_ext_bus_link_power_down(struct hdac_ext_link *link) { - snd_hdac_updatel(link->ml_addr, AZX_REG_ML_LCTL, AZX_MLCTL_SPA, 0); + snd_hdac_updatel(link->ml_addr, AZX_REG_ML_LCTL, AZX_ML_LCTL_SPA, 0); return check_hdac_link_power_active(link, false); } @@ -226,7 +226,7 @@ int snd_hdac_ext_bus_link_power_up_all(struct hdac_bus *bus) list_for_each_entry(hlink, &bus->hlink_list, list) { snd_hdac_updatel(hlink->ml_addr, AZX_REG_ML_LCTL, - AZX_MLCTL_SPA, AZX_MLCTL_SPA); + AZX_ML_LCTL_SPA, AZX_ML_LCTL_SPA); ret = check_hdac_link_power_active(hlink, true); if (ret < 0) return ret; @@ -247,7 +247,7 @@ int snd_hdac_ext_bus_link_power_down_all(struct hdac_bus *bus) list_for_each_entry(hlink, &bus->hlink_list, list) { snd_hdac_updatel(hlink->ml_addr, AZX_REG_ML_LCTL, - AZX_MLCTL_SPA, 0); + AZX_ML_LCTL_SPA, 0); ret = check_hdac_link_power_active(hlink, false); if (ret < 0) return ret; @@ -281,7 +281,7 @@ int snd_hdac_ext_bus_link_get(struct hdac_bus *bus, * clear the register to invalidate all the output streams */ snd_hdac_updatew(link->ml_addr, AZX_REG_ML_LOSIDV, - ML_LOSIDV_STREAM_MASK, 0); + AZX_ML_LOSIDV_STREAM_MASK, 0); /* * wait for 521usec for codec to report status * HDA spec section 4.3 - Codec Discovery diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 7720978dc1326..bf9df9bc8f1bf 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -489,14 +489,14 @@ static int intel_ml_lctl_set_power(struct azx *chip, int state) * If other links are enabled for stream, they need similar fix */ val = readl(bus->mlcap + AZX_ML_BASE + AZX_REG_ML_LCTL); - val &= ~AZX_MLCTL_SPA; - val |= state << AZX_MLCTL_SPA_SHIFT; + val &= ~AZX_ML_LCTL_SPA; + val |= state << AZX_ML_LCTL_SPA_SHIFT; writel(val, bus->mlcap + AZX_ML_BASE + AZX_REG_ML_LCTL); /* wait for CPA */ timeout = 50; while (timeout) { if (((readl(bus->mlcap + AZX_ML_BASE + AZX_REG_ML_LCTL)) & - AZX_MLCTL_CPA) == (state << AZX_MLCTL_CPA_SHIFT)) + AZX_ML_LCTL_CPA) == (state << AZX_ML_LCTL_CPA_SHIFT)) return 0; timeout--; udelay(10); @@ -514,15 +514,15 @@ static void intel_init_lctl(struct azx *chip) /* 0. check lctl register value is correct or not */ val = readl(bus->mlcap + AZX_ML_BASE + AZX_REG_ML_LCTL); /* if SCF is already set, let's use it */ - if ((val & ML_LCTL_SCF_MASK) != 0) + if ((val & AZX_ML_LCTL_SCF) != 0) return; /* * Before operating on SPA, CPA must match SPA. * Any deviation may result in undefined behavior. */ - if (((val & AZX_MLCTL_SPA) >> AZX_MLCTL_SPA_SHIFT) != - ((val & AZX_MLCTL_CPA) >> AZX_MLCTL_CPA_SHIFT)) + if (((val & AZX_ML_LCTL_SPA) >> AZX_ML_LCTL_SPA_SHIFT) != + ((val & AZX_ML_LCTL_CPA) >> AZX_ML_LCTL_CPA_SHIFT)) return; /* 1. turn link down: set SPA to 0 and wait CPA to 0 */ @@ -532,7 +532,7 @@ static void intel_init_lctl(struct azx *chip) goto set_spa; /* 2. update SCF to select a properly audio clock*/ - val &= ~ML_LCTL_SCF_MASK; + val &= ~AZX_ML_LCTL_SCF; val |= intel_get_lctl_scf(chip); writel(val, bus->mlcap + AZX_ML_BASE + AZX_REG_ML_LCTL); -- 2.34.1

2 1

Adding Focusrite Scarlett 2i4 gen2
by GitHub pull_request - opened 23 Aug '22

23 Aug '22

alsa-project/alsa-ucm-conf pull request #203 was opened from PatrickLang: This cleans up the Focusrite Scarlett 2i4 Gen2 device a bit. This device is split into two stereo pairs for output, and has 2 mic/line/instrument inputs. There are no toggles or mixer controls exposed to Alsa. It has hardware switches for: - Headphones - can monitor line outputs 1+2 or 3+4 - Headphone input/playback mix - Monitor out (Line 1+2) - Each input has a level pot, and switches for pad and Z (line/inst) - There is 1 physical +48v switch Please let me know if any more info would be helpful. I have captured some more notes showing before/after state at https://gist.github.com/PatrickLang/79a3090eea6f2d640179457b5d428134#scarle… I'm planning to write a UCM2 profile for the more complicated Focusrite Scarlett 18i8 Gen2 next which has more inputs, but also multiple mix busses controllable through Alsa Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/203 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/203.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH] ASoC: codes: src4xxx: Avoid clang -Wsometimes-uninitialized in src4xxx_hw_params()
by Nathan Chancellor 23 Aug '22

23 Aug '22

Clang warns: sound/soc/codecs/src4xxx.c:280:3: error: variable 'd' is used uninitialized whenever switch default is taken [-Werror,-Wsometimes-uninitialized] default: ^~~~~~~ sound/soc/codecs/src4xxx.c:298:59: note: uninitialized use occurs here ret = regmap_write(src4xxx->regmap, SRC4XXX_RCV_PLL_11, d); ^ sound/soc/codecs/src4xxx.c:223:20: note: initialize the variable 'd' to silence this warning int val, pj, jd, d; ^ = 0 sound/soc/codecs/src4xxx.c:280:3: error: variable 'jd' is used uninitialized whenever switch default is taken [-Werror,-Wsometimes-uninitialized] default: ^~~~~~~ sound/soc/codecs/src4xxx.c:293:59: note: uninitialized use occurs here ret = regmap_write(src4xxx->regmap, SRC4XXX_RCV_PLL_10, jd); ^~ sound/soc/codecs/src4xxx.c:223:17: note: initialize the variable 'jd' to silence this warning int val, pj, jd, d; ^ = 0 sound/soc/codecs/src4xxx.c:280:3: error: variable 'pj' is used uninitialized whenever switch default is taken [-Werror,-Wsometimes-uninitialized] default: ^~~~~~~ sound/soc/codecs/src4xxx.c:288:59: note: uninitialized use occurs here ret = regmap_write(src4xxx->regmap, SRC4XXX_RCV_PLL_0F, pj); ^~ sound/soc/codecs/src4xxx.c:223:13: note: initialize the variable 'pj' to silence this warning int val, pj, jd, d; ^ = 0 3 errors generated. According to the comment in the default case, other parts of the chip are still functional without these values so just return 0 in the default case to avoid using these variables uninitialized. Link: https://github.com/ClangBuiltLinux/linux/issues/1691 Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: "Sudip Mukherjee (Codethink)" <sudipm.mukherjee(a)gmail.com> Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- sound/soc/codecs/src4xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/src4xxx.c b/sound/soc/codecs/src4xxx.c index a8f143057b41..cf45caa4bf7f 100644 --- a/sound/soc/codecs/src4xxx.c +++ b/sound/soc/codecs/src4xxx.c @@ -283,7 +283,7 @@ static int src4xxx_hw_params(struct snd_pcm_substream *substream, */ dev_info(component->dev, "Couldn't set the RCV PLL as this master clock rate is unknown\n"); - break; + return 0; } ret = regmap_write(src4xxx->regmap, SRC4XXX_RCV_PLL_0F, pj); if (ret < 0) base-commit: 94f072748337424c9cf92cd018532a34db3a5516 -- 2.37.2

2 3

Re: [PATCH/RESEND 2 v1] ASoC: trival spelling fix.
by Maurycy Z 22 Aug '22

22 Aug '22

"system" is mis-spelled as "ststem" in the help for SND_AUDIO_GRAPH_CARD. Acked-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Maurycy Zalewski <10maurycy10(a)gmail.com> --- diff --git a/sound/soc/generic/Kconfig b/sound/soc/generic/Kconfig index b6df4e26b..72f3446e1 100644 --- a/sound/soc/generic/Kconfig +++ b/sound/soc/generic/Kconfig @@ -16,7 +16,7 @@ config SND_AUDIO_GRAPH_CARD help This option enables generic simple sound card support with OF-graph DT bindings. - It also support DPCM of multi CPU single Codec ststem. + It also support DPCM of multi CPU single Codec system. config SND_AUDIO_GRAPH_CARD2 tristate "ASoC Audio Graph sound card2 support"

1 0