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

[PATCH 1/2] PCI: Relaxed tail alignment should never increase min_align

by Ilpo Järvinen

When using relaxed tail alignment for the bridge window, pbus_size_mem() also tries to minimize min_align, which can under certain scenarios end up increasing min_align from that found by calculate_mem_align(). Ensure min_align is not increased by the relaxed tail alignment. Eventually, it would be better to add calculate_relaxed_head_align() similar to calculate_mem_align() which finds out what alignment can be used for the head without introducing any gaps into the bridge window to give flexibility on head address too. But that looks relatively complex algorithm so it requires much more testing than fixing the immediate problem causing a regression. Fixes: 67f9085596ee ("PCI: Allow relaxed bridge window tail sizing for optional resources") Reported-by: Rio <rio(a)r26.me> Tested-by: Rio <rio(a)r26.me> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> --- drivers/pci/setup-bus.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 07c3d021a47e..f90d49cd07da 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1169,6 +1169,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, resource_size_t children_add_size = 0; resource_size_t children_add_align = 0; resource_size_t add_align = 0; + resource_size_t relaxed_align; if (!b_res) return -ENOSPC; @@ -1246,8 +1247,9 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, if (bus->self && size0 && !pbus_upstream_space_available(bus, mask | IORESOURCE_PREFETCH, type, size0, min_align)) { - min_align = 1ULL << (max_order + __ffs(SZ_1M)); - min_align = max(min_align, win_align); + relaxed_align = 1ULL << (max_order + __ffs(SZ_1M)); + relaxed_align = max(relaxed_align, win_align); + min_align = min(min_align, relaxed_align); size0 = calculate_memsize(size, min_size, 0, 0, resource_size(b_res), win_align); pci_info(bus->self, "bridge window %pR to %pR requires relaxed alignment rules\n", b_res, &bus->busn_res); @@ -1261,8 +1263,9 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, if (bus->self && size1 && !pbus_upstream_space_available(bus, mask | IORESOURCE_PREFETCH, type, size1, add_align)) { - min_align = 1ULL << (max_order + __ffs(SZ_1M)); - min_align = max(min_align, win_align); + relaxed_align = 1ULL << (max_order + __ffs(SZ_1M)); + relaxed_align = max(min_align, win_align); + min_align = min(min_align, relaxed_align); size1 = calculate_memsize(size, min_size, add_size, children_add_size, resource_size(b_res), win_align); pci_info(bus->self, -- 2.39.5

3 weeks, 3 days

2
2
0 0

[PATCH v1 0/4] Fix uprobe pte be overwritten when expanding vma

by Pu Lehui

From: Pu Lehui <pulehui(a)huawei.com> patch 1: the mainly fix for uprobe pte be overwritten issue. patch 2: WARN_ON_ONCE for new_pte not NULL during move_ptes. patch 3: extract some utils function for upcomming selftest. patch 4: selftest related to this series. v1: - limit skip uprobe_mmap to copy_vma flow. - add related selftest. - correct Fixes tag. RFC v2: https://lore.kernel.org/all/20250527132351.2050820-1-pulehui@huaweicloud.co… - skip uprobe_mmap on expanded vma. - add skip_vma_uprobe field to struct vma_prepare and vma_merge_struct. (Lorenzo) - add WARN_ON_ONCE when new_pte is not NULL. (Oleg) - Corrected some of the comments. RFC v1: https://lore.kernel.org/all/20250521092503.3116340-1-pulehui@huaweicloud.co… Pu Lehui (4): mm: Fix uprobe pte be overwritten when expanding vma mm: Expose abnormal new_pte during move_ptes selftests/mm: Extract read_sysfs and write_sysfs into vm_util selftests/mm: Add test about uprobe pte be orphan during vma merge mm/mremap.c | 2 ++ mm/vma.c | 20 ++++++++++-- mm/vma.h | 7 +++++ tools/testing/selftests/mm/ksm_tests.c | 32 ++------------------ tools/testing/selftests/mm/merge.c | 42 ++++++++++++++++++++++++++ tools/testing/selftests/mm/thuge-gen.c | 6 ++-- tools/testing/selftests/mm/vm_util.c | 38 +++++++++++++++++++++++ tools/testing/selftests/mm/vm_util.h | 2 ++ 8 files changed, 113 insertions(+), 36 deletions(-) -- 2.34.1

3 weeks, 3 days

9
29
0 0

[PATCH v1] xhci: dbctty: disable ECHO flag by default

by Łukasz Bartosik

When /dev/ttyDBC0 device is created then by default ECHO flag is set for the terminal device. However if data arrives from a peer before application using /dev/ttyDBC0 applies its set of terminal flags then the arriving data will be echoed which might not be desired behavior. Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> --- drivers/usb/host/xhci-dbgtty.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index 60ed753c85bb..d894081d8d15 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -617,6 +617,7 @@ int dbc_tty_init(void) dbc_tty_driver->type = TTY_DRIVER_TYPE_SERIAL; dbc_tty_driver->subtype = SERIAL_TYPE_NORMAL; dbc_tty_driver->init_termios = tty_std_termios; + dbc_tty_driver->init_termios.c_lflag &= ~ECHO; dbc_tty_driver->init_termios.c_cflag = B9600 | CS8 | CREAD | HUPCL | CLOCAL; dbc_tty_driver->init_termios.c_ispeed = 9600; -- 2.50.0.rc0.642.g800a2b2222-goog

3 weeks, 3 days

2
1
0 0

[PATCH 2/2] PCI: Fix pdev_resources_assignable() disparity

by Ilpo Järvinen

pdev_sort_resources() uses pdev_resources_assignable() helper to decide if device's resources cannot be assigned. pbus_size_mem(), on the other hand, does not do the same check. This could lead into a situation where a resource ends up on realloc_head list but is not on the head list, which is turn prevents emptying the resource from the realloc_head list in __assign_resources_sorted(). A non-empty realloc_head is unacceptable because it triggers an internal sanity check as show in this log with a device that has class 0 (PCI_CLASS_NOT_DEFINED): pci 0001:01:00.0: [144d:a5a5] type 00 class 0x000000 PCIe Endpoint pci 0001:01:00.0: BAR 0 [mem 0x00000000-0x000fffff 64bit] pci 0001:01:00.0: ROM [mem 0x00000000-0x0000ffff pref] pci 0001:01:00.0: enabling Extended Tags pci 0001:01:00.0: PME# supported from D0 D3hot D3cold pci 0001:01:00.0: 15.752 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x2 link at 0001:00:00.0 (capable of 31.506 Gb/s with 16.0 GT/s PCIe x2 link) pcieport 0001:00:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 01-ff] add_size 100000 add_align 100000 pcieport 0001:00:00.0: bridge window [mem 0x40000000-0x401fffff]: assigned ------------[ cut here ]------------ kernel BUG at drivers/pci/setup-bus.c:2532! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP ... Call trace: pci_assign_unassigned_bus_resources+0x110/0x114 (P) pci_rescan_bus+0x28/0x48 Use pdev_resources_assignable() also within pbus_size_mem() to skip processing of non-assignable resources which removes the disparity in between what resources pdev_sort_resources() and pbus_size_mem() consider. As non-assignable resources are no longer processed, they are not added to the realloc_head list, thus the sanity check no longer triggers. This disparity problem is very old but only now became apparent after the commit 2499f5348431 ("PCI: Rework optional resource handling") that made the ROM resources optional when calculating bridge window sizes which required adding the resource to the realloc_head list. Previously, bridge windows were just sized larger than necessary. Fixes: 2499f5348431 ("PCI: Rework optional resource handling") Reported-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> --- The reporter was perhaps not happy with this fix as behavior of PCI core isn't identical after this fix even if this patch fixes the problem on the PCI core side which causes the internal sanity check to fire. It seems that in the reporter's case, an out-of-tree driver was involved that performed things and made assumptions a driver should not do in its probe function such as assuming a bridge window is assigned even if there are not child resources to be put into it (the child device in reporter's case doesn't have a valid class and gets therefore skipped by the resource fitting/assignment): https://lore.kernel.org/all/bd579412-d07c-476d-8932-55c1f69adc9f@linaro.org/ In other words, the out-of-tree driver relies on the disparity in the PCI core's resource fitting code which is now eliminated by this fix. drivers/pci/setup-bus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index f90d49cd07da..24863d8d0053 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1191,6 +1191,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, resource_size_t r_size; if (r->parent || (r->flags & IORESOURCE_PCI_FIXED) || + !pdev_resources_assignable(dev) || ((r->flags & mask) != type && (r->flags & mask) != type2 && (r->flags & mask) != type3)) -- 2.39.5

3 weeks, 3 days

2
1
0 0

[PATCH 5.10] blk-mq: Fix kmemleak in blk_mq_init_allocated_queue

by Denis Arefev

From: Chen Jun <chenjun102(a)huawei.com> commit 943f45b9399ed8b2b5190cbc797995edaa97f58f upstream. There is a kmemleak caused by modprobe null_blk.ko unreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0 [<00000000b389383b>] do_init_module+0x1a4/0x680 [<0000000087cf3542>] load_module+0x6249/0x7110 [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200 [<00000000fdcfff51>] do_syscall_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 That is because q->ma_ops is set to NULL before blk_release_queue is called. blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] if (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q); [1]: blk_mq_alloc_and_init_hctx failed at i != 0. [2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and will be cleaned up in blk_mq_release. [3]: q->nr_hw_queues is 0. [4]: Set q->mq_ops to NULL. [5]: queue_is_mq returns false due to [4]. And blk_mq_release will not be called. The hctxs in q->unused_hctx_list are leaked. To fix it, call blk_release_queue in exception path. Fixes: 2f8f1336a48b ("blk-mq: always free hctx after request queue is freed") Signed-off-by: Yuan Can <yuancan(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Link: https://lore.kernel.org/r/20221031031242.94107-1-chenjun102@huawei.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2022-49901 Link: https://nvd.nist.gov/vuln/detail/CVE-2022-49901 --- block/blk-mq.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 21531aa163cb..6dd1398d0301 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -3335,9 +3335,8 @@ struct request_queue *blk_mq_init_allocated_queue(struct blk_mq_tag_set *set, return q; err_hctxs: - kfree(q->queue_hw_ctx); - q->nr_hw_queues = 0; - blk_mq_sysfs_deinit(q); + blk_mq_release(q); + err_poll: blk_stat_free_callback(q->poll_cb); q->poll_cb = NULL; -- 2.43.0

3 weeks, 3 days

1
0
0 0

[PATCH] usb: hub: fix detection of high tier USB3 devices behind suspended hubs

by Mathias Nyman

USB3 devices connected behind several external suspended hubs may not be detected when plugged in due to aggressive hub runtime pm suspend. The hub driver immediately runtime-suspends hubs if there are no active children or port activity. There is a delay between the wake signal causing hub resume, and driver visible port activity on the hub downstream facing ports. Most of the LFPS handshake, resume signaling and link training done on the downstream ports is not visible to the hub driver until completed, when device then will appear fully enabled and running on the port. This delay between wake signal and detectable port change is even more significant with chained suspended hubs where the wake signal will propagate upstream first. Suspended hubs will only start resuming downstream ports after upstream facing port resumes. The hub driver may resume a USB3 hub, read status of all ports, not yet see any activity, and runtime suspend back the hub before any port activity is visible. This exact case was seen when conncting USB3 devices to a suspended Thunderbolt dock. USB3 specification defines a 100ms tU3WakeupRetryDelay, indicating USB3 devices expect to be resumed within 100ms after signaling wake. if not then device will resend the wake signal. Give the USB3 hubs twice this time (200ms) to detect any port changes after resume, before allowing hub to runtime suspend again. Cc: stable(a)vger.kernel.org Fixes: 596d789a211d ("USB: set hub's default autosuspend delay as 0") Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/core/hub.c | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 770d1e91183c..5c12dfdef569 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -68,6 +68,12 @@ */ #define USB_SHORT_SET_ADDRESS_REQ_TIMEOUT 500 /* ms */ +/* + * Give SS hubs 200ms time after wake to train downstream links before + * assuming no port activity and allowing hub to runtime suspend back. + */ +#define USB_SS_PORT_U0_WAKE_TIME 200 /* ms */ + /* Protect struct usb_device->state and ->children members * Note: Both are also protected by ->dev.sem, except that ->state can * change to USB_STATE_NOTATTACHED even when the semaphore isn't held. */ @@ -1068,11 +1074,12 @@ int usb_remove_device(struct usb_device *udev) enum hub_activation_type { HUB_INIT, HUB_INIT2, HUB_INIT3, /* INITs must come first */ - HUB_POST_RESET, HUB_RESUME, HUB_RESET_RESUME, + HUB_POST_RESET, HUB_RESUME, HUB_RESET_RESUME, HUB_POST_RESUME, }; static void hub_init_func2(struct work_struct *ws); static void hub_init_func3(struct work_struct *ws); +static void hub_post_resume(struct work_struct *ws); static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) { @@ -1095,6 +1102,13 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) goto init2; goto init3; } + + if (type == HUB_POST_RESUME) { + usb_autopm_put_interface_async(to_usb_interface(hub->intfdev)); + hub_put(hub); + return; + } + hub_get(hub); /* The superspeed hub except for root hub has to use Hub Depth @@ -1343,6 +1357,16 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) device_unlock(&hdev->dev); } + if (type == HUB_RESUME && hub_is_superspeed(hub->hdev)) { + /* give usb3 downstream links training time after hub resume */ + INIT_DELAYED_WORK(&hub->init_work, hub_post_resume); + queue_delayed_work(system_power_efficient_wq, &hub->init_work, + msecs_to_jiffies(USB_SS_PORT_U0_WAKE_TIME)); + usb_autopm_get_interface_no_resume( + to_usb_interface(hub->intfdev)); + return; + } + hub_put(hub); } @@ -1361,6 +1385,13 @@ static void hub_init_func3(struct work_struct *ws) hub_activate(hub, HUB_INIT3); } +static void hub_post_resume(struct work_struct *ws) +{ + struct usb_hub *hub = container_of(ws, struct usb_hub, init_work.work); + + hub_activate(hub, HUB_POST_RESUME); +} + enum hub_quiescing_type { HUB_DISCONNECT, HUB_PRE_RESET, HUB_SUSPEND }; -- 2.43.0

3 weeks, 3 days

3
3
0 0

[PATCH 5.10] lib/generic-radix-tree.c: Don't overflow in peek()

by Denis Arefev

From: Kent Overstreet <kent.overstreet(a)gmail.com> commit 9492261ff2460252cf2d8de89cdf854c7e2b28a0 upstream. When we started spreading new inode numbers throughout most of the 64 bit inode space, that triggered some corner case bugs, in particular some integer overflows related to the radix tree code. Oops. Fixes: ba20ba2e3743 ("generic radix trees") Signed-off-by: Kent Overstreet <kent.overstreet(a)gmail.com> [Denis: minor fix to resolve merge conflict and add tag Fixes] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2021-47432 Link: https://nvd.nist.gov/vuln/detail/cve-2021-47432 --- include/linux/generic-radix-tree.h | 7 +++++++ lib/generic-radix-tree.c | 17 ++++++++++++++--- 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/include/linux/generic-radix-tree.h b/include/linux/generic-radix-tree.h index bfd00320c7f3..0e7abc635e5f 100644 --- a/include/linux/generic-radix-tree.h +++ b/include/linux/generic-radix-tree.h @@ -39,6 +39,7 @@ #include <asm/page.h> #include <linux/bug.h> #include <linux/kernel.h> +#include <linux/limits.h> #include <linux/log2.h> struct genradix_root; @@ -183,6 +184,12 @@ void *__genradix_iter_peek(struct genradix_iter *, struct __genradix *, size_t); static inline void __genradix_iter_advance(struct genradix_iter *iter, size_t obj_size) { + if (iter->offset + obj_size < iter->offset) { + iter->offset = SIZE_MAX; + iter->pos = SIZE_MAX; + return; + } + iter->offset += obj_size; if (!is_power_of_2(obj_size) && diff --git a/lib/generic-radix-tree.c b/lib/generic-radix-tree.c index 34d3ac52de89..78f081d695d0 100644 --- a/lib/generic-radix-tree.c +++ b/lib/generic-radix-tree.c @@ -168,6 +168,10 @@ void *__genradix_iter_peek(struct genradix_iter *iter, struct genradix_root *r; struct genradix_node *n; unsigned level, i; + + if (iter->offset == SIZE_MAX) + return NULL; + restart: r = READ_ONCE(radix->root); if (!r) @@ -186,10 +190,17 @@ void *__genradix_iter_peek(struct genradix_iter *iter, (GENRADIX_ARY - 1); while (!n->children[i]) { + size_t objs_per_ptr = genradix_depth_size(level); + + if (iter->offset + objs_per_ptr < iter->offset) { + iter->offset = SIZE_MAX; + iter->pos = SIZE_MAX; + return NULL; + } + i++; - iter->offset = round_down(iter->offset + - genradix_depth_size(level), - genradix_depth_size(level)); + iter->offset = round_down(iter->offset + objs_per_ptr, + objs_per_ptr); iter->pos = (iter->offset >> PAGE_SHIFT) * objs_per_page; if (i == GENRADIX_ARY) -- 2.43.0

3 weeks, 3 days

1
0
0 0

[PATCH v8 1/4] serial: 8250: fix panic due to PSLVERR

by Yunhui Cui

When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Cc: stable(a)vger.kernel.org --- drivers/tty/serial/8250/8250_port.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 6d7b8c4667c9c..07fe818dffa34 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2376,9 +2376,10 @@ int serial8250_do_startup(struct uart_port *port) /* * Now, initialize the UART */ - serial_port_out(port, UART_LCR, UART_LCR_WLEN8); uart_port_lock_irqsave(port, &flags); + serial_port_out(port, UART_LCR, UART_LCR_WLEN8); + if (up->port.flags & UPF_FOURPORT) { if (!up->port.irq) up->port.mctrl |= TIOCM_OUT1; -- 2.39.5

3 weeks, 3 days

5
9
0 0

[PATCH 0/3] clk: samsung: gs101 & exynos850 fixes

by André Draszik

Hi, The patches fix some errors in the gs101 clock driver as well as a trivial comment typo in the Exynos E850 clock driver. Cheers, Andre Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- André Draszik (3): clk: samsung: gs101: fix CLK_DOUT_CMU_G3D_BUSD clk: samsung: gs101: fix alternate mout_hsi0_usb20_ref parent clock clk: samsung: exynos850: fix a comment drivers/clk/samsung/clk-exynos850.c | 2 +- drivers/clk/samsung/clk-gs101.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) --- base-commit: a0bea9e39035edc56a994630e6048c8a191a99d8 change-id: 20250519-samsung-clk-fixes-a4f5bfb54c73 Best regards, -- André Draszik <andre.draszik(a)linaro.org>

3 weeks, 3 days

2
4
0 0

[PATCH] uapi: bitops: use UAPI-safe variant of BITS_PER_LONG again

by Thomas Weißschuh

Commit 1e7933a575ed ("uapi: Revert "bitops: avoid integer overflow in GENMASK(_ULL)"") did not take in account that the usage of BITS_PER_LONG in __GENMASK() was changed to __BITS_PER_LONG for UAPI-safety in commit 3c7a8e190bc5 ("uapi: introduce uapi-friendly macros for GENMASK"). BITS_PER_LONG can not be used in UAPI headers as it derives from the kernel configuration and not from the current compiler invocation. When building compat userspace code or a compat vDSO its value will be incorrect. Switch back to __BITS_PER_LONG. Fixes: 1e7933a575ed ("uapi: Revert "bitops: avoid integer overflow in GENMASK(_ULL)"") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> --- include/uapi/linux/bits.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/bits.h b/include/uapi/linux/bits.h index 682b406e10679dc8baa188830ab0811e7e3e13e3..a04afef9efca42f062e142fcb33f5d267512b1e5 100644 --- a/include/uapi/linux/bits.h +++ b/include/uapi/linux/bits.h @@ -4,9 +4,9 @@ #ifndef _UAPI_LINUX_BITS_H #define _UAPI_LINUX_BITS_H -#define __GENMASK(h, l) (((~_UL(0)) << (l)) & (~_UL(0) >> (BITS_PER_LONG - 1 - (h)))) +#define __GENMASK(h, l) (((~_UL(0)) << (l)) & (~_UL(0) >> (__BITS_PER_LONG - 1 - (h)))) -#define __GENMASK_ULL(h, l) (((~_ULL(0)) << (l)) & (~_ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h)))) +#define __GENMASK_ULL(h, l) (((~_ULL(0)) << (l)) & (~_ULL(0) >> (__BITS_PER_LONG_LONG - 1 - (h)))) #define __GENMASK_U128(h, l) \ ((_BIT128((h)) << 1) - (_BIT128(l))) --- base-commit: e271ed52b344ac02d4581286961d0c40acc54c03 change-id: 20250606-uapi-genmask-e07667de69ec Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

3 weeks, 3 days

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror