April 2025 - Linux-stable-mirror

[PATCH] drm/panthor: Fix memory leak in panthor_ioctl_group_create()

by Jann Horn

When bailing out due to group_priority_permit() failure, the queue_args need to be freed. Fix it by rearranging the function to use the goto-on-error pattern, such that the success case flows straight without indentation while error cases jump forward to cleanup. Cc: stable(a)vger.kernel.org Fixes: 5f7762042f8a ("drm/panthor: Restrict high priorities on group_create") Signed-off-by: Jann Horn <jannh(a)google.com> --- testcase: ``` #include <err.h> #include <fcntl.h> #include <stddef.h> #include <sys/ioctl.h> #include <drm/panthor_drm.h> #define SYSCHK(x) ({ \ typeof(x) __res = (x); \ if (__res == (typeof(x))-1) \ err(1, "SYSCHK(" #x ")"); \ __res; \ }) #define GPU_PATH "/dev/dri/by-path/platform-fb000000.gpu-card" int main(void) { int fd = SYSCHK(open(GPU_PATH, O_RDWR)); while (1) { struct drm_panthor_queue_create qc[16] = {}; struct drm_panthor_group_create gc = { .queues = { .stride = sizeof(struct drm_panthor_queue_create), .count = 16, .array = (unsigned long)qc }, .priority = PANTHOR_GROUP_PRIORITY_HIGH+1/*invalid*/ }; ioctl(fd, DRM_IOCTL_PANTHOR_GROUP_CREATE, &gc); } } ``` I have tested that without this patch, after running the testcase for a few seconds and then manually killing it, 2G of RAM in kmalloc-128 have been leaked. With the patch applied, the memory leak is gone. (By the way, get_maintainer.pl suggests that I also send this patch to the general DRM maintainers and the DRM-misc maintainers; looking at MAINTAINERS, it looks like it is normal that the general DRM maintainers are listed for everything under drivers/gpu/, but DRM-misc has exclusion rules for a bunch of drivers but not panthor. I don't know if that is intentional.) --- drivers/gpu/drm/panthor/panthor_drv.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c index c520f156e2d73f7e735f8bf2d6d8e8efacec9362..815c23cff25f305d884e8e3e263fa22888f7d5ce 100644 --- a/drivers/gpu/drm/panthor/panthor_drv.c +++ b/drivers/gpu/drm/panthor/panthor_drv.c @@ -1032,14 +1032,15 @@ static int panthor_ioctl_group_create(struct drm_device *ddev, void *data, ret = group_priority_permit(file, args->priority); if (ret) - return ret; + goto out; ret = panthor_group_create(pfile, args, queue_args); - if (ret >= 0) { - args->group_handle = ret; - ret = 0; - } + if (ret < 0) + goto out; + args->group_handle = ret; + ret = 0; +out: kvfree(queue_args); return ret; } --- base-commit: 9f8e716d46c68112484a23d1742d9ec725e082fc change-id: 20241113-panthor-fix-gcq-bailout-2d9ac36590ed -- Jann Horn <jannh(a)google.com>

6 hours, 54 minutes

4
4
0 0

[PATCH 0/3] Fixes/improvements for SM6350 UFS

by Luca Weiss

Fix the order of the freq-table-hz property, then convert to OPP tables and add interconnect support for UFS for the SM6350 SoC. Signed-off-by: Luca Weiss <luca.weiss(a)fairphone.com> --- Luca Weiss (3): arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS arm64: dts: qcom: sm6350: Add OPP table support to UFSHC arm64: dts: qcom: sm6350: Add interconnect support to UFS arch/arm64/boot/dts/qcom/sm6350.dtsi | 49 ++++++++++++++++++++++++++++-------- 1 file changed, 39 insertions(+), 10 deletions(-) --- base-commit: eea255893718268e1ab852fb52f70c613d109b99 change-id: 20250314-sm6350-ufs-things-53c5de9fec5e Best regards, -- Luca Weiss <luca.weiss(a)fairphone.com>

2 days, 15 hours

2
3
0 0

[PATCH v3 0/3] m68k: Bug fix and cleanup for framebuffer debug console

by Finn Thain

This series has a bug fix for the early bootconsole as well as some related efficiency improvements and cleanup. The relevant code is subject to CONSOLE_DEBUG, which is presently only used with CONFIG_MAC. To test this series (in qemu-system-m68k, for example) it's helpful to enable CONFIG_EARLY_PRINTK and CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER and boot with kernel parameters 'console=ttyS0 earlyprintk keep_bootcon'. --- Changed since v1: - Solved problem with line wrap while scrolling. - Added two additional patches. Changed since v2: - Adopted addq and subq as suggested by Andreas. Finn Thain (3): m68k: Fix lost column on framebuffer debug console m68k: Avoid pointless recursion in debug console rendering m68k: Remove unused "cursor home" code from debug console arch/m68k/kernel/head.S | 73 +++++++++++++++++++++-------------------- 1 file changed, 37 insertions(+), 36 deletions(-) -- 2.45.3

1 week, 5 days

3
3
0 0

[PATCH v3 1/2] platform/x86: int3472: add hpd pin support

by Dongcheng Yan

Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is being received. On the host side this is wired to a GPIO for polling or interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges lt6911uxe and lt6911uxc. The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it here as well. Signed-off-by: Dongcheng Yan <dongcheng.yan(a)intel.com> --- drivers/platform/x86/intel/int3472/common.h | 1 + drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h index 51b818e62a25..4593d567caf4 100644 --- a/drivers/platform/x86/intel/int3472/common.h +++ b/drivers/platform/x86/intel/int3472/common.h @@ -23,6 +23,7 @@ #define INT3472_GPIO_TYPE_CLK_ENABLE 0x0c #define INT3472_GPIO_TYPE_PRIVACY_LED 0x0d #define INT3472_GPIO_TYPE_HANDSHAKE 0x12 +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT 0x13 #define INT3472_PDEV_MAX_NAME_LEN 23 #define INT3472_MAX_SENSOR_GPIOS 3 diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c index 394975f55d64..efa3bc7af193 100644 --- a/drivers/platform/x86/intel/int3472/discrete.c +++ b/drivers/platform/x86/intel/int3472/discrete.c @@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3 *con_id = "privacy-led"; *gpio_flags = GPIO_ACTIVE_HIGH; break; + case INT3472_GPIO_TYPE_HOTPLUG_DETECT: + *con_id = "hpd"; + *gpio_flags = GPIO_ACTIVE_HIGH; + break; case INT3472_GPIO_TYPE_POWER_ENABLE: *con_id = "avdd"; *gpio_flags = GPIO_ACTIVE_HIGH; @@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3 * 0x0b Power enable * 0x0c Clock enable * 0x0d Privacy LED + * 0x13 Hotplug detect * * There are some known platform specific quirks where that does not quite * hold up; for example where a pin with type 0x01 (Power down) is mapped to @@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares, switch (type) { case INT3472_GPIO_TYPE_RESET: case INT3472_GPIO_TYPE_POWERDOWN: + case INT3472_GPIO_TYPE_HOTPLUG_DETECT: ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags); if (ret) err_msg = "Failed to map GPIO pin to sensor\n"; base-commit: 4d1e8c8f11c611db5828e4bae7292bc295eea8ef -- 2.34.1

2 weeks, 1 day

8
12
0 0

[PATCH 0/2] Add dma-coherent for gs101 UFS dt node

by Peter Griffin

ufs-exynos driver enables the shareability option for gs101 which means the descriptors need to be allocated as cacheable. Fix the DT node and update bindings to add the dma-coherent property. This fixes the UFS stability issues we have seen with the upstream UFS driver. Note this DT fix can go in independently of the other UFS fixes series I sent recently [1], as the bootloader already leaves the sharability bits enabled. regards, Peter [1] https://lore.kernel.org/linux-scsi/20250226220414.343659-1-peter.griffin@li… To: André Draszik <andre.draszik(a)linaro.org> To: Tudor Ambarus <tudor.ambarus(a)linaro.org> To: Rob Herring <robh(a)kernel.org> To: Krzysztof Kozlowski <krzk+dt(a)kernel.org> To: Conor Dooley <conor+dt(a)kernel.org> To: Alim Akhtar <alim.akhtar(a)samsung.com> To: Avri Altman <avri.altman(a)wdc.com> To: Bart Van Assche <bvanassche(a)acm.org> To: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-samsung-soc(a)vger.kernel.org Cc: devicetree(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-scsi(a)vger.kernel.org Cc: kernel-team(a)android.com Cc: willmcvicker(a)google.com Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> --- Peter Griffin (2): arm64: dts: exynos: gs101: ufs: add dma-coherent property scsi: ufs: dt-bindings: exynos: add dma-coherent property for gs101 Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml | 2 ++ arch/arm64/boot/dts/exynos/google/gs101.dtsi | 1 + 2 files changed, 3 insertions(+) --- base-commit: b323d8e7bc03d27dec646bfdccb7d1a92411f189 change-id: 20250314-ufs-dma-coherent-980f2467690d Best regards, -- Peter Griffin <peter.griffin(a)linaro.org>

2 weeks, 4 days

6
13
0 0

5.10 kernel series fails to build on newer toolchain: FAILED unresolved symbol filp_close

by Philip Müller

For some odd reason 5.10 kernel series doesn't compile with a newer toolchain since 2025-02-09: 2025-02-09T17:32:07.7991299Z GEN .version 2025-02-09T17:32:07.8270062Z CHK include/generated/compile.h 2025-02-09T17:32:07.8540777Z LD vmlinux.o 2025-02-09T17:32:11.7210899Z MODPOST vmlinux.symvers 2025-02-09T17:32:12.0869599Z MODINFO modules.builtin.modinfo 2025-02-09T17:32:12.1403022Z GEN modules.builtin 2025-02-09T17:32:12.1475659Z LD .tmp_vmlinux.btf 2025-02-09T17:32:19.6117204Z BTF .btf.vmlinux.bin.o 2025-02-09T17:32:31.2916650Z LD .tmp_vmlinux.kallsyms1 2025-02-09T17:32:34.8731104Z KSYMS .tmp_vmlinux.kallsyms1.S 2025-02-09T17:32:35.4910608Z AS .tmp_vmlinux.kallsyms1.o 2025-02-09T17:32:35.9662538Z LD .tmp_vmlinux.kallsyms2 2025-02-09T17:32:39.2595984Z KSYMS .tmp_vmlinux.kallsyms2.S 2025-02-09T17:32:39.8802028Z AS .tmp_vmlinux.kallsyms2.o 2025-02-09T17:32:40.3659440Z LD vmlinux 2025-02-09T17:32:48.0031558Z BTFIDS vmlinux 2025-02-09T17:32:48.0143553Z FAILED unresolved symbol filp_close 2025-02-09T17:32:48.5019928Z make: *** [Makefile:1207: vmlinux] Error 255 2025-02-09T17:32:48.5061241Z ==> ERROR: A failure occurred in build(). 5.10.234 built fine couple of days ago with the older one. There were slight changes made. 5.4 and 5.15 still compile. Wonder what might be missing here ... -- Best, Philip

3 weeks, 3 days

4
13
0 0

FAILED: patch "[PATCH] kbuild: rpm-pkg: simplify installkernel %post" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 358de8b4f201bc05712484b15f0109b1ae3516a8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024021932-lavish-expel-58e5@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 358de8b4f201 ("kbuild: rpm-pkg: simplify installkernel %post") 0df8e9708594 ("scripts: clean up IA-64 code") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 358de8b4f201bc05712484b15f0109b1ae3516a8 Mon Sep 17 00:00:00 2001 From: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> Date: Mon, 29 Jan 2024 10:28:19 +0100 Subject: [PATCH] kbuild: rpm-pkg: simplify installkernel %post The new installkernel application that is now included in systemd-udev package allows installation although destination files are already present in the boot directory of the kernel package, but is failing with the implemented workaround for the old installkernel application from grubby package. For the new installkernel application, as Davide says: <<The %post currently does a shuffling dance before calling installkernel. This isn't actually necessary afaict, and the current implementation ends up triggering downstream issues such as https://github.com/systemd/systemd/issues/29568 This commit simplifies the logic to remove the shuffling. For reference, the original logic was added in commit 3c9c7a14b627("rpm-pkg: add %post section to create initramfs and grub hooks").>> But we need to keep the old behavior as well, because the old installkernel application from grubby package, does not allow this simplification and we need to be backward compatible to avoid issues with the different packages. Mimic Fedora shipping process and store vmlinuz, config amd System.map in the module directory instead of the boot directory. In this way, we will avoid the commented problem for all the cases, because the new destination files are not going to exist in the boot directory of the kernel package. Replace installkernel tool with kernel-install tool, because the latter is more complete. Besides, after installkernel tool execution, check to complete if the correct package files vmlinuz, System.map and config files are present in /boot directory, and if necessary, copy manually for install operation. In this way, take into account if files were not previously copied from /usr/lib/kernel/install.d/* scripts and if the suitable files for the requested package are present (it could be others if the rpm files were replace with a new pacakge with the same release and a different build). Tested with Fedora 38, Fedora 39, RHEL 9, Oracle Linux 9.3, openSUSE Tumbleweed and openMandrive ROME, using dnf/zypper and rpm tools. cc: stable(a)vger.kernel.org Co-Developed-by: Davide Cavalca <dcavalca(a)meta.com> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec index 89298983a169..f58726671fb3 100644 --- a/scripts/package/kernel.spec +++ b/scripts/package/kernel.spec @@ -55,12 +55,12 @@ patch -p1 < %{SOURCE2} %{make} %{makeflags} KERNELRELEASE=%{KERNELRELEASE} KBUILD_BUILD_VERSION=%{release} %install -mkdir -p %{buildroot}/boot -cp $(%{make} %{makeflags} -s image_name) %{buildroot}/boot/vmlinuz-%{KERNELRELEASE} +mkdir -p %{buildroot}/lib/modules/%{KERNELRELEASE} +cp $(%{make} %{makeflags} -s image_name) %{buildroot}/lib/modules/%{KERNELRELEASE}/vmlinuz %{make} %{makeflags} INSTALL_MOD_PATH=%{buildroot} modules_install %{make} %{makeflags} INSTALL_HDR_PATH=%{buildroot}/usr headers_install -cp System.map %{buildroot}/boot/System.map-%{KERNELRELEASE} -cp .config %{buildroot}/boot/config-%{KERNELRELEASE} +cp System.map %{buildroot}/lib/modules/%{KERNELRELEASE} +cp .config %{buildroot}/lib/modules/%{KERNELRELEASE}/config ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEASE}/build %if %{with_devel} %{make} %{makeflags} run-command KBUILD_RUN_COMMAND='${srctree}/scripts/package/install-extmod-build %{buildroot}/usr/src/kernels/%{KERNELRELEASE}' @@ -70,13 +70,14 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEA rm -rf %{buildroot} %post -if [ -x /sbin/installkernel -a -r /boot/vmlinuz-%{KERNELRELEASE} -a -r /boot/System.map-%{KERNELRELEASE} ]; then -cp /boot/vmlinuz-%{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm -cp /boot/System.map-%{KERNELRELEASE} /boot/.System.map-%{KERNELRELEASE}-rpm -rm -f /boot/vmlinuz-%{KERNELRELEASE} /boot/System.map-%{KERNELRELEASE} -/sbin/installkernel %{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm -rm -f /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm +if [ -x /usr/bin/kernel-install ]; then + /usr/bin/kernel-install add %{KERNELRELEASE} /lib/modules/%{KERNELRELEASE}/vmlinuz fi +for file in vmlinuz System.map config; do + if ! cmp --silent "/lib/modules/%{KERNELRELEASE}/${file}" "/boot/${file}-%{KERNELRELEASE}"; then + cp "/lib/modules/%{KERNELRELEASE}/${file}" "/boot/${file}-%{KERNELRELEASE}" + fi +done %preun if [ -x /sbin/new-kernel-pkg ]; then @@ -94,7 +95,6 @@ fi %defattr (-, root, root) /lib/modules/%{KERNELRELEASE} %exclude /lib/modules/%{KERNELRELEASE}/build -/boot/* %files headers %defattr (-, root, root)

3 weeks, 4 days

5
8
0 0

[REGRESSION] e1000e heavy packet loss on Meteor Lake - 6.14.2

by Marek Marczykowski-Górecki

Hi, After updating to 6.14.2, the ethernet adapter is almost unusable, I get over 30% packet loss. Bisect says it's this commit: commit 85f6414167da39e0da30bf370f1ecda5a58c6f7b Author: Vitaly Lifshits <vitaly.lifshits(a)intel.com> Date: Thu Mar 13 16:05:56 2025 +0200 e1000e: change k1 configuration on MTP and later platforms [ Upstream commit efaaf344bc2917cbfa5997633bc18a05d3aed27f ] Starting from Meteor Lake, the Kumeran interface between the integrated MAC and the I219 PHY works at a different frequency. This causes sporadic MDI errors when accessing the PHY, and in rare circumstances could lead to packet corruption. To overcome this, introduce minor changes to the Kumeran idle state (K1) parameters during device initialization. Hardware reset reverts this configuration, therefore it needs to be applied in a few places. Fixes: cc23f4f0b6b9 ("e1000e: Add support for Meteor Lake") Signed-off-by: Vitaly Lifshits <vitaly.lifshits(a)intel.com> Tested-by: Avigail Dahan <avigailx.dahan(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> drivers/net/ethernet/intel/e1000e/defines.h | 3 ++ drivers/net/ethernet/intel/e1000e/ich8lan.c | 80 +++++++++++++++++++++++++++-- drivers/net/ethernet/intel/e1000e/ich8lan.h | 4 ++ 3 files changed, 82 insertions(+), 5 deletions(-) My system is Novacustom V540TU laptop with Intel Core Ultra 5 125H. And the e1000e driver is running in a Xen HVM (with PCI passthrough). Interestingly, I have also another one with Intel Core Ultra 7 155H where the issue does not happen. I don't see what is different about network adapter there, they look identical on lspci (but there are differences about other devices)... I see the commit above was already backported to other stable branches too... #regzbot introduced: 85f6414167da39e0da30bf370f1ecda5a58c6f7b -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

4 weeks, 1 day

4
19
0 0

[PATCH v2 0/6] media: ti, cdns: Multiple pixel support and misc fixes

by Jai Luthra

Hi, The first four patches in this series are miscellaneous fixes and improvements in the Cadence and TI CSI-RX drivers around probing, fwnode and link creation. The last two patches add support for transmitting multiple pixels per clock on the internal bus between Cadence CSI-RX bridge and TI CSI-RX wrapper. As this internal bus is 32-bit wide, the maximum number of pixels that can be transmitted per cycle depend upon the format's bit width. Secondly, the downstream element must support unpacking of multiple pixels. Thus we export a module function that can be used by the downstream driver to negotiate the pixels per cycle on the output pixel stream of the Cadence bridge. Signed-off-by: Jai Luthra <jai.luthra(a)ideasonboard.com> --- Changes in v2: - Rebase on v6.15-rc1 - Fix lkp warnings in PATCH 5/6 missing header for FIELD_PREP - Add R-By tags from Devarsh and Changhuang - Link to v1: https://lore.kernel.org/r/20250324-probe_fixes-v1-0-5cd5b9e1cfac@ideasonboa… --- Jai Luthra (6): media: ti: j721e-csi2rx: Use devm_of_platform_populate media: ti: j721e-csi2rx: Use fwnode_get_named_child_node media: ti: j721e-csi2rx: Fix source subdev link creation media: cadence: csi2rx: Implement get_fwnode_pad op media: cadence: cdns-csi2rx: Support multiple pixels per clock cycle media: ti: j721e-csi2rx: Support multiple pixels per clock drivers/media/platform/cadence/cdns-csi2rx.c | 76 +++++++++++++++++----- drivers/media/platform/cadence/cdns-csi2rx.h | 19 ++++++ drivers/media/platform/ti/Kconfig | 3 +- .../media/platform/ti/j721e-csi2rx/j721e-csi2rx.c | 66 ++++++++++++++----- 4 files changed, 129 insertions(+), 35 deletions(-) --- base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 change-id: 20250314-probe_fixes-7e0ec33c7fee Best regards, -- Jai Luthra <jai.luthra(a)ideasonboard.com>

1 month

2
3
0 0

FAILED: patch "[PATCH] iio: dac: ad3552r-common: fix ad3541/2r ranges" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 1e758b613212b6964518a67939535910b5aee831 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025021010-antarctic-untried-a72b@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e758b613212b6964518a67939535910b5aee831 Mon Sep 17 00:00:00 2001 From: Angelo Dureghello <adureghello(a)baylibre.com> Date: Wed, 8 Jan 2025 18:29:15 +0100 Subject: [PATCH] iio: dac: ad3552r-common: fix ad3541/2r ranges Fix ad3541/2r voltage ranges to be as per ad3542r datasheet, rev. C, table 38 (page 57). The wrong ad354xr ranges was generating erroneous Vpp output. In more details: - fix wrong number of ranges, they are 5 ranges, not 6, - remove non-existent 0-3V range, - adjust order, since ad3552r_find_range() get a wrong index, producing a wrong Vpp as output. Retested all the ranges on real hardware, EVALAD3542RFMCZ: adi,output-range-microvolt (fdt): <(000000) (2500000)>; ok (Rfbx1, switch 10) <(000000) (5000000)>; ok (Rfbx1, switch 10) <(000000) (10000000)>; ok (Rfbx1, switch 10) <(-5000000) (5000000)>; ok (Rfbx2, switch +/- 5) <(-2500000) (7500000)>; ok (Rfbx2, switch -2.5/7.5) Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support") Signed-off-by: Angelo Dureghello <adureghello(a)baylibre.com> Reviewed-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250108-wip-bl-ad3552r-axi-v0-iio-testing-carlos-… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/dac/ad3552r-common.c b/drivers/iio/dac/ad3552r-common.c index 0f495df2e5ce..03e0864f5084 100644 --- a/drivers/iio/dac/ad3552r-common.c +++ b/drivers/iio/dac/ad3552r-common.c @@ -22,11 +22,10 @@ EXPORT_SYMBOL_NS_GPL(ad3552r_ch_ranges, "IIO_AD3552R"); const s32 ad3542r_ch_ranges[AD3542R_MAX_RANGES][2] = { [AD3542R_CH_OUTPUT_RANGE_0__2P5V] = { 0, 2500 }, - [AD3542R_CH_OUTPUT_RANGE_0__3V] = { 0, 3000 }, [AD3542R_CH_OUTPUT_RANGE_0__5V] = { 0, 5000 }, [AD3542R_CH_OUTPUT_RANGE_0__10V] = { 0, 10000 }, - [AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V] = { -2500, 7500 }, - [AD3542R_CH_OUTPUT_RANGE_NEG_5__5V] = { -5000, 5000 } + [AD3542R_CH_OUTPUT_RANGE_NEG_5__5V] = { -5000, 5000 }, + [AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V] = { -2500, 7500 } }; EXPORT_SYMBOL_NS_GPL(ad3542r_ch_ranges, "IIO_AD3552R"); diff --git a/drivers/iio/dac/ad3552r.h b/drivers/iio/dac/ad3552r.h index fd5a3dfd1d1c..4b5581039ae9 100644 --- a/drivers/iio/dac/ad3552r.h +++ b/drivers/iio/dac/ad3552r.h @@ -131,7 +131,7 @@ #define AD3552R_CH1_ACTIVE BIT(1) #define AD3552R_MAX_RANGES 5 -#define AD3542R_MAX_RANGES 6 +#define AD3542R_MAX_RANGES 5 #define AD3552R_QUAD_SPI 2 extern const s32 ad3552r_ch_ranges[AD3552R_MAX_RANGES][2]; @@ -189,16 +189,14 @@ enum ad3552r_ch_vref_select { enum ad3542r_ch_output_range { /* Range from 0 V to 2.5 V. Requires Rfb1x connection */ AD3542R_CH_OUTPUT_RANGE_0__2P5V, - /* Range from 0 V to 3 V. Requires Rfb1x connection */ - AD3542R_CH_OUTPUT_RANGE_0__3V, /* Range from 0 V to 5 V. Requires Rfb1x connection */ AD3542R_CH_OUTPUT_RANGE_0__5V, /* Range from 0 V to 10 V. Requires Rfb2x connection */ AD3542R_CH_OUTPUT_RANGE_0__10V, - /* Range from -2.5 V to 7.5 V. Requires Rfb2x connection */ - AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V, /* Range from -5 V to 5 V. Requires Rfb2x connection */ AD3542R_CH_OUTPUT_RANGE_NEG_5__5V, + /* Range from -2.5 V to 7.5 V. Requires Rfb2x connection */ + AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V, }; enum ad3552r_ch_output_range {

1 month

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025