- Linux-stable-mirror - lists.linaro.org

[PATCH] nvme-pci: add quirk for Wodposit WPBSNM8-256GTP to disable secondary temp thresholds

by Ilikara Zheng

Secondary temperature thresholds (temp2_{min,max}) were not reported properly on this NVMe SSD. This resulted in an error while attempting to read these values with sensors(1): ERROR: Can't get value of subfeature temp2_min: I/O error ERROR: Can't get value of subfeature temp2_max: I/O error Add the device to the nvme_id_table with the NVME_QUIRK_NO_SECONDARY_TEMP_THRESH flag to suppress access to all non- composite temperature thresholds. Cc: stable(a)vger.kernel.org Signed-off-by: Ilikara Zheng <ilikara(a)aosc.io> --- drivers/nvme/host/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index e5ca8301bb8b..31049f33f27d 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3997,6 +3997,8 @@ static const struct pci_device_id nvme_id_table[] = { .driver_data = NVME_QUIRK_NO_DEEPEST_PS, }, { PCI_DEVICE(0x1e49, 0x0041), /* ZHITAI TiPro7000 NVMe SSD */ .driver_data = NVME_QUIRK_NO_DEEPEST_PS, }, + { PCI_DEVICE(0x1fa0, 0x2283), /* Wodposit WPBSNM8-256GTP */ + .driver_data = NVME_QUIRK_NO_SECONDARY_TEMP_THRESH, }, { PCI_DEVICE(0x025e, 0xf1ac), /* SOLIDIGM P44 pro SSDPFKKW020X7 */ .driver_data = NVME_QUIRK_NO_DEEPEST_PS, }, { PCI_DEVICE(0xc0a9, 0x540a), /* Crucial P2 */ -- 2.52.0

46 minutes

3
4
0 0

[PATCH 6.18 200/614] drm/xe: Enforce correct user fence signaling order using

by Greg Kroah-Hartman

6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Matthew Brost <matthew.brost(a)intel.com> [ Upstream commit adda4e855ab6409a3edaa585293f1f2069ab7299 ] Prevent application hangs caused by out-of-order fence signaling when user fences are attached. Use drm_syncobj (via dma-fence-chain) to guarantee that each user fence signals in order, regardless of the signaling order of the attached fences. Ensure user fence writebacks to user space occur in the correct sequence. v7: - Skip drm_syncbj create of error (CI) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Link: https://patch.msgid.link/20251031234050.3043507-2-matthew.brost@intel.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/xe/xe_exec_queue.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c b/drivers/gpu/drm/xe/xe_exec_queue.c index cb5f204c08ed6..a6efe4e8ab556 100644 --- a/drivers/gpu/drm/xe/xe_exec_queue.c +++ b/drivers/gpu/drm/xe/xe_exec_queue.c @@ -344,6 +344,9 @@ void xe_exec_queue_destroy(struct kref *ref) struct xe_exec_queue *q = container_of(ref, struct xe_exec_queue, refcount); struct xe_exec_queue *eq, *next; + if (q->ufence_syncobj) + drm_syncobj_put(q->ufence_syncobj); + if (q->ufence_syncobj) drm_syncobj_put(q->ufence_syncobj); -- 2.51.0

58 minutes

2
1
0 0

[PATCH] Revert "gpio: swnode: don't use the swnode's name as the key for GPIO lookup"

by Charles Keepax

This reverts commit 25decf0469d4c91d90aa2e28d996aed276bfc622. This software node change doesn't actually fix any current issues with the kernel, it is an improvement to the lookup process rather than fixing a live bug. It also causes a couple of regressions with shipping laptops, which relied on the label based lookup. There is a fix for the regressions in mainline, the first 5 patches of [1]. However, those patches are fairly substantial changes and given the patch causing the regression doesn't actually fix a bug it seems better to just revert it in stable. CC: stable(a)vger.kernel.org # 6.18 Link: https://lore.kernel.org/linux-sound/20251120-reset-gpios-swnodes-v7-0-a1004… [1] Link: https://lore.kernel.org/stable/20251125102924.3612459-1-ckeepax@opensource.… [2] Closes: https://github.com/thesofproject/linux/issues/5599 Closes: https://github.com/thesofproject/linux/issues/5603 Acked-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> --- This fix for the software node lookups is also required on 6.18 stable, see the discussion for 6.12/6.17 in [2] for why we are doing a revert rather than backporting the other fixes. The "full" fixes are merged in 6.19 so this should be the last kernel we need to push this revert onto. Thanks, Charles drivers/gpio/gpiolib-swnode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c index e3806db1c0e07..f21dbc28cf2c8 100644 --- a/drivers/gpio/gpiolib-swnode.c +++ b/drivers/gpio/gpiolib-swnode.c @@ -41,7 +41,7 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode) !strcmp(gdev_node->name, GPIOLIB_SWNODE_UNDEFINED_NAME)) return ERR_PTR(-ENOENT); - gdev = gpio_device_find_by_fwnode(fwnode); + gdev = gpio_device_find_by_label(gdev_node->name); return gdev ?: ERR_PTR(-EPROBE_DEFER); } -- 2.47.3

1 hour, 3 minutes

1
0
0 0

[PATCH] bus: fsl-mc: fix use-after-free in driver_override_show()

by Gui-Dong Han

The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock. This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function. Fix this by holding the device_lock around the read operation. Fixes: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override' in the mc-bus") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)gmail.com> --- I verified this with a stress test that continuously writes/reads the attribute. It triggered KASAN and leaked bytes like a0 f4 81 9f a3 ff ff (likely kernel pointers). Since driver_override is world-readable (0644), this allows unprivileged users to leak kernel pointers and bypass KASLR. Similar races were fixed in other buses (e.g., commits 9561475db680 and 91d44c1afc61). Currently, 9 of 11 buses handle this correctly; this patch fixes one of the remaining two. --- drivers/bus/fsl-mc/fsl-mc-bus.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index 25845c04e562..a97baf2cbcdd 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -202,8 +202,12 @@ static ssize_t driver_override_show(struct device *dev, struct device_attribute *attr, char *buf) { struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev); + ssize_t len; - return sysfs_emit(buf, "%s\n", mc_dev->driver_override); + device_lock(dev); + len = sysfs_emit(buf, "%s\n", mc_dev->driver_override); + device_unlock(dev); + return len; } static DEVICE_ATTR_RW(driver_override); -- 2.43.0

1 hour, 14 minutes

2
3
0 0

[PATCH v2] [STABLE ONLY] firmware: arm_scmi: Fix unused notifier-block in unregister

by Amitai Gottlieb

In scmi_devm_notifier_unregister(), the notifier-block argument was ignored and never passed to devres_release(). As a result, the function always returned -ENOENT and failed to unregister the notifier. Drivers that depend on this helper for teardown could therefore hit unexpected failures, including kernel panics. Commit 264a2c520628 ("firmware: arm_scmi: Simplify scmi_devm_notifier_unregister") removed the faulty code path during refactoring and hence this fix is not required upstream. Cc: <stable(a)vger.kernel.org> # 5.15.x, 6.1.x, and 6.6.x Fixes: 5ad3d1cf7d34 ("firmware: arm_scmi: Introduce new devres notification ops") Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Reviewed-by: Cristian Marussi <cristian.marussi(a)arm.com> Signed-off-by: Amitai Gottlieb <amitaig(a)hailo.ai> --- v2: * changed the wording of commit-message after suggestions made by Sudeep Holla <sudeep.holla(a)arm.com> drivers/firmware/arm_scmi/notify.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c index 0efd20cd9d69..4782b115e6ec 100644 --- a/drivers/firmware/arm_scmi/notify.c +++ b/drivers/firmware/arm_scmi/notify.c @@ -1539,6 +1539,7 @@ static int scmi_devm_notifier_unregister(struct scmi_device *sdev, dres.handle = sdev->handle; dres.proto_id = proto_id; dres.evt_id = evt_id; + dres.nb = nb; if (src_id) { dres.__src_id = *src_id; dres.src_id = &dres.__src_id; -- 2.34.1

1 hour, 15 minutes

2
1
0 0

[PATCH v4] w1: therm: Fix off-by-one buffer overflow in alarms_store

by Thorsten Blum

The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code. Cc: stable(a)vger.kernel.org Fixes: e2c94d6f5720 ("w1_therm: adding alarm sysfs entry") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- Compile-tested only. Changes in v4: - Use simple_strtoll because kstrtoint also parses long long internally - Return -ERANGE in addition to -EINVAL to match kstrtoint's behavior - Remove any changes unrelated to fixing the buffer overflow (Krzysztof) while maintaining the same behavior and return values as before - Link to v3: https://lore.kernel.org/lkml/20251030155614.447905-1-thorsten.blum@linux.de… Changes in v3: - Add integer range check for 'temp' to match kstrtoint() behavior - Explicitly cast 'temp' to int when calling int_to_short() - Link to v2: https://lore.kernel.org/lkml/20251029130045.70127-2-thorsten.blum@linux.dev/ Changes in v2: - Fix buffer overflow instead of truncating the copy using strscpy() - Parse buffer directly using simple_strtol() as suggested by David - Update patch subject and description - Link to v1: https://lore.kernel.org/lkml/20251017170047.114224-2-thorsten.blum@linux.de… --- drivers/w1/slaves/w1_therm.c | 64 ++++++++++++------------------------ 1 file changed, 21 insertions(+), 43 deletions(-) diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c index 9ccedb3264fb..5707fa34e804 100644 --- a/drivers/w1/slaves/w1_therm.c +++ b/drivers/w1/slaves/w1_therm.c @@ -1836,55 +1836,36 @@ static ssize_t alarms_store(struct device *device, struct w1_slave *sl = dev_to_w1_slave(device); struct therm_info info; u8 new_config_register[3]; /* array of data to be written */ - int temp, ret; - char *token = NULL; + long long temp; + int ret = 0; s8 tl, th; /* 1 byte per value + temp ring order */ - char *p_args, *orig; - - p_args = orig = kmalloc(size, GFP_KERNEL); - /* Safe string copys as buf is const */ - if (!p_args) { - dev_warn(device, - "%s: error unable to allocate memory %d\n", - __func__, -ENOMEM); - return size; - } - strcpy(p_args, buf); - - /* Split string using space char */ - token = strsep(&p_args, " "); - - if (!token) { - dev_info(device, - "%s: error parsing args %d\n", __func__, -EINVAL); - goto free_m; - } - - /* Convert 1st entry to int */ - ret = kstrtoint (token, 10, &temp); + const char *p = buf; + char *endp; + + temp = simple_strtoll(p, &endp, 10); + if (p == endp || *endp != ' ') + ret = -EINVAL; + else if (temp < INT_MIN || temp > INT_MAX) + ret = -ERANGE; if (ret) { dev_info(device, "%s: error parsing args %d\n", __func__, ret); - goto free_m; + goto err; } tl = int_to_short(temp); - /* Split string using space char */ - token = strsep(&p_args, " "); - if (!token) { - dev_info(device, - "%s: error parsing args %d\n", __func__, -EINVAL); - goto free_m; - } - /* Convert 2nd entry to int */ - ret = kstrtoint (token, 10, &temp); + p = endp + 1; + temp = simple_strtoll(p, &endp, 10); + if (p == endp) + ret = -EINVAL; + else if (temp < INT_MIN || temp > INT_MAX) + ret = -ERANGE; if (ret) { dev_info(device, "%s: error parsing args %d\n", __func__, ret); - goto free_m; + goto err; } - /* Prepare to cast to short by eliminating out of range values */ th = int_to_short(temp); @@ -1905,7 +1886,7 @@ static ssize_t alarms_store(struct device *device, dev_info(device, "%s: error reading from the slave device %d\n", __func__, ret); - goto free_m; + goto err; } /* Write data in the device RAM */ @@ -1913,7 +1894,7 @@ static ssize_t alarms_store(struct device *device, dev_info(device, "%s: Device not supported by the driver %d\n", __func__, -ENODEV); - goto free_m; + goto err; } ret = SLAVE_SPECIFIC_FUNC(sl)->write_data(sl, new_config_register); @@ -1922,10 +1903,7 @@ static ssize_t alarms_store(struct device *device, "%s: error writing to the slave device %d\n", __func__, ret); -free_m: - /* free allocated memory */ - kfree(orig); - +err: return size; } -- 2.51.1

1 hour, 18 minutes

3
6
0 0

Re: [syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry

by syzbot

Hello, syzbot has tested the proposed patch and the reproducer did not trigger any issue: Reported-by: syzbot+f792df426ff0f5ceb8d1(a)syzkaller.appspotmail.com Tested-by: syzbot+f792df426ff0f5ceb8d1(a)syzkaller.appspotmail.com Tested on: commit: 40fbbd64 Merge tag 'pull-fixes' of git://git.kernel.or.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=154c931a580000 kernel config: https://syzkaller.appspot.com/x/.config?x=72e765d013fc99c dashboard link: https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1 compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8 patch: https://syzkaller.appspot.com/x/patch.diff?x=118de184580000 Note: testing is done by a robot and is best-effort only.

1 hour, 33 minutes

1
0
0 0

[PATCH v4] drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer

by Krzysztof Niemiec

Initialize the eb.vma array with values of 0 when the eb structure is first set up. In particular, this sets the eb->vma[i].vma pointers to NULL, simplifying cleanup and getting rid of the bug described below. During the execution of eb_lookup_vmas(), the eb->vma array is successively filled up with struct eb_vma objects. This process includes calling eb_add_vma(), which might fail; however, even in the event of failure, eb->vma[i].vma is set for the currently processed buffer. If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which prompts a call to eb_release_vmas() to clean up the mess. Since eb_lookup_vmas() might fail during processing any (possibly not first) buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know at what point did the lookup function fail. In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is set to NULL in case i915_gem_object_userptr_submit_init() fails; the current one needs to be cleaned up by eb_release_vmas() at this point, so the next one is set. If eb_add_vma() fails, neither the current nor the next vma is nullified, which is a source of a NULL deref bug described in [1]. When entering eb_lookup_vmas(), the vma pointers are set to the slab poison value, instead of NULL. This doesn't matter for the actual lookup, since it gets overwritten anyway, however the eb_release_vmas() function only recognizes NULL as the stopping value, hence the pointers are being nullified as they go in case of intermediate failure. This patch changes the approach to filling them all with NULL at the start instead, rather than handling that manually during failure. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15062 Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf") Reported-by: Gangmin Kim <km.kim1503(a)gmail.com> Cc: <stable(a)vger.kernel.org> # 5.16.x Signed-off-by: Krzysztof Niemiec <krzysztof.niemiec(a)intel.com> --- I messed up the continuity in previous revisions; the original patch was sent as [1], and the first revision (which I didn't mark as v2 due to the title change) was sent as [2]. This is the full current changelog: v4: - delete an empty line (Janusz), reword the comment a bit (Krzysztof, Janusz) v3: - use memset() to fill the entire eb.vma array with zeros instead of looping through the elements (Janusz) - add a comment clarifying the mechanism of the initial allocation (Janusz) - change the commit log again, including title - rearrange the tags to keep checkpatch happy v2: - set the eb->vma[i].vma pointers to NULL during setup instead of ad-hoc at failure (Janusz) - romanize the reporter's name (Andi, offline) - change the commit log, including title [1] https://patchwork.freedesktop.org/series/156832/ [2] https://patchwork.freedesktop.org/series/158036/ .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 37 +++++++++---------- 1 file changed, 17 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index b057c2fa03a4..348023d13668 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -951,13 +951,13 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) vma = eb_lookup_vma(eb, eb->exec[i].handle); if (IS_ERR(vma)) { err = PTR_ERR(vma); - goto err; + return err; } err = eb_validate_vma(eb, &eb->exec[i], vma); if (unlikely(err)) { i915_vma_put(vma); - goto err; + return err; } err = eb_add_vma(eb, &current_batch, i, vma); @@ -966,19 +966,8 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) if (i915_gem_object_is_userptr(vma->obj)) { err = i915_gem_object_userptr_submit_init(vma->obj); - if (err) { - if (i + 1 < eb->buffer_count) { - /* - * Execbuffer code expects last vma entry to be NULL, - * since we already initialized this entry, - * set the next value to NULL or we mess up - * cleanup handling. - */ - eb->vma[i + 1].vma = NULL; - } - + if (err) return err; - } eb->vma[i].flags |= __EXEC_OBJECT_USERPTR_INIT; eb->args->flags |= __EXEC_USERPTR_USED; @@ -986,10 +975,6 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) } return 0; - -err: - eb->vma[i].vma = NULL; - return err; } static int eb_lock_vmas(struct i915_execbuffer *eb) @@ -3375,7 +3360,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, eb.exec = exec; eb.vma = (struct eb_vma *)(exec + args->buffer_count + 1); - eb.vma[0].vma = NULL; + memset(eb.vma, 0x00, args->buffer_count * sizeof(struct eb_vma)); + eb.batch_pool = NULL; eb.invalid_flags = __EXEC_OBJECT_UNKNOWN_FLAGS; @@ -3584,7 +3570,18 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data, if (err) return err; - /* Allocate extra slots for use by the command parser */ + /* + * Allocate extra slots for use by the command parser. + * + * Note that this allocation handles two different arrays (the + * exec2_list array, and the eventual eb.vma array introduced in + * i915_gem_do_execubuffer()), that reside in virtually contiguous + * memory. Also note that the allocation intentionally doesn't fill the + * area with zeros (because the exec2_list part doesn't need to be, as + * it's immediately overwritten by user data a few lines below). + * However, the eb.vma part is explicitly zeroed later in + * i915_gem_do_execbuffer(). + */ exec2_list = kvmalloc_array(count + 2, eb_element_size(), __GFP_NOWARN | GFP_KERNEL); if (exec2_list == NULL) { -- 2.45.2

1 hour, 42 minutes

4
3
0 0

[PATCH] ext4: xattr: fix wrong search.here in clone_block

by Jinchao Wang

syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1]. When xattr_find_entry() returns -ENODATA, search.here still points to the position after the last valid entry. ext4_xattr_block_set() clones the xattr block because the original block maybe shared and must not be modified in place. In the clone_block, search.here is recomputed unconditionally from the old offset, which may place it past search.first. This results in a negative reset size and an out-of-bounds memmove() in ext4_xattr_set_entry(). Fix this by initializing search.here correctly when search.not_found is set. #syz test [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1 Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set) Cc: stable(a)vger.kernel.org Reported-by: syzbot+f792df426ff0f5ceb8d1(a)syzkaller.appspotmail.com Signed-off-by: Jinchao Wang <wangjinchao600(a)gmail.com> --- fs/ext4/xattr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 2e02efbddaac..cc30abeb7f30 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1980,7 +1980,10 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode, goto cleanup; s->first = ENTRY(header(s->base)+1); header(s->base)->h_refcount = cpu_to_le32(1); - s->here = ENTRY(s->base + offset); + if (s->not_found) + s->here = s->first; + else + s->here = ENTRY(s->base + offset); s->end = s->base + bs->bh->b_size; /* -- 2.43.0

1 hour, 55 minutes

1
0
0 0

Re: [PATCH v1] rust: Add some DMA helpers for architectures without CONFIG_HAS_DMA

by Danilo Krummrich

(Cc: stable(a)vger.kernel.org) On Thu Dec 4, 2025 at 5:06 PM CET, FUJITA Tomonori wrote: > Add dma_set_mask(), dma_set_coherent_mask(), dma_map_sgtable(), and > dma_max_mapping_size() helpers to fix a build error when > CONFIG_HAS_DMA is not enabled. > > Note that when CONFIG_HAS_DMA is enabled, they are included in both > bindings_generated.rs and bindings_helpers_generated.rs. The former > takes precedence so behavior remains unchanged in that case. > > This fixes the following build error on UML: > > error[E0425]: cannot find function `dma_set_mask` in crate `bindings` > --> /linux/rust/kernel/dma.rs:46:38 > | > 46 | to_result(unsafe { bindings::dma_set_mask(self.as_ref().as_raw(), mask.value()) }) > | ^^^^^^^^^^^^ help: a function with a similar name exists: `xa_set_mark` > | > ::: /build/um/rust/bindings/bindings_generated.rs:24690:5 > | > 24690 | pub fn xa_set_mark(arg1: *mut xarray, index: ffi::c_ulong, arg2: xa_mark_t); > | ---------------------------------------------------------------------------- similarly named function `xa_set_mark` defined here > > error[E0425]: cannot find function `dma_set_coherent_mask` in crate `bindings` > --> /linux/rust/kernel/dma.rs:63:38 > | > 63 | to_result(unsafe { bindings::dma_set_coherent_mask(self.as_ref().as_raw(), mask.value()) }) > | ^^^^^^^^^^^^^^^^^^^^^ help: a function with a similar name exists: `dma_coherent_ok` > | > ::: /build/um/rust/bindings/bindings_generated.rs:52745:5 > | > 52745 | pub fn dma_coherent_ok(dev: *mut device, phys: phys_addr_t, size: usize) -> bool_; > | ---------------------------------------------------------------------------------- similarly named function `dma_coherent_ok` defined here > > error[E0425]: cannot find function `dma_map_sgtable` in crate `bindings` > --> /linux/rust/kernel/scatterlist.rs:212:23 > | > 212 | bindings::dma_map_sgtable(dev.as_raw(), sgt.as_ptr(), dir.into(), 0) > | ^^^^^^^^^^^^^^^ help: a function with a similar name exists: `dma_unmap_sgtable` > | > ::: /build/um/rust/bindings/bindings_helpers_generated.rs:1351:5 > | > 1351 | / pub fn dma_unmap_sgtable( > 1352 | | dev: *mut device, > 1353 | | sgt: *mut sg_table, > 1354 | | dir: dma_data_direction, > 1355 | | attrs: ffi::c_ulong, > 1356 | | ); > | |______- similarly named function `dma_unmap_sgtable` defined here > > error[E0425]: cannot find function `dma_max_mapping_size` in crate `bindings` > --> /linux/rust/kernel/scatterlist.rs:356:52 > | > 356 | let max_segment = match unsafe { bindings::dma_max_mapping_size(dev.as_raw()) } { > | ^^^^^^^^^^^^^^^^^^^^ not found in `bindings` > > error: aborting due to 4 previous errors > > Fixes: 101d66828a4ee ("rust: dma: add DMA addressing capabilities") > Signed-off-by: FUJITA Tomonori <fujita.tomonori(a)gmail.com> Applied to driver-core-linus, thanks! [ Use relative paths in the error splat; add 'dma' prefix. - Danilo ]

2 hours, 5 minutes

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror