June 2025 - Linux-stable-mirror

[PATCH v1] arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on

by Francesco Dolcini

From: Francesco Dolcini <francesco.dolcini(a)toradex.com> LDO5 regulator is used to power the i.MX8MM NVCC_SD2 I/O supply, that is used for the SD2 card interface and also for some GPIOs. When the SD card interface is not enabled the regulator subsystem could turn off this supply, since it is not used anywhere else, however this will also remove the power to some other GPIOs, for example one I/O that is used to power the ethernet phy, leading to a non working ethernet interface. [ 31.820515] On-module +V3.3_1.8_SD (LDO5): disabling [ 31.821761] PMIC_USDHC_VSELECT: disabling [ 32.764949] fec 30be0000.ethernet end0: Link is Down Fix this keeping the LDO5 supply always on. Cc: stable(a)vger.kernel.org Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Fixes: f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5") Signed-off-by: Francesco Dolcini <francesco.dolcini(a)toradex.com> --- arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi index d29710772569..1594ce9182a5 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi @@ -464,6 +464,7 @@ reg_vdd_phy: LDO4 { }; reg_nvcc_sd: LDO5 { + regulator-always-on; regulator-max-microvolt = <3300000>; regulator-min-microvolt = <1800000>; regulator-name = "On-module +V3.3_1.8_SD (LDO5)"; -- 2.39.5

1 week, 1 day

2
1
0 0

[PATCH] usb: hub: Don't try to recover devices lost during warm reset.

by Mathias Nyman

Hub driver warm-resets ports in SS.Inactive or Compliance mode to recover a possible connected device. The port reset code correctly detects if a connection is lost during reset, but hub driver port_event() fails to take this into account in some cases. port_event() ends up using stale values and assumes there is a connected device, and will try all means to recover it, including power-cycling the port. Details: This case was triggered when xHC host was suspended with DbC (Debug Capability) enabled and connected. DbC turns one xHC port into a simple usb debug device, allowing debugging a system with an A-to-A USB debug cable. xhci DbC code disables DbC when xHC is system suspended to D3, and enables it back during resume. We essentially end up with two hosts connected to each other during suspend, and, for a short while during resume, until DbC is enabled back. The suspended xHC host notices some activity on the roothub port, but can't train the link due to being suspended, so xHC hardware sets a CAS (Cold Attach Status) flag for this port to inform xhci host driver that the port needs to be warm reset once xHC resumes. CAS is xHCI specific, and not part of USB specification, so xhci driver tells usb core that the port has a connection and link is in compliance mode. Recovery from complinace mode is similar to CAS recovery. xhci CAS driver support that fakes a compliance mode connection was added in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Once xHCI resumes and DbC is enabled back, all activity on the xHC roothub host side port disappears. The hub driver will anyway think port has a connection and link is in compliance mode, and hub driver will try to recover it. The port power-cycle during recovery seems to cause issues to the active DbC connection. Fix this by clearing connect_change flag if hub_port_reset() returns -ENOTCONN, thus avoiding the whole unnecessary port recovery and initialization attempt. Cc: stable(a)vger.kernel.org Fixes: 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/core/hub.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 6bb6e92cb0a4..f981e365be36 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -5754,6 +5754,7 @@ static void port_event(struct usb_hub *hub, int port1) struct usb_device *hdev = hub->hdev; u16 portstatus, portchange; int i = 0; + int err; connect_change = test_bit(port1, hub->change_bits); clear_bit(port1, hub->event_bits); @@ -5850,8 +5851,11 @@ static void port_event(struct usb_hub *hub, int port1) } else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION) || udev->state == USB_STATE_NOTATTACHED) { dev_dbg(&port_dev->dev, "do warm reset, port only\n"); - if (hub_port_reset(hub, port1, NULL, - HUB_BH_RESET_TIME, true) < 0) + err = hub_port_reset(hub, port1, NULL, + HUB_BH_RESET_TIME, true); + if (!udev && err == -ENOTCONN) + connect_change = 0; + else if (err < 0) hub_port_disable(hub, port1, 1); } else { dev_dbg(&port_dev->dev, "do warm reset, full device\n"); -- 2.43.0

1 week, 1 day

1
0
0 0

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

by gregkh＠linuxfoundation.org

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

1 week, 1 day

5
8
0 0

[PATCH v2 0/2] PCI: of: Fix OF device node refcount leakages

by Zijun Hu

This patch series is to fix OF device node refcount leakage for - of_irq_parse_and_map_pci() - of_pci_prop_intr_map() Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- Similar fixes within mainline: Commit: 962a2805e47b ("of/irq: Fix device node refcount leakage in API irq_of_parse_and_map()") Commit: ff93e7213d6c ("of/irq: Fix device node refcount leakage in API of_irq_parse_raw()") --- Changes in v2: - Change author mail - Link to v1: https://lore.kernel.org/r/20250407-fix_of_pci-v1-0-a14d981fd148@quicinc.com --- Zijun Hu (2): PCI: of: Fix OF device node refcount leakage in API of_irq_parse_and_map_pci() PCI: of: Fix OF device node refcount leakages in of_pci_prop_intr_map() drivers/pci/of.c | 2 ++ drivers/pci/of_property.c | 20 +++++++++++--------- 2 files changed, 13 insertions(+), 9 deletions(-) --- base-commit: c10ba24fb5c9d6e2eb595bf7a0a00fda8f265a0b change-id: 20250407-fix_of_pci-20b45dcc26b5 Best regards, -- Zijun Hu <zijun.hu(a)oss.qualcomm.com>

1 week, 1 day

1
1
0 0

[REGRESSION] stable-rc/linux-5.10.y: (build) call to '__compiletime_assert_669' declared with 'error' attribute...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: --- call to '__compiletime_assert_669' declared with 'error' attribute: BUILD_BUG_ON failed: NFP_BPF_SCALAR_VALUE != SCALAR_VALUE || NFP_BPF_MAP_VALUE != PTR_TO_MAP_VALUE || NFP_BPF_STACK != PTR_TO_STACK || NFP_BPF_PACKET_DATA != PTR_TO_PACKET in drivers/net/ethernet/netronome/nfp/bpf/verifier.o (drivers/net/ethernet/netronome/nfp/bpf/verifier.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:a443657e962cc5696a4fadb99408418d06ed31b4 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: dd859e40a92ee19d6b87baa7c8278804c20c4781 Log excerpt: ===================================================== drivers/net/ethernet/netronome/nfp/bpf/verifier.c:234:3: error: call to '__compiletime_assert_669' declared with 'error' attribute: BUILD_BUG_ON failed: NFP_BPF_SCALAR_VALUE != SCALAR_VALUE || NFP_BPF_MAP_VALUE != PTR_TO_MAP_VALUE || NFP_BPF_STACK != PTR_TO_STACK || NFP_BPF_PACKET_DATA != PTR_TO_PACKET 234 | BUILD_BUG_ON(NFP_BPF_SCALAR_VALUE != SCALAR_VALUE || | ^ ./include/linux/build_bug.h:50:2: note: expanded from macro 'BUILD_BUG_ON' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^ ./include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^ ././include/linux/compiler_types.h:309:2: note: expanded from macro 'compiletime_assert' 309 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ ././include/linux/compiler_types.h:297:2: note: expanded from macro '_compiletime_assert' 297 | __compiletime_assert(condition, msg, prefix, suffix) | ^ ././include/linux/compiler_types.h:290:4: note: expanded from macro '__compiletime_assert' 290 | prefix ## suffix(); \ | ^ <scratch space>:5:1: note: expanded from here 5 | __compiletime_assert_669 | ^ CC [M] drivers/net/wireless/zydas/zd1211rw/zd_rf_rf2959.o CC [M] drivers/mmc/host/vub300.o 1 error generated. ===================================================== # Builds where the incident occurred: ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:6859285f5c2cf25042d0f80e #kernelci issue maestro:a443657e962cc5696a4fadb99408418d06ed31b4 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 week, 2 days

1
0
0 0

[REGRESSION] stable-rc/linux-5.10.y: (build) call to '__compiletime_assert_730' declared with 'error' attribute...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: --- call to '__compiletime_assert_730' declared with 'error' attribute: BUILD_BUG_ON failed: NFP_BPF_SCALAR_VALUE != SCALAR_VALUE || NFP_BPF_MAP_VALUE != PTR_TO_MAP_VALUE || NFP_BPF_STACK != PTR_TO_STACK || NFP_BPF_PACKET_DATA != PTR_TO_PACKET in drivers/net/ethernet/netronome/nfp/bpf/verifier.o (drivers/net/ethernet/netronome/nfp/bpf/verifier.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:c9be1e56d1a9e040b3bd8a197186766f617e4e08 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: dd859e40a92ee19d6b87baa7c8278804c20c4781 Log excerpt: ===================================================== drivers/net/ethernet/netronome/nfp/bpf/verifier.c:234:3: error: call to '__compiletime_assert_730' declared with 'error' attribute: BUILD_BUG_ON failed: NFP_BPF_SCALAR_VALUE != SCALAR_VALUE || NFP_BPF_MAP_VALUE != PTR_TO_MAP_VALUE || NFP_BPF_STACK != PTR_TO_STACK || NFP_BPF_PACKET_DATA != PTR_TO_PACKET 234 | BUILD_BUG_ON(NFP_BPF_SCALAR_VALUE != SCALAR_VALUE || | ^ ./include/linux/build_bug.h:50:2: note: expanded from macro 'BUILD_BUG_ON' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^ ./include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^ ././include/linux/compiler_types.h:309:2: note: expanded from macro 'compiletime_assert' 309 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ ././include/linux/compiler_types.h:297:2: note: expanded from macro '_compiletime_assert' 297 | __compiletime_assert(condition, msg, prefix, suffix) | ^ ././include/linux/compiler_types.h:290:4: note: expanded from macro '__compiletime_assert' 290 | prefix ## suffix(); \ | ^ <scratch space>:2:1: note: expanded from here 2 | __compiletime_assert_730 | ^ CC [M] drivers/net/wireless/realtek/rtlwifi/efuse.o 1 error generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685928155c2cf25042d0f643 #kernelci issue maestro:c9be1e56d1a9e040b3bd8a197186766f617e4e08 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 week, 2 days

1
0
0 0

[PATCH 0/4] Fix kernel panic problem caused by bpf verifier in 5.10 stable kernel

by Aaron Lu

Hi, Wei reported when loading his bpf prog in 5.10.200 kernel, host would panic, this didn't happen in 5.10.135 kernel. Test on latest v5.10.238 still has this panic: [ 26.531718] BUG: kernel NULL pointer dereference, address: 0000000000000168 [ 26.538093] #PF: supervisor read access in kernel mode [ 26.542727] #PF: error_code(0x0000) - not-present page [ 26.548093] PGD 10f3e9067 P4D 10f332067 PUD 10f0c5067 PMD 0 [ 26.553211] Oops: 0000 [#1] SMP NOPTI [ 26.556531] CPU: 2 PID: 541 Comm: main Not tainted 5.10.238-00267-g01e7e36b8606 #63 [ 26.563816] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 26.572357] RIP: 0010:__mark_chain_precision+0x24b/0x4d0 [ 26.576572] Code: 51 01 be 20 00 00 00 4c 89 ef 48 63 d2 e8 bd df 31 00 89 c1 83 f8 1f 7f 29 48 63 d1 48 89 d0 48 c1 e0 04 48 29 d0 48 8d 04 c3 <83> 38 01 75 c3 0f b6 74 24 06 80 78 74 00 c6 40 74 01 44 0f 44 f6 [ 26.589100] RSP: 0018:ffa0000000ff7b60 EFLAGS: 00010216 [ 26.592612] RAX: 0000000000000168 RBX: 0000000000000000 RCX: 0000000000000003 [ 26.597416] RDX: 0000000000000003 RSI: 0000000000000020 RDI: ffa0000000ff7b78 [ 26.601362] RBP: 0000000000000003 R08: ffa0000000ff7b70 R09: 0000000000000004 [ 26.604261] R10: 0000000000000007 R11: ffa0000000425000 R12: ff11000102ee2000 [ 26.607202] R13: ffa0000000ff7b78 R14: 0000000000000000 R15: ff1100010ee37140 [ 26.610327] FS: 00000000007a0630(0000) GS:ff1100081c400000(0000) knlGS:0000000000000000 [ 26.613678] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 26.616105] CR2: 0000000000000168 CR3: 0000000115e72002 CR4: 0000000000371ee0 [ 26.619059] Call Trace: [ 26.620118] adjust_reg_min_max_vals+0x133/0x340 [ 26.622048] ? krealloc+0x63/0xe0 [ 26.623435] do_check+0x38c/0xa80 [ 26.624859] do_check_common+0x15b/0x280 [ 26.626496] bpf_check+0xbe1/0xd30 [ 26.627939] ? srso_alias_return_thunk+0x5/0x7f [ 26.629796] ? trace_hardirqs_on+0x1a/0xd0 [ 26.631503] ? srso_alias_return_thunk+0x5/0x7f [ 26.633402] bpf_prog_load+0x422/0x8a0 [ 26.634987] ? srso_alias_return_thunk+0x5/0x7f [ 26.636864] ? __handle_mm_fault+0x3cb/0x6d0 [ 26.638658] ? srso_alias_return_thunk+0x5/0x7f [ 26.640543] ? lock_release+0xe3/0x110 [ 26.642114] __do_sys_bpf+0x485/0xdf0 [ 26.643624] do_syscall_64+0x33/0x40 [ 26.645110] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ 26.647190] RIP: 0033:0x409a6e [ 26.648470] Code: 24 28 44 8b 44 24 2c e9 70 ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 49 89 f2 48 89 fa 48 89 ce 48 89 df 0f 05 <48> 3d 01 f0 ff ff 76 15 48 f7 d8 48 89 c1 48 c7 c0 ff ff ff ff 48 [ 26.656154] RSP: 002b:000000c00199edc0 EFLAGS: 00000212 ORIG_RAX: 0000000000000141 [ 26.659451] RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000409a6e [ 26.662375] RDX: 0000000000000098 RSI: 000000c00199f290 RDI: 0000000000000005 [ 26.665267] RBP: 000000c00199ee00 R08: 0000000000000000 R09: 0000000000000000 [ 26.668204] R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000 [ 26.671125] R13: 0000000000000080 R14: 000000c000002380 R15: 8080808080808080 [ 26.674085] Modules linked in: [ 26.675363] CR2: 0000000000000168 [ 26.676772] ---[ end trace 3fc192ee4dabbf12 ]--- [ 26.678667] RIP: 0010:__mark_chain_precision+0x24b/0x4d0 [ 26.680926] Code: 51 01 be 20 00 00 00 4c 89 ef 48 63 d2 e8 bd df 31 00 89 c1 83 f8 1f 7f 29 48 63 d1 48 89 d0 48 c1 e0 04 48 29 d0 48 8d 04 c3 <83> 38 01 75 c3 0f b6 74 24 06 80 78 74 00 c6 40 74 01 44 0f 44 f6 [ 26.688665] RSP: 0018:ffa0000000ff7b60 EFLAGS: 00010216 [ 26.690828] RAX: 0000000000000168 RBX: 0000000000000000 RCX: 0000000000000003 [ 26.693777] RDX: 0000000000000003 RSI: 0000000000000020 RDI: ffa0000000ff7b78 [ 26.696680] RBP: 0000000000000003 R08: ffa0000000ff7b70 R09: 0000000000000004 [ 26.699651] R10: 0000000000000007 R11: ffa0000000425000 R12: ff11000102ee2000 [ 26.702561] R13: ffa0000000ff7b78 R14: 0000000000000000 R15: ff1100010ee37140 [ 26.705522] FS: 00000000007a0630(0000) GS:ff1100081c400000(0000) knlGS:0000000000000000 [ 26.708806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 26.711179] CR2: 0000000000000168 CR3: 0000000115e72002 CR4: 0000000000371ee0 [ 26.714143] Kernel panic - not syncing: Fatal exception [ 26.716893] Kernel Offset: disabled [ 26.718911] Rebooting in 5 seconds.. I did a bisect in linux-5.10.y branch and found the fbc is commit 2474ec58b96d("bpf: allow precision tracking for programs with subprogs"). This series revert the above commit and related commits. After the revert, kernel does not panic anymore. For detailed log and a reproducer, please reference this link: https://lore.kernel.org/stable/20250605070921.GA3795@bytedance Aaron Lu (4): Revert "selftests/bpf: make test_align selftest more robust" Revert "bpf: aggressively forget precise markings during state checkpointing" Revert "bpf: stop setting precise in current state" Revert "bpf: allow precision tracking for programs with subprogs" kernel/bpf/verifier.c | 175 ++---------------- .../testing/selftests/bpf/prog_tests/align.c | 36 ++-- 2 files changed, 26 insertions(+), 185 deletions(-) -- 2.39.5

1 week, 2 days

1
4
0 0

[PATCH v3] usb: cdnsp: Fix issue with CV Bad Descriptor test

by Pawel Laszczak

The SSP2 controller has extra endpoint state preserve bit (ESP) which setting causes that endpoint state will be preserved during Halt Endpoint command. It is used only for EP0. Without this bit the Command Verifier "TD 9.10 Bad Descriptor Test" failed. Setting this bit doesn't have any impact for SSP controller. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") cc: stable(a)vger.kernel.org Signed-off-by: Pawel Laszczak <pawell(a)cadence.com> --- Changelog: v3: - removed else {} v2: - removed some typos - added pep variable initialization - updated TRB_ESP description drivers/usb/cdns3/cdnsp-debug.h | 5 +++-- drivers/usb/cdns3/cdnsp-ep0.c | 18 +++++++++++++++--- drivers/usb/cdns3/cdnsp-gadget.h | 6 ++++++ drivers/usb/cdns3/cdnsp-ring.c | 3 ++- 4 files changed, 26 insertions(+), 6 deletions(-) diff --git a/drivers/usb/cdns3/cdnsp-debug.h b/drivers/usb/cdns3/cdnsp-debug.h index cd138acdcce1..86860686d836 100644 --- a/drivers/usb/cdns3/cdnsp-debug.h +++ b/drivers/usb/cdns3/cdnsp-debug.h @@ -327,12 +327,13 @@ static inline const char *cdnsp_decode_trb(char *str, size_t size, u32 field0, case TRB_RESET_EP: case TRB_HALT_ENDPOINT: ret = scnprintf(str, size, - "%s: ep%d%s(%d) ctx %08x%08x slot %ld flags %c", + "%s: ep%d%s(%d) ctx %08x%08x slot %ld flags %c %c", cdnsp_trb_type_string(type), ep_num, ep_id % 2 ? "out" : "in", TRB_TO_EP_INDEX(field3), field1, field0, TRB_TO_SLOT_ID(field3), - field3 & TRB_CYCLE ? 'C' : 'c'); + field3 & TRB_CYCLE ? 'C' : 'c', + field3 & TRB_ESP ? 'P' : 'p'); break; case TRB_STOP_RING: ret = scnprintf(str, size, diff --git a/drivers/usb/cdns3/cdnsp-ep0.c b/drivers/usb/cdns3/cdnsp-ep0.c index f317d3c84781..5cd9b898ce97 100644 --- a/drivers/usb/cdns3/cdnsp-ep0.c +++ b/drivers/usb/cdns3/cdnsp-ep0.c @@ -414,6 +414,7 @@ static int cdnsp_ep0_std_request(struct cdnsp_device *pdev, void cdnsp_setup_analyze(struct cdnsp_device *pdev) { struct usb_ctrlrequest *ctrl = &pdev->setup; + struct cdnsp_ep *pep; int ret = -EINVAL; u16 len; @@ -427,10 +428,21 @@ void cdnsp_setup_analyze(struct cdnsp_device *pdev) goto out; } + pep = &pdev->eps[0]; + /* Restore the ep0 to Stopped/Running state. */ - if (pdev->eps[0].ep_state & EP_HALTED) { - trace_cdnsp_ep0_halted("Restore to normal state"); - cdnsp_halt_endpoint(pdev, &pdev->eps[0], 0); + if (pep->ep_state & EP_HALTED) { + if (GET_EP_CTX_STATE(pep->out_ctx) == EP_STATE_HALTED) + cdnsp_halt_endpoint(pdev, pep, 0); + + /* + * Halt Endpoint Command for SSP2 for ep0 preserve current + * endpoint state and driver has to synchronize the + * software endpoint state with endpoint output context + * state. + */ + pep->ep_state &= ~EP_HALTED; + pep->ep_state |= EP_STOPPED; } /* diff --git a/drivers/usb/cdns3/cdnsp-gadget.h b/drivers/usb/cdns3/cdnsp-gadget.h index 2afa3e558f85..a91cca509db0 100644 --- a/drivers/usb/cdns3/cdnsp-gadget.h +++ b/drivers/usb/cdns3/cdnsp-gadget.h @@ -987,6 +987,12 @@ enum cdnsp_setup_dev { #define STREAM_ID_FOR_TRB(p) ((((p)) << 16) & GENMASK(31, 16)) #define SCT_FOR_TRB(p) (((p) << 1) & 0x7) +/* + * Halt Endpoint Command TRB field. + * The ESP bit only exists in the SSP2 controller. + */ +#define TRB_ESP BIT(9) + /* Link TRB specific fields. */ #define TRB_TC BIT(1) diff --git a/drivers/usb/cdns3/cdnsp-ring.c b/drivers/usb/cdns3/cdnsp-ring.c index fd06cb85c4ea..d397d28efc6e 100644 --- a/drivers/usb/cdns3/cdnsp-ring.c +++ b/drivers/usb/cdns3/cdnsp-ring.c @@ -2483,7 +2483,8 @@ void cdnsp_queue_halt_endpoint(struct cdnsp_device *pdev, unsigned int ep_index) { cdnsp_queue_command(pdev, 0, 0, 0, TRB_TYPE(TRB_HALT_ENDPOINT) | SLOT_ID_FOR_TRB(pdev->slot_id) | - EP_ID_FOR_TRB(ep_index)); + EP_ID_FOR_TRB(ep_index) | + (!ep_index ? TRB_ESP : 0)); } void cdnsp_force_header_wakeup(struct cdnsp_device *pdev, int intf_num) -- 2.43.0

1 week, 2 days

2
5
0 0

[PATCH 5.10/5.15 1/1] fuse: don't increment nlink in link()

by d.privalov

From: Miklos Szeredi <mszeredi(a)redhat.com> commit 97f044f690bac2b094bfb7fb2d177ef946c85880 upstream. The fuse_iget() call in create_new_entry() already updated the inode with all the new attributes and incremented the attribute version. Incrementing the nlink will result in the wrong count. This wasn't noticed because the attributes were invalidated right after this. Updating ctime is still needed for the writeback case when the ctime is not refreshed. Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Signed-off-by: Dmitriy Privalov <d.privalov(a)omp.ru> --- fs/fuse/dir.c | 29 ++++++++++------------------- 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c index 4488a53a192d..7055fdc1b8ce 100644 --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -807,7 +807,7 @@ void fuse_flush_time_update(struct inode *inode) mapping_set_error(inode->i_mapping, err); } -void fuse_update_ctime(struct inode *inode) +static void fuse_update_ctime_in_cache(struct inode *inode) { if (!IS_NOCMTIME(inode)) { inode->i_ctime = current_time(inode); @@ -816,6 +816,12 @@ void fuse_update_ctime(struct inode *inode) } } +void fuse_update_ctime(struct inode *inode) +{ + fuse_invalidate_attr(inode); + fuse_update_ctime_in_cache(inode); +} + static int fuse_unlink(struct inode *dir, struct dentry *entry) { int err; @@ -986,25 +992,10 @@ static int fuse_link(struct dentry *entry, struct inode *newdir, args.in_args[1].size = newent->d_name.len + 1; args.in_args[1].value = newent->d_name.name; err = create_new_entry(fm, &args, newdir, newent, inode->i_mode); - /* Contrary to "normal" filesystems it can happen that link - makes two "logical" inodes point to the same "physical" - inode. We invalidate the attributes of the old one, so it - will reflect changes in the backing inode (link count, - etc.) - */ - if (!err) { - struct fuse_inode *fi = get_fuse_inode(inode); - - spin_lock(&fi->lock); - fi->attr_version = atomic64_inc_return(&fm->fc->attr_version); - if (likely(inode->i_nlink < UINT_MAX)) - inc_nlink(inode); - spin_unlock(&fi->lock); - fuse_invalidate_attr(inode); - fuse_update_ctime(inode); - } else if (err == -EINTR) { + if (!err) + fuse_update_ctime_in_cache(inode); + else if (err == -EINTR) fuse_invalidate_attr(inode); - } return err; } -- 2.34.1

1 week, 2 days

2
1
0 0

[PATCH] arm64: dts: ti: k3-j722s-evm: Fix USB gpio-hog level for Type-C

by Siddharth Vadapalli

According to the "GPIO Expander Map / Table" section of the J722S EVM Schematic within the Evaluation Module Design Files package [0], the GPIO Pin P05 located on the GPIO Expander 1 (I2C0/0x23) has to be pulled down to select the Type-C interface. Since commit under Fixes claims to enable the Type-C interface, update the property within "p05-hog" from "output-high" to "output-low", thereby switching from the Type-A interface to the Type-C interface. [0]: https://www.ti.com/lit/zip/sprr495 Cc: <stable(a)vger.kernel.org> Fixes: 485705df5d5f ("arm64: dts: ti: k3-j722s: Enable PCIe and USB support on J722S-EVM") Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> --- Hello, This patch is based on commit 86731a2a651e Linux 6.16-rc3 of Mainline Linux. Regards, Siddharth. arch/arm64/boot/dts/ti/k3-j722s-evm.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts index a47852fdca70..d0533723412a 100644 --- a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts +++ b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts @@ -634,7 +634,7 @@ p05-hog { /* P05 - USB2.0_MUX_SEL */ gpio-hog; gpios = <5 GPIO_ACTIVE_LOW>; - output-high; + output-low; }; p01_hog: p01-hog { -- 2.34.1

1 week, 2 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025