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

FAILED: patch "[PATCH] rust: compile libcore with edition 2024 for 1.87+" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x f4daa80d6be7d3c55ca72a8e560afc4e21f886aa # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025061734-shale-reliably-8969@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f4daa80d6be7d3c55ca72a8e560afc4e21f886aa Mon Sep 17 00:00:00 2001 From: Gary Guo <gary(a)garyguo.net> Date: Sat, 17 May 2025 09:55:59 +0100 Subject: [PATCH] rust: compile libcore with edition 2024 for 1.87+ Rust 1.87 (released on 2025-05-15) compiles core library with edition 2024 instead of 2021 [1]. Ensure that the edition matches libcore's expectation to avoid potential breakage. [ J3m3 reported in Zulip [2] that the `rust-analyzer` target was broken after this patch -- indeed, we need to avoid `core-cfgs` since those are passed to the `rust-analyzer` target. So, instead, I tweaked the patch to create a new `core-edition` variable and explicitly mention the `--edition` flag instead of reusing `core-cfg`s. In addition, pass a new argument using this new variable to `generate_rust_analyzer.py` so that we set the right edition there. By the way, for future reference: the `filter-out` change is needed for Rust < 1.87, since otherwise we would skip the `--edition=2021` we just added, ending up with no edition flag, and thus the compiler would default to the 2015 one. [2] https://rust-for-linux.zulipchat.com/#narrow/channel/291565/topic/x/near/52… - Miguel ] Cc: stable(a)vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/138162 [1] Reported-by: est31 <est31(a)protonmail.com> Closes: https://github.com/Rust-for-Linux/linux/issues/1163 Signed-off-by: Gary Guo <gary(a)garyguo.net> Link: https://lore.kernel.org/r/20250517085600.2857460-1-gary@garyguo.net Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> diff --git a/rust/Makefile b/rust/Makefile index f207ba0ed466..d62b58d0a55c 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -60,6 +60,8 @@ endif core-cfgs = \ --cfg no_fp_fmt_parse +core-edition := $(if $(call rustc-min-version,108700),2024,2021) + # `rustc` recognizes `--remap-path-prefix` since 1.26.0, but `rustdoc` only # since Rust 1.81.0. Moreover, `rustdoc` ICEs on out-of-tree builds since Rust # 1.82.0 (https://github.com/rust-lang/rust/issues/138520). Thus workaround both @@ -106,8 +108,8 @@ rustdoc-macros: $(src)/macros/lib.rs FORCE # Starting with Rust 1.82.0, skipping `-Wrustdoc::unescaped_backticks` should # not be needed -- see https://github.com/rust-lang/rust/pull/128307. -rustdoc-core: private skip_flags = -Wrustdoc::unescaped_backticks -rustdoc-core: private rustc_target_flags = $(core-cfgs) +rustdoc-core: private skip_flags = --edition=2021 -Wrustdoc::unescaped_backticks +rustdoc-core: private rustc_target_flags = --edition=$(core-edition) $(core-cfgs) rustdoc-core: $(RUST_LIB_SRC)/core/src/lib.rs FORCE +$(call if_changed,rustdoc) @@ -416,7 +418,7 @@ quiet_cmd_rustc_library = $(if $(skip_clippy),RUSTC,$(RUSTC_OR_CLIPPY_QUIET)) L cmd_rustc_library = \ OBJTREE=$(abspath $(objtree)) \ $(if $(skip_clippy),$(RUSTC),$(RUSTC_OR_CLIPPY)) \ - $(filter-out $(skip_flags),$(rust_flags) $(rustc_target_flags)) \ + $(filter-out $(skip_flags),$(rust_flags)) $(rustc_target_flags) \ --emit=dep-info=$(depfile) --emit=obj=$@ \ --emit=metadata=$(dir $@)$(patsubst %.o,lib%.rmeta,$(notdir $@)) \ --crate-type rlib -L$(objtree)/$(obj) \ @@ -427,7 +429,7 @@ quiet_cmd_rustc_library = $(if $(skip_clippy),RUSTC,$(RUSTC_OR_CLIPPY_QUIET)) L rust-analyzer: $(Q)MAKEFLAGS= $(srctree)/scripts/generate_rust_analyzer.py \ - --cfgs='core=$(core-cfgs)' \ + --cfgs='core=$(core-cfgs)' $(core-edition) \ $(realpath $(srctree)) $(realpath $(objtree)) \ $(rustc_sysroot) $(RUST_LIB_SRC) $(if $(KBUILD_EXTMOD),$(srcroot)) \ > rust-project.json @@ -483,9 +485,9 @@ $(obj)/helpers/helpers.o: $(src)/helpers/helpers.c $(recordmcount_source) FORCE $(obj)/exports.o: private skip_gendwarfksyms = 1 $(obj)/core.o: private skip_clippy = 1 -$(obj)/core.o: private skip_flags = -Wunreachable_pub +$(obj)/core.o: private skip_flags = --edition=2021 -Wunreachable_pub $(obj)/core.o: private rustc_objcopy = $(foreach sym,$(redirect-intrinsics),--redefine-sym $(sym)=__rust$(sym)) -$(obj)/core.o: private rustc_target_flags = $(core-cfgs) +$(obj)/core.o: private rustc_target_flags = --edition=$(core-edition) $(core-cfgs) $(obj)/core.o: $(RUST_LIB_SRC)/core/src/lib.rs \ $(wildcard $(objtree)/include/config/RUSTC_VERSION_TEXT) FORCE +$(call if_changed_rule,rustc_library) diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py index fe663dd0c43b..7c3ea2b55041 100755 --- a/scripts/generate_rust_analyzer.py +++ b/scripts/generate_rust_analyzer.py @@ -19,7 +19,7 @@ def args_crates_cfgs(cfgs): return crates_cfgs -def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): +def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edition): # Generate the configuration list. cfg = [] with open(objtree / "include" / "generated" / "rustc_cfg") as fd: @@ -35,7 +35,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): crates_indexes = {} crates_cfgs = args_crates_cfgs(cfgs) - def append_crate(display_name, root_module, deps, cfg=[], is_workspace_member=True, is_proc_macro=False): + def append_crate(display_name, root_module, deps, cfg=[], is_workspace_member=True, is_proc_macro=False, edition="2021"): crate = { "display_name": display_name, "root_module": str(root_module), @@ -43,7 +43,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): "is_proc_macro": is_proc_macro, "deps": [{"crate": crates_indexes[dep], "name": dep} for dep in deps], "cfg": cfg, - "edition": "2021", + "edition": edition, "env": { "RUST_MODFILE": "This is only for rust-analyzer" } @@ -61,6 +61,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): display_name, deps, cfg=[], + edition="2021", ): append_crate( display_name, @@ -68,12 +69,13 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): deps, cfg, is_workspace_member=False, + edition=edition, ) # NB: sysroot crates reexport items from one another so setting up our transitive dependencies # here is important for ensuring that rust-analyzer can resolve symbols. The sources of truth # for this dependency graph are `(sysroot_src / crate / "Cargo.toml" for crate in crates)`. - append_sysroot_crate("core", [], cfg=crates_cfgs.get("core", [])) + append_sysroot_crate("core", [], cfg=crates_cfgs.get("core", []), edition=core_edition) append_sysroot_crate("alloc", ["core"]) append_sysroot_crate("std", ["alloc", "core"]) append_sysroot_crate("proc_macro", ["core", "std"]) @@ -177,6 +179,7 @@ def main(): parser = argparse.ArgumentParser() parser.add_argument('--verbose', '-v', action='store_true') parser.add_argument('--cfgs', action='append', default=[]) + parser.add_argument("core_edition") parser.add_argument("srctree", type=pathlib.Path) parser.add_argument("objtree", type=pathlib.Path) parser.add_argument("sysroot", type=pathlib.Path) @@ -193,7 +196,7 @@ def main(): assert args.sysroot in args.sysroot_src.parents rust_project = { - "crates": generate_crates(args.srctree, args.objtree, args.sysroot_src, args.exttree, args.cfgs), + "crates": generate_crates(args.srctree, args.objtree, args.sysroot_src, args.exttree, args.cfgs, args.core_edition), "sysroot": str(args.sysroot), }

3 months

3
3
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) clang: error: assembler command failed with exit code 1 (use -v to...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- clang: error: assembler command failed with exit code 1 (use -v to see invocation) in drivers/firmware/qcom_scm-32.o (scripts/Makefile.build:262) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:e1ce6e2cb61e68ec7bf14991570487d713f77e0a - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: e2f5a2e75b315706dd2d1d50a4313e5785eb189d Log excerpt: ===================================================== CC drivers/firmware/qcom_scm-32.o CC lib/idr.o CC drivers/gpu/host1x/debug.o CC drivers/clk/rockchip/clk-rk3328.o CC drivers/clk/rockchip/clk-rk3368.o CC lib/ioremap.o CC drivers/gpu/drm/drm_probe_helper.o CC drivers/clk/rockchip/clk-rk3399.o /tmp/qcom_scm-32-2d4d72.s: Assembler messages: /tmp/qcom_scm-32-2d4d72.s:56: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:69: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:173: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:394: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:545: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:930: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:1070: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:1117: Error: selected processor does not support `smc #0' in ARM mode clang: error: assembler command failed with exit code 1 (use -v to see invocation) ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685191885c2cf25042b9bb39 ## multi_v7_defconfig on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685191845c2cf25042b9bb35 #kernelci issue maestro:e1ce6e2cb61e68ec7bf14991570487d713f77e0a 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

3 months

1
0
0 0

[REGRESSION] stable-rc/linux-6.1.y: (build) stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupport...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.1.y: --- stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] in drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.o (drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:69fb66ef80a96ff4750a9dacf73be24a7cbe888e - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 2c86adab41e98d103953bf8c447202c9147150ab Log excerpt: ===================================================== drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3795:6: error: stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] 3795 | void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) | ^ CC drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn303/dcn303_fpu.o 1 error generated. CC drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/dcn314_fpu.o ===================================================== # Builds where the incident occurred: ## x86_64_defconfig+kselftest+x86-board on (x86_64): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685193725c2cf25042b9bcc9 #kernelci issue maestro:69fb66ef80a96ff4750a9dacf73be24a7cbe888e 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

3 months

1
0
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) in drivers/firmware/qcom_scm-32.o (scripts/Makefile.build:262) [lo...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- in drivers/firmware/qcom_scm-32.o (scripts/Makefile.build:262) [logspec:kbuild,kbuild.compiler] --- - dashboard: https://d.kernelci.org/i/maestro:04c1ce2921a16b59c7329a6026c59ea7942ef691 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: e2f5a2e75b315706dd2d1d50a4313e5785eb189d Log excerpt: ===================================================== CC drivers/firmware/qcom_scm-32.o CC drivers/firmware/trusted_foundations.o CC drivers/clk/qcom/clk-regmap.o CC drivers/gpio/gpio-pl061.o CC kernel/resource.o CC kernel/sysctl.o /tmp/ccsKkK07.s: Assembler messages: /tmp/ccsKkK07.s:45: Error: selected processor does not support `smc #0' in ARM mode /tmp/ccsKkK07.s:94: Error: selected processor does not support `smc #0' in ARM mode /tmp/ccsKkK07.s:160: Error: selected processor does not support `smc #0' in ARM mode /tmp/ccsKkK07.s:296: Error: selected processor does not support `smc #0' in ARM mode ===================================================== # Builds where the incident occurred: ## multi_v7_defconfig on (arm): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:685191a35c2cf25042b9bb4f ## multi_v7_defconfig+kselftest on (arm): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:685191ab5c2cf25042b9bb56 #kernelci issue maestro:04c1ce2921a16b59c7329a6026c59ea7942ef691 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

3 months

1
0
0 0

[REGRESSION] stable-rc/linux-5.15.y: (build) integer literal is too large to be represented in type 'long', int...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: --- integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] in drivers/gpu/drm/meson/meson_vclk.o (drivers/gpu/drm/meson/meson_vclk.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:ae3b0334acd91200d6ced325a381bafac2d46493 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: d99cd6f3a570e2f93e8f966b8ca772ef3da54fe2 Log excerpt: ===================================================== drivers/gpu/drm/meson/meson_vclk.c:399:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 399 | .pll_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:411:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 411 | .pll_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:423:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 423 | .pll_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:436:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 436 | .phy_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:460:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 460 | .phy_freq = 2970000000, | ^ CC [M] net/dccp/feat.o drivers/gpu/drm/meson/meson_vclk.c:850:8: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 850 | case 2970000000: | ^ drivers/gpu/drm/meson/meson_vclk.c:868:8: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 868 | case 2970000000: | ^ drivers/gpu/drm/meson/meson_vclk.c:885:8: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 885 | case 2970000000: | ^ 8 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685192b15c2cf25042b9bc2e #kernelci issue maestro:ae3b0334acd91200d6ced325a381bafac2d46493 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

3 months

1
0
0 0

[PATCH v2] serial: core: restore of_node information in sysfs

by Aidan Stewart

Since in v6.8-rc1, the of_node symlink under tty devices is missing. This breaks any udev rules relying on this information. Link the of_node information in the serial controller device with the parent defined in the device tree. This will also apply to the serial device which takes the serial controller as a parent device. Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") Cc: stable(a)vger.kernel.org Signed-off-by: Aidan Stewart <astewart(a)tektelic.com> --- v1 -> v2: - v1: https://lore.kernel.org/linux-serial/20250616162154.9057-1-astewart@tekteli… - Remove IS_ENABLED(CONFIG_OF) check. --- drivers/tty/serial/serial_base_bus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c index 5d1677f1b651..cb3b127b06b6 100644 --- a/drivers/tty/serial/serial_base_bus.c +++ b/drivers/tty/serial/serial_base_bus.c @@ -72,6 +72,7 @@ static int serial_base_device_init(struct uart_port *port, dev->parent = parent_dev; dev->bus = &serial_base_bus_type; dev->release = release; + device_set_of_node_from_dev(dev, parent_dev); if (!serial_base_initialized) { dev_dbg(port->dev, "uart_add_one_port() called before arch_initcall()?\n"); -- 2.49.0

3 months

1
0
0 0

[PATCH 6.12.y 0/2] Kunit to check the longest symbol length

by Sergio González Collado

The longest length of a symbol (KSYM_NAME_LEN) was increased to 512 in the reference [1]. Because in Rust symbols can become quite long due to namespacing introduced by modules, types, traits, generics, etc. This patch series presents two commits that implement a test to verify that a symbol with KSYM_NAME_LEN of 512 can be read. The first commit: To check that symbol length was valid, the commit implements a kunit test that verifies that a symbol of 512 length can be read. The second commit: There was a warning when building with clang because there was a definition of unlikely from compiler.h in tools/include/linux, which conflicted with the one in the instruction decoder selftest. [1] https://lore.kernel.org/lkml/20220802015052.10452-6-ojeda@kernel.org/ --- Nathan Chancellor (1): x86/tools: Drop duplicate unlikely() definition in insn_decoder_test.c Sergio González Collado (1): Kunit to check the longest symbol length arch/x86/tools/insn_decoder_test.c | 5 +- lib/Kconfig.debug | 9 ++++ lib/Makefile | 2 + lib/longest_symbol_kunit.c | 82 ++++++++++++++++++++++++++++++ 4 files changed, 95 insertions(+), 3 deletions(-) create mode 100644 lib/longest_symbol_kunit.c base-commit: ba9210b8c96355a16b78e1b890dce78f284d6f31 -- 2.39.2

3 months

4
11
0 0

[PATCH] serial: core: restore of_node information in sysfs

by Aidan Stewart

Since in v6.8-rc1, the of_node symlink under tty devices is missing. This breaks any udev rules relying on this information. Link the of_node information in the serial controller device with the parent defined in the device tree. This will also apply to the serial device which takes the serial controller as a parent device. Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") Cc: stable(a)vger.kernel.org Signed-off-by: Aidan Stewart <astewart(a)tektelic.com> --- drivers/tty/serial/serial_base_bus.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c index 5d1677f1b651..0e4bf7a3e775 100644 --- a/drivers/tty/serial/serial_base_bus.c +++ b/drivers/tty/serial/serial_base_bus.c @@ -73,6 +73,10 @@ static int serial_base_device_init(struct uart_port *port, dev->bus = &serial_base_bus_type; dev->release = release; + if (IS_ENABLED(CONFIG_OF)) { + device_set_of_node_from_dev(dev, parent_dev); + } + if (!serial_base_initialized) { dev_dbg(port->dev, "uart_add_one_port() called before arch_initcall()?\n"); return -EPROBE_DEFER; -- 2.49.0

3 months

2
3
0 0

FAILED: patch "[PATCH] usb: cdnsp: Fix issue with detecting command completion event" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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-5.4.y git checkout FETCH_HEAD git cherry-pick -x f4ecdc352646f7d23f348e5c544dbe3212c94fc8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025061708-cameo-caring-38a0@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f4ecdc352646f7d23f348e5c544dbe3212c94fc8 Mon Sep 17 00:00:00 2001 From: Pawel Laszczak <pawell(a)cadence.com> Date: Tue, 13 May 2025 05:30:09 +0000 Subject: [PATCH] usb: cdnsp: Fix issue with detecting command completion event In some cases, there is a small-time gap in which CMD_RING_BUSY can be cleared by controller but adding command completion event to event ring will be delayed. As the result driver will return error code. This behavior has been detected on usbtest driver (test 9) with configuration including ep1in/ep1out bulk and ep2in/ep2out isoc endpoint. Probably this gap occurred because controller was busy with adding some other events to event ring. The CMD_RING_BUSY is cleared to '0' when the Command Descriptor has been executed and not when command completion event has been added to event ring. To fix this issue for this test the small delay is sufficient less than 10us) but to make sure the problem doesn't happen again in the future the patch introduces 10 retries to check with delay about 20us before returning error code. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Pawel Laszczak <pawell(a)cadence.com> Acked-by: Peter Chen <peter.chen(a)kernel.org> Link: https://lore.kernel.org/r/PH7PR07MB9538AA45362ACCF1B94EE9B7DD96A@PH7PR07MB9… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/cdns3/cdnsp-gadget.c b/drivers/usb/cdns3/cdnsp-gadget.c index cd1e00daf43f..55f95f41b3b4 100644 --- a/drivers/usb/cdns3/cdnsp-gadget.c +++ b/drivers/usb/cdns3/cdnsp-gadget.c @@ -548,6 +548,7 @@ int cdnsp_wait_for_cmd_compl(struct cdnsp_device *pdev) dma_addr_t cmd_deq_dma; union cdnsp_trb *event; u32 cycle_state; + u32 retry = 10; int ret, val; u64 cmd_dma; u32 flags; @@ -579,8 +580,23 @@ int cdnsp_wait_for_cmd_compl(struct cdnsp_device *pdev) flags = le32_to_cpu(event->event_cmd.flags); /* Check the owner of the TRB. */ - if ((flags & TRB_CYCLE) != cycle_state) + if ((flags & TRB_CYCLE) != cycle_state) { + /* + * Give some extra time to get chance controller + * to finish command before returning error code. + * Checking CMD_RING_BUSY is not sufficient because + * this bit is cleared to '0' when the Command + * Descriptor has been executed by controller + * and not when command completion event has + * be added to event ring. + */ + if (retry--) { + udelay(20); + continue; + } + return -EINVAL; + } cmd_dma = le64_to_cpu(event->event_cmd.cmd_trb);

3 months

2
1
0 0

[PATCH v7 0/5] media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5 + other meta fixes

by Ricardo Ribalda

This series introduces a new metadata format for UVC cameras and adds a couple of improvements to the UVC metadata handling. The new metadata format can be enabled in runtime with quirks. Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Changes in v7: - Add patch: Introduce dev->meta_formats - Link to v6: https://lore.kernel.org/r/20250604-uvc-meta-v6-0-7141d48c322c@chromium.org Changes in v6 (Thanks Laurent): - Fix typo in metafmt-uvc.rst - Improve metafmt-uvc-msxu-1-5.rst - uvc_meta_v4l2_try_format() block MSXU format unless the quirk is active - Refactor uvc_enable_msxu - Document uvc_meta_detect_msxu - Rebase series - Add R-b - Link to v5: https://lore.kernel.org/r/20250404-uvc-meta-v5-0-f79974fc2d20@chromium.org Changes in v5: - Fix codestyle and kerneldoc warnings reported by media-ci - Link to v4: https://lore.kernel.org/r/20250403-uvc-meta-v4-0-877aa6475975@chromium.org Changes in v4: - Rename format to V4L2_META_FMT_UVC_MSXU_1_5 (Thanks Mauro) - Flag the new format with a quirk. - Autodetect MSXU devices. - Link to v3: https://lore.kernel.org/linux-media/20250313-uvc-metadata-v3-0-c467af869c60… Changes in v3: - Fix doc syntax errors. - Link to v2: https://lore.kernel.org/r/20250306-uvc-metadata-v2-0-7e939857cad5@chromium.… Changes in v2: - Add metadata invalid fix - Move doc note to a separate patch - Introduce V4L2_META_FMT_UVC_CUSTOM (thanks HdG!). - Link to v1: https://lore.kernel.org/r/20250226-uvc-metadata-v1-1-6cd6fe5ec2cb@chromium.… --- Ricardo Ribalda (5): media: uvcvideo: Do not mark valid metadata as invalid media: Documentation: Add note about UVCH length field media: uvcvideo: Introduce dev->meta_formats media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5 media: uvcvideo: Auto-set UVC_QUIRK_MSXU_META .../userspace-api/media/v4l/meta-formats.rst | 1 + .../media/v4l/metafmt-uvc-msxu-1-5.rst | 23 ++++ .../userspace-api/media/v4l/metafmt-uvc.rst | 4 +- MAINTAINERS | 1 + drivers/media/usb/uvc/uvc_driver.c | 7 ++ drivers/media/usb/uvc/uvc_metadata.c | 133 +++++++++++++++++++-- drivers/media/usb/uvc/uvc_video.c | 12 +- drivers/media/usb/uvc/uvcvideo.h | 3 + drivers/media/v4l2-core/v4l2-ioctl.c | 1 + include/linux/usb/uvc.h | 3 + include/uapi/linux/videodev2.h | 1 + 11 files changed, 175 insertions(+), 14 deletions(-) --- base-commit: c3021d6a80ff05034dfee494115ec71f1954e311 change-id: 20250403-uvc-meta-e556773d12ae Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

3 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror