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

[PATCH] tty: serial: sh-sci: fix RSCI FIFO overrun handling

by Cosmin Tanislav

The receive error handling code is shared between RSCI and all other SCIF port types, but the RSCI overrun_reg is specified as a memory offset, while for other SCIF types it is an enum value used to index into the sci_port_params->regs array, as mentioned above the sci_serial_in() function. For RSCI, the overrun_reg is CSR (0x48), causing the sci_getreg() call inside the sci_handle_fifo_overrun() function to index outside the bounds of the regs array, which currently has a size of 20, as specified by SCI_NR_REGS. Because of this, we end up accessing memory outside of RSCI's rsci_port_params structure, which, when interpreted as a plat_sci_reg, happens to have a non-zero size, causing the following WARN when sci_serial_in() is called, as the accidental size does not match the supported register sizes. The existence of the overrun_reg needs to be checked because SCIx_SH3_SCIF_REGTYPE has overrun_reg set to SCLSR, but SCLSR is not present in the regs array. Avoid calling sci_getreg() for port types which don't use standard register handling. Use the ops->read_reg() and ops->write_reg() functions to properly read and write registers for RSCI, and change the type of the status variable to accommodate the 32-bit CSR register. sci_getreg() and sci_serial_in() are also called with overrun_reg in the sci_mpxed_interrupt() interrupt handler, but that code path is not used for RSCI, as it does not have a muxed interrupt. ------------[ cut here ]------------ Invalid register access WARNING: CPU: 0 PID: 0 at drivers/tty/serial/sh-sci.c:522 sci_serial_in+0x38/0xac Modules linked in: renesas_usbhs at24 rzt2h_adc industrialio_adc sha256 cfg80211 bluetooth ecdh_generic ecc rfkill fuse drm backlight ipv6 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc1+ #30 PREEMPT Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sci_serial_in+0x38/0xac lr : sci_serial_in+0x38/0xac sp : ffff800080003e80 x29: ffff800080003e80 x28: ffff800082195b80 x27: 000000000000000d x26: ffff8000821956d0 x25: 0000000000000000 x24: ffff800082195b80 x23: ffff000180e0d800 x22: 0000000000000010 x21: 0000000000000000 x20: 0000000000000010 x19: ffff000180e72000 x18: 000000000000000a x17: ffff8002bcee7000 x16: ffff800080000000 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 x11: 0000000000000058 x10: 0000000000000018 x9 : ffff8000821a6a48 x8 : 0000000000057fa8 x7 : 0000000000000406 x6 : ffff8000821fea48 x5 : ffff00033ef88408 x4 : ffff8002bcee7000 x3 : ffff800082195b80 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800082195b80 Call trace: sci_serial_in+0x38/0xac (P) sci_handle_fifo_overrun.isra.0+0x70/0x134 sci_er_interrupt+0x50/0x39c __handle_irq_event_percpu+0x48/0x140 handle_irq_event+0x44/0xb0 handle_fasteoi_irq+0xf4/0x1a0 handle_irq_desc+0x34/0x58 generic_handle_domain_irq+0x1c/0x28 gic_handle_irq+0x4c/0x140 call_on_irq_stack+0x30/0x48 do_interrupt_handler+0x80/0x84 el1_interrupt+0x34/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 default_idle_call+0x28/0x58 (P) do_idle+0x1f8/0x250 cpu_startup_entry+0x34/0x3c rest_init+0xd8/0xe0 console_on_rootfs+0x0/0x6c __primary_switched+0x88/0x90 ---[ end trace 0000000000000000 ]--- Cc: stable(a)vger.kernel.org Fixes: 0666e3fe95ab ("serial: sh-sci: Add support for RZ/T2H SCI") Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa(a)renesas.com> --- drivers/tty/serial/sh-sci.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index 538b2f991609..62bb62b82cbe 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -1014,16 +1014,18 @@ static int sci_handle_fifo_overrun(struct uart_port *port) struct sci_port *s = to_sci_port(port); const struct plat_sci_reg *reg; int copied = 0; - u16 status; + u32 status; - reg = sci_getreg(port, s->params->overrun_reg); - if (!reg->size) - return 0; + if (s->type != SCI_PORT_RSCI) { + reg = sci_getreg(port, s->params->overrun_reg); + if (!reg->size) + return 0; + } - status = sci_serial_in(port, s->params->overrun_reg); + status = s->ops->read_reg(port, s->params->overrun_reg); if (status & s->params->overrun_mask) { status &= ~s->params->overrun_mask; - sci_serial_out(port, s->params->overrun_reg, status); + s->ops->write_reg(port, s->params->overrun_reg, status); port->icount.overrun++; -- 2.51.0

1 day, 12 hours

2
3
0 0

[PATCH] leds: leds-cros_ec: Skip LEDs without color components

by Thomas Weißschuh

A user reports that on their Lenovo Corsola Magneton with EC firmware steelix-15194.270.0 the driver probe fails with EINVAL. It turns out that the power LED does not contain any color components as indicated by the following "ectool led power query" output: Brightness range for LED 1: red : 0x0 green : 0x0 blue : 0x0 yellow : 0x0 white : 0x0 amber : 0x0 The LED also does not react to commands sent manually through ectool and is generally non-functional. Instead of failing the probe for all LEDs managed by the EC when one without color components is encountered, silently skip those. Fixes: 8d6ce6f3ec9d ("leds: Add ChromeOS EC driver") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- drivers/leds/leds-cros_ec.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/leds/leds-cros_ec.c b/drivers/leds/leds-cros_ec.c index 377cf04e202a..bea3cc3fbfd2 100644 --- a/drivers/leds/leds-cros_ec.c +++ b/drivers/leds/leds-cros_ec.c @@ -142,9 +142,6 @@ static int cros_ec_led_count_subleds(struct device *dev, } } - if (!num_subleds) - return -EINVAL; - *max_brightness = common_range; return num_subleds; } @@ -189,6 +186,8 @@ static int cros_ec_led_probe_one(struct device *dev, struct cros_ec_device *cros &priv->led_mc_cdev.led_cdev.max_brightness); if (num_subleds < 0) return num_subleds; + if (num_subleds == 0) + return 0; /* LED without any colors, skip */ priv->cros_ec = cros_ec; priv->led_id = id; --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20251028-cros_ec-leds-no-colors-18eb8d1efa92 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

1 day, 12 hours

2
1
0 0

[PATCH] mfd: altera-sysmgr: Fix device reference leak in altr_sysmgr_regmap_lookup_by_phandle

by Miaoqian Lin

driver_find_device_by_of_node() calls driver_find_device(), which calls get_device(). get_device() increments the device's reference count, so driver_find_device_by_of_node() returns a device with its reference count incremented. We need to release this reference after usage to avoid a reference leak. Add put_device(dev) after dev_get_drvdata() to fix the reference leak. Found via static analysis. Fixes: f36e789a1f8d ("mfd: altera-sysmgr: Add SOCFPGA System Manager") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/mfd/altera-sysmgr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/altera-sysmgr.c b/drivers/mfd/altera-sysmgr.c index fb5f988e61f3..cb66b2fff536 100644 --- a/drivers/mfd/altera-sysmgr.c +++ b/drivers/mfd/altera-sysmgr.c @@ -116,6 +116,7 @@ struct regmap *altr_sysmgr_regmap_lookup_by_phandle(struct device_node *np, return ERR_PTR(-EPROBE_DEFER); sysmgr = dev_get_drvdata(dev); + put_device(dev); return sysmgr->regmap; } -- 2.39.5 (Apple Git-154)

1 day, 12 hours

2
1
0 0

[PATCH 0/6] Hello,

by Miquel Raynal

Here is a series adding support for 6 Winbond SPI NOR chips. Describing these chips is needed otherwise the block protection feature is not available. Everything else looks fine otherwise. In practice I am only adding 6 very similar IDs but I split the commits because the amount of meta data to show proof that all the chips have been tested and work is pretty big. As the commits simply add an ID, I am Cc'ing stable with the hope to get these backported to LTS kernels as allowed by the stable rules (see link below, but I hope I am doing this right). Link: https://elixir.bootlin.com/linux/v6.17.7/source/Documentation/process/stabl… Thanks, Miquèl --- Miquel Raynal (6): mtd: spi-nor: winbond: Add support for W25Q01NWxxIQ chips mtd: spi-nor: winbond: Add support for W25Q01NWxxIM chips mtd: spi-nor: winbond: Add support for W25Q02NWxxIM chips mtd: spi-nor: winbond: Add support for W25H512NWxxAM chips mtd: spi-nor: winbond: Add support for W25H01NWxxAM chips mtd: spi-nor: winbond: Add support for W25H02NWxxAM chips drivers/mtd/spi-nor/winbond.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) --- base-commit: 479ba7fc704936b74a91ee352fe113d6391d562f change-id: 20251105-winbond-v6-18-rc1-spi-nor-7f78cb2785d6 Best regards, -- Miquel Raynal <miquel.raynal(a)bootlin.com>

1 day, 13 hours

3
9
0 0

[PATCH net v9 0/4] net: netpoll: fix memory leak and add comprehensive selftests

by Breno Leitao

Fix a memory leak in netpoll and introduce netconsole selftests that expose the issue when running with kmemleak detection enabled. This patchset includes a selftest for netpoll with multiple concurrent users (netconsole + bonding), which simulates the scenario from test[1] that originally demonstrated the issue allegedly fixed by commit efa95b01da18 ("netpoll: fix use after free") - a commit that is now being reverted. Sending this to "net" branch because this is a fix, and the selftest might help with the backports validation. Link: https://lore.kernel.org/lkml/96b940137a50e5c387687bb4f57de8b0435a653f.14048… [1] Signed-off-by: Breno Leitao <leitao(a)debian.org> --- Changes in v9: - Reordered the config entries in tools/testing/selftests/drivers/net/bonding/config (NIPA) - Link to v8: https://lore.kernel.org/r/20251104-netconsole_torture-v8-0-5288440e2fa0@deb… Changes in v8: - Sending it again, now that commit 1a8fed52f7be1 ("netdevsim: set the carrier when the device goes up") has landed in net - Created one namespace for TX and one for RX (Paolo) - Used additional helpers to create and delete netdevsim (Paolo) - Link to v7: https://lore.kernel.org/r/20251003-netconsole_torture-v7-0-aa92fcce62a9@deb… Changes in v7: - Rebased on top of `net` - Link to v6: https://lore.kernel.org/r/20251002-netconsole_torture-v6-0-543bf52f6b46@deb… Changes in v6: - Expand the tests even more and some small fixups - Moved the test to bonding selftests - Link to v5: https://lore.kernel.org/r/20250918-netconsole_torture-v5-0-77e25e0a4eb6@deb… Changes in v5: - Set CONFIG_BONDING=m in selftests/drivers/net/config. - Link to v4: https://lore.kernel.org/r/20250917-netconsole_torture-v4-0-0a5b3b8f81ce@deb… Changes in v4: - Added an additional selftest to test multiple netpoll users in parallel - Link to v3: https://lore.kernel.org/r/20250905-netconsole_torture-v3-0-875c7febd316@deb… Changes in v3: - This patchset is a merge of the fix and the selftest together as recommended by Jakub. Changes in v2: - Reuse the netconsole creation from lib_netcons.sh. Thus, refactoring the create_dynamic_target() (Jakub) - Move the "wait" to after all the messages has been sent. - Link to v1: https://lore.kernel.org/r/20250902-netconsole_torture-v1-1-03c6066598e9@deb… --- Breno Leitao (4): net: netpoll: fix incorrect refcount handling causing incorrect cleanup selftest: netcons: refactor target creation selftest: netcons: create a torture test selftest: netcons: add test for netconsole over bonded interfaces net/core/netpoll.c | 7 +- tools/testing/selftests/drivers/net/Makefile | 1 + .../testing/selftests/drivers/net/bonding/Makefile | 2 + tools/testing/selftests/drivers/net/bonding/config | 4 + .../drivers/net/bonding/netcons_over_bonding.sh | 361 +++++++++++++++++++++ .../selftests/drivers/net/lib/sh/lib_netcons.sh | 82 ++++- .../selftests/drivers/net/netcons_torture.sh | 130 ++++++++ 7 files changed, 569 insertions(+), 18 deletions(-) --- base-commit: 7d1988a943850c584e8e2e4bcc7a3b5275024072 change-id: 20250902-netconsole_torture-8fc23f0aca99 Best regards, -- Breno Leitao <leitao(a)debian.org>

1 day, 13 hours

1
1
0 0

[PATCH] scsi: target: tcm_loop: fix segfault in tcm_loop_tpg_address_show()

by Hamza Mahfooz

If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ... Cc: stable(a)vger.kernel.org Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs") Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> --- drivers/target/loopback/tcm_loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c index c7b7da629741..01a8e349dc4d 100644 --- a/drivers/target/loopback/tcm_loop.c +++ b/drivers/target/loopback/tcm_loop.c @@ -894,6 +894,9 @@ static ssize_t tcm_loop_tpg_address_show(struct config_item *item, struct tcm_loop_tpg, tl_se_tpg); struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba; + if (!tl_hba->sh) + return -ENODEV; + return snprintf(page, PAGE_SIZE, "%d:0:%d\n", tl_hba->sh->host_no, tl_tpg->tl_tpgt); } -- 2.49.0

1 day, 13 hours

3
2
0 0

[PATCH v2] iio: trigger: Fix error handling in viio_trigger_alloc

by Ma Ke

viio_trigger_alloc() initializes the device with device_initialize() but uses kfree() directly in error paths, which bypasses the device's release callback iio_trig_release(). This could lead to memory leaks and inconsistent device state. Additionally, the current error handling has the following issues: 1. Potential double-free of IRQ descriptors when kvasprintf fails. 2. The release function may attempt to free negative subirq_base. 3. Missing mutex_destroy in release function. Fix these issues by: 1. Replacing kfree(trig) with put_device(&trig->dev) in error paths. 2. Setting subirq_base to 0 after freeing IRQ descriptors in error path to prevent double-free in release callback. 3. Modifying release function to properly handle negative subirq_base. 4. Adding missing mutex_destroy(). Found by code review. Cc: stable(a)vger.kernel.org Fixes: 2c99f1a09da3 ("iio: trigger: clean up viio_trigger_alloc()") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the patch, thanks for developer's suggestions. --- drivers/iio/industrialio-trigger.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c index 54416a384232..9f6d30a244d9 100644 --- a/drivers/iio/industrialio-trigger.c +++ b/drivers/iio/industrialio-trigger.c @@ -524,6 +524,7 @@ static void iio_trig_release(struct device *device) CONFIG_IIO_CONSUMERS_PER_TRIGGER); } kfree(trig->name); + mutex_destroy(&trig->pool_lock); kfree(trig); } @@ -596,8 +597,9 @@ struct iio_trigger *viio_trigger_alloc(struct device *parent, free_descs: irq_free_descs(trig->subirq_base, CONFIG_IIO_CONSUMERS_PER_TRIGGER); + trig->subirq_base = 0; free_trig: - kfree(trig); + put_device(&trig->dev); return NULL; } -- 2.17.1

1 day, 14 hours

3
2
0 0

[PATCH v1 1/2] kasan: Unpoison pcpu chunks with base address tag

by Maciej Wieczor-Retman

From: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> A KASAN tag mismatch, possibly causing a kernel panic, can be observed on systems with a tag-based KASAN enabled and with multiple NUMA nodes. It was reported on arm64 and reproduced on x86. It can be explained in the following points: 1. There can be more than one virtual memory chunk. 2. Chunk's base address has a tag. 3. The base address points at the first chunk and thus inherits the tag of the first chunk. 4. The subsequent chunks will be accessed with the tag from the first chunk. 5. Thus, the subsequent chunks need to have their tag set to match that of the first chunk. Refactor code by moving it into a helper in preparation for the actual fix. Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: <stable(a)vger.kernel.org> # 6.1+ Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> Tested-by: Baoquan He <bhe(a)redhat.com> --- Changelog v1 (after splitting of from the KASAN series): - Rewrite first paragraph of the patch message to point at the user impact of the issue. - Move helper to common.c so it can be compiled in all KASAN modes. include/linux/kasan.h | 10 ++++++++++ mm/kasan/common.c | 11 +++++++++++ mm/vmalloc.c | 4 +--- 3 files changed, 22 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index d12e1a5f5a9a..b00849ea8ffd 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -614,6 +614,13 @@ static __always_inline void kasan_poison_vmalloc(const void *start, __kasan_poison_vmalloc(start, size); } +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms); +static __always_inline void kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) +{ + if (kasan_enabled()) + __kasan_unpoison_vmap_areas(vms, nr_vms); +} + #else /* CONFIG_KASAN_VMALLOC */ static inline void kasan_populate_early_vm_area_shadow(void *start, @@ -638,6 +645,9 @@ static inline void *kasan_unpoison_vmalloc(const void *start, static inline void kasan_poison_vmalloc(const void *start, unsigned long size) { } +static inline void kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) +{ } + #endif /* CONFIG_KASAN_VMALLOC */ #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ diff --git a/mm/kasan/common.c b/mm/kasan/common.c index d4c14359feaf..c63544a98c24 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -28,6 +28,7 @@ #include <linux/string.h> #include <linux/types.h> #include <linux/bug.h> +#include <linux/vmalloc.h> #include "kasan.h" #include "../slab.h" @@ -582,3 +583,13 @@ bool __kasan_check_byte(const void *address, unsigned long ip) } return true; } + +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) +{ + int area; + + for (area = 0 ; area < nr_vms ; area++) { + kasan_poison(vms[area]->addr, vms[area]->size, + arch_kasan_get_tag(vms[area]->addr), false); + } +} diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 798b2ed21e46..934c8bfbcebf 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4870,9 +4870,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets, * With hardware tag-based KASAN, marking is skipped for * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc(). */ - for (area = 0; area < nr_vms; area++) - vms[area]->addr = kasan_unpoison_vmalloc(vms[area]->addr, - vms[area]->size, KASAN_VMALLOC_PROT_NORMAL); + kasan_unpoison_vmap_areas(vms, nr_vms); kfree(vas); return vms; -- 2.51.0

1 day, 14 hours

5
6
0 0

[PATCH] drivers: Fix reference leak in altr_sysmgr_regmap_lookup_by_phandle()

by Ma Ke

altr_sysmgr_regmap_lookup_by_phandle() utilizes driver_find_device_by_of_node() which internally calls driver_find_device() to locate the matching device. driver_find_device() increments the ref count of the found device by calling get_device(), but altr_sysmgr_regmap_lookup_by_phandle() fails to call put_device() to decrement the reference count before returning. This results in a reference count leak of the device, which may prevent the device from being properly released and cause a memory leak. Found by code review. Cc: stable(a)vger.kernel.org Fixes: cfba5de9b99f ("drivers: Introduce device lookup variants by of_node") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/mfd/altera-sysmgr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/altera-sysmgr.c b/drivers/mfd/altera-sysmgr.c index fb5f988e61f3..c6c763fb7bbe 100644 --- a/drivers/mfd/altera-sysmgr.c +++ b/drivers/mfd/altera-sysmgr.c @@ -98,6 +98,7 @@ struct regmap *altr_sysmgr_regmap_lookup_by_phandle(struct device_node *np, struct device *dev; struct altr_sysmgr *sysmgr; struct device_node *sysmgr_np; + struct regmap *regmap; if (property) sysmgr_np = of_parse_phandle(np, property, 0); @@ -116,8 +117,10 @@ struct regmap *altr_sysmgr_regmap_lookup_by_phandle(struct device_node *np, return ERR_PTR(-EPROBE_DEFER); sysmgr = dev_get_drvdata(dev); + regmap = sysmgr->regmap; + put_device(dev); - return sysmgr->regmap; + return regmap; } EXPORT_SYMBOL_GPL(altr_sysmgr_regmap_lookup_by_phandle); -- 2.17.1

1 day, 15 hours

3
2
0 0

[PATCH v3 0/1] Bluetooth: btusb: add default nvm file

by Shuai Zhang

this patch adds support for default NVM file Changes v3: - Remove rery, modify btusb_setup_qca_load_nvm, and add board_id to enable the use of the default NVM file. - Link to v2 https://lore.kernel.org/all/20251029022955.827475-2-quic_shuaz@quicinc.com/ Changes v2: - Add log for failed default nvm file request. - Added Cc: stable(a)vger.kernel.org to comply with stable kernel rules. - Link to v1: https://lore.kernel.org/all/20251028120550.2225434-1-quic_shuaz@quicinc.com/ Shuai Zhang (1): Bluetooth: btusb: add default nvm file drivers/bluetooth/btusb.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) -- 2.34.1

1 day, 15 hours

1
2
0 0

[PATCH v1] Bluetooth: btusb: add new custom firmwares

by Shuai Zhang

There are custom-made firmwares based on board ID for a given QCA BT chip sometimes, and they are different with existing firmwares and put in a separate subdirectory to avoid conflict, for example: QCA2066, as a variant of WCN6855, has firmwares under 'qca/QCA2066/' of linux-firmware repository. Cc: stable(a)vger.kernel.org Signed-off-by: Shuai Zhang <quic_shuaz(a)quicinc.com> --- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index dcbff7641..7175e9b2d 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3273,6 +3273,7 @@ static const struct qca_device_info qca_devices_table[] = { static const struct qca_custom_firmware qca_custom_btfws[] = { { 0x00130201, 0x030A, "QCA2066" }, + { 0x00130201, 0x030B, "QCA2066" }, { }, }; -- 2.34.1

1 day, 15 hours

1
0
0 0

[PATCH 6.6.y] smb: client: support kvec iterators in async read path

by Henrique Carvalho

commit 3ee1a1fc39819906f04d6c62c180e760cd3a689d upstream. Add cifs_limit_kvec_subset() and select the appropriate limiter in cifs_send_async_read() to handle kvec iterators in async read path, fixing the EIO bug when running executables in cifs shares mounted with nolease. This patch -- or equivalent patch, does not exist upstream, as the upstream code has suffered considerable API changes. The affected path is currently handled by netfs lib and located under netfs/direct_read.c. Reproducer: $ mount.cifs //server/share /mnt -o nolease $ cat - > /mnt/test.sh <<EOL echo hallo EOL $ chmod +x /mnt/test.sh $ /mnt/test.sh bash: /mnt/test.sh: /bin/bash: Defekter Interpreter: Eingabe-/Ausgabefehler $ rm -f /mnt/test.sh Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Reported-by: Laura Kerner <laura.kerner(a)ichaus.de> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1245449 Signed-off-by: Henrique Carvalho <henrique.carvalho(a)suse.com> --- fs/smb/client/file.c | 46 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/file.c b/fs/smb/client/file.c index d883ed75022c..4878c74bae6f 100644 --- a/fs/smb/client/file.c +++ b/fs/smb/client/file.c @@ -3527,6 +3527,42 @@ static size_t cifs_limit_bvec_subset(const struct iov_iter *iter, size_t max_siz return span; } +static size_t cifs_limit_kvec_subset(const struct iov_iter *iter, size_t max_size, + size_t max_segs, unsigned int *_nsegs) +{ + const struct kvec *kvecs = iter->kvec; + unsigned int nkv = iter->nr_segs, ix = 0, nsegs = 0; + size_t len, span = 0, n = iter->count; + size_t skip = iter->iov_offset; + + if (WARN_ON(!iov_iter_is_kvec(iter)) || n == 0) + return 0; + + while (n && ix < nkv && skip) { + len = kvecs[ix].iov_len; + if (skip < len) + break; + skip -= len; + n -= len; + ix++; + } + + while (n && ix < nkv) { + len = min3(n, kvecs[ix].iov_len - skip, max_size); + span += len; + max_size -= len; + nsegs++; + ix++; + if (max_size == 0 || nsegs >= max_segs) + break; + skip = 0; + n -= len; + } + + *_nsegs = nsegs; + return span; +} + static int cifs_write_from_iter(loff_t fpos, size_t len, struct iov_iter *from, struct cifsFileInfo *open_file, @@ -4079,6 +4115,13 @@ cifs_send_async_read(loff_t fpos, size_t len, struct cifsFileInfo *open_file, int rc; pid_t pid; struct TCP_Server_Info *server; + size_t (*limit_iov_subset)(const struct iov_iter *iter, size_t max_size, + size_t max_segs, unsigned int *_nsegs); + + if (iov_iter_is_kvec(&ctx->iter)) + limit_iov_subset = cifs_limit_kvec_subset; + else + limit_iov_subset = cifs_limit_bvec_subset; server = cifs_pick_channel(tlink_tcon(open_file->tlink)->ses); @@ -4113,8 +4156,7 @@ cifs_send_async_read(loff_t fpos, size_t len, struct cifsFileInfo *open_file, max_len = min_t(size_t, len, rsize); - cur_len = cifs_limit_bvec_subset(&ctx->iter, max_len, - max_segs, &nsegs); + cur_len = limit_iov_subset(&ctx->iter, max_len, max_segs, &nsegs); cifs_dbg(FYI, "read-to-iter len=%zx/%zx nsegs=%u/%lu/%u\n", cur_len, max_len, nsegs, ctx->iter.nr_segs, max_segs); if (cur_len == 0) { -- 2.47.0

1 day, 15 hours

4
4
0 0

[PATCH v2 2/2] Bluetooth: hci_qca: Convert timeout from jiffies to ms

by Shuai Zhang

Since the timer uses jiffies as its unit rather than ms, the timeout value must be converted from ms to jiffies when configuring the timer. Otherwise, the intended 8s timeout is incorrectly set to approximately 33s. Cc: stable(a)vger.kernel.org Signed-off-by: Shuai Zhang <quic_shuaz(a)quicinc.com> --- drivers/bluetooth/hci_qca.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index fa6be1992..c14b2fa9d 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1602,7 +1602,7 @@ static void qca_wait_for_dump_collection(struct hci_dev *hdev) struct qca_data *qca = hu->priv; wait_on_bit_timeout(&qca->flags, QCA_MEMDUMP_COLLECTION, - TASK_UNINTERRUPTIBLE, MEMDUMP_TIMEOUT_MS); + TASK_UNINTERRUPTIBLE, msecs_to_jiffies(MEMDUMP_TIMEOUT_MS)); clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); } -- 2.34.1

1 day, 15 hours

1
0
0 0

[PATCH v2 1/2] Bluetooth: qca: Fix delayed hw_error handling due to missing wakeup during SSR

by Shuai Zhang

When Bluetooth controller encounters a coredump, it triggers the Subsystem Restart (SSR) mechanism. The controller first reports the coredump data, and once the data upload is complete, it sends a hw_error event. The host relies on this event to proceed with subsequent recovery actions. If the host has not finished processing the coredump data when the hw_error event is received, it sets a timer to wait until either the data processing is complete or the timeout expires before handling the event. The current implementation lacks a wakeup trigger. As a result, even if the coredump data has already been processed, the host continues to wait until the timer expires, causing unnecessary delays in handling the hw_error event. To fix this issue, adds a `wake_up_bit()` call after the host finishes processing the coredump data. This ensures that the waiting thread is promptly notified and can proceed to handle the hw_error event without waiting for the timeout. Test case: - Trigger controller coredump using the command: `hcitool cmd 0x3f 0c 26`. - Use `btmon` to capture HCI logs. - Observe the time interval between receiving the hw_error event and the execution of the power-off sequence in the HCI log. Cc: stable(a)vger.kernel.org Signed-off-by: Shuai Zhang <quic_shuaz(a)quicinc.com> --- drivers/bluetooth/hci_qca.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 888176b0f..fa6be1992 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1103,7 +1103,7 @@ static void qca_controller_memdump(struct work_struct *work) qca->qca_memdump = NULL; qca->memdump_state = QCA_MEMDUMP_COLLECTED; cancel_delayed_work(&qca->ctrl_memdump_timeout); - clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); + clear_and_wake_up_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); clear_bit(QCA_IBS_DISABLED, &qca->flags); mutex_unlock(&qca->hci_memdump_lock); return; @@ -1181,7 +1181,7 @@ static void qca_controller_memdump(struct work_struct *work) kfree(qca->qca_memdump); qca->qca_memdump = NULL; qca->memdump_state = QCA_MEMDUMP_COLLECTED; - clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); + clear_and_wake_up_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); } mutex_unlock(&qca->hci_memdump_lock); -- 2.34.1

1 day, 15 hours

1
0
0 0

[RFT PATCH] mfd: max77620: Fix potential IRQ chip conflict when probing two devices

by Krzysztof Kozlowski

MAX77620 is most likely always a single device on the board, however nothing stops board designers to have two of them, thus same device driver could probe twice. Or user could manually try to probing second time. Device driver is not ready for that case, because it allocates statically 'struct regmap_irq_chip' as non-const and stores during probe in 'irq_drv_data' member a pointer to per-probe state container ('struct max77620_chip'). devm_regmap_add_irq_chip() does not make a copy of 'struct regmap_irq_chip' but store the pointer. Second probe - either successful or failure - would overwrite the 'irq_drv_data' from previous device probe, so interrupts would be executed in a wrong context. Fixes: 3df140d11c6d ("mfd: max77620: Mask/unmask interrupt before/after servicing it") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Not tested on hardware --- drivers/mfd/max77620.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c index 21d2ab3db254..3af2974b3023 100644 --- a/drivers/mfd/max77620.c +++ b/drivers/mfd/max77620.c @@ -254,7 +254,7 @@ static int max77620_irq_global_unmask(void *irq_drv_data) return ret; } -static struct regmap_irq_chip max77620_top_irq_chip = { +static const struct regmap_irq_chip max77620_top_irq_chip = { .name = "max77620-top", .irqs = max77620_top_irqs, .num_irqs = ARRAY_SIZE(max77620_top_irqs), @@ -498,6 +498,7 @@ static int max77620_probe(struct i2c_client *client) const struct i2c_device_id *id = i2c_client_get_device_id(client); const struct regmap_config *rmap_config; struct max77620_chip *chip; + struct regmap_irq_chip *chip_desc; const struct mfd_cell *mfd_cells; int n_mfd_cells; bool pm_off; @@ -508,6 +509,14 @@ static int max77620_probe(struct i2c_client *client) return -ENOMEM; i2c_set_clientdata(client, chip); + + chip_desc = devm_kmemdup(&client->dev, &max77620_top_irq_chip, + sizeof(max77620_top_irq_chip), + GFP_KERNEL); + if (!chip_desc) + return -ENOMEM; + chip_desc->irq_drv_data = chip; + chip->dev = &client->dev; chip->chip_irq = client->irq; chip->chip_id = (enum max77620_chip_id)id->driver_data; @@ -544,11 +553,9 @@ static int max77620_probe(struct i2c_client *client) if (ret < 0) return ret; - max77620_top_irq_chip.irq_drv_data = chip; ret = devm_regmap_add_irq_chip(chip->dev, chip->rmap, client->irq, IRQF_ONESHOT | IRQF_SHARED, 0, - &max77620_top_irq_chip, - &chip->top_irq_data); + chip_desc, &chip->top_irq_data); if (ret < 0) { dev_err(chip->dev, "Failed to add regmap irq: %d\n", ret); return ret; -- 2.48.1

1 day, 16 hours

2
1
0 0

Re: Patch "drm/amd/display: change dc stream color settings only in atomic commit" has been added to the 6.17-stable tree

by Melissa Wen

Hi Sasha, Same here, can you backport the previous related commit (2f9c63883730 "drm/amd/display: update color on atomic commit time" [1]) too? Otherwise, the commit below alone will cause regressions. Thanks, Melissa [1] https://github.com/torvalds/linux/commit/2f9c63883730a0bfecb086e6e59246933f… On 04/11/2025 20:53, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm/amd/display: change dc stream color settings only in atomic commit > > to the 6.17-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > drm-amd-display-change-dc-stream-color-settings-only.patch > and it can be found in the queue-6.17 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 87fe0b67d6d8340123e563e7156fbdf070a2954d > Author: Melissa Wen <mwen(a)igalia.com> > Date: Thu Sep 11 14:21:20 2025 -0300 > > drm/amd/display: change dc stream color settings only in atomic commit > > [ Upstream commit 51cb93aa0c4a9bb126b76f6e9fd640d88de25cee ] > > Don't update DC stream color components during atomic check. The driver > will continue validating the new CRTC color state but will not change DC > stream color components. The DC stream color state will only be > programmed at commit time in the `atomic_setup_commit` stage. > > It fixes gamma LUT loss reported by KDE users when changing brightness > quickly or changing Display settings (such as overscan) with nightlight > on and HDR. As KWin can do a test commit with color settings different > from those that should be applied in a non-test-only commit, if the > driver changes DC stream color state in atomic check, this state can be > eventually HW programmed in commit tail, instead of the respective state > set by the non-blocking commit. > > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4444 > Reported-by: Xaver Hugl <xaver.hugl(a)gmail.com> > Signed-off-by: Melissa Wen <mwen(a)igalia.com> > Reviewed-by: Harry Wentland <harry.wentland(a)amd.com> > Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index d66c9609efd8d..60eb2c2c79b77 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -11105,7 +11105,7 @@ static int dm_update_crtc_state(struct amdgpu_display_manager *dm, > if (dm_new_crtc_state->base.color_mgmt_changed || > dm_old_crtc_state->regamma_tf != dm_new_crtc_state->regamma_tf || > drm_atomic_crtc_needs_modeset(new_crtc_state)) { > - ret = amdgpu_dm_update_crtc_color_mgmt(dm_new_crtc_state); > + ret = amdgpu_dm_check_crtc_color_mgmt(dm_new_crtc_state, true); > if (ret) > goto fail; > } > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h > index c18a6b43c76f6..42801caf57b69 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h > @@ -1037,6 +1037,8 @@ void amdgpu_dm_init_color_mod(void); > int amdgpu_dm_create_color_properties(struct amdgpu_device *adev); > int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state); > int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc); > +int amdgpu_dm_check_crtc_color_mgmt(struct dm_crtc_state *crtc, > + bool check_only); > int amdgpu_dm_update_plane_color_mgmt(struct dm_crtc_state *crtc, > struct drm_plane_state *plane_state, > struct dc_plane_state *dc_plane_state); > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c > index c0dfe2d8b3bec..d4739b6334c24 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c > @@ -566,12 +566,11 @@ static int __set_output_tf(struct dc_transfer_func *func, > return res ? 0 : -ENOMEM; > } > > -static int amdgpu_dm_set_atomic_regamma(struct dc_stream_state *stream, > +static int amdgpu_dm_set_atomic_regamma(struct dc_transfer_func *out_tf, > const struct drm_color_lut *regamma_lut, > uint32_t regamma_size, bool has_rom, > enum dc_transfer_func_predefined tf) > { > - struct dc_transfer_func *out_tf = &stream->out_transfer_func; > int ret = 0; > > if (regamma_size || tf != TRANSFER_FUNCTION_LINEAR) { > @@ -885,33 +884,33 @@ int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state) > } > > /** > - * amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC stream. > + * amdgpu_dm_check_crtc_color_mgmt: Check if DRM color props are programmable by DC. > * @crtc: amdgpu_dm crtc state > + * @check_only: only check color state without update dc stream > * > - * With no plane level color management properties we're free to use any > - * of the HW blocks as long as the CRTC CTM always comes before the > - * CRTC RGM and after the CRTC DGM. > - * > - * - The CRTC RGM block will be placed in the RGM LUT block if it is non-linear. > - * - The CRTC DGM block will be placed in the DGM LUT block if it is non-linear. > - * - The CRTC CTM will be placed in the gamut remap block if it is non-linear. > + * This function just verifies CRTC LUT sizes, if there is enough space for > + * output transfer function and if its parameters can be calculated by AMD > + * color module. It also adjusts some settings for programming CRTC degamma at > + * plane stage, using plane DGM block. > * > * The RGM block is typically more fully featured and accurate across > * all ASICs - DCE can't support a custom non-linear CRTC DGM. > * > * For supporting both plane level color management and CRTC level color > - * management at once we have to either restrict the usage of CRTC properties > - * or blend adjustments together. > + * management at once we have to either restrict the usage of some CRTC > + * properties or blend adjustments together. > * > * Returns: > - * 0 on success. Error code if setup fails. > + * 0 on success. Error code if validation fails. > */ > -int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > + > +int amdgpu_dm_check_crtc_color_mgmt(struct dm_crtc_state *crtc, > + bool check_only) > { > struct dc_stream_state *stream = crtc->stream; > struct amdgpu_device *adev = drm_to_adev(crtc->base.state->dev); > bool has_rom = adev->asic_type <= CHIP_RAVEN; > - struct drm_color_ctm *ctm = NULL; > + struct dc_transfer_func *out_tf; > const struct drm_color_lut *degamma_lut, *regamma_lut; > uint32_t degamma_size, regamma_size; > bool has_regamma, has_degamma; > @@ -940,6 +939,14 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > crtc->cm_has_degamma = false; > crtc->cm_is_degamma_srgb = false; > > + if (check_only) { > + out_tf = kvzalloc(sizeof(*out_tf), GFP_KERNEL); > + if (!out_tf) > + return -ENOMEM; > + } else { > + out_tf = &stream->out_transfer_func; > + } > + > /* Setup regamma and degamma. */ > if (is_legacy) { > /* > @@ -954,8 +961,8 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > * inverse color ramp in legacy userspace. > */ > crtc->cm_is_degamma_srgb = true; > - stream->out_transfer_func.type = TF_TYPE_DISTRIBUTED_POINTS; > - stream->out_transfer_func.tf = TRANSFER_FUNCTION_SRGB; > + out_tf->type = TF_TYPE_DISTRIBUTED_POINTS; > + out_tf->tf = TRANSFER_FUNCTION_SRGB; > /* > * Note: although we pass has_rom as parameter here, we never > * actually use ROM because the color module only takes the ROM > @@ -963,16 +970,12 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > * > * See more in mod_color_calculate_regamma_params() > */ > - r = __set_legacy_tf(&stream->out_transfer_func, regamma_lut, > + r = __set_legacy_tf(out_tf, regamma_lut, > regamma_size, has_rom); > - if (r) > - return r; > } else { > regamma_size = has_regamma ? regamma_size : 0; > - r = amdgpu_dm_set_atomic_regamma(stream, regamma_lut, > + r = amdgpu_dm_set_atomic_regamma(out_tf, regamma_lut, > regamma_size, has_rom, tf); > - if (r) > - return r; > } > > /* > @@ -981,6 +984,43 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > * have to place the CTM in the OCSC in that case. > */ > crtc->cm_has_degamma = has_degamma; > + if (check_only) > + kvfree(out_tf); > + > + return r; > +} > + > +/** > + * amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC stream. > + * @crtc: amdgpu_dm crtc state > + * > + * With no plane level color management properties we're free to use any > + * of the HW blocks as long as the CRTC CTM always comes before the > + * CRTC RGM and after the CRTC DGM. > + * > + * - The CRTC RGM block will be placed in the RGM LUT block if it is non-linear. > + * - The CRTC DGM block will be placed in the DGM LUT block if it is non-linear. > + * - The CRTC CTM will be placed in the gamut remap block if it is non-linear. > + * > + * The RGM block is typically more fully featured and accurate across > + * all ASICs - DCE can't support a custom non-linear CRTC DGM. > + * > + * For supporting both plane level color management and CRTC level color > + * management at once we have to either restrict the usage of CRTC properties > + * or blend adjustments together. > + * > + * Returns: > + * 0 on success. Error code if setup fails. > + */ > +int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > +{ > + struct dc_stream_state *stream = crtc->stream; > + struct drm_color_ctm *ctm = NULL; > + int ret; > + > + ret = amdgpu_dm_check_crtc_color_mgmt(crtc, false); > + if (ret) > + return ret; > > /* Setup CRTC CTM. */ > if (crtc->base.ctm) {

1 day, 16 hours

1
0
0 0

Re: Patch "drm/amd/display: change dc stream color settings only in atomic commit" has been added to the 6.12-stable tree

by Melissa Wen

Hi Sasha, Can you backport the previous related commit (2f9c63883730 "drm/amd/display: update color on atomic commit time" [1]) too? Otherwise, the commit below alone will cause regressions. Thanks, Melissa [1] https://github.com/torvalds/linux/commit/2f9c63883730a0bfecb086e6e59246933f… On 04/11/2025 21:07, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm/amd/display: change dc stream color settings only in atomic commit > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > drm-amd-display-change-dc-stream-color-settings-only.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit fbdf5decdbe18e9488d0bf6ade60f63bf0348ee1 > Author: Melissa Wen <mwen(a)igalia.com> > Date: Thu Sep 11 14:21:20 2025 -0300 > > drm/amd/display: change dc stream color settings only in atomic commit > > [ Upstream commit 51cb93aa0c4a9bb126b76f6e9fd640d88de25cee ] > > Don't update DC stream color components during atomic check. The driver > will continue validating the new CRTC color state but will not change DC > stream color components. The DC stream color state will only be > programmed at commit time in the `atomic_setup_commit` stage. > > It fixes gamma LUT loss reported by KDE users when changing brightness > quickly or changing Display settings (such as overscan) with nightlight > on and HDR. As KWin can do a test commit with color settings different > from those that should be applied in a non-test-only commit, if the > driver changes DC stream color state in atomic check, this state can be > eventually HW programmed in commit tail, instead of the respective state > set by the non-blocking commit. > > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4444 > Reported-by: Xaver Hugl <xaver.hugl(a)gmail.com> > Signed-off-by: Melissa Wen <mwen(a)igalia.com> > Reviewed-by: Harry Wentland <harry.wentland(a)amd.com> > Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index ea6bc9517ed86..c314c213c21c3 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -10773,7 +10773,7 @@ static int dm_update_crtc_state(struct amdgpu_display_manager *dm, > if (dm_new_crtc_state->base.color_mgmt_changed || > dm_old_crtc_state->regamma_tf != dm_new_crtc_state->regamma_tf || > drm_atomic_crtc_needs_modeset(new_crtc_state)) { > - ret = amdgpu_dm_update_crtc_color_mgmt(dm_new_crtc_state); > + ret = amdgpu_dm_check_crtc_color_mgmt(dm_new_crtc_state, true); > if (ret) > goto fail; > } > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h > index 9603352ee0949..47f6569be54cb 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h > @@ -971,6 +971,8 @@ void amdgpu_dm_init_color_mod(void); > int amdgpu_dm_create_color_properties(struct amdgpu_device *adev); > int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state); > int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc); > +int amdgpu_dm_check_crtc_color_mgmt(struct dm_crtc_state *crtc, > + bool check_only); > int amdgpu_dm_update_plane_color_mgmt(struct dm_crtc_state *crtc, > struct drm_plane_state *plane_state, > struct dc_plane_state *dc_plane_state); > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c > index ebabfe3a512f4..e9c765e1c17ce 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c > @@ -566,12 +566,11 @@ static int __set_output_tf(struct dc_transfer_func *func, > return res ? 0 : -ENOMEM; > } > > -static int amdgpu_dm_set_atomic_regamma(struct dc_stream_state *stream, > +static int amdgpu_dm_set_atomic_regamma(struct dc_transfer_func *out_tf, > const struct drm_color_lut *regamma_lut, > uint32_t regamma_size, bool has_rom, > enum dc_transfer_func_predefined tf) > { > - struct dc_transfer_func *out_tf = &stream->out_transfer_func; > int ret = 0; > > if (regamma_size || tf != TRANSFER_FUNCTION_LINEAR) { > @@ -885,33 +884,33 @@ int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state) > } > > /** > - * amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC stream. > + * amdgpu_dm_check_crtc_color_mgmt: Check if DRM color props are programmable by DC. > * @crtc: amdgpu_dm crtc state > + * @check_only: only check color state without update dc stream > * > - * With no plane level color management properties we're free to use any > - * of the HW blocks as long as the CRTC CTM always comes before the > - * CRTC RGM and after the CRTC DGM. > - * > - * - The CRTC RGM block will be placed in the RGM LUT block if it is non-linear. > - * - The CRTC DGM block will be placed in the DGM LUT block if it is non-linear. > - * - The CRTC CTM will be placed in the gamut remap block if it is non-linear. > + * This function just verifies CRTC LUT sizes, if there is enough space for > + * output transfer function and if its parameters can be calculated by AMD > + * color module. It also adjusts some settings for programming CRTC degamma at > + * plane stage, using plane DGM block. > * > * The RGM block is typically more fully featured and accurate across > * all ASICs - DCE can't support a custom non-linear CRTC DGM. > * > * For supporting both plane level color management and CRTC level color > - * management at once we have to either restrict the usage of CRTC properties > - * or blend adjustments together. > + * management at once we have to either restrict the usage of some CRTC > + * properties or blend adjustments together. > * > * Returns: > - * 0 on success. Error code if setup fails. > + * 0 on success. Error code if validation fails. > */ > -int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > + > +int amdgpu_dm_check_crtc_color_mgmt(struct dm_crtc_state *crtc, > + bool check_only) > { > struct dc_stream_state *stream = crtc->stream; > struct amdgpu_device *adev = drm_to_adev(crtc->base.state->dev); > bool has_rom = adev->asic_type <= CHIP_RAVEN; > - struct drm_color_ctm *ctm = NULL; > + struct dc_transfer_func *out_tf; > const struct drm_color_lut *degamma_lut, *regamma_lut; > uint32_t degamma_size, regamma_size; > bool has_regamma, has_degamma; > @@ -940,6 +939,14 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > crtc->cm_has_degamma = false; > crtc->cm_is_degamma_srgb = false; > > + if (check_only) { > + out_tf = kvzalloc(sizeof(*out_tf), GFP_KERNEL); > + if (!out_tf) > + return -ENOMEM; > + } else { > + out_tf = &stream->out_transfer_func; > + } > + > /* Setup regamma and degamma. */ > if (is_legacy) { > /* > @@ -954,8 +961,8 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > * inverse color ramp in legacy userspace. > */ > crtc->cm_is_degamma_srgb = true; > - stream->out_transfer_func.type = TF_TYPE_DISTRIBUTED_POINTS; > - stream->out_transfer_func.tf = TRANSFER_FUNCTION_SRGB; > + out_tf->type = TF_TYPE_DISTRIBUTED_POINTS; > + out_tf->tf = TRANSFER_FUNCTION_SRGB; > /* > * Note: although we pass has_rom as parameter here, we never > * actually use ROM because the color module only takes the ROM > @@ -963,16 +970,12 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > * > * See more in mod_color_calculate_regamma_params() > */ > - r = __set_legacy_tf(&stream->out_transfer_func, regamma_lut, > + r = __set_legacy_tf(out_tf, regamma_lut, > regamma_size, has_rom); > - if (r) > - return r; > } else { > regamma_size = has_regamma ? regamma_size : 0; > - r = amdgpu_dm_set_atomic_regamma(stream, regamma_lut, > + r = amdgpu_dm_set_atomic_regamma(out_tf, regamma_lut, > regamma_size, has_rom, tf); > - if (r) > - return r; > } > > /* > @@ -981,6 +984,43 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > * have to place the CTM in the OCSC in that case. > */ > crtc->cm_has_degamma = has_degamma; > + if (check_only) > + kvfree(out_tf); > + > + return r; > +} > + > +/** > + * amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC stream. > + * @crtc: amdgpu_dm crtc state > + * > + * With no plane level color management properties we're free to use any > + * of the HW blocks as long as the CRTC CTM always comes before the > + * CRTC RGM and after the CRTC DGM. > + * > + * - The CRTC RGM block will be placed in the RGM LUT block if it is non-linear. > + * - The CRTC DGM block will be placed in the DGM LUT block if it is non-linear. > + * - The CRTC CTM will be placed in the gamut remap block if it is non-linear. > + * > + * The RGM block is typically more fully featured and accurate across > + * all ASICs - DCE can't support a custom non-linear CRTC DGM. > + * > + * For supporting both plane level color management and CRTC level color > + * management at once we have to either restrict the usage of CRTC properties > + * or blend adjustments together. > + * > + * Returns: > + * 0 on success. Error code if setup fails. > + */ > +int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc) > +{ > + struct dc_stream_state *stream = crtc->stream; > + struct drm_color_ctm *ctm = NULL; > + int ret; > + > + ret = amdgpu_dm_check_crtc_color_mgmt(crtc, false); > + if (ret) > + return ret; > > /* Setup CRTC CTM. */ > if (crtc->base.ctm) {

1 day, 16 hours

1
0
0 0

[PATCH] spi: Try to get ACPI GPIO IRQ earlier

by Hans de Goede

Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device. If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables. Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet. Link: https://bbs.archlinux.org/viewtopic.php?id=302348 Fixes: d24cfee7f63d ("spi: Fix acpi deferred irq probe") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hansg(a)kernel.org> --- drivers/spi/spi.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 2e0647a06890..8588e8562220 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2851,6 +2851,16 @@ static acpi_status acpi_register_spi_device(struct spi_controller *ctlr, acpi_set_modalias(adev, acpi_device_hid(adev), spi->modalias, sizeof(spi->modalias)); + /* + * This gets re-tried in spi_probe() for -EPROBE_DEFER handling in case + * the GPIO controller does not have a driver yet. This needs to be done + * here too, because this call sets the GPIO direction and/or bias. + * Setting these needs to be done even if there is no driver, in which + * case spi_probe() will never get called. + */ + if (spi->irq < 0) + spi->irq = acpi_dev_gpio_irq_get(adev, 0); + acpi_device_set_enumerated(adev); adev->power.flags.ignore_parent = true; -- 2.51.1

1 day, 16 hours

3
10
0 0

[PATCH v10 2/5] NFSD: Make FILE_SYNC WRITEs comply with spec

by Chuck Lever

From: Chuck Lever <chuck.lever(a)oracle.com> Mike noted that when NFSD responds to an NFS_FILE_SYNC WRITE, it does not also persist file time stamps. To wit, Section 18.32.3 of RFC 8881 mandates: > The client specifies with the stable parameter the method of how > the data is to be processed by the server. If stable is > FILE_SYNC4, the server MUST commit the data written plus all file > system metadata to stable storage before returning results. This > corresponds to the NFSv2 protocol semantics. Any other behavior > constitutes a protocol violation. If stable is DATA_SYNC4, then > the server MUST commit all of the data to stable storage and > enough of the metadata to retrieve the data before returning. Commit 3f3503adb332 ("NFSD: Use vfs_iocb_iter_write()") replaced: - flags |= RWF_SYNC; with: + kiocb.ki_flags |= IOCB_DSYNC; which appears to be correct given: if (flags & RWF_SYNC) kiocb_flags |= IOCB_DSYNC; in kiocb_set_rw_flags(). However the author of that commit did not appreciate that the previous line in kiocb_set_rw_flags() results in IOCB_SYNC also being set: kiocb_flags |= (__force int) (flags & RWF_SUPPORTED); RWF_SUPPORTED contains RWF_SYNC, and RWF_SYNC is the same bit as IOCB_SYNC. Reviewers at the time did not catch the omission. Reported-by: Mike Snitzer <snitzer(a)kernel.org> Closes: https://lore.kernel.org/linux-nfs/20251018005431.3403-1-cel@kernel.org/T/#t Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Fixes: 3f3503adb332 ("NFSD: Use vfs_iocb_iter_write()") Cc: stable(a)vger.kernel.org Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- fs/nfsd/vfs.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c index f537a7b4ee01..5333d49910d9 100644 --- a/fs/nfsd/vfs.c +++ b/fs/nfsd/vfs.c @@ -1314,8 +1314,18 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh *fhp, stable = NFS_UNSTABLE; init_sync_kiocb(&kiocb, file); kiocb.ki_pos = offset; - if (stable && !fhp->fh_use_wgather) - kiocb.ki_flags |= IOCB_DSYNC; + if (likely(!fhp->fh_use_wgather)) { + switch (stable) { + case NFS_FILE_SYNC: + /* persist data and timestamps */ + kiocb.ki_flags |= IOCB_DSYNC | IOCB_SYNC; + break; + case NFS_DATA_SYNC: + /* persist data only */ + kiocb.ki_flags |= IOCB_DSYNC; + break; + } + } nvecs = xdr_buf_to_bvec(rqstp->rq_bvec, rqstp->rq_maxpages, payload); iov_iter_bvec(&iter, ITER_SOURCE, rqstp->rq_bvec, nvecs, *cnt); -- 2.51.0

1 day, 16 hours

3
2
0 0

[PATCH v2] leds: leds-lp50xx: LP5009 supports 3 modules for a total of 9 LEDs

by Christian Hitz

From: Christian Hitz <christian.hitz(a)bbv.ch> LP5009 supports 9 LED outputs that are grouped into 3 modules. Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Hitz <christian.hitz(a)bbv.ch> --- Changes in v2: - Improve log message --- drivers/leds/leds-lp50xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c index 94f8ef6b482c..05229e2f2e7e 100644 --- a/drivers/leds/leds-lp50xx.c +++ b/drivers/leds/leds-lp50xx.c @@ -54,7 +54,7 @@ /* There are 3 LED outputs per bank */ #define LP50XX_LEDS_PER_MODULE 3 -#define LP5009_MAX_LED_MODULES 2 +#define LP5009_MAX_LED_MODULES 3 #define LP5012_MAX_LED_MODULES 4 #define LP5018_MAX_LED_MODULES 6 #define LP5024_MAX_LED_MODULES 8 -- 2.51.1

1 day, 16 hours

2
1
0 0

[PATCH] LoongArch: KVM: Fix max supported vCPUs set with eiointc

by Bibo Mao

VM fails to boot with 256 vCPUs, the detailed command is qemu-system-loongarch64 -smp 256 and there is error reported as follows: KVM_LOONGARCH_EXTIOI_INIT_NUM_CPU failed: Invalid argument There is typo issue in function kvm_eiointc_ctrl_access() when set max supported vCPUs. Cc: stable(a)vger.kernel.org Fixes: 47256c4c8b1b ("LoongArch: KVM: Avoid copy_*_user() with lock hold in kvm_eiointc_ctrl_access()") Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> --- arch/loongarch/kvm/intc/eiointc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/loongarch/kvm/intc/eiointc.c b/arch/loongarch/kvm/intc/eiointc.c index c32333695381..a1cc116b4dac 100644 --- a/arch/loongarch/kvm/intc/eiointc.c +++ b/arch/loongarch/kvm/intc/eiointc.c @@ -439,7 +439,7 @@ static int kvm_eiointc_ctrl_access(struct kvm_device *dev, spin_lock_irqsave(&s->lock, flags); switch (type) { case KVM_DEV_LOONGARCH_EXTIOI_CTRL_INIT_NUM_CPU: - if (val >= EIOINTC_ROUTE_MAX_VCPUS) + if (val > EIOINTC_ROUTE_MAX_VCPUS) ret = -EINVAL; else s->num_cpu = val; base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 -- 2.39.3

1 day, 17 hours

2
1
0 0

💬📝 Need Accurate WhatsApp Chat Translation Services? ✅

by Communication Dubai

[Company Logo] COMMUNICATION LEGAL TRANSLATION: BEST LEGAL TRANSLATION SERVICES IN UAE LOOKING FOR WHATSAPP CHAT TRANSLATION? WhatsApp Chat Translation Dubai ensures precise translation of chat messages in various languages, bridging communication gaps for personal or business needs while maintaining confidentiality and accuracy. WHY CHOOSE US? [check mark] Certified Translation Services [check mark] Fast Turn-around Times [check mark] Support for 75+ Languages [check mark] Competitive Rates [check mark] Over 95,000 Satisfied Clients [check mark] Providing Services Since 1996 Request a Quote [http://track.uaetranslationservices.com/web/index.php/campaigns/kf505bzjlya…] [ Whatsapp chat translation dubai] [http://track.uaetranslationservices.com/web/index.php/campaigns/kf505bzjlya…] HIGH QUALITY TRANSLATION SERVICES, CERTIFIED BY THE UAE MINISTRY OF JUSTICE [Company Logo] The leading Dubai-based translation agency in the Middle East offering its services in more than 75 languages with world- class quality. CONTACT US admin(a)communicationdubai.com www.communicationdubai.com +971 42663517 I +971 502885313 IF YOU WANT TO UNSUBSCRIBE CLICK HERE [http://track.uaetranslationservices.com/web/index.php/campaigns/kf505bzjlya…] AND ABUSE REPORT [http://track.uaetranslationservices.com/web/index.php/campaigns/kf505bzjlya…]

1 day, 19 hours

1
0
0 0

[PATCH v2] ALSA: wavefront: Fix integer overflow in sample size validation

by Junrui Luo

The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain(a)outlook.com> --- Changes in v2: - Check for negative freemem before size comparison - Link to v1: https://lore.kernel.org/all/SYBPR01MB7881FA5CEECF0CCEABDD6CC4AFC4A@SYBPR01M… --- sound/isa/wavefront/wavefront_synth.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/isa/wavefront/wavefront_synth.c b/sound/isa/wavefront/wavefront_synth.c index cd5c177943aa..0d78533e1cfd 100644 --- a/sound/isa/wavefront/wavefront_synth.c +++ b/sound/isa/wavefront/wavefront_synth.c @@ -950,9 +950,9 @@ wavefront_send_sample (snd_wavefront_t *dev, if (header->size) { dev->freemem = wavefront_freemem (dev); - if (dev->freemem < (int)header->size) { + if (dev->freemem < 0 || dev->freemem < header->size) { dev_err(dev->card->dev, - "insufficient memory to load %d byte sample.\n", + "insufficient memory to load %u byte sample.\n", header->size); return -ENOMEM; } -- 2.51.1.dirty

1 day, 19 hours

2
1
0 0

[PATCH] ALSA: wavefront: Clear substream pointers on close

by Junrui Luo

Clear substream pointers in close functions to avoid leaving dangling pointers, helping to improve code safety and prevents potential issues. Reported-by: Yuhao Jiang <danisjiang(a)gmail.com> Reported-by: Junrui Luo <moonafterrain(a)outlook.com> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain(a)outlook.com> --- sound/isa/wavefront/wavefront_midi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/isa/wavefront/wavefront_midi.c b/sound/isa/wavefront/wavefront_midi.c index 1250ecba659a..69d87c4cafae 100644 --- a/sound/isa/wavefront/wavefront_midi.c +++ b/sound/isa/wavefront/wavefront_midi.c @@ -278,6 +278,7 @@ static int snd_wavefront_midi_input_close(struct snd_rawmidi_substream *substrea return -EIO; guard(spinlock_irqsave)(&midi->open); + midi->substream_input[mpu] = NULL; midi->mode[mpu] &= ~MPU401_MODE_INPUT; return 0; @@ -300,6 +301,7 @@ static int snd_wavefront_midi_output_close(struct snd_rawmidi_substream *substre return -EIO; guard(spinlock_irqsave)(&midi->open); + midi->substream_output[mpu] = NULL; midi->mode[mpu] &= ~MPU401_MODE_OUTPUT; return 0; } -- 2.51.1.dirty

1 day, 19 hours

2
1
0 0

[PATCH RESEND 0/3] PCI: meson: Fix the parsing of DBI region

by Manivannan Sadhasivam

Hi, This compile tested only series aims to fix the DBI parsing issue repored in [1]. The issue stems from the fact that the DT and binding described 'dbi' region as 'elbi' from the start. Now, both binding and DTs are fixed and the driver is reworked to work with both old and new DTs. Note: The driver patch is OK to be backported till 6.2 where the common resource parsing code was introduced. But the DTS patch should not be backported. And I'm not sure about the backporting of the binding. Please test this series on the Meson board with old and new DTs. - Mani [1] https://lore.kernel.org/linux-pci/DM4PR05MB102707B8CDF84D776C39F22F2C7F0A@D… Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com> --- Resending as the git sendemail config got messed up --- Manivannan Sadhasivam (3): dt-bindings: PCI: amlogic: Fix the register name of the DBI region arm64: dts: amlogic: Fix the register name of the 'DBI' region PCI: meson: Fix parsing the DBI register region .../devicetree/bindings/pci/amlogic,axg-pcie.yaml | 6 +++--- arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++-- arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +- drivers/pci/controller/dwc/pci-meson.c | 18 +++++++++++++++--- drivers/pci/controller/dwc/pcie-designware.c | 12 +++++++----- 5 files changed, 28 insertions(+), 14 deletions(-) --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20251031-pci-meson-fix-c8b651bc6662 Best regards, -- Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com>

1 day, 19 hours

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror