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

[PATCH] cfg80211: Fix "suspicious RCU usage in wiphy_apply_custom_regulatory" warning/backtrace
by Hans de Goede 19 Jan '21

19 Jan '21

Commit beee24695157 ("cfg80211: Save the regulatory domain when setting custom regulatory") adds a get_wiphy_regdom call to wiphy_apply_custom_regulatory. But as the comment above wiphy_apply_custom_regulatory says: "/* Used by drivers prior to wiphy registration */" this function is used by driver's probe function before the wiphy is registered and at this point wiphy->regd will typically by NULL and calling rcu_dereference_rtnl on a NULL pointer causes the following warning/backtrace: ============================= WARNING: suspicious RCU usage 5.11.0-rc1+ #19 Tainted: G W ----------------------------- net/wireless/reg.c:144 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by kworker/2:0/22: #0: ffff9a4bc104df38 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1ee/0x570 #1: ffffb6e94010be78 ((work_completion)(&fw_work->work)){+.+.}-{0:0}, at: process_one_work+0x1ee/0x570 stack backtrace: CPU: 2 PID: 22 Comm: kworker/2:0 Tainted: G W 5.11.0-rc1+ #19 Hardware name: LENOVO 60073/INVALID, BIOS 01WT17WW 08/01/2014 Workqueue: events request_firmware_work_func Call Trace: dump_stack+0x8b/0xb0 get_wiphy_regdom+0x57/0x60 [cfg80211] wiphy_apply_custom_regulatory+0xa0/0xf0 [cfg80211] brcmf_cfg80211_attach+0xb02/0x1360 [brcmfmac] brcmf_attach+0x189/0x460 [brcmfmac] brcmf_sdio_firmware_callback+0x78a/0x8f0 [brcmfmac] brcmf_fw_request_done+0x67/0xf0 [brcmfmac] request_firmware_work_func+0x3d/0x70 process_one_work+0x26e/0x570 worker_thread+0x55/0x3c0 ? process_one_work+0x570/0x570 kthread+0x137/0x150 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 Add a check for wiphy->regd being NULL before calling get_wiphy_regdom (as is already done in other places) to fix this. wiphy->regd will likely always be NULL when wiphy_apply_custom_regulatory gets called, so arguably the tmp = get_wiphy_regdom() and rcu_free_regdom(tmp) calls should simply be dropped, this patch keeps the 2 calls, to allow drivers to call wiphy_apply_custom_regulatory more then once if necessary. Cc: Ilan Peer <ilan.peer(a)intel.com> Fixes: beee24695157 ("cfg80211: Save the regulatory domain when setting custom regulator") Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- net/wireless/reg.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index bb72447ad960..9254b9cbaa21 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -2547,7 +2547,7 @@ static void handle_band_custom(struct wiphy *wiphy, void wiphy_apply_custom_regulatory(struct wiphy *wiphy, const struct ieee80211_regdomain *regd) { - const struct ieee80211_regdomain *new_regd, *tmp; + const struct ieee80211_regdomain *new_regd, *tmp = NULL; enum nl80211_band band; unsigned int bands_set = 0; @@ -2571,7 +2571,8 @@ void wiphy_apply_custom_regulatory(struct wiphy *wiphy, if (IS_ERR(new_regd)) return; - tmp = get_wiphy_regdom(wiphy); + if (wiphy->regd) + tmp = get_wiphy_regdom(wiphy); rcu_assign_pointer(wiphy->regd, new_regd); rcu_free_regdom(tmp); } -- 2.28.0

2 4

[PATCH 0/5] soundwire: fix ACK/NAK handling and improve log
by Bard Liao 19 Jan '21

19 Jan '21

The existing code reports a NAK only when ACK=0 This is not aligned with the SoundWire 1.x specifications. Table 32 in the SoundWire 1.2 specification shows that a Device shall not set NAK=1 if ACK=1. But Table 33 shows the Combined Response may very well be NAK=1/ACK=1, e.g. if another Device than the one addressed reports a parity error. NAK=1 signals a 'Command_Aborted', regardless of the ACK bit value. Move the tests for NAK so that the NAK=1/ACK=1 combination is properly detected according to the specification. Also, improve the demesg log to get more information for debugging. Bard Liao (1): soundwire: bus: add more details to track failed transfers Pierre-Louis Bossart (4): soundwire: use consistent format for Slave devID logs soundwire: cadence: add status in dev_dbg 'State change' log soundwire: cadence: fix ACK/NAK handling soundwire: cadence: adjust verbosity in response handling drivers/soundwire/bus.c | 11 ++++++----- drivers/soundwire/cadence_master.c | 29 +++++++++++++++-------------- drivers/soundwire/slave.c | 10 ++++------ 3 files changed, 25 insertions(+), 25 deletions(-) -- 2.17.1

2 6

[PATCH] MAINTAINERS: soundwire: Add soundwire tree
by Vinod Koul 19 Jan '21

19 Jan '21

Somehow the soundwire MAINTAINERS did not have the tree details, so add it. Signed-off-by: Vinod Koul <vkoul(a)kernel.org> --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 546aa66428c9..10b234688f22 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16654,6 +16654,7 @@ R: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> R: Sanyog Kale <sanyog.r.kale(a)intel.com> L: alsa-devel(a)alsa-project.org (moderated for non-subscribers) S: Supported +T: git git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git F: Documentation/driver-api/soundwire/ F: drivers/soundwire/ F: include/linux/soundwire/ -- 2.26.2

1 1

[PATCH] soundwire: sysfs: Constiyf static struct attribute_group
by Rikard Falkeborn 19 Jan '21

19 Jan '21

The only place sdw_slave_dev_attr_group is used is when its address is passed to devm_device_add_group() which takes a pointer to const struct attribute_group. Make it const to allow the compiler to put it in read-only memory. This makes all attribute_group structs in the file const. Done with the help of Coccinelle. Signed-off-by: Rikard Falkeborn <rikard.falkeborn(a)gmail.com> --- drivers/soundwire/sysfs_slave.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soundwire/sysfs_slave.c b/drivers/soundwire/sysfs_slave.c index b48b6617a396..3210359cd944 100644 --- a/drivers/soundwire/sysfs_slave.c +++ b/drivers/soundwire/sysfs_slave.c @@ -130,7 +130,7 @@ static struct attribute *slave_dev_attrs[] = { * we don't use ATTRIBUTES_GROUP here since we want to add a subdirectory * for device-level properties */ -static struct attribute_group sdw_slave_dev_attr_group = { +static const struct attribute_group sdw_slave_dev_attr_group = { .attrs = slave_dev_attrs, .name = "dev-properties", }; -- 2.30.0

2 2

[PATCH 0/2] ASoC/SoundWire: fix timeout values
by Bard Liao 19 Jan '21

19 Jan '21

The timeout for an individual transaction w/ the Cadence IP is the same as the entire resume operation for codecs. This doesn't make sense, we need to have at least one order of magnitude between individual transactions and the entire resume operation. Set the timeout on the Cadence side to 500ms and 5s for the codec resume. Both ASoC and SoundWire trees are fine for this series. Pierre-Louis Bossart (2): ASoC: codecs: soundwire: increase resume timeout soundwire: cadence: reduce timeout on transactions drivers/soundwire/cadence_master.c | 2 +- sound/soc/codecs/max98373-sdw.c | 4 +++- sound/soc/codecs/rt1308-sdw.c | 2 +- sound/soc/codecs/rt5682.h | 2 +- sound/soc/codecs/rt700-sdw.c | 2 +- sound/soc/codecs/rt711-sdw.c | 2 +- sound/soc/codecs/rt715-sdw.c | 2 +- 7 files changed, 9 insertions(+), 7 deletions(-) -- 2.17.1

3 4

[PATCH] soundwire: intel: don't return error when clock stop failed
by Bard Liao 19 Jan '21

19 Jan '21

dev->power.runtime_error will be set to the return value of the runtime suspend callback function, and runtime resume function will return -EINVAL if dev->power.runtime_error is not 0. Somehow the codec rarely doesn't return an ACK to the clock prepare command. If we stop the runtime suspend process and return error, we will not be able to resume again. Likewise, if the codec lost sync and did not rejoin, the resume operation will also fail. As a result, the SoundWire bus can not be used anymore. This patch suggests to finish the runtime suspend process even if we fail to stop sdw bus clock. In the case where we do a hardware reset, the codecs will be reconfigured completely. In the case where we use the regular clock stop, the codecs keep their state and worst case will fall off the bus and reattach. The only drawback is that the power consumption may be higher and device-initiated interrupts may be lost, but at least audio function can still work after resume. Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- drivers/soundwire/intel.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index 10b60b7b17bb..a2d5cdaa9998 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -1673,10 +1673,12 @@ static int __maybe_unused intel_suspend_runtime(struct device *dev) } else if (clock_stop_quirks & SDW_INTEL_CLK_STOP_BUS_RESET || !clock_stop_quirks) { + bool wake_enable = true; + ret = sdw_cdns_clock_stop(cdns, true); if (ret < 0) { dev_err(dev, "cannot enable clock stop on suspend\n"); - return ret; + wake_enable = false; } ret = sdw_cdns_enable_interrupt(cdns, false); @@ -1691,7 +1693,7 @@ static int __maybe_unused intel_suspend_runtime(struct device *dev) return ret; } - intel_shim_wake(sdw, true); + intel_shim_wake(sdw, wake_enable); } else { dev_err(dev, "%s clock_stop_quirks %x unsupported\n", __func__, clock_stop_quirks); -- 2.17.1

2 1

[PATCH] ASoC: rt5682: remove LDO2 power supply widget
by shumingf＠realtek.com 19 Jan '21

19 Jan '21

From: Shuming Fan <shumingf(a)realtek.com> The application circuit shall provide MICVDD power. Hence, the codec driver doesn't need to enable LDO2. This patch also reduces power consumption while the recording from the headset. Signed-off-by: Shuming Fan <shumingf(a)realtek.com> --- sound/soc/codecs/rt5682.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/sound/soc/codecs/rt5682.c b/sound/soc/codecs/rt5682.c index 42ad5bea86b5..81a4b115b538 100644 --- a/sound/soc/codecs/rt5682.c +++ b/sound/soc/codecs/rt5682.c @@ -1630,8 +1630,6 @@ static const struct snd_kcontrol_new rt5682_adcdat_pin_ctrl = SOC_DAPM_ENUM("ADCDAT", rt5682_adcdat_pin_enum); static const struct snd_soc_dapm_widget rt5682_dapm_widgets[] = { - SND_SOC_DAPM_SUPPLY("LDO2", RT5682_PWR_ANLG_3, RT5682_PWR_LDO2_BIT, - 0, NULL, 0), SND_SOC_DAPM_SUPPLY("PLL1", RT5682_PWR_ANLG_3, RT5682_PWR_PLL_BIT, 0, NULL, 0), SND_SOC_DAPM_SUPPLY("PLL2B", RT5682_PWR_ANLG_3, RT5682_PWR_PLL2B_BIT, @@ -1854,8 +1852,6 @@ static const struct snd_soc_dapm_route rt5682_dapm_routes[] = { {"CLKDET SYS", NULL, "CLKDET"}, - {"IN1P", NULL, "LDO2"}, - {"BST1 CBJ", NULL, "IN1P"}, {"RECMIX1L", "CBJ Switch", "BST1 CBJ"}, -- 2.29.0

2 1

snd_pcm_extplug_callback_t transfer callback and buffering
by Arsen Arsenović 18 Jan '21

18 Jan '21

Hello! I am writing an external noise cancellation plugin for ALSA, based on rnnoise, but I've hit a bit of a roadblock: rnnoise processes chunks of 480 floats at a time and does no buffering, but alsa expects the transfer callback to take all the data from the input and put it onto the output, with no way to signal that any buffering is or should be happening. I have tried to return a multiple of 480 from the transfer callback and keep a buffer with the leftover data, to be prepended to the next payload, but it looks like ALSA will, when a plugin returns too little data, just send back the same non-processed data in a new call, which breaks this idea. Any way I can work around these limitations? Another solution could be for external plugins to report the amount they consumed and output, rather than a single number for both, but I am not aware of how to do that. -- Arsen Arsenović

1 0

[GIT PULL] ASoC fixes for v5.11-rc4
by Mark Brown 18 Jan '21

18 Jan '21

The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-fix-v5.11-rc4 for you to fetch changes up to 7505c06dabb5e814bda610c8d83338544f15db45: MAINTAINERS: update qcom ASoC drivers list (2021-01-15 17:25:35 +0000) ---------------------------------------------------------------- ASoC: Fixes for v5.11 A few more fixes for v5.11, mostly around HDA jack detection, plus a couple of updates to the MAINTAINERS entries. ---------------------------------------------------------------- Kai Vehmanen (1): ASoC: SOF: Intel: fix page fault at probe if i915 init fails Kai-Heng Feng (3): ASoC: SOF: Intel: hda: Resume codec to do jack detection ASoC: SOF: Intel: hda: Modify existing helper to disable WAKEEN ASoC: SOF: Intel: hda: Avoid checking jack on system suspend Mark Brown (1): Merge v5.11-rc3 Mauro Carvalho Chehab (1): MAINTAINERS: update references to stm32 audio bindings Srinivas Kandagatla (2): MAINTAINERS: update maintainers of qcom audio MAINTAINERS: update qcom ASoC drivers list Stephan Gerhold (1): ASoC: hdmi-codec: Fix return value in hdmi_codec_set_jack() .../bindings/sound/ti,j721e-cpb-audio.yaml | 4 +- .../bindings/sound/ti,j721e-cpb-ivi-audio.yaml | 4 +- MAINTAINERS | 18 +++++--- sound/soc/amd/raven/pci-acp3x.c | 16 ++----- sound/soc/amd/renoir/rn-pci-acp3x.c | 14 ++++++ sound/soc/atmel/Kconfig | 4 +- sound/soc/codecs/Kconfig | 2 +- sound/soc/codecs/hdmi-codec.c | 2 +- sound/soc/codecs/max98373-i2c.c | 20 +++++++++ sound/soc/codecs/max98373-sdw.c | 20 +++++++++ sound/soc/codecs/max98373.c | 34 +++++++++++++-- sound/soc/codecs/max98373.h | 8 ++++ sound/soc/codecs/rt711.c | 6 +++ sound/soc/fsl/imx-hdmi.c | 3 +- sound/soc/intel/boards/haswell.c | 1 + sound/soc/intel/skylake/cnl-sst.c | 1 + sound/soc/meson/axg-tdm-interface.c | 14 +++++- sound/soc/meson/axg-tdmin.c | 13 +----- sound/soc/qcom/lpass-cpu.c | 20 +-------- sound/soc/qcom/lpass-platform.c | 50 +++++++++++++++------- sound/soc/sh/rcar/adg.c | 18 ++++---- sound/soc/soc-dapm.c | 1 + sound/soc/sof/Kconfig | 2 +- sound/soc/sof/intel/hda-codec.c | 37 ++++++++-------- sound/soc/sof/intel/hda-dsp.c | 9 ++-- sound/soc/sof/intel/hda.h | 2 +- 26 files changed, 217 insertions(+), 106 deletions(-)

2 1

[PATCH] ALSA: hda: Balance runtime/system PM if direct-complete is disabled
by Kai-Heng Feng 18 Jan '21

18 Jan '21

HDA controller can't be runtime-suspended after commit 215a22ed31a1 ("ALSA: hda: Refactor codjc PM to use direct-complete optimization"), which enables direct-complete for HDA codec. The HDA codec driver didn't expect direct-complete will be disabled after it returns a positive value from prepare() callback. However, there are some places that PM core can disable direct-complete. For instance, system hibernation or when codec has subordinates like LEDs. So if a device is prepared for direct-complete but PM core still calls codec's suspend or freeze callback, resume the device to keep PM operations balanced. Reported-by: Kenneth R. Crudup <kenny(a)panix.com> Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization") Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- sound/pci/hda/hda_codec.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 687216e74526..0afbced979df 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -2997,6 +2997,9 @@ static void hda_codec_pm_complete(struct device *dev) static int hda_codec_pm_suspend(struct device *dev) { + if (pm_runtime_status_suspended(dev)) + pm_runtime_resume(dev); + dev->power.power_state = PMSG_SUSPEND; return hda_codec_suspend(dev); } @@ -3009,6 +3012,9 @@ static int hda_codec_pm_resume(struct device *dev) static int hda_codec_pm_freeze(struct device *dev) { + if (pm_runtime_status_suspended(dev)) + pm_runtime_resume(dev); + dev->power.power_state = PMSG_FREEZE; return hda_codec_suspend(dev); } -- 2.29.2

2 2