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

[PATCH v6 0/6] reset: gpio: ASoC: shared GPIO resets
by Krzysztof Kozlowski 22 Feb '24

22 Feb '24

Hi, Dependencies / Merging ====================== 1. Depends on !GPIOLIB stub: https://lore.kernel.org/all/20240125081601.118051-3-krzysztof.kozlowski@lin… 2. Patch #2 (cpufreq: do not open-code of_phandle_args_equal()) and patch #4 (reset: Instantiate reset GPIO controller for shared reset-gpios) depend on OF change (patch #1). Changes in v6 ============= 1. reset/core.c: Add check for number of GPIO cells==2 (Neil). 2. Add Rb/Ack tags. Changes in v5 ============= 1. Minor comments from Philipp: missing cleanup.h, correct indentation of pr_err(), shorten gpio_device_find_by_fwnode() line. 2. Acks/Rbs. Changes in v4 ============= 1. New patches: of: add of_phandle_args_equal() helper cpufreq: do not open-code of_phandle_args_equal() 2. reset-gpio.c: - Drop unneeded comment (Bartosz), add Rb tag. - Do not assign of_node. 3. reset/core.c: - Implement most of Bartosz feedback (I responded to one which I did not implement) and comments from Philipp. - Expect either rcdev->of_args or rcdev->of_node. - Drop __reset_gpios_args_match() and use common helper (Philipp). - Move declarations of automatic-cleanup variables in __reset_add_reset_gpio_lookup() to place of use (Bartosz). - Separate gpio_device_get_label() and kstrdup() (Philipp). - Correct doc for __reset_add_reset_gpio_device(), rewrite few comments. - Drop unneeded "r" variable in __reset_find_rcdev() (Philipp). - Drop of_phandle_args initialization in __of_reset_control_get (Philipp). - Check if CONFIG_RESET_GPIO is enabled before trying to look up reset-gpios. 4. Drop Chris' patch: "i2c: muxes: pca954x: Allow sharing reset GPIO", because discussion is on going. Changes in v3 ============= 1. reset-gpio.c: - Add reset_gpio_of_xlate (Philipp). - reset_gpio_of_args_put->reset_gpio_of_node_put (Philipp). - Expect via platdata of_phandle_args. - Do not call device_set_node() to attach itself to reset consumer (the final device). This was questionable idea in the first place. Bartosz suggested to use GPIO_LOOKUP to solve this. 2. reset/core.c, implement Philipp's feedback. That was a lot: - Commit msg fixes. - Add new platform_device earlier, when reset core found "reset-gpios" but not "resets". - Do not overwrite of_phandle_args. - Expect matching .of_reset_n_cells. - Pass of_phandle_args as platdata to reset-gpio. - Rename reset_gpio_device->reset_gpio_lookup and others. Fix few comments and code cleanup pointed on review. - From Bartosz: Use GPIO_LOOKUP and a lot of cleanup.h in __reset_add_reset_gpio_lookup(). 3. Include here Chris' patch: "i2c: muxes: pca954x: Allow sharing reset GPIO". Changes in v2 ============= 1. wsa884x.c: add missing return in wsa884x_get_reset(), correct comment. 2. qcom,wsa8840.yaml: fix oneOf syntax. 3. reset-gpio.c: - Fix smatch warning on platdata evaluation. - Parse GPIO args and store them in rc.of_args. 4. reset/core.c: - Revise approach based on Bartosz comments: parse the reset-gpios phandle with arguments, do not use deprecated API and do not rely on gpio_desc pointer. - Create a list of instantiated platform devices to avoid any duplicates. - After creating reset-gpio platform device, try to get new reset controller or return EPROBE_DEFER. - Drop the "cookie" member and add new "of_args" to "struct reset_controller_dev". Description =========== We have at least few cases where hardware engineers decided to use one powerdown/shutdown/reset GPIO line for multiple devices: 1. WSA884x (this and previous patch): https://lore.kernel.org/all/b7aeda24-d638-45b7-8e30-80d287f498f8@sirena.org… 2. https://lore.kernel.org/all/20231027033104.1348921-1-chris.packham@alliedte… 3. https://lore.kernel.org/lkml/20191030120440.3699-1-peter.ujfalusi@ti.com/ 4. https://lore.kernel.org/all/20211018234923.1769028-1-sean.anderson@seco.com/ 5. https://social.treehouse.systems/@marcan/111268780311634160 I try to solve my case, hopefuly Chris' (2), partially Sean's (4) and maybe Hectors (5), using Rob's suggestion: https://lore.kernel.org/all/YXi5CUCEi7YmNxXM@robh.at.kernel.org/ Best regards, Krzysztof Cc: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Cc: Bartosz Golaszewski <brgl(a)bgdev.pl> Cc: Sean Anderson <sean.anderson(a)seco.com> Krzysztof Kozlowski (6): of: Add of_phandle_args_equal() helper cpufreq: do not open-code of_phandle_args_equal() reset: gpio: Add GPIO-based reset controller reset: Instantiate reset GPIO controller for shared reset-gpios ASoC: dt-bindings: qcom,wsa8840: Add reset-gpios for shared line ASoC: codecs: wsa884x: Allow sharing reset GPIO .../bindings/sound/qcom,wsa8840.yaml | 11 +- MAINTAINERS | 5 + drivers/reset/Kconfig | 9 + drivers/reset/Makefile | 1 + drivers/reset/core.c | 224 +++++++++++++++++- drivers/reset/reset-gpio.c | 119 ++++++++++ include/linux/cpufreq.h | 3 +- include/linux/of.h | 16 ++ include/linux/reset-controller.h | 4 + sound/soc/codecs/wsa884x.c | 53 ++++- 10 files changed, 419 insertions(+), 26 deletions(-) create mode 100644 drivers/reset/reset-gpio.c -- 2.34.1

5 25

[PATCH] slimbus: core: Remove usage of the deprecated ida_simple_xx() API
by Christophe JAILLET 21 Feb '24

21 Feb '24

ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). Note that the upper limit of ida_simple_get() is exclusive, but the one of ida_alloc_range() is inclusive. So change this change allows one more device. Previously address 0xFE was never used. Fixes: 46a2bb5a7f7e ("slimbus: core: Add slim controllers support") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- /!\ Untested /!\ The change of behavior is motivated by the comment in drivers/slimbus/slimbus.h stating that /* Manager's logical address is set to 0xFF per spec */, so all other values, including 0xFE should be valid, IMHO. So considering this as a bug-fix, I added a Fixes tag. --- drivers/slimbus/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/slimbus/core.c b/drivers/slimbus/core.c index d43873bb5fe6..01cbd4621981 100644 --- a/drivers/slimbus/core.c +++ b/drivers/slimbus/core.c @@ -436,8 +436,8 @@ static int slim_device_alloc_laddr(struct slim_device *sbdev, if (ret < 0) goto err; } else if (report_present) { - ret = ida_simple_get(&ctrl->laddr_ida, - 0, SLIM_LA_MANAGER - 1, GFP_KERNEL); + ret = ida_alloc_max(&ctrl->laddr_ida, + SLIM_LA_MANAGER - 1, GFP_KERNEL); if (ret < 0) goto err; -- 2.34.1

2 2

[v2 PATCH 0/1] ALSA: virtio: add support for audio controls
by Aiswarya Cyriac 20 Feb '24

20 Feb '24

From: Anton Yakovlev <anton.yakovlev(a)opensynergy.com> Changes in v2 - Fix reporting of incorrect number of items for ENUMERATED controls Implementation of support for audio controls in accordance with the extension of the virtio sound device specification[1] planned for virtio-v1.3-cs01. Design　of virtual audio controls is based on and derived from ALSA audio controls. It allows the driver to perform all standard operations, such as reading and writing audio control value, as well as working with metadata (represented in the TLV form). The driver part was tested on top of the Linux 5.10 kernel. As a device part was used OpenSynergy proprietary implementation. [1] https://lists.oasis-open.org/archives/virtio-comment/202104/msg00013.html Anton Yakovlev (1): ALSA: virtio: add support for audio controls include/uapi/linux/virtio_snd.h | 154 +++++++++++ sound/virtio/Makefile | 1 + sound/virtio/virtio_card.c | 21 ++ sound/virtio/virtio_card.h | 22 ++ sound/virtio/virtio_kctl.c | 464 ++++++++++++++++++++++++++++++++ 5 files changed, 662 insertions(+) create mode 100644 sound/virtio/virtio_kctl.c -- 2.25.1

4 4

Codec stops working after sleep and resume
by Jesús Jiménez Sánchez 15 Feb '24

15 Feb '24

I am using the tlv320aic31xx codec in my embedded device and I've noticed that, after forcing the unit into sleep and then, resume, I get a bunch of these errors: ``` tlv320aic31xx-codec 0-0018: ASoC: error at snd_soc_component_update_bits on tlv320aic31xx-codec.0-0018: -108 tlv320aic31xx-codec 0-0018: aic31xx_wait_bits: Failed! 0x25 was 0xcc239ca8 expected 0x0 (-108, 0x20, 0 us) tlv320aic31xx-codec 0-0018: ASoC: POST_PMD: HPL Driver event failed: -1 tlv320aic31xx-codec 0-0018: ASoC: error at snd_soc_component_update_bits on tlv320aic31xx-codec.0-0018: -108 tlv320aic31xx-codec 0-0018: ASoC: POST_PMD: SPL ClassD event failed: -108 tlv320aic31xx-codec 0-0018: ASoC: POST_PMD: SPR ClassD event failed: -108 tlv320aic31xx-codec 0-0018: ASoC: error at snd_soc_component_update_bits on tlv320aic31xx-codec.0-0018: -108 tlv320aic31xx-codec 0-0018: ASoC: error at snd_soc_component_update_bits on tlv320aic31xx-codec.0-0018: -108 tlv320aic31xx-codec 0-0018: ASoC: error at snd_soc_component_update_bits on tlv320aic31xx-codec.0-0018: -108 tlv320aic31xx-codec 0-0018: ASoC: error at snd_soc_component_update_bits on tlv320aic31xx-codec.0-0018: -108 tlv320aic31xx-codec 0-0018: ASoC: error at snd_soc_component_update_bits on tlv320aic31xx-codec.0-0018: -108 tlv320aic31xx-codec 0-0018: ASoC: error at snd_soc_component_update_bits on tlv320aic31xx-codec.0-0018: -108 tlv320aic31xx-codec 0-0018: ASoC: error at snd_soc_component_update_bits on tlv320aic31xx-codec.0-0018: -108 ``` When I look at he output of `dmesg`, I found this: ``` ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1506 at drivers/i2c/i2c-core.h:54 __i2c_transfer+0xac/0xb4 i2c i2c-0: Transfer while suspended Modules linked in: rfcomm stm32_adc stm32_timer_trigger stm32_lptimer_trigger sha256_generic libsha256 sha256_arm snd_soc_simple_card snd_soc_simple_card_utils cfg80211 stm32_crc32 hci_uart btqca stm32_cryp libdes crypto_engine snd_soc_stm32_i2s snd_soc_tlv320aic31xx bluetooth stm32_adc_core snd_soc_core atmel_mxt_ts snd_pcm_dmaengine snd_pcm ecdh_generic snd_timer snd ecc sgm4151x_charger soundcore libaes [last unloaded: wlan] CPU: 0 PID: 1506 Comm: sh Tainted: G O 5.15.67 #1 Hardware name: STM32 (Device Tree Support) [<c010e8cc>] (unwind_backtrace) from [<c010c120>] (show_stack+0x10/0x14) [<c010c120>] (show_stack) from [<c011dc1c>] (__warn+0xec/0x148) [<c011dc1c>] (__warn) from [<c0bed42c>] (warn_slowpath_fmt+0x78/0xac) [<c0bed42c>] (warn_slowpath_fmt) from [<c092ecdc>] (__i2c_transfer+0xac/0xb4) [<c092ecdc>] (__i2c_transfer) from [<c092ed80>] (i2c_transfer+0x9c/0x138) [<c092ed80>] (i2c_transfer) from [<c06f5a40>] (regmap_i2c_read+0x5c/0x98) [<c06f5a40>] (regmap_i2c_read) from [<c06f0e2c>] (_regmap_raw_read+0x10c/0x2a8) [<c06f0e2c>] (_regmap_raw_read) from [<c06f1008>] (_regmap_bus_read+0x40/0x6c) [<c06f1008>] (_regmap_bus_read) from [<c06ef9c4>] (_regmap_read+0x60/0x14c) [<c06ef9c4>] (_regmap_read) from [<c06effdc>] (_regmap_update_bits+0xb4/0xf4) [<c06effdc>] (_regmap_update_bits) from [<c06f00c0>] (_regmap_select_page+0xa4/0x108) [<c06f00c0>] (_regmap_select_page) from [<c06f07a8>] (_regmap_raw_write_impl+0x684/0x968) [<c06f07a8>] (_regmap_raw_write_impl) from [<c06f0b04>] (_regmap_bus_raw_write+0x78/0xa0) [<c06f0b04>] (_regmap_bus_raw_write) from [<c06efe40>] (_regmap_write+0x4c/0x134) [<c06efe40>] (_regmap_write) from [<c06f0010>] (_regmap_update_bits+0xe8/0xf4) [<c06f0010>] (_regmap_update_bits) from [<c06f1820>] (regmap_update_bits_base+0x50/0x74) [<c06f1820>] (regmap_update_bits_base) from [<bf0d0980>] (snd_soc_component_update_bits+0x78/0x124 [snd_soc_core]) [<bf0d0980>] (snd_soc_component_update_bits [snd_soc_core]) from [<bf0daa20>] (dapm_seq_run_coalesced+0x14c/0x1a4 [snd_soc_core]) [<bf0daa20>] (dapm_seq_run_coalesced [snd_soc_core]) from [<bf0dab68>] (dapm_seq_run+0xf0/0x350 [snd_soc_core]) [<bf0dab68>] (dapm_seq_run [snd_soc_core]) from [<bf0db170>] (dapm_power_widgets+0x3a8/0x530 [snd_soc_core]) [<bf0db170>] (dapm_power_widgets [snd_soc_core]) from [<bf0cc214>] (snd_soc_dapm_sync+0x48/0x54 [snd_soc_core]) [<bf0cc214>] (snd_soc_dapm_sync [snd_soc_core]) from [<bf0c652c>] (snd_soc_suspend+0xf0/0x230 [snd_soc_core]) [<bf0c652c>] (snd_soc_suspend [snd_soc_core]) from [<c06df188>] (dpm_run_callback+0x48/0x134) [<c06df188>] (dpm_run_callback) from [<c06df58c>] (__device_suspend+0x11c/0x4c4) [<c06df58c>] (__device_suspend) from [<c06e1c10>] (dpm_suspend+0x148/0x2cc) [<c06e1c10>] (dpm_suspend) from [<c06e20e8>] (dpm_suspend_start+0x64/0x6c) [<c06e20e8>] (dpm_suspend_start) from [<c0159f00>] (suspend_devices_and_enter+0x150/0x2b4) [<c0159f00>] (suspend_devices_and_enter) from [<c0bede38>] (enter_state+0x204/0x250) [<c0bede38>] (enter_state) from [<c015a0a4>] (pm_suspend+0x40/0x98) [<c015a0a4>] (pm_suspend) from [<c0158ae4>] (state_store+0x68/0xc8) [<c0158ae4>] (state_store) from [<c0330a68>] (kernfs_fop_write_iter+0x10c/0x1cc) [<c0330a68>] (kernfs_fop_write_iter) from [<c028ea40>] (vfs_write+0x298/0x45c) [<c028ea40>] (vfs_write) from [<c028ed4c>] (ksys_write+0x60/0xe4) [<c028ed4c>] (ksys_write) from [<c0100060>] (ret_fast_syscall+0x0/0x48) Exception stack(0xcffcbfa8 to 0xcffcbff0) bfa0: 00000004 005ac7d8 00000001 005ac7d8 00000004 00000000 bfc0: 00000004 005ac7d8 00000001 00000004 b6f01680 bee896d8 005a8448 005a8590 bfe0: 005a6dfc bee89690 004fcda4 b6dcb4f8 ---[ end trace 75457fd792755cae ]--- ``` I've been trying for a few days, but I can't find the source of the problem or a way to solve it. Is there anything I might be missing? I assume the problem is that it's trying to write to the registers after the suspend has happened, but I haven't been able to prove that either, and I wouldn't know how to fix that. Could that be what's happening here? Thanks.

1 1

[PATCH 6.1.y 0/7] ASoC: codecs: es8326: fix support
by kovalev＠altlinux.org 13 Feb '24

13 Feb '24

These patches were backported from v6.6 upstream and are intended for 6.1.y stable kernel. Patches have been successfully tested on the latest 6.1.75 kernel. [PATCH 6.1.y 1/7] ASoC: codecs: es8326: Convert to i2c's .probe_new() [PATCH 6.1.y 2/7] ASoC: codecs: ES8326: Add es8326_mute function [PATCH 6.1.y 3/7] ASoC: codecs: ES8326: Change Hp_detect register names [PATCH 6.1.y 4/7] ASoC: codecs: ES8326: Change Volatile Reg function [PATCH 6.1.y 5/7] ASoC: codecs: ES8326: Fix power-up sequence [PATCH 6.1.y 6/7] ASOC: codecs: ES8326: Add calibration support for [PATCH 6.1.y 7/7] ASoC: codecs: ES8326: Update jact detection function

3 10

[PATCH v2 00/33] spi: get rid of some legacy macros
by Uwe Kleine-König 12 Feb '24

12 Feb '24

Hello, this is v2 of this patch set. Changes since (implicit) v1, sent with Message-Id: cover.1705348269.git.u.kleine-koenig(a)pengutronix.de: - Rebase to v6.8-rc1 - Fix a build failure on sh - Added the tags received in (implicit) v1. The slave-mt27xx driver needs some more work. The patch presented here is enough however to get rid of the defines handled in patch 32. Cleaning that up is out-of-scope for this series, so I'll delay that until later. Note that Jonathan Cameron has already applied patch 3 to his tree, it didn't appear in a public tree though yet. I still included it here to make the kernel build bots happy. Best regards Uwe Uwe Kleine-König (33): fpga: ice40-spi: Follow renaming of SPI "master" to "controller" ieee802154: ca8210: Follow renaming of SPI "master" to "controller" iio: adc: ad_sigma_delta: Follow renaming of SPI "master" to "controller" Input: pxspad - follow renaming of SPI "master" to "controller" Input: synaptics-rmi4 - follow renaming of SPI "master" to "controller" media: mgb4: Follow renaming of SPI "master" to "controller" media: netup_unidvb: Follow renaming of SPI "master" to "controller" media: usb/msi2500: Follow renaming of SPI "master" to "controller" media: v4l2-subdev: Follow renaming of SPI "master" to "controller" misc: gehc-achc: Follow renaming of SPI "master" to "controller" mmc: mmc_spi: Follow renaming of SPI "master" to "controller" mtd: dataflash: Follow renaming of SPI "master" to "controller" mtd: rawnand: fsl_elbc: Let .probe retry if local bus is missing net: ks8851: Follow renaming of SPI "master" to "controller" net: vertexcom: mse102x: Follow renaming of SPI "master" to "controller" platform/chrome: cros_ec_spi: Follow renaming of SPI "master" to "controller" spi: bitbang: Follow renaming of SPI "master" to "controller" spi: cadence-quadspi: Don't emit error message on allocation error spi: cadence-quadspi: Follow renaming of SPI "master" to "controller" spi: cavium: Follow renaming of SPI "master" to "controller" spi: geni-qcom: Follow renaming of SPI "master" to "controller" spi: loopback-test: Follow renaming of SPI "master" to "controller" spi: slave-mt27xx: Follow renaming of SPI "master" to "controller" spi: spidev: Follow renaming of SPI "master" to "controller" staging: fbtft: Follow renaming of SPI "master" to "controller" staging: greybus: spi: Follow renaming of SPI "master" to "controller" tpm_tis_spi: Follow renaming of SPI "master" to "controller" usb: gadget: max3420_udc: Follow renaming of SPI "master" to "controller" video: fbdev: mmp: Follow renaming of SPI "master" to "controller" wifi: libertas: Follow renaming of SPI "master" to "controller" spi: fsl-lib: Follow renaming of SPI "master" to "controller" spi: Drop compat layer from renaming "master" to "controller" Documentation: spi: Update documentation for renaming "master" to "controller" .../driver-api/driver-model/devres.rst | 2 +- Documentation/spi/spi-summary.rst | 74 +++++++++---------- drivers/char/tpm/tpm_tis_spi_main.c | 4 +- drivers/fpga/ice40-spi.c | 4 +- drivers/iio/adc/ad_sigma_delta.c | 14 ++-- drivers/input/joystick/psxpad-spi.c | 4 +- drivers/input/rmi4/rmi_spi.c | 2 +- drivers/media/pci/mgb4/mgb4_core.c | 14 ++-- .../media/pci/netup_unidvb/netup_unidvb_spi.c | 48 ++++++------ drivers/media/usb/msi2500/msi2500.c | 38 +++++----- drivers/media/v4l2-core/v4l2-spi.c | 4 +- drivers/misc/gehc-achc.c | 8 +- drivers/mmc/host/mmc_spi.c | 6 +- drivers/mtd/devices/mtd_dataflash.c | 2 +- drivers/mtd/nand/raw/fsl_elbc_nand.c | 3 +- drivers/net/ethernet/micrel/ks8851_spi.c | 4 +- drivers/net/ethernet/vertexcom/mse102x.c | 2 +- drivers/net/ieee802154/ca8210.c | 2 +- .../net/wireless/marvell/libertas/if_spi.c | 2 +- drivers/platform/chrome/cros_ec_spi.c | 8 +- drivers/spi/spi-ath79.c | 4 +- drivers/spi/spi-bitbang.c | 64 ++++++++-------- drivers/spi/spi-butterfly.c | 6 +- drivers/spi/spi-cadence-quadspi.c | 7 +- drivers/spi/spi-cavium.c | 6 +- drivers/spi/spi-cavium.h | 2 +- drivers/spi/spi-davinci.c | 6 +- drivers/spi/spi-fsl-lib.c | 14 ++-- drivers/spi/spi-geni-qcom.c | 2 +- drivers/spi/spi-gpio.c | 2 +- drivers/spi/spi-lm70llp.c | 6 +- drivers/spi/spi-loopback-test.c | 4 +- drivers/spi/spi-oc-tiny.c | 6 +- drivers/spi/spi-omap-uwire.c | 4 +- drivers/spi/spi-sh-sci.c | 10 +-- drivers/spi/spi-slave-mt27xx.c | 2 +- drivers/spi/spi-xilinx.c | 4 +- drivers/spi/spi-xtensa-xtfpga.c | 2 +- drivers/spi/spi.c | 2 +- drivers/spi/spidev.c | 2 +- drivers/staging/fbtft/fbtft-core.c | 4 +- drivers/staging/greybus/spilib.c | 66 ++++++++--------- drivers/usb/gadget/udc/max3420_udc.c | 2 +- drivers/video/fbdev/mmp/hw/mmp_spi.c | 26 +++---- include/linux/spi/spi.h | 20 +---- include/linux/spi/spi_bitbang.h | 2 +- include/media/v4l2-common.h | 6 +- 47 files changed, 254 insertions(+), 272 deletions(-) base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d -- 2.43.0

6 10

ALSA-LIB: Support for format IEC958_SUBFRAME_LE in the plug plugin?
by Pavel Hofman 09 Feb '24

09 Feb '24

Hi, RPi has recently moved to the VC4 driver which accepts only IEC958_SUBFRAME_LE format https://github.com/torvalds/linux/blob/ecb1b8288dc7ccbdcb3b9df005fa1c0e0c03… . Since then people started to have issues with their previous configs which use only the plug plugin (plughw:X). Wrapping the device with the hdmi plugin solves the problem, as it should. But e.g. mainline java support for alsa offers only hw cards wrapped with the plug plugin (hardcoded, not possible to specify the device name directly). Stock Java apps then do not work with RPi HDMI. I was wondering if it made sense to add support for the IEC958 formats (using the iec958 plugin methods) to the plug plugin. It may be complicated with the hdmi_mode hint though, I do not know if there is any API to recognize HDMI vs. SPDIF. Maybe a different format specifically for HDMI could have been perhaps useful but it may be too late for that. Thank you very much for consideration. With regards, Pavel.

2 11

[PATCH v2 00/13] of: property: add port base loop
by Kuninori Morimoto 05 Feb '24

05 Feb '24

Hi Rob This is v2 of port base loop patch-set We have endpoint base functions - of_graph_get_next_endpoint() - of_graph_get_endpoint_count() - for_each_endpoint_of_node() But to handling "port" base things, it is not useful. We want to have "port" base functions, too. This patch-set adds it. Because current existing drivers couldn't use "port" base functions, it were implemented in a different way. This patch-set doesn't try to full-replace to avoid unknown bug, try easy / quick replace only for now, but easy to know how "port" base functions are needed. Because I can't test the driver which I can't use, non-ASoC drivers needs Tested-by, Acked-by. v1 -> v2 - tidyup function explain - add missing header on each files Kuninori Morimoto (13): of: property: add port base loop of: property: use of_graph_get_next_port() on of_graph_get_next_endpoint() of: property: add of_graph_get_next_endpoint_raw() drm: omapdrm: use of_graph_get_next_endpoint_raw() media: xilinx-tpg: use of_graph_get_next_endpoint_raw() ASoC: audio-graph-card: use of_graph_get_next_endpoint_raw() ASoC: audio-graph-card2: use of_graph_get_next_port() ASoC: audio-graph-card2: use of_graph_get_next_endpoint_raw() ASoC: test-component: use for_each_port_of_node() fbdev: omapfb: use of_graph_get_remote_port() fbdev: omapfb: use of_graph_get_next_port() fbdev: omapfb: use of_graph_get_next_endpoint_raw() fbdev: omapfb: use of_graph_get_next_endpoint() drivers/gpu/drm/omapdrm/dss/dpi.c | 2 +- drivers/gpu/drm/omapdrm/dss/sdi.c | 2 +- drivers/media/platform/xilinx/xilinx-tpg.c | 2 +- drivers/of/property.c | 92 +++++++++++++--- drivers/video/fbdev/omap2/omapfb/dss/dpi.c | 3 +- drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 3 +- drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 101 +----------------- drivers/video/fbdev/omap2/omapfb/dss/dss.c | 9 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 3 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 3 +- drivers/video/fbdev/omap2/omapfb/dss/sdi.c | 3 +- drivers/video/fbdev/omap2/omapfb/dss/venc.c | 3 +- include/linux/of_graph.h | 23 ++++ include/video/omapfb_dss.h | 11 -- sound/soc/generic/audio-graph-card.c | 2 +- sound/soc/generic/audio-graph-card2.c | 31 ++---- sound/soc/generic/test-component.c | 2 +- 17 files changed, 133 insertions(+), 162 deletions(-) -- 2.25.1

6 37

[PATCH v8 00/13] Introduce STM32 Firewall framework
by Gatien Chevallier 03 Feb '24

03 Feb '24

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 access-controller device tree binding. It is used by peripherals to reference a domain access controller. In this case a firewall controller. The bus uses the ID referenced by the access-controller 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 V8: - Add missing "simple-bus" compatible in STM32MP13/25 SoC device tree files for the ETZPC/RIFSC nodes - Add missing dependency on OF for OF_DYNAMIC that is selected by STM32_FIREWALL Changes in V7: - Separate indentation changes from access-controllers changes in the device tree file commits - Select OF_DYNAMIC when STM32_FIREWALL is set in order to use of_detach_node() in the firewall framework - Handle previously non-present RNG and HASH nodes in the STM32MP13 device tree file Changes in V6: - Rename access-controller to access-controllers - Remove access-controller-provider - Update device trees and other bindings accordingly - Rework ETZPC/RIFSC bindings to define what access-controllers cells contain inside #access-controller-cells - Some other minor fixes Changes in V5: - Integrate and rework the "feature-domains" binding patch in this patchset. The binding is renamed to "access-controller" - Rename every feature-domain* reference to access-control* ones - Correct loop bug and missing select STM32_FIREWALL in 32-bit platform Kconfig Changes in V4: - Fix typo in commit message and YAML check errors in "dt-bindings: Document common device controller bindings" Note: This patch should be ignored as stated in the cover letter. I've done this to avoid errors on this series of patch - Correct code syntax/style issues reported by Simon Horman - Added Jonathan's tag for IIO on the treewide patch Changes in V3: Change incorrect ordering for bindings commits leading to an error while running "make DT_CHECKER_FLAGS=-m dt_binding_check" 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 Gatien Chevallier (12): dt-bindings: treewide: add access-controllers description dt-bindings: bus: document RIFSC dt-bindings: bus: document ETZPC firewall: introduce stm32_firewall framework of: property: fw_devlink: Add support for "access-controller" bus: rifsc: introduce RIFSC firewall controller driver arm64: dts: st: add RIFSC as an access 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: put ETZPC as an access controller for STM32MP15x boards ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards ARM: dts: stm32: put ETZPC as an access controller for STM32MP13x boards Oleksii Moisieiev (1): dt-bindings: document generic access controllers .../access-controllers.yaml | 84 + .../bindings/bus/st,stm32-etzpc.yaml | 87 + .../bindings/bus/st,stm32mp25-rifsc.yaml | 96 + .../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 + .../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 | 4 + .../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 | 1063 ++++--- 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 | 2756 +++++++++-------- arch/arm/boot/dts/st/stm32mp153.dtsi | 52 +- arch/arm/boot/dts/st/stm32mp15xc.dtsi | 19 +- arch/arm/mach-stm32/Kconfig | 1 + arch/arm64/Kconfig.platforms | 1 + arch/arm64/boot/dts/st/stm32mp251.dtsi | 7 +- drivers/bus/Kconfig | 10 + drivers/bus/Makefile | 1 + drivers/bus/stm32_etzpc.c | 141 + drivers/bus/stm32_firewall.c | 294 ++ drivers/bus/stm32_firewall.h | 83 + drivers/bus/stm32_rifsc.c | 252 ++ drivers/of/property.c | 2 + include/linux/bus/stm32_firewall_device.h | 141 + 48 files changed, 3352 insertions(+), 1938 deletions(-) create mode 100644 Documentation/devicetree/bindings/access-controllers/access-controllers.yaml 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 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

3 19

[PATCH v5 0/4] ASoC: qcom: volume fixes and codec cleanups
by Johan Hovold 03 Feb '24

03 Feb '24

To reduce the risk of speaker damage the PA gain needs to be limited on machines like the Lenovo Thinkpad X13s until we have active speaker protection in place. Limit the gain to the current default setting provided by the UCM configuration which most user have so far been using (due to a bug in the configuration files which prevented hardware volume control [1]). The wsa883x PA volume control also turned out to be broken, which meant that the default setting used by UCM configuration is actually the lowest level (-3 dB). With the codec driver fixed, hardware volume control also works as expected. Note that the new wsa884x driver most likely suffers from a similar bug, I'll send a fix for that once I've got that confirmed. Included is also a related fix for the LPASS WSA macro driver, which was changing the digital gain setting behind the back of user space and which can result in excessive (or too low) digital gain. There are further Qualcomm codec drivers that similarly appear to manipulate various gain settings, but on closer inspection it turns out that they only write back the current settings. Tests reveal that these writes are indeed needed for any prior updates to take effect (at least for the WSA and RX macros). Johan [1] https://github.com/alsa-project/alsa-ucm-conf/pull/382 Changes in v5 - rebase on v6.8-rc1 Changes in v4 - keep the full PA volume control range and only fix the exported dB values - use a combined -3 dB machine limit as limiting just the PA volume confuses PulseAudio - drop the PA gain initialisation which is no longer needed Changes in v3 - fix the wsa883x PA volume control and update the machine limits accordingly Changes in v2 - keep the volume register write on power-on in lpass-wsa-macro - drop the other patches removing volume register writes on DAPM events - only drop the constant-zero gain offsets in wcd9335 Johan Hovold (4): ASoC: codecs: wsa883x: fix PA volume control ASoC: qcom: sc8280xp: limit speaker volumes ASoC: codecs: lpass-wsa-macro: fix compander volume hack ASoC: codecs: wcd9335: drop unused gain hack remnant sound/soc/codecs/lpass-wsa-macro.c | 7 ------- sound/soc/codecs/wcd9335.c | 4 ---- sound/soc/codecs/wsa883x.c | 6 +++++- sound/soc/qcom/sc8280xp.c | 12 +++++++----- 4 files changed, 12 insertions(+), 17 deletions(-) -- 2.43.0

4 9