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

[PATCH v3 00/11] Introduce STM32 Firewall framework
by Gatien Chevallier 25 Sep '23

25 Sep '23

Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers register to the framework to offer firewall services such as access granting. This series of patches is a new approach on the previous STM32 system bus, history is available here: https://lore.kernel.org/lkml/20230127164040.1047583/ The need for such framework arises from the fact that there are now multiple hardware firewalls implemented across multiple products. Drivers are shared between different products, using the same code. When it comes to firewalls, the purpose mostly stays the same: Protect hardware resources. But the implementation differs, and there are multiple types of firewalls: peripheral, memory, ... Some hardware firewall controllers such as the RIFSC implemented on STM32MP2x platforms may require to take ownership of a resource before being able to use it, hence the requirement for firewall services to take/release the ownership of such resources. On the other hand, hardware firewall configurations are becoming more and more complex. These mecanisms prevent platform crashes or other firewall-related incoveniences by denying access to some resources. The stm32 firewall framework offers an API that is defined in firewall controllers drivers to best fit the specificity of each firewall. For every peripherals protected by either the ETZPC or the RIFSC, the firewall framework checks the firewall controlelr registers to see if the peripheral's access is granted to the Linux kernel. If not, the peripheral is configured as secure, the node is marked populated, so that the driver is not probed for that device. The firewall framework relies on the feature-domain-controller device tree bindings: https://lore.kernel.org/lkml/0c0a82bb-18ae-d057-562b. It is used by peripherals to reference a domain controller, in this case a firewall feature domain. The bus uses the ID referenced by the feature-domains property to know where to look in the firewall to get the security configuration for the peripheral. This allows a device tree description rather than a hardcoded peripheral table in the bus driver. The STM32 ETZPC device is responsible for filtering accesses based on security level, or co-processor isolation for any resource connected to it. The RIFSC is responsible for filtering accesses based on Compartment ID / security level / privilege level for any resource connected to it. STM32MP13/15/25 SoC device tree files are updated in this series to implement this mecanism. Changes in V2: generic: - Add fw_devlink dependency for "feature-domains" property. bindings: - Corrected YAMLS errors highlighted by Rob's robot - Firewall controllers YAMLs no longer define the maxItems for the "feature-domains" property - Renamed st,stm32-rifsc.yaml to st,stm32mp25-rifsc.yaml - Fix examples in YAML files - Change feature-domains maxItems to 2 in firewall consumer files as there should not be more than 2 entries for now - Declare "feature-domain-names" as an optional property for firewall controllers child nodes. - Add missing "feature-domains" property declaration in bosch,m_can.yaml and st,stm32-cryp.yaml files firewall framework: - Support multiple entries for "feature-domains" property - Better handle the device-tree parsing using phandle+args APIs - Remove "resource firewall" type - Add a field for the name of the firewall entry - Fix licenses RIFSC: - Add controller name - Driver is now a module_platform_driver - Fix license ETZPC: - Add controller name - Driver is now a module_platform_driver - Fix license Device trees: - Fix rifsc node name - Move the "ranges" property under the "feature-domains" one Changes in V3: Change incorrect ordering for bindings commits leading to an error while running "make DT_CHECKER_FLAGS=-m dt_binding_check" Oleksii Moisieiev (1): dt-bindings: Document common device controller bindings Gatien Chevallier (10): dt-bindings: treewide: add feature-domains description dt-bindings: bus: document RIFSC dt-bindings: bus: document ETZPC firewall: introduce stm32_firewall framework of: property: fw_devlink: Add support for "feature-domains" bus: rifsc: introduce RIFSC firewall controller driver arm64: dts: st: add RIFSC as a domain controller for STM32MP25x boards bus: etzpc: introduce ETZPC firewall controller driver ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards .../bindings/bus/st,stm32-etzpc.yaml | 96 + .../bindings/bus/st,stm32mp25-rifsc.yaml | 105 + .../bindings/crypto/st,stm32-cryp.yaml | 4 + .../bindings/crypto/st,stm32-hash.yaml | 4 + .../devicetree/bindings/dma/st,stm32-dma.yaml | 4 + .../bindings/dma/st,stm32-dmamux.yaml | 4 + .../feature-domain-controller.yaml | 84 + .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 4 + .../bindings/iio/adc/st,stm32-adc.yaml | 4 + .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 4 + .../bindings/iio/dac/st,stm32-dac.yaml | 4 + .../bindings/media/cec/st,stm32-cec.yaml | 4 + .../bindings/media/st,stm32-dcmi.yaml | 4 + .../memory-controllers/st,stm32-fmc2-ebi.yaml | 4 + .../bindings/mfd/st,stm32-lptimer.yaml | 4 + .../bindings/mfd/st,stm32-timers.yaml | 5 + .../devicetree/bindings/mmc/arm,pl18x.yaml | 4 + .../bindings/net/can/bosch,m_can.yaml | 4 + .../devicetree/bindings/net/stm32-dwmac.yaml | 4 + .../bindings/phy/phy-stm32-usbphyc.yaml | 4 + .../bindings/regulator/st,stm32-vrefbuf.yaml | 4 + .../devicetree/bindings/rng/st,stm32-rng.yaml | 4 + .../bindings/serial/st,stm32-uart.yaml | 4 + .../bindings/sound/st,stm32-i2s.yaml | 4 + .../bindings/sound/st,stm32-sai.yaml | 4 + .../bindings/sound/st,stm32-spdifrx.yaml | 4 + .../bindings/spi/st,stm32-qspi.yaml | 4 + .../devicetree/bindings/spi/st,stm32-spi.yaml | 4 + .../devicetree/bindings/usb/dwc2.yaml | 4 + MAINTAINERS | 7 + arch/arm/boot/dts/st/stm32mp131.dtsi | 1027 +++--- arch/arm/boot/dts/st/stm32mp133.dtsi | 51 +- arch/arm/boot/dts/st/stm32mp13xc.dtsi | 19 +- arch/arm/boot/dts/st/stm32mp13xf.dtsi | 19 +- arch/arm/boot/dts/st/stm32mp151.dtsi | 2757 +++++++++-------- arch/arm/boot/dts/st/stm32mp153.dtsi | 52 +- arch/arm/boot/dts/st/stm32mp15xc.dtsi | 19 +- arch/arm64/Kconfig.platforms | 1 + arch/arm64/boot/dts/st/stm32mp251.dtsi | 7 +- drivers/bus/Kconfig | 9 + drivers/bus/Makefile | 1 + drivers/bus/stm32_etzpc.c | 141 + drivers/bus/stm32_firewall.c | 288 ++ drivers/bus/stm32_firewall.h | 83 + drivers/bus/stm32_rifsc.c | 252 ++ drivers/of/property.c | 2 + include/linux/bus/stm32_firewall_device.h | 140 + 47 files changed, 3346 insertions(+), 1919 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml create mode 100644 Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml create mode 100644 Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml create mode 100644 drivers/bus/stm32_etzpc.c create mode 100644 drivers/bus/stm32_firewall.c create mode 100644 drivers/bus/stm32_firewall.h create mode 100644 drivers/bus/stm32_rifsc.c create mode 100644 include/linux/bus/stm32_firewall_device.h -- 2.25.1

4 17

[PATCH] ASoC: audio-iio-aux: Use flex array to simplify code
by Christophe JAILLET 25 Sep '23

25 Sep '23

"io-channel-names" is expected to have few values, so there is no real point to allocate audio_iio_aux_chan structure with a dedicate memory allocation. Using a flexible array for struct audio_iio_aux->chans avoids the overhead of an additional, managed, memory allocation. This also saves an indirection when the array is accessed. Finally, __counted_by() can be used for run-time bounds checking if configured and supported by the compiler. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- sound/soc/codecs/audio-iio-aux.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/sound/soc/codecs/audio-iio-aux.c b/sound/soc/codecs/audio-iio-aux.c index a8bf14239bd7..1e8e1effc2af 100644 --- a/sound/soc/codecs/audio-iio-aux.c +++ b/sound/soc/codecs/audio-iio-aux.c @@ -26,8 +26,8 @@ struct audio_iio_aux_chan { struct audio_iio_aux { struct device *dev; - struct audio_iio_aux_chan *chans; unsigned int num_chans; + struct audio_iio_aux_chan chans[] __counted_by(num_chans); }; static int audio_iio_aux_info_volsw(struct snd_kcontrol *kcontrol, @@ -250,23 +250,18 @@ static int audio_iio_aux_probe(struct platform_device *pdev) int ret; int i; - iio_aux = devm_kzalloc(dev, sizeof(*iio_aux), GFP_KERNEL); + count = device_property_string_array_count(dev, "io-channel-names"); + if (count < 0) + return dev_err_probe(dev, count, "failed to count io-channel-names\n"); + + iio_aux = devm_kzalloc(dev, struct_size(iio_aux, chans, count), GFP_KERNEL); if (!iio_aux) return -ENOMEM; iio_aux->dev = dev; - count = device_property_string_array_count(dev, "io-channel-names"); - if (count < 0) - return dev_err_probe(dev, count, "failed to count io-channel-names\n"); - iio_aux->num_chans = count; - iio_aux->chans = devm_kmalloc_array(dev, iio_aux->num_chans, - sizeof(*iio_aux->chans), GFP_KERNEL); - if (!iio_aux->chans) - return -ENOMEM; - names = kcalloc(iio_aux->num_chans, sizeof(*names), GFP_KERNEL); if (!names) return -ENOMEM; -- 2.34.1

2 1

[PATCH 0/4] ALSA: hda: Abstract and update HOST-stream setup procedure
by Cezary Rojewski 25 Sep '23

25 Sep '23

The patchset targets two intertwined topics: The driver shall poll SDxFIFOS to ensure a valid value is set by the controller after programming SDxFMT. Due to amount of users and limited-number of configuration available in our CI when compared to overall possibilities on the market, the check is non-blocking. Second topic relates to stream setup procedure. The procedure differs between HDAudio controller device revisions. Right now those differences are handled directly by a platform driver. Existing top-level 'if (pci->device == APL)' could be replaced by a abstraction in lower parts of the code instead. With that done, the two users are updated accordingly. In avs-driver case, this updates the flow to the recommended one. Cezary Rojewski (4): ALSA: hda: Poll SDxFIFOS after programming SDxFMT ALSA: hda: Introduce HOST stream setup mechanism ASoC: Intel: avs: Use helper to setup HOST stream ASoC: Intel: Skylake: Use helper to setup HOST stream include/sound/hda_register.h | 2 ++ include/sound/hdaudio.h | 3 +++ include/sound/hdaudio_ext.h | 3 +++ sound/hda/ext/hdac_ext_stream.c | 41 +++++++++++++++++++++++++++++++ sound/hda/hdac_stream.c | 8 ++++++ sound/soc/intel/avs/pcm.c | 2 +- sound/soc/intel/skylake/skl-pcm.c | 14 +---------- 7 files changed, 59 insertions(+), 14 deletions(-) -- 2.25.1

3 8

[PATCH v2 0/4] ALSA: hda: Abstract and update HOST-stream setup procedure
by Cezary Rojewski 25 Sep '23

25 Sep '23

The patchset targets two intertwined topics: The driver shall poll SDxFIFOS to ensure a valid value is set by the controller after programming SDxFMT. Due to amount of users and limited-number of configuration available in our CI when compared to overall possibilities on the market, the check is non-blocking. Second topic relates to stream setup procedure. The procedure differs between HDAudio controller device revisions. Right now those differences are handled directly by a platform driver. Existing top-level 'if (pci->device == APL)' could be replaced by a abstraction in lower parts of the code instead. With that done, the two users are updated accordingly. In avs-driver case, this updates the flow to the recommended one. Changes in v2: - fixed ->host_setup assignment in patch 02/04 Cezary Rojewski (4): ALSA: hda: Poll SDxFIFOS after programming SDxFMT ALSA: hda: Introduce HOST stream setup mechanism ASoC: Intel: avs: Use helper to setup HOST stream ASoC: Intel: Skylake: Use helper to setup HOST stream include/sound/hda_register.h | 2 ++ include/sound/hdaudio.h | 3 +++ include/sound/hdaudio_ext.h | 3 +++ sound/hda/ext/hdac_ext_stream.c | 41 +++++++++++++++++++++++++++++++ sound/hda/hdac_stream.c | 8 ++++++ sound/soc/intel/avs/pcm.c | 2 +- sound/soc/intel/skylake/skl-pcm.c | 14 +---------- 7 files changed, 59 insertions(+), 14 deletions(-) -- 2.25.1

1 4

[PATCH v7 03/12] sound: Fix snd_pcm_readv()/writev() to use iov access functions
by David Howells 25 Sep '23

25 Sep '23

Fix snd_pcm_readv()/writev() to use iov access functions rather than poking at the iov_iter internals directly. Signed-off-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Jaroslav Kysela <perex(a)perex.cz> Reviewed-by: Takashi Iwai <tiwai(a)suse.de> cc: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> cc: Jens Axboe <axboe(a)kernel.dk> cc: Suren Baghdasaryan <surenb(a)google.com> cc: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> cc: alsa-devel(a)alsa-project.org --- sound/core/pcm_native.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index bd9ddf412b46..9a69236fa207 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3527,7 +3527,7 @@ static ssize_t snd_pcm_readv(struct kiocb *iocb, struct iov_iter *to) if (runtime->state == SNDRV_PCM_STATE_OPEN || runtime->state == SNDRV_PCM_STATE_DISCONNECTED) return -EBADFD; - if (!to->user_backed) + if (!user_backed_iter(to)) return -EINVAL; if (to->nr_segs > 1024 || to->nr_segs != runtime->channels) return -EINVAL; @@ -3567,7 +3567,7 @@ static ssize_t snd_pcm_writev(struct kiocb *iocb, struct iov_iter *from) if (runtime->state == SNDRV_PCM_STATE_OPEN || runtime->state == SNDRV_PCM_STATE_DISCONNECTED) return -EBADFD; - if (!from->user_backed) + if (!user_backed_iter(from)) return -EINVAL; if (from->nr_segs > 128 || from->nr_segs != runtime->channels || !frame_aligned(runtime, iov->iov_len))

1 0

[v1 0/2] ASoC: mediatek: mt8188-mt6359: add rt5682s support
by xiazhengqiao 25 Sep '23

25 Sep '23

To use RT5682S as the codec and MAX98390 as the amp, add a new sound card named mt8188_rt5682. xiazhengqiao (2): ASoC: dt-bindings: mediatek,mt8188-mt6359: add RT5682S support ASoC: mediatek: mt8188-mt6359: add rt5682s support .../sound/mediatek,mt8188-mt6359.yaml | 1 + sound/soc/mediatek/Kconfig | 1 + sound/soc/mediatek/mt8188/mt8188-mt6359.c | 154 +++++++++++++++++- 3 files changed, 155 insertions(+), 1 deletion(-) -- 2.17.1

2 3

[PATCH 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring suspend
by Chancel Liu 25 Sep '23

25 Sep '23

Add a property to list DAPM endpoints which mark paths between these endpoints ignoring suspend. These DAPM paths can still be power on when system enters into suspend. Signed-off-by: Chancel Liu <chancel.liu(a)nxp.com> --- Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml index 188f38baddec..ec6e09eab427 100644 --- a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml @@ -91,6 +91,12 @@ properties: - rpmsg-audio-channel - rpmsg-micfil-channel + fsl,lpa-widgets: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of DAPM endpoints which mark paths between these endpoints + ignoring suspend. + required: - compatible -- 2.25.1

2 4

[PATCH] ALSA: control: do not access controls without possession of r_w lock
by Ma Ke 25 Sep '23

25 Sep '23

we should not access any of its memory when we don't ensure possession of a read/write lock. Otherwise we risk a use after free access, which allows local users to cause a denial of service and obtain sensitive information from kernel memory. Signed-off-by: Ma Ke <make_ruc2021(a)163.com> --- sound/core/control.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/core/control.c b/sound/core/control.c index 59c8658966d4..98782cc68ee1 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -590,7 +590,8 @@ static int __snd_ctl_remove(struct snd_card *card, remove_hash_entries(card, kcontrol); card->controls_count -= kcontrol->count; - for (idx = 0; idx < kcontrol->count; idx++) + count = kcontrol->count; + for (idx = 0; idx < count; idx++) snd_ctl_notify_one(card, SNDRV_CTL_EVENT_MASK_REMOVE, kcontrol, idx); snd_ctl_free_one(kcontrol); return 0; -- 2.37.2

3 3

Invalid jack configuration on Mac Pro 2013
by Julio Merino 24 Sep '23

24 Sep '23

Hello, I have a Mac Pro 2013 running Fedora 38 and, while I get sound, the jack connections seem to be incorrectly configured. I tried to follow https://docs.kernel.org/sound/hd-audio/notes.html for troubleshooting, and went the route of trying to figure out pin configuration changes... but so far haven't succeeded. So... I'm sending this as a bug report per the instructions in that document. Here is what I observe: - The machine has two jacks: line out and headphones. - The line out jack emits red light while playing. - When nothing is connected to either jack, sound plays through the internal speaker: OK. - When connecting speakers to the line out jack, the internal speaker is muted but no sound comes through the speakers. - When connecting headphones to the headphones jack, sound comes through the headphones BUT this only happens when something /else/ is connected to the line out jack to silence the internal speaker. Otherwise the headphones jack seems non-functional. - The volume indicator in Gnome switches from speaker to headphones when something is connected to the line out jack. It doesn't recognize any changes when connecting something to the headphones jack. - I tried booting with model=mbp11 and the only thing that seems to change is that the red light turns off. Here is the output of alsa-info.sh: http://alsa-project.org/db/?f=07112f6bc87c0938b38394e7d52aeecb307afcbe Please let me know if you need any other details. Happy to test out any changes via a "patch firmware" file or sysfs settings. Thank you

1 0

mainline build failure due to ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver")
by Sudip Mukherjee (Codethink) 24 Sep '23

24 Sep '23

Hi All, The latest mainline kernel branch fails to build alpha, csky and s390 allmodconfig with the error: drivers/mfd/cs42l43.c:1138:12: error: 'cs42l43_runtime_resume' defined but not used [-Werror=unused-function] 1138 | static int cs42l43_runtime_resume(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~ drivers/mfd/cs42l43.c:1124:12: error: 'cs42l43_runtime_suspend' defined but not used [-Werror=unused-function] 1124 | static int cs42l43_runtime_suspend(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/mfd/cs42l43.c:1106:12: error: 'cs42l43_resume' defined but not used [-Werror=unused-function] 1106 | static int cs42l43_resume(struct device *dev) | ^~~~~~~~~~~~~~ drivers/mfd/cs42l43.c:1076:12: error: 'cs42l43_suspend' defined but not used [-Werror=unused-function] 1076 | static int cs42l43_suspend(struct device *dev) | ^~~~~~~~~~~~~~~ git bisect pointed to ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver") I will be happy to test any patch or provide any extra log if needed. -- Regards Sudip

6 7