October 2024 - Linux-stable-mirror

[PATCH 6.1.y 5.15.y 5.10.y] serial: protect uart_port_dtr_rts() in uart_shutdown() too

by Tomas Krcka

From: "Jiri Slaby (SUSE)" <jirislaby(a)kernel.org> [ Upstream commit 602babaa84d627923713acaf5f7e9a4369e77473 ] Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. Signed-off-by: Jiri Slaby (SUSE) <jirislaby(a)kernel.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20240805102046.307511-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Adapted over commit 5701cb8bf50e ("tty: Call ->dtr_rts() parameter active consistently") not in the tree] Signed-off-by: Tomas Krcka <krckatom(a)amazon.de> --- drivers/tty/serial/serial_core.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 58e857fb8dee..fd9f635dc247 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -339,14 +339,16 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state) /* * Turn off DTR and RTS early. */ - if (uport && uart_console(uport) && tty) { - uport->cons->cflag = tty->termios.c_cflag; - uport->cons->ispeed = tty->termios.c_ispeed; - uport->cons->ospeed = tty->termios.c_ospeed; - } + if (uport) { + if (uart_console(uport) && tty) { + uport->cons->cflag = tty->termios.c_cflag; + uport->cons->ispeed = tty->termios.c_ispeed; + uport->cons->ospeed = tty->termios.c_ospeed; + } - if (!tty || C_HUPCL(tty)) - uart_port_dtr_rts(uport, 0); + if (!tty || C_HUPCL(tty)) + uart_port_dtr_rts(uport, 0); + } uart_port_shutdown(port); } -- 2.40.1

1 year

1
0
0 0

[PATCH vhost 1/2] vdpa/mlx5: Fix PA offset with unaligned starting iotlb map

by Dragos Tatulea

From: Si-Wei Liu <si-wei.liu(a)oracle.com> When calculating the physical address range based on the iotlb and mr [start,end) ranges, the offset of mr->start relative to map->start is not taken into account. This leads to some incorrect and duplicate mappings. For the case when mr->start < map->start the code is already correct: the range in [mr->start, map->start) was handled by a different iteration. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Cc: stable(a)vger.kernel.org Signed-off-by: Si-Wei Liu <si-wei.liu(a)oracle.com> Signed-off-by: Dragos Tatulea <dtatulea(a)nvidia.com> --- drivers/vdpa/mlx5/core/mr.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c index 2dd21e0b399e..7d0c83b5b071 100644 --- a/drivers/vdpa/mlx5/core/mr.c +++ b/drivers/vdpa/mlx5/core/mr.c @@ -373,7 +373,7 @@ static int map_direct_mr(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_direct_mr struct page *pg; unsigned int nsg; int sglen; - u64 pa; + u64 pa, offset; u64 paend; struct scatterlist *sg; struct device *dma = mvdev->vdev.dma_dev; @@ -396,8 +396,10 @@ static int map_direct_mr(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_direct_mr sg = mr->sg_head.sgl; for (map = vhost_iotlb_itree_first(iotlb, mr->start, mr->end - 1); map; map = vhost_iotlb_itree_next(map, mr->start, mr->end - 1)) { - paend = map->addr + maplen(map, mr); - for (pa = map->addr; pa < paend; pa += sglen) { + offset = mr->start > map->start ? mr->start - map->start : 0; + pa = map->addr + offset; + paend = map->addr + offset + maplen(map, mr); + for (; pa < paend; pa += sglen) { pg = pfn_to_page(__phys_to_pfn(pa)); if (!sg) { mlx5_vdpa_warn(mvdev, "sg null. start 0x%llx, end 0x%llx\n", -- 2.46.1

1 year

2
1
0 0

stable-rc linux-6.6.y: Queues: tinyconfig: undefined reference to `irq_work_queue'

by Naresh Kamboju

Most of the tinyconfigs are failing on stable-rc linux-6.6.y. Build errors: -------------- aarch64-linux-gnu-ld: kernel/task_work.o: in function `task_work_add': task_work.c:(.text+0x190): undefined reference to `irq_work_queue' task_work.c:(.text+0x190): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `irq_work_queue' Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> metadata: ------------ git_describe: v6.6.57-251-g1870a9bd3fe7 git_repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Build: v6.6.57-251-g1870a9bd3fe7 Details: https://qa-reports.linaro.org/lkft/linux-stable-rc-queues-queue_6.6/build/v… kernel_version: 6.6.58 Regressions (compared to build v6.6.57) ------------------------------------------------------------------------ parisc: * build/gcc-11-tinyconfig mips: * build/gcc-12-tinyconfig * build/clang-19-tinyconfig * build/gcc-8-tinyconfig * build/clang-nightly-tinyconfig arm: * build/clang-19-tinyconfig * build/gcc-8-tinyconfig * build/gcc-13-tinyconfig * build/clang-nightly-tinyconfig powerpc: * build/clang-19-tinyconfig * build/gcc-8-tinyconfig * build/gcc-13-tinyconfig * build/clang-nightly-tinyconfig arm64: * build/clang-19-tinyconfig * build/gcc-8-tinyconfig * build/gcc-13-tinyconfig * build/clang-nightly-tinyconfig arc: * build/gcc-9-tinyconfig * build/gcc-8-tinyconfig s390: * build/clang-19-tinyconfig * build/gcc-8-tinyconfig * build/gcc-13-tinyconfig * build/clang-nightly-tinyconfig sparc: * build/gcc-8-tinyconfig * build/gcc-11-tinyconfig riscv: * build/clang-19-tinyconfig * build/gcc-8-tinyconfig * build/gcc-13-tinyconfig compare history links: ----- - https://qa-reports.linaro.org/lkft/linux-stable-rc-queues-queue_6.6/build/v… - https://qa-reports.linaro.org/lkft/linux-stable-rc-queues-queue_6.6/build/v… -- Linaro LKFT https://lkft.linaro.org

1 year

2
2
0 0

[PATCH] sched/topology: Enable topology_span_sane check only for debug builds

by Saurabh Sengar

On a x86 system under test with 1780 CPUs, topology_span_sane() takes around 8 seconds cumulatively for all the iterations. It is an expensive operation which does the sanity of non-NUMA topology masks. CPU topology is not something which changes very frequently hence make this check optional for the systems where the topology is trusted and need faster bootup. Restrict this to SCHED_DEBUG builds so that this penalty can be avoided for the systems who wants to avoid it. Fixes: ccf74128d66c ("sched/topology: Assert non-NUMA topology masks don't (partially) overlap") Signed-off-by: Saurabh Sengar <ssengar(a)linux.microsoft.com> --- kernel/sched/topology.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 9748a4c8d668..dacc8c6f978b 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -2354,6 +2354,7 @@ static struct sched_domain *build_sched_domain(struct sched_domain_topology_leve return sd; } +#ifdef CONFIG_SCHED_DEBUG /* * Ensure topology masks are sane, i.e. there are no conflicts (overlaps) for * any two given CPUs at this (non-NUMA) topology level. @@ -2387,6 +2388,7 @@ static bool topology_span_sane(struct sched_domain_topology_level *tl, return true; } +#endif /* * Build sched domains for a given set of CPUs and attach the sched domains @@ -2417,8 +2419,10 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att sd = NULL; for_each_sd_topology(tl) { +#ifdef CONFIG_SCHED_DEBUG if (WARN_ON(!topology_span_sane(tl, cpu_map, i))) goto error; +#endif sd = build_sched_domain(tl, cpu_map, attr, sd, i); -- 2.43.0

1 year

4
3
0 0

menuconfig: missing options in drivers - input device

by Edmund Raile

Hello, I'd like to report a regression to menuconfig. In "Device Drivers" ---> "Input device support" There used to be submenus for keyboards, mice etc. Now, only the entry "Hardware I/O ports" remains. They can still be accessed (and configured) by searching for them, then pressing the corresponding number: /Keyboard /KEYBOARD_ATKBD I also determined the commit: f79dc03fe68c79d388908182e68d702f7f1786bc kconfig: refactor choice value calculation #regzbot introduced: f79dc03fe68c I've only encountered this here but it is not impossible other entries elsewhere in menuconfig might be missing aswell. The issue is present in stable 6.11.5 and mainline. Kind regards, Edmund Raile.

1 year

1
0
0 0

firewire-ohci: device rediscovery hardlock regression

by Edmund Raile

Hello, I'd like to report a regression in firewire-ohci that results in the kernel hardlocking when re-discovering a FireWire device. TI XIO2213B RME FireFace 800 It will occur under three conditions: * power-cycling the FireWire device * un- and re-plugging the FireWire device * suspending and then waking the PC Often it would also occur directly on boot in QEMU but I have not yet observed this specific behavior on bare metal. Here is an excerpt from the stack trace (don't know whether it is acceptable to send in full): kernel: ------------[ cut here ]------------ kernel: refcount_t: addition on 0; use-after-free. kernel: WARNING: CPU: 3 PID: 116 at lib/refcount.c:25 refcount_warn_saturate (/build/linux/lib/refcount.c:25 (discriminator 1)) kernel: Workqueue: firewire_ohci bus_reset_work kernel: RIP: 0010:refcount_warn_saturate (/build/linux/lib/refcount.c:25 (discriminator 1)) kernel: Call Trace: kernel: <TASK> kernel: ? refcount_warn_saturate (/build/linux/lib/refcount.c:25 (discriminator 1)) kernel: ? __warn.cold (/build/linux/kernel/panic.c:693) kernel: ? refcount_warn_saturate (/build/linux/lib/refcount.c:25 (discriminator 1)) kernel: ? report_bug (/build/linux/lib/bug.c:180 /build/linux/lib/bug.c:219) kernel: ? handle_bug (/build/linux/arch/x86/kernel/traps.c:218) kernel: ? exc_invalid_op (/build/linux/arch/x86/kernel/traps.c:260 (discriminator 1)) kernel: ? asm_exc_invalid_op (/build/linux/./arch/x86/include/asm/idtentry.h:621) kernel: ? refcount_warn_saturate (/build/linux/lib/refcount.c:25 (discriminator 1)) kernel: for_each_fw_node (/build/linux/./include/linux/refcount.h:190 /build/linux/./include/linux/refcount.h:241 /build/linux/./include/linux/refcount.h:258 /build/linux/drivers/firewire/core.h:199 /build/linux/drivers/firewire/core-topology.c:275) kernel: ? __pfx_report_found_node (/build/linux/drivers/firewire/core- topology.c:312) kernel: fw_core_handle_bus_reset (/build/linux/drivers/firewire/core- topology.c:399 (discriminator 1) /build/linux/drivers/firewire/core- topology.c:504 (discriminator 1)) kernel: bus_reset_work (/build/linux/drivers/firewire/ohci.c:2121) kernel: process_one_work (/build/linux/./arch/x86/include/asm/jump_label.h:27 /build/linux/./include/linux/jump_label.h:207 /build/linux/./include/trace/events/workqueue.h:110 /build/linux/kernel/workqueue.c:3236) kernel: worker_thread (/build/linux/kernel/workqueue.c:3306 (discriminator 2) /build/linux/kernel/workqueue.c:3393 (discriminator 2)) kernel: ? __pfx_worker_thread (/build/linux/kernel/workqueue.c:3339) kernel: kthread (/build/linux/kernel/kthread.c:389) kernel: ? __pfx_kthread (/build/linux/kernel/kthread.c:342) kernel: ret_from_fork (/build/linux/arch/x86/kernel/process.c:153) kernel: ? __pfx_kthread (/build/linux/kernel/kthread.c:342) kernel: ret_from_fork_asm (/build/linux/arch/x86/entry/entry_64.S:254) kernel: </TASK> I have identified the commit via bisection: 24b7f8e5cd656196a13077e160aec45ad89b58d9 firewire: core: use helper functions for self ID sequence It was part of the following patch series: firewire: add tracepoints events for self ID sequence https://lore.kernel.org/all/20240605235155.116468-6-o-takashi@sakamocchi.jp/ #regzbot introduced: 24b7f8e5cd65 Since this was before v6.10-rc5 and stable 6.10.14 is EOL, stable v6.11.5 and mainline are affected. Reversion appears to be non-trivial as it is part of a patch series, other files have been altered as well and other commits build on top of it. Call chain: core-topology.c fw_core_handle_bus_reset() -> core-topology.c for_each_fw_node(card, local_node, report_found_node) -> core.h fw_node_get(root) -> refcount.h __refcount_inc(&node) -> refcount.h __refcount_add(1, r, oldp); -> refcount.h refcount_warn_saturate(r, REFCOUNT_ADD_UAF); -> refcount.h REFCOUNT_WARN("addition on 0; use-after-free") Since local_node of fw_core_handle_bus_reset() is retrieved by local_node = build_tree(card, self_ids, self_id_count); build_tree() needs to be looked at, it was indeed altered by 24b7f8e5cd65. After a hard 3 hour look traversing all used functions and comparing against the original function (as of e404cacfc5ed), this caught my eye: for (port_index = 0; port_index < total_port_count; ++port_index) { switch (port_status) { case PHY_PACKET_SELF_ID_PORT_STATUS_PARENT: node->color = i; In both for loops, "port_index" was replaced by "i" "i" remains in use above: for (i = 0, h = &stack; i < child_port_count; i++) h = h->prev; While the original also used the less descriptive i in the loop for (i = 0; i < port_count; i++) { switch (get_port_type(sid, i)) { case SELFID_PORT_PARENT: node->color = i; but reset it to 0 at the beginning of the loop. So the stray "i" in the for loop should be replaced with the loop iterator "port_index" as it is meant to be synchronous with the loop iterator (i.e. the port_index), no? diff --git a/drivers/firewire/core-topology.c b/drivers/firewire/core- topology.c index 8c10f47cc8fc..7fd91ba9c9c4 100644 --- a/drivers/firewire/core-topology.c +++ b/drivers/firewire/core-topology.c @@ -207,7 +207,7 @@ static struct fw_node *build_tree(struct fw_card *card, const u32 *sid, int self // the node->ports array where the parent node should be. Later, // when we handle the parent node, we fix up the reference. ++parent_count; - node->color = i; + node->color = port_index; break; What threw me off was discaridng node->color as it would be replaced later anyways (can't be important!), or so I thought. Please tell me, is this line of reasoning correct or am I missing something? Compiling 24b7f8e5cd65 and later mainline with the patch above resulted in a kernel that didn't crash! In case my solution should turn out to be correct, I will gladly submit the patch. Kind regards, Edmund Raile.

1 year

2
1
0 0

[PATCH v2 0/2] soc: qcom: pmic_glink: Resolve failures to bring up pmic_glink

by Bjorn Andersson

With the transition of pd-mapper into the kernel, the timing was altered such that on some targets the initial rpmsg_send() requests from pmic_glink clients would be attempted before the firmware had announced intents, and the firmware reject intent requests. Fix this Signed-off-by: Bjorn Andersson <bjorn.andersson(a)oss.qualcomm.com> --- Changes in v2: - Introduced "intents" and fixed a few spelling mistakes in the commit message of patch 1 - Cleaned up log snippet in commit message of patch 2, added battery manager log - Changed the arbitrary 10 second timeout to 5... Ought to be enough for anybody. - Added a small sleep in the send-loop in patch 2, and by that refactored the loop completely. - Link to v1: https://lore.kernel.org/r/20241022-pmic-glink-ecancelled-v1-0-9e26fc74e0a3@… --- Bjorn Andersson (2): rpmsg: glink: Handle rejected intent request better soc: qcom: pmic_glink: Handle GLINK intent allocation rejections drivers/rpmsg/qcom_glink_native.c | 10 +++++++--- drivers/soc/qcom/pmic_glink.c | 25 ++++++++++++++++++++++--- 2 files changed, 29 insertions(+), 6 deletions(-) --- base-commit: 42f7652d3eb527d03665b09edac47f85fb600924 change-id: 20241022-pmic-glink-ecancelled-d899a9ca0358 Best regards, -- Bjorn Andersson <bjorn.andersson(a)oss.qualcomm.com>

1 year

4
7
0 0

[PATCH 5.10] drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)

by Artem Sdvizhkov

From: "Wachowski, Karol" <karol.wachowski(a)intel.com> commit 39bc27bd688066a63e56f7f64ad34fae03fbe3b8 upstream. Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); Return -EINVAL early if COW mapping is detected. This bug affects all drm drivers using default shmem helpers. It can be reproduced by this simple example: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0; Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects") Cc: Noralf Trønnes <noralf(a)tronnes.org> Cc: Eric Anholt <eric(a)anholt.net> Cc: Rob Herring <robh(a)kernel.org> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)gmail.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.2+ Signed-off-by: Wachowski, Karol <karol.wachowski(a)intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20240520100514.925681-1-jacek… [Artem: bp to fix CVE-2024-39497, in order to adapt this patch to branch 5.10 add header file mm/internal.h] Signed-off-by: Artem Sdvizhkov <raclesdv(a)gmail.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index e8f07305e279..37f347f39c88 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -17,6 +17,8 @@ #include <drm/drm_prime.h> #include <drm/drm_print.h> +#include "../../../mm/internal.h" /* is_cow_mapping() */ + /** * DOC: overview * @@ -630,6 +632,9 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) return ret; } + if (is_cow_mapping(vma->vm_flags)) + return -EINVAL; + shmem = to_drm_gem_shmem_obj(obj); ret = drm_gem_shmem_get_pages(shmem); -- 2.43.0

1 year

1
0
0 0

[PATCH v10 0/6] RISC-V: Detect and report speed of unaligned vector accesses

by Charlie Jenkins

Adds support for detecting and reporting the speed of unaligned vector accesses on RISC-V CPUs. Adds vec_misaligned_speed key to the hwprobe adds Zicclsm to cpufeature and fixes the check for scalar unaligned emulated all CPUs. The vec_misaligned_speed key keeps the same format as the scalar unaligned access speed key. This set does not emulate unaligned vector accesses on CPUs that do not support them. Only reports if userspace can run them and speed of unaligned vector accesses if supported. Signed-off-by: Charlie Jenkins <charlie(a)rivosinc.com> Signed-off-by: Jesse Taube <jesse(a)rivosinc.com> --- Changes in V6: Added ("RISC-V: Scalar unaligned access emulated on hotplug CPUs") Changes in V8: Dropped Zicclsm s/RISCV_HWPROBE_VECTOR_MISALIGNED/RISCV_HWPROBE_MISALIGNED_VECTOR/g to match RISCV_HWPROBE_MISALIGNED_SCALAR_* Rebased onto palmer/fixes (32d5f7add080a936e28ab4142bfeea6b06999789) Changes in V9: Missed a RISCV_HWPROBE_VECTOR_MISALIGNED... Changes in V10: - I sent on behalf of Jesse - Remove v0 from clobber args in inline asm and leave comment --- Jesse Taube (6): RISC-V: Check scalar unaligned access on all CPUs RISC-V: Scalar unaligned access emulated on hotplug CPUs RISC-V: Replace RISCV_MISALIGNED with RISCV_SCALAR_MISALIGNED RISC-V: Detect unaligned vector accesses supported RISC-V: Report vector unaligned access speed hwprobe RISC-V: hwprobe: Document unaligned vector perf key Documentation/arch/riscv/hwprobe.rst | 16 +++ arch/riscv/Kconfig | 58 ++++++++++- arch/riscv/include/asm/cpufeature.h | 10 +- arch/riscv/include/asm/entry-common.h | 11 -- arch/riscv/include/asm/hwprobe.h | 2 +- arch/riscv/include/asm/vector.h | 2 + arch/riscv/include/uapi/asm/hwprobe.h | 5 + arch/riscv/kernel/Makefile | 3 +- arch/riscv/kernel/copy-unaligned.h | 5 + arch/riscv/kernel/fpu.S | 4 +- arch/riscv/kernel/sys_hwprobe.c | 41 ++++++++ arch/riscv/kernel/traps_misaligned.c | 139 +++++++++++++++++++++++-- arch/riscv/kernel/unaligned_access_speed.c | 156 +++++++++++++++++++++++++++-- arch/riscv/kernel/vec-copy-unaligned.S | 58 +++++++++++ arch/riscv/kernel/vector.c | 2 +- 15 files changed, 474 insertions(+), 38 deletions(-) --- base-commit: 98f7e32f20d28ec452afb208f9cffc08448a2652 change-id: 20240920-jesse_unaligned_vector-7083fd28659c -- - Charlie

1 year

2
3
0 0

[PATCH] iio: light: veml6030: fix microlux value calculation

by Javier Carrasco

The raw value conversion to obtain a measurement in lux as INT_PLUS_MICRO does not calculate the decimal part properly to display it as micro (in this case microlux). It only calculates the module to obtain the decimal part from a resolution that is 10000 times the provided in the datasheet (0.5376 lux/cnt for the veml6030). The resulting value must still be multiplied by 100 to make it micro. This bug was introduced with the original implementation of the driver. Cc: stable(a)vger.kernel.org Fixes: 7b779f573c48 ("iio: light: add driver for veml6030 ambient light sensor") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- I found this almost by chance while testing new supported devices. The decimal part was always suspiciously small, and when I compared samples to the expected value according to the datasheet, it became clear what was going on. Example with a veml7700 (same resolution as the veml6030): Resolution for gain = 1/8, IT = 100 ms: 0.5736 lux/cnt. cat in_illuminance_raw in_illuminance_input 40 21.005040 -> wrong! 40 * 0.5736 is 21.504. Tested with a veml6035 and a veml7700, the same will happen with the original veml6030, as the operation is identical for all devices. --- drivers/iio/light/veml6030.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/light/veml6030.c b/drivers/iio/light/veml6030.c index d6f3b104b0e6..a0bf03e37df7 100644 --- a/drivers/iio/light/veml6030.c +++ b/drivers/iio/light/veml6030.c @@ -691,7 +691,7 @@ static int veml6030_read_raw(struct iio_dev *indio_dev, } if (mask == IIO_CHAN_INFO_PROCESSED) { *val = (reg * data->cur_resolution) / 10000; - *val2 = (reg * data->cur_resolution) % 10000; + *val2 = (reg * data->cur_resolution) % 10000 * 100; return IIO_VAL_INT_PLUS_MICRO; } *val = reg; --- base-commit: 15e7d45e786a62a211dd0098fee7c57f84f8c681 change-id: 20241016-veml6030-fix-processed-micro-616d00d555dc Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

1 year

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024