6.12.40-rc1 review
Greg Kroah-Hartman
maintainerPATCH 144/158 usb: hub: Fix flushing and scheduling of delayed work that tunes runtime pm
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit a49e1e2e785fb3621f2d748581881b23a364998a upstream.
Delayed work to prevent USB3 hubs from runtime-suspending immediately after resume was added in commit 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs").
This delayed work needs be flushed if system suspends, or hub needs to be quiesced for other reasons right after resume. Not flushing it triggered issues on QC SC8280XP CRD board during suspend/resume testing.
Fix it by flushing the delayed resume work in hub_quiesce()
The delayed work item that allow hub runtime suspend is also scheduled just before calling autopm get. Alan pointed out there is a small risk that work is run before autopm get, which would call autopm put before get, and mess up the runtime pm usage order.
Swap the order of work sheduling and calling autopm get to solve this.
--- drivers/usb/core/hub.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/core/hub.c +4 -2
@@ -1358,11 +1358,12 @@ static void hub_activate(struct usb_hubif (type ==HUB_RESUME &&hub_is_superspeed (hub->hdev)) {/* give usb3 downstream links training time after hub resume */ +usb_autopm_get_interface_no_resume ( +to_usb_interface (hub->intfdev)); +INIT_DELAYED_WORK (&hub->init_work, hub_post_resume);queue_delayed_work (system_power_efficient_wq, &hub->init_work,msecs_to_jiffies (USB_SS_PORT_U0_WAKE_TIME )); -usb_autopm_get_interface_no_resume ( -to_usb_interface (hub->intfdev));return ; }
@@ -1416,6 +1417,7 @@ static void hub_quiesce(struct usb_hub */* Stop hub_wq and related activity */ del_timer_sync (&hub->irq_urb_retry); +flush_delayed_work (&hub->init_work);usb_kill_urb (hub->urb);if (hub->has_indicators)cancel_delayed_work_sync (&hub->leds);
Greg Kroah-Hartman
maintainerPATCH 145/158 usb: hub: Fix flushing of delayed work used for post resume purposes
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit 9bd9c8026341f75f25c53104eb7e656e357ca1a2 upstream.
Delayed work that prevents USB3 hubs from runtime-suspending too early needed to be flushed in hub_quiesce() to resolve issues detected on QC SC8280XP CRD board during suspend resume testing.
This flushing did however trigger new issues on Raspberry Pi 3B+, which doesn't have USB3 ports, and doesn't queue any post resume delayed work.
The flushed 'hub->init_work' item is used for several purposes, and is originally initialized with a 'NULL' work function. The work function is also changed on the fly, which may contribute to the issue.
Solve this by creating a dedicated delayed work item for post resume work, and flush that delayed work in hub_quiesce()
--- drivers/usb/core/hub.c | 21 ++++++++------------- drivers/usb/core/hub.h | 1 + 2 files changed, 9 insertions(+), 13 deletions(-)
drivers/usb/core/hub.c +8 -13
@@ -1073,12 +1073,11 @@ int usb_remove_device(struct usb_deviceenum hub_activation_type {HUB_INIT ,HUB_INIT2 ,HUB_INIT3 ,/* INITs must come first */ -HUB_POST_RESET ,HUB_RESUME ,HUB_RESET_RESUME ,HUB_POST_RESUME , +HUB_POST_RESET ,HUB_RESUME ,HUB_RESET_RESUME , };static void hub_init_func2 (struct work_struct *ws);static void hub_init_func3 (struct work_struct *ws); -static void hub_post_resume (struct work_struct *ws);static void hub_activate (struct usb_hub *hub,enum hub_activation_type type) {
@@ -1102,12 +1101,6 @@ static void hub_activate(struct usb_hub goto init3; } -if (type ==HUB_POST_RESUME ) { -usb_autopm_put_interface_async (to_usb_interface (hub->intfdev)); -hub_put (hub); -return ; - } -hub_get (hub);/* The superspeed hub except for root hub has to use Hub Depth
@@ -1361,8 +1354,8 @@ static void hub_activate(struct usb_hubusb_autopm_get_interface_no_resume (to_usb_interface (hub->intfdev)); -INIT_DELAYED_WORK (&hub->init_work, hub_post_resume); -queue_delayed_work (system_power_efficient_wq, &hub->init_work, +queue_delayed_work (system_power_efficient_wq, + &hub->post_resume_work,msecs_to_jiffies (USB_SS_PORT_U0_WAKE_TIME ));return ; }
@@ -1387,9 +1380,10 @@ static void hub_init_func3(struct work_sstatic void hub_post_resume (struct work_struct *ws) { - struct usb_hub *hub = container_of(ws, struct usb_hub, init_work.work); + struct usb_hub *hub = container_of(ws, struct usb_hub, post_resume_work.work); -hub_activate (hub,HUB_POST_RESUME ); +usb_autopm_put_interface_async (to_usb_interface (hub->intfdev)); +hub_put (hub); }enum hub_quiescing_type {
@@ -1417,7 +1411,7 @@ static void hub_quiesce(struct usb_hub */* Stop hub_wq and related activity */ del_timer_sync (&hub->irq_urb_retry); -flush_delayed_work (&hub->init_work); +flush_delayed_work (&hub->post_resume_work);usb_kill_urb (hub->urb);if (hub->has_indicators)cancel_delayed_work_sync (&hub->leds);
@@ -1976,6 +1970,7 @@ static int hub_probe(struct usb_interfac hub->hdev = hdev;INIT_DELAYED_WORK (&hub->leds, led_work);INIT_DELAYED_WORK (&hub->init_work,NULL ); +INIT_DELAYED_WORK (&hub->post_resume_work, hub_post_resume);INIT_WORK (&hub->events, hub_event);INIT_LIST_HEAD (&hub->onboard_devs);spin_lock_init (&hub->irq_urb_lock);
drivers/usb/core/hub.h +1 -0
@@ -70,6 +70,7 @@ struct usb_hub {u8 indicator[USB_MAXCHILDREN ];struct delayed_work leds;struct delayed_work init_work; +struct delayed_work post_resume_work;struct work_struct events;spinlock_t irq_urb_lock;struct timer_list irq_urb_retry;
Greg Kroah-Hartman
maintainerPATCH 146/158 usb: hub: Dont try to recover devices lost during warm reset.
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit 2521106fc732b0b75fd3555c689b1ed1d29d273c upstream.
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.
--- drivers/usb/core/hub.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/usb/core/hub.c +6 -2
@@ -5749,6 +5749,7 @@ static void port_event(struct usb_hub *hstruct 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);
@@ -5845,8 +5846,11 @@ static void port_event(struct usb_hub *h }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" );
Greg Kroah-Hartman
maintainerPATCH 147/158 usb: dwc3: qcom: Dont leave BCR asserted
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krishna Kurapati <[email protected]>
commit ef8abc0ba49ce717e6bc4124e88e59982671f3b5 upstream.
Leaving the USB BCR asserted prevents the associated GDSC to turn on. This blocks any subsequent attempts of probing the device, e.g. after a probe deferral, with the following showing in the log:
[ 1.332226] usb30_prim_gdsc status stuck at 'off'
Leave the BCR deasserted when exiting the driver to avoid this issue.
--- drivers/usb/dwc3/dwc3-qcom.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/usb/dwc3/dwc3-qcom.c +2 -6
@@ -763,13 +763,13 @@ static int dwc3_qcom_probe(struct platfo ret =reset_control_deassert (qcom->resets);if (ret) {dev_err (&pdev->dev,"failed to deassert resets, err=%d\n" , ret); - goto reset_assert; +return ret; } ret =dwc3_qcom_clk_init (qcom,of_clk_get_parent_count (np));if (ret) {dev_err_probe (dev, ret,"failed to get clocks\n" ); - goto reset_assert; +return ret; } qcom->qscratch_base =devm_platform_ioremap_resource (pdev,0 );
@@ -835,8 +835,6 @@ clk_disable:clk_disable_unprepare (qcom->clks[i]);clk_put (qcom->clks[i]); } -reset_assert: -reset_control_assert (qcom->resets);return ret; }
@@ -857,8 +855,6 @@ static void dwc3_qcom_remove(struct plat qcom->num_clocks =0 ;dwc3_qcom_interconnect_exit (qcom); -reset_control_assert (qcom->resets); -pm_runtime_allow (dev);pm_runtime_disable (dev); }
Greg Kroah-Hartman
maintainerPATCH 148/158 net: libwx: fix multicast packets received count
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiawen Wu <[email protected]>
commit 2b30a3d1ec2538a1fd363fde746b9fe1d38abc77 upstream.
Multicast good packets received by PF rings that pass ethternet MAC address filtering are counted for rtnl_link_stats64.multicast. The counter is not cleared on read. Fix the duplicate counting on updating statistics.
--- drivers/net/ethernet/wangxun/libwx/wx_hw.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/wangxun/libwx/wx_hw.c +2 -0
@@ -2355,6 +2355,8 @@ void wx_update_stats(struct wx *wx) hwstats->fdirmiss +=rd32 (wx,WX_RDB_FDIR_MISS ); } +/* qmprc is not cleared on read, manual reset it */ + hwstats->qmprc =0 ;for (i =0 ; i < wx->mac.max_rx_queues; i++) hwstats->qmprc +=rd32 (wx,WX_PX_MPRC (i)); }
Greg Kroah-Hartman
maintainerPATCH 149/158 rust: use `#[used(compiler)]` to fix build and `modpost` with Rust >= 1.89.0
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miguel Ojeda <[email protected]>
commit 7498159226772d66f150dd406be462d75964a366 upstream.
Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler fails to build the rusttest target due to undefined references such as:
kernel...-cgu.0:(.text....+0x116): undefined reference to
`rust_helper_kunit_get_current_test'Moreover, tooling like modpost gets confused:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/nova/nova.o
ERROR: modpost: missing MODULE_LICENSE() in drivers/gpu/nova-core/nova_core.o
The reason behind both issues is that the Rust compiler will now [1] treat #[used] as #[used(linker)] instead of #[used(compiler)] for our targets. This means that the retain section flag (R, SHF_GNU_RETAIN) will be used and that they will be marked as unique too, with different IDs. In turn, that means we end up with undefined references that did not get discarded in rusttest and that multiple .modinfo sections are generated, which confuse tooling like modpost because they only expect one.
Thus start using #[used(compiler)] to keep the previous behavior and to be explicit about what we want. Sadly, it is an unstable feature (used_with_arg) [2] -- we will talk to upstream Rust about it. The good news is that it has been available for a long time (Rust >= 1.60) [3].
The changes should also be fine for previous Rust versions, since they behave the same way as before [4].
Alternatively, we could use #[no_mangle] or #[export_name = ...] since those still behave like #[used(compiler)], but of course it is not really what we want to express, and it requires other changes to avoid symbol conflicts.
--- rust/Makefile | 1 + rust/kernel/lib.rs | 1 + rust/macros/module.rs | 10 +++++----- scripts/Makefile.build | 2 +- 4 files changed, 8 insertions(+), 6 deletions(-)
rust/Makefile +1 -0
@@ -157,6 +157,7 @@ quiet_cmd_rustdoc_test = RUSTDOC T $< cmd_rustdoc_test = \ OBJTREE=$(abspath $(objtree)) \ $(RUSTDOC) --test $(rust_common_flags) \ + -Zcrate-attr='feature(used_with_arg)' \ @$(objtree)/include/generated/rustc_cfg \ $(rustc_target_flags) $(rustdoc_test_target_flags) \ $(rustdoc_test_quiet) \
rust/kernel/lib.rs +1 -0
@@ -18,6 +18,7 @@#![feature(inline_const)] #![feature(lint_reasons)] #![feature(unsize)] +#![feature(used_with_arg)] // Ensure conditional compilation based on the kernel configuration works; // otherwise we may silently break things like initcall handling.
rust/macros/module.rs +5 -5
@@ -57,7 +57,7 @@ impl<'a> ModInfoBuilder<'a> { {cfg}#[doc(hidden)] #[link_section = \".modinfo\"] - #[used] + #[used(compiler)] pub static __{module}_{counter}: [u8; {length}] = *{string}; ",cfg = if builtin {
@@ -230,7 +230,7 @@ pub(crate) fn module(ts: TokenStream) ->// key or a new section. For the moment, keep it simple. #[cfg( MODULE )] #[doc(hidden)] -#[used] +#[used(compiler)] static __IS_RUST_MODULE: () = ();static mut __MOD:Option <{type_}> =None ;
@@ -253,7 +253,7 @@ pub(crate) fn module(ts: TokenStream) ->#[cfg( MODULE )] #[doc(hidden)] -#[used] +#[used(compiler)] #[link_section = \".init.data\"] static __UNIQUE_ID___addressable_init_module: unsafe extern \"C\" fn() -> i32 = init_module;
@@ -273,7 +273,7 @@ pub(crate) fn module(ts: TokenStream) ->#[cfg( MODULE )] #[doc(hidden)] -#[used] +#[used(compiler)] #[link_section = \".exit.data\"] static __UNIQUE_ID___addressable_cleanup_module: extern \"C\" fn() = cleanup_module;
@@ -283,7 +283,7 @@ pub(crate) fn module(ts: TokenStream) ->#[cfg(not( CONFIG_HAVE_ARCH_PREL32_RELOCATIONS ))] #[doc(hidden)] #[link_section = \"{initcall_section}\"] - #[used] + #[used(compiler)] pub static __{name}_initcall: extern \"C\" fn() -> kernel::ffi::c_int = __{name}_init; #[cfg(not(MODULE))]
scripts/Makefile.build +1 -1
@@ -248,7 +248,7 @@ $(obj)/%.lst: $(obj)/%.c FORCE # Compile Rust sources (.rs) # --------------------------------------------------------------------------- -rust_allowed_features := arbitrary_self_types,lint_reasons +rust_allowed_features := arbitrary_self_types,lint_reasons,used_with_arg # `--out-dir` is required to avoid temporaries being created by `rustc` in the # current working directory, which may be not accessible in the out-of-tree
Greg Kroah-Hartman
maintainerPATCH 150/158 selftests/bpf: Set test path for token/obj_priv_implicit_token_envvar
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ihor Solodrai <[email protected]>
commit f01750aecdfb8bfb02842f60af3d805a3ae7267a upstream.
token/obj_priv_implicit_token_envvar test may fail in an environment where the process executing tests can not write to the root path.
Example:
https://github.com/libbpf/libbpf/actions/runs/11844507007/job/33007897936
Change default path used by the test to /tmp/bpf-token-fs, and make it runtime configurable via an environment variable.
--- tools/testing/selftests/bpf/prog_tests/token.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)
tools/testing/selftests/bpf/prog_tests/token.c +12 -7
@@ -828,8 +828,12 @@ static int userns_obj_priv_btf_success(ireturn validate_struct_ops_load (mnt_fd, true/* should succeed */ ); } +static const char *token_bpffs_custom_dir () +{ +return getenv ("BPF_SELFTESTS_BPF_TOKEN_DIR" ) ?:"/tmp/bpf-token-fs" ; +} +#define TOKEN_ENVVAR "LIBBPF_BPF_TOKEN_PATH" -#define TOKEN_BPFFS_CUSTOM "/bpf-token-fs"static int userns_obj_priv_implicit_token (int mnt_fd,struct token_lsm *lsm_skel) {
@@ -892,6 +896,7 @@ static int userns_obj_priv_implicit_tokestatic int userns_obj_priv_implicit_token_envvar (int mnt_fd,struct token_lsm *lsm_skel) { +const char *custom_dir =token_bpffs_custom_dir ();LIBBPF_OPTS (bpf_object_open_opts, opts);struct dummy_st_ops_success *skel;int err;
@@ -909,10 +914,10 @@ static int userns_obj_priv_implicit_toke* BPF token implicitly, unless pointed to it through * LIBBPF_BPF_TOKEN_PATH envvar */ -rmdir (TOKEN_BPFFS_CUSTOM ); -if (!ASSERT_OK (mkdir (TOKEN_BPFFS_CUSTOM ,0777 ),"mkdir_bpffs_custom" )) +rmdir (custom_dir); +if (!ASSERT_OK (mkdir (custom_dir,0777 ),"mkdir_bpffs_custom" )) goto err_out; - err =sys_move_mount (mnt_fd,"" ,AT_FDCWD ,TOKEN_BPFFS_CUSTOM ,MOVE_MOUNT_F_EMPTY_PATH ); + err =sys_move_mount (mnt_fd,"" ,AT_FDCWD , custom_dir,MOVE_MOUNT_F_EMPTY_PATH );if (!ASSERT_OK (err,"move_mount_bpffs" )) goto err_out;
@@ -925,7 +930,7 @@ static int userns_obj_priv_implicit_toke goto err_out; } - err =setenv (TOKEN_ENVVAR ,TOKEN_BPFFS_CUSTOM ,1 /*overwrite*/ ); + err =setenv (TOKEN_ENVVAR , custom_dir,1 /*overwrite*/ );if (!ASSERT_OK (err,"setenv_token_path" )) goto err_out;
@@ -951,11 +956,11 @@ static int userns_obj_priv_implicit_tokeif (!ASSERT_ERR (err,"obj_empty_token_path_load" )) goto err_out; -rmdir (TOKEN_BPFFS_CUSTOM ); +rmdir (custom_dir);unsetenv (TOKEN_ENVVAR );return 0 ; err_out: -rmdir (TOKEN_BPFFS_CUSTOM ); +rmdir (custom_dir);unsetenv (TOKEN_ENVVAR );return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 151/158 i2c: omap: Add support for setting mux
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jayesh Choudhary <[email protected]>
commit b6ef830c60b6f4adfb72d0780b4363df3a1feb9c upstream.
Some SoCs require muxes in the routing for SDA and SCL lines. Therefore, add support for setting the mux by reading the mux-states property from the dt-node.
Stable-dep-of: a9503a2ecd95 ("i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()")
--- drivers/i2c/busses/Kconfig | 1 + drivers/i2c/busses/i2c-omap.c | 22 ++++++++++++++++++++++ 2 files changed, 23 insertions(+)
drivers/i2c/busses/Kconfig +1 -0
@@ -937,6 +937,7 @@ config I2C_OMAP tristate "OMAP I2C adapter" depends on ARCH_OMAP || ARCH_K3 || COMPILE_TEST default MACH_OMAP_OSK + select MULTIPLEXER help If you say yes to this option, support will be included for the I2C interface on the Texas Instruments OMAP1/2 family of processors.
drivers/i2c/busses/i2c-omap.c +22 -0
@@ -24,6 +24,7 @@#include <linux/platform_device.h> #include <linux/clk.h> #include <linux/io.h> +#include <linux/mux/consumer.h> #include <linux/of.h> #include <linux/slab.h> #include <linux/platform_data/i2c-omap.h>
@@ -211,6 +212,7 @@ struct omap_i2c_dev {u16 syscstate;u16 westate;u16 errata; +struct mux_state *mux_state; };static const u8 reg_map_ip_v1[] = {
@@ -1452,6 +1454,23 @@ omap_i2c_probe(struct platform_device *p (1000 * omap->speed /8 ); } +if (of_property_read_bool (node,"mux-states" )) { +struct mux_state *mux_state; + + mux_state =devm_mux_state_get (&pdev->dev,NULL ); +if (IS_ERR (mux_state)) { + r =PTR_ERR (mux_state); +dev_dbg (&pdev->dev,"failed to get I2C mux: %d\n" , r); + goto err_disable_pm; + } + omap->mux_state = mux_state; + r =mux_state_select (omap->mux_state); +if (r) { +dev_err (&pdev->dev,"failed to select I2C mux: %d\n" , r); + goto err_disable_pm; + } + } +/* reset ASAP, clearing any IRQs */ omap_i2c_init (omap);
@@ -1511,6 +1530,9 @@ static void omap_i2c_remove(struct platfi2c_del_adapter (&omap->adapter); +if (omap->mux_state) +mux_state_deselect (omap->mux_state); + ret =pm_runtime_get_sync (&pdev->dev);if (ret <0 )dev_err (omap->dev,"Failed to resume hardware, skip disable\n" );
Greg Kroah-Hartman
maintainerPATCH 152/158 i2c: omap: Fix an error handling path in omap_i2c_probe()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
commit 666c23af755dccca8c25b5d5200ca28153c69a05 upstream.
If an error occurs after calling mux_state_select(), mux_state_deselect() should be called as already done in the remove function.
Stable-dep-of: a9503a2ecd95 ("i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()")
--- drivers/i2c/busses/i2c-omap.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-omap.c +5 -2
@@ -1461,13 +1461,13 @@ omap_i2c_probe(struct platform_device *pif (IS_ERR (mux_state)) { r =PTR_ERR (mux_state);dev_dbg (&pdev->dev,"failed to get I2C mux: %d\n" , r); - goto err_disable_pm; + goto err_put_pm; } omap->mux_state = mux_state; r =mux_state_select (omap->mux_state);if (r) {dev_err (&pdev->dev,"failed to select I2C mux: %d\n" , r); - goto err_disable_pm; + goto err_put_pm; } }
@@ -1515,6 +1515,9 @@ omap_i2c_probe(struct platform_device *p err_unuse_clocks:omap_i2c_write_reg (omap,OMAP_I2C_CON_REG ,0 ); +if (omap->mux_state) +mux_state_deselect (omap->mux_state); +err_put_pm:pm_runtime_dont_use_autosuspend (omap->dev);pm_runtime_put_sync (omap->dev); err_disable_pm:
Greg Kroah-Hartman
maintainerPATCH 153/158 i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
commit a9503a2ecd95e23d7243bcde7138192de8c1c281 upstream.
omap_i2c_init() can fail. Handle this error in omap_i2c_probe().
--- drivers/i2c/busses/i2c-omap.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/i2c/busses/i2c-omap.c +4 -1
@@ -1472,7 +1472,9 @@ omap_i2c_probe(struct platform_device *p }/* reset ASAP, clearing any IRQs */ -omap_i2c_init (omap); + r =omap_i2c_init (omap); +if (r) + goto err_mux_state_deselect;if (omap->rev <OMAP_I2C_OMAP1_REV_2 ) r = devm_request_irq(&pdev->dev, omap->irq, omap_i2c_omap1_isr,
@@ -1515,6 +1517,7 @@ omap_i2c_probe(struct platform_device *p err_unuse_clocks:omap_i2c_write_reg (omap,OMAP_I2C_CON_REG ,0 ); +err_mux_state_deselect:if (omap->mux_state)mux_state_deselect (omap->mux_state); err_put_pm:
Greg Kroah-Hartman
maintainerPATCH 154/158 i2c: omap: fix deprecated of_property_read_bool() use
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit e66b0a8f048bc8590eb1047480f946898a3f80c9 upstream.
Using of_property_read_bool() for non-boolean properties is deprecated and results in a warning during runtime since commit c141ecc3cecd ("of:
Warn when of_property_read_bool() is used on non-boolean properties").
--- drivers/i2c/busses/i2c-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i2c/busses/i2c-omap.c +1 -1
@@ -1454,7 +1454,7 @@ omap_i2c_probe(struct platform_device *p (1000 * omap->speed /8 ); } -if (of_property_read_bool (node,"mux-states" )) { +if (of_property_present (node,"mux-states" )) {struct mux_state *mux_state; mux_state =devm_mux_state_get (&pdev->dev,NULL );
Greg Kroah-Hartman
maintainerPATCH 155/158 sched,freezer: Remove unnecessary warning in __thaw_task
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Ridong <[email protected]>
commit 9beb8c5e77dc10e3889ff5f967eeffba78617a88 upstream.
Commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") modified the cgroup_freezing() logic to verify that the FROZEN flag is not set, affecting the return value of the freezing() function, in order to address a warning in __thaw_task.
A race condition exists that may allow tasks to escape being frozen. The following scenario demonstrates this issue:
CPU 0 (get_signal path) CPU 1 (freezer.state reader)try_to_freeze read freezer.state__refrigerator freezer_read
update_if_frozen
WRITE_ONCE(current->__state, TASK_FROZEN); ... /* Task is now marked frozen */ /* frozen(task) == true */ /* Assuming other tasks are frozen */ freezer->state |= CGROUP_FROZEN;
/* freezing(current) returns false */
/* because cgroup is frozen (not freezing) */ break out__set_current_state(TASK_RUNNING);
/* Bug: Task resumes running when it should remain frozen */
The existing !frozen(p) check in __thaw_task makes the WARN_ON_ONCE(freezing(p)) warning redundant. Removing this warning enables reverting commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to resolve the issue.
This patch removes the warning from __thaw_task. A subsequent patch will revert commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to complete the fix.
--- kernel/freezer.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-)
kernel/freezer.c +3 -12
@@ -201,18 +201,9 @@ static int __restore_freezer_state(strucvoid __thaw_task (struct task_struct *p) { -unsigned long flags; - -spin_lock_irqsave (&freezer_lock, flags); -if (WARN_ON_ONCE (freezing (p))) - goto unlock; - -if (!frozen (p) ||task_call_func (p, __restore_freezer_state,NULL )) - goto unlock; - -wake_up_state (p,TASK_FROZEN ); -unlock: -spin_unlock_irqrestore (&freezer_lock, flags); +guard (spinlock_irqsave)(&freezer_lock); +if (frozen (p) && !task_call_func (p, __restore_freezer_state,NULL )) +wake_up_state (p,TASK_FROZEN ); }/**
Greg Kroah-Hartman
maintainerPATCH 156/158 drm/xe/mocs: Initialize MOCS index early
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Balasubramani Vivekanandan <[email protected]>
commit 2a58b21adee3df10ca6f4491af965c4890d2d8e3 upstream.
MOCS uc_index is used even before it is initialized in the following callstack
guc_prepare_xfer()
__xe_guc_upload()
xe_guc_min_load_for_hwconfig()
xe_uc_init_hwconfig()
xe_gt_init_hwconfig()Do MOCS index initialization earlier in the device probe.
Stable-dep-of: 3155ac89251d ("drm/xe: Move page fault init after topology init")
--- drivers/gpu/drm/xe/xe_gt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/xe/xe_gt.c +2 -2
@@ -389,6 +389,8 @@ int xe_gt_init_early(struct xe_gt *gt)if (err)return err; +xe_mocs_init_early (gt); +return 0 ; }
@@ -596,8 +598,6 @@ int xe_gt_init(struct xe_gt *gt)if (err)return err; -xe_mocs_init_early (gt); - err =xe_gt_sysfs_init (gt);if (err)return err;
Greg Kroah-Hartman
maintainerPATCH 157/158 drm/xe: Move page fault init after topology init
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Brost <[email protected]>
commit 3155ac89251dcb5e35a3ec2f60a74a6ed22c56fd upstream.
We need the topology to determine GT page fault queue size, move page fault init after topology init.
--- drivers/gpu/drm/xe/xe_gt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/xe/xe_gt.c +3 -3
@@ -594,15 +594,15 @@ int xe_gt_init(struct xe_gt *gt)xe_hw_fence_irq_init (>->fence_irq[i]); } - err =xe_gt_pagefault_init (gt); + err =xe_gt_sysfs_init (gt);if (err)return err; - err =xe_gt_sysfs_init (gt); + err =gt_fw_domain_init (gt);if (err)return err; - err =gt_fw_domain_init (gt); + err =xe_gt_pagefault_init (gt);if (err)return err;
Greg Kroah-Hartman
maintainerPATCH 158/158 smb: client: let smbd_post_send_iter() respect the peers max_send_size and transmit all data
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
commit 1944f6ab4967db7ad8d4db527dceae8c77de76e9 upstream.
We should not send smbdirect_data_transfer messages larger than the negotiated max_send_size, typically 1364 bytes, which means 24 bytes of the smbdirect_data_transfer header + 1340 payload bytes.
This happened when doing an SMB2 write with more than 1340 bytes (which is done inline as it's below rdma_readwrite_threshold).
It means the peer resets the connection.
When testing between cifs.ko and ksmbd.ko something like this is logged:
client:
CIFS: VFS: RDMA transport re-established
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
CIFS: VFS: \\carina Send error in SessSetup = -11
smb2_reconnect: 12 callbacks suppressed
CIFS: VFS: reconnect tcon failed rc = -11
CIFS: VFS: reconnect tcon failed rc = -11
CIFS: VFS: reconnect tcon failed rc = -11
CIFS: VFS: SMB: Zero rsize calculated, using minimum value 65536
and:
CIFS: VFS: RDMA transport re-established
siw: got TERMINATE. layer 1, type 2, code 2
CIFS: VFS: smbd_recv:1894 disconnected
siw: got TERMINATE. layer 1, type 2, code 2
The ksmbd dmesg is showing things like:
smb_direct: Recv error. status='local length error (1)' opcode=128
smb_direct: disconnected
smb_direct: Recv error. status='local length error (1)' opcode=128
ksmbd: smb_direct: disconnected
ksmbd: sock_read failed: -107
As smbd_post_send_iter() limits the transmitted number of bytes we need loop over it in order to transmit the whole iter.
--- fs/smb/client/smbdirect.c | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-)
fs/smb/client/smbdirect.c +27 -4
@@ -907,8 +907,10 @@ wait_send_queue: .local_dma_lkey = sc->ib.pd->local_dma_lkey, .direction = DMA_TO_DEVICE, }; +size_t payload_len =umin (*_remaining_data_length, + sp->max_send_size -sizeof (*packet)); - rc =smb_extract_iter_to_rdma (iter, *_remaining_data_length, + rc =smb_extract_iter_to_rdma (iter, payload_len, &extract);if (rc <0 ) goto err_dma;
@@ -1013,6 +1015,27 @@ static int smbd_post_send_empty(struct sreturn smbd_post_send_iter (info,NULL , &remaining_data_length); } +static int smbd_post_send_full_iter (struct smbd_connection *info, +struct iov_iter *iter, +int *_remaining_data_length) +{ +int rc =0 ; + +/* +* smbd_post_send_iter() respects the +* negotiated max_send_size, so we need to +* loop until the full iter is posted +*/ + +while (iov_iter_count (iter) >0 ) { + rc =smbd_post_send_iter (info, iter, _remaining_data_length); +if (rc <0 ) +break ; + } + +return rc; +} +/* * Post a receive request to the transport * The remote peer can only send data when a receive request is posted
@@ -1962,14 +1985,14 @@ int smbd_send(struct TCP_Server_Info *se klen += rqst->rq_iov[i].iov_len;iov_iter_kvec (&iter,ITER_SOURCE , rqst->rq_iov, rqst->rq_nvec, klen); - rc =smbd_post_send_iter (info, &iter, &remaining_data_length); + rc =smbd_post_send_full_iter (info, &iter, &remaining_data_length);if (rc <0 )break ;if (iov_iter_count (&rqst->rq_iter) >0 ) {/* And then the data pages if there are any */ - rc =smbd_post_send_iter (info, &rqst->rq_iter, - &remaining_data_length); + rc =smbd_post_send_full_iter (info, &rqst->rq_iter, + &remaining_data_length);if (rc <0 )break ; }
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.40-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
With addition to the previous report on the stable-rc 6.15.8-rc1 review While building allyesconfig build for arm64 and x86 with the toolchain clang-nightly version 22.0.0 the following build warnings / errors noticed on the stable-rc 6.12.40-rc1 review.
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Build regression: arm64 x86 kcsan_test.c error variable 'dummy' is uninitialized when passed as a const pointer argument here
## Build log
kernel/kcsan/kcsan_test.c:591:41: error: variable 'dummy' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
591 | KCSAN_EXPECT_READ_BARRIER(atomic_read(&dummy), false);
| ^~~~~
1 error generated.
## Source
* Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* Git sha: 596aae841edf981aab1df1845e6df012bed94594
* Git describe: v6.12.39-159-g596aae841edf
* Architectures: arm64 x86
* Toolchains: Debian clang version 22.0.0 (++20250721112855+43a829a7e894-1~exp1~20250721112913.1588)
* Kconfigs: allyesconfig
## Build
* Build log: https://regressions.linaro.org/lkft/linux-stable-rc-linux-6.12.y/v6.12.39-159-g596aae841edf/build/clang-nightly-allyesconfig/
* Build run: https://regressions.linaro.org/lkft/linux-stable-rc-linux-6.12.y/v6.12.39-159-g596aae841edf/testruns/1703644/
* Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/30EXE6Cnct6e7DCgsWWrXlMdO0z/
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/30EXE6Cnct6e7DCgsWWrXlMdO0z/config
## Steps to reproduce
* tuxmake --runtime podman --target-arch arm64 --toolchain clang-nightly --kconfig allyesconfig LLVM=1 LLVM_IAS=1
--
Linaro LKFT
https://lkft.linaro.org
Quoted 35 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.40-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
With addition to the previous report on the stable-rc 6.15.8-rc1 review While building allyesconfig build for arm64 and x86 with the toolchain clang-nightly version 22.0.0 the following build warnings / errors noticed on the stable-rc 6.12.40-rc1 review.
Regression Analysis:
- New regression? Yes
- Reproducibility? YesBuild regression: arm64 x86
kcsan_test.cerror variable 'dummy' is uninitialized when passed as a const pointer argument here
Quoted 8 lines
## Build log
kernel/kcsan/kcsan_test.c:591:41: error: variable 'dummy' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
591 |KCSAN_EXPECT_READ_BARRIER(atomic_read(&dummy), false);
| ^~~~~
1 error generated.
Thanks for catching this. Newer versions of Clang seem to be getting smarter. We can silence the warning with the below patch:
From 56c920457a4e7077b83aafb0c9c8105fb98b0158 Mon Sep 17 00:00:00 2001
From: Marco Elver <[email protected]>
Date: Tue, 22 Jul 2025 20:19:17 +0200
Subject: [PATCH] kcsan/test: Initialize dummy variable
Newer compiler versions rightfully point out:
kernel/kcsan/kcsan_test.c:591:41: error: variable 'dummy' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
591 | KCSAN_EXPECT_READ_BARRIER(atomic_read(&dummy), false);
| ^~~~~
1 error generated.
Although this particular test does not care about the value stored in the dummy atomic variable, let's silence the warning.
--- kernel/kcsan/kcsan_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/kcsan/kcsan_test.c +1 -1
@@ -533,7 +533,7 @@ static void test_barrier_nothreads(struct kunit *test)struct kcsan_scoped_access *reorder_access =NULL ;#endif arch_spinlock_t arch_spinlock = __ARCH_SPIN_LOCK_UNLOCKED; -atomic_t dummy; +atomic_t dummy =ATOMIC_INIT (0 );KCSAN_TEST_REQUIRES (test, reorder_access !=NULL );KCSAN_TEST_REQUIRES (test,IS_ENABLED (CONFIG_SMP ));
Signature · 1 line
2.50.0.727.gbf7dc18ff4-goog
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.40-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.40-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · On Tue, 22 Jul 2025 15:43:04 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for loongarch64:
Thanks!
Cheers,
Miguel
Am 22.07.2025 um 15:43 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Hi Greg,
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
No problems seen on x86_64 and aarch64 with our testing.
Thanks,
Harshit
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.40-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.12:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
120 tests: 120 pass, 0 failLinux version: 6.12.40-rc1-g596aae841edf
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.40-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
The kernel, bpf tool, and perf tool builds fine for v6.12.40-rc1 on x86 and arm64 Azure VM.
Thanks,
Hardik
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.40-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.12.40-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 596aae841edf981aab1df1845e6df012bed94594
* git describe: v6.12.39-159-g596aae841edf
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.39-159-g596aae841edf
## Test Regressions (compared to v6.12.37-168-gd50d16f00292)
## Metric Regressions (compared to v6.12.37-168-gd50d16f00292)
## Test Fixes (compared to v6.12.37-168-gd50d16f00292)
## Metric Fixes (compared to v6.12.37-168-gd50d16f00292)
## Test result summary
total: 322673, pass: 295025, fail: 7381, skip: 19752, xfail: 515
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 137 passed, 2 failed
* arm64: 57 total, 56 passed, 1 failed
* i386: 18 total, 18 passed, 0 failed
* mips: 34 total, 33 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 40 total, 40 passed, 0 failed
* riscv: 25 total, 23 passed, 2 failed
* s390: 22 total, 21 passed, 1 failed
* sh: 5 total, 5 passed, 0 failed
* sparc: 4 total, 3 passed, 1 failed
* x86_64: 49 total, 47 passed, 2 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mm
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* modules
* perf
* rcutorture
* rt-tests-cyclicdeadline
* rt-tests-pi-stress
* rt-tests-pmqtest
* rt-tests-rt-migrate-test
* rt-tests-signaltest
--
Linaro LKFT
https://lkft.linaro.org
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.12.40 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.12.y
Best regards,
Pavel
Signature · 2 lines
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany