[Deepin-Kernel-SIG] [linux 6.6-y] [Upstream] Update kernel base to 6.6.119 #1375
+909
−28,086
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[ Upstream commit 0c73772 ] The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary. Fixes: 7259124 ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c") Signed-off-by: Seungjin Bae <[email protected]> Reviewed-by: Jimmy Assarsson <[email protected]> Tested-by: Jimmy Assarsson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit e9dd83a75a7274edef21682c823bf0b66d7b6b7f) Signed-off-by: Wentao Guan <[email protected]>
…ed URBs [ Upstream commit 516a0cd ] The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue Closes: candle-usb/candleLight_fw#187 Fixes: d08e973 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20251114-gs_usb-fix-usb-callbacks-v1-1-a29b42eacada@pengutronix.de Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 1a588c40a422a3663a52f1c5535e8fb6b044167d) Signed-off-by: Wentao Guan <[email protected]>
…re accessing header [ Upstream commit 6fe9f32 ] The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain "dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since "urb->context" contains "parent", it is always defined, while "dev" is not defined if the URB it too short. Fixes: d08e973 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20251114-gs_usb-fix-usb-callbacks-v1-2-a29b42eacada@pengutronix.de Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 3433680b759646efcacc64fe36aa2e51ae34b8f0) Signed-off-by: Wentao Guan <[email protected]>
…re accessing data [ Upstream commit 395d988 ] The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. Fixes: d08e973 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20251114-gs_usb-fix-usb-callbacks-v1-3-a29b42eacada@pengutronix.de [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 4ffac725154cf6a253f5e6aa0c8946232b6a0af5) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 89bb613 ] There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314 Fixes: 6fe26f6 ("Bluetooth: MGMT: Protect mgmt_pending list with its own lock") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=9aa47cd4633a3cf92a80 Tested-by: [email protected] Signed-off-by: Edward Adam Davis <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit fe68510fc99bb4b88c9c611f83699749002d515a) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 545d7827b2cd5de5eb85580cebeda6b35b3ff443 ] The change eed467b ("Bluetooth: fix passkey uninitialized when used") introduced a goto that bypasses the creation of temporary mackey and ltk which are later used by the likes of DHKey Check step. Later ffee202 ("Bluetooth: Always request for user confirmation for Just Works (LE SC)") which means confirm_hint is always set in case JUST_WORKS so the branch checking for an existing LTK becomes pointless as confirm_hint will always be set, so this just merge both cases of malicious or legitimate devices to be confirmed before continuing with the pairing procedure. Link: bluez/bluez#1622 Fixes: eed467b ("Bluetooth: fix passkey uninitialized when used") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit fd6a1261d05d7f4d6630229e1f280dd7256b9ce8) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit ec3803b ] As the interface mode doesn't need to be updated on PHYs connected with USXGMII and integrated PHYs, gpy_update_interface() should just return 0 in these cases rather than -EINVAL which has wrongly been introduced by commit 7a495dd ("net: phy: mxl-gpy: Change gpy_update_interface() function return type"), as this breaks support for those PHYs. Fixes: 7a495dd ("net: phy: mxl-gpy: Change gpy_update_interface() function return type") Signed-off-by: Daniel Golle <[email protected]> Reviewed-by: Maxime Chevallier <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Link: https://patch.msgid.link/f744f721a1fcc5e2e936428c62ff2c7d94d2a293.1763648168.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit ff45dd52bd189cc35d590fd948dd852ac370c4e0) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 9b9c0ad ] This passes the address of the pointer "&punit_ipcdev" when the intent was to pass the pointer itself "punit_ipcdev" (without the ampersand). This means that the: complete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it. Fixes: fdca4f1 ("platform:x86: add Intel P-Unit mailbox IPC driver") Signed-off-by: Dan Carpenter <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 3e7442c5802146fd418ba3f68dcb9ca92b5cec83) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 7526183 ] ATL2 hardware was missing descriptor cache invalidation in hw_stop(), causing SMMU translation faults during device shutdown and module removal: [ 70.355743] arm-smmu-v3 arm-smmu-v3.5.auto: event 0x10 received: [ 70.361893] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0002060000000010 [ 70.367948] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0000020000000000 [ 70.374002] arm-smmu-v3 arm-smmu-v3.5.auto: 0x00000000ff9bc000 [ 70.380055] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0000000000000000 [ 70.386109] arm-smmu-v3 arm-smmu-v3.5.auto: event: F_TRANSLATION client: 0001:06:00.0 sid: 0x20600 ssid: 0x0 iova: 0xff9bc000 ipa: 0x0 [ 70.398531] arm-smmu-v3 arm-smmu-v3.5.auto: unpriv data write s1 "Input address caused fault" stag: 0x0 Commit 7a1bb49 ("net: aquantia: fix potential IOMMU fault after driver unbind") and commit ed4d81c ("net: aquantia: when cleaning hw cache it should be toggled") fixed cache invalidation for ATL B0, but ATL2 was left with only interrupt disabling. This allowed hardware to write to cached descriptors after DMA memory was unmapped, triggering SMMU faults. Once cache invalidation is applied to ATL2, the translation fault can't be observed anymore. Add shared aq_hw_invalidate_descriptor_cache() helper and use it in both ATL B0 and ATL2 hw_stop() implementations for consistent behavior. Fixes: e54dcf4 ("net: atlantic: basic A2 init/deinit hw_ops") Tested-by: Carol Soto <[email protected]> Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 30a1d3db72bc60591c546b29042e7f789976fc38) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 9780f53 ] To initialize the taprio block in lan966x, it is required to configure the register REVISIT_DLY. The purpose of this register is to set the delay before revisit the next gate and the value of this register depends on the system clock. The problem is that the we calculated wrong the value of the system clock period in picoseconds. The actual system clock is ~165.617754MHZ and this correspond to a period of 6038 pico seconds and not 15125 as currently set. Fixes: e462b27 ("net: lan966x: Add offload support for taprio") Signed-off-by: Horatiu Vultur <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 58c411509141244c576ec86d5a5e6a5b63bede94) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit d2099d9 ] The rate limiting validation condition currently checks the output variable max_bw_value[i] instead of the input value maxrate->tc_maxrate[i]. This causes the validation to compare an uninitialized or stale value rather than the actual requested rate. The condition should check the input rate to properly validate against the upper limit: } else if (maxrate->tc_maxrate[i] <= upper_limit_gbps) { This aligns with the pattern used in the first branch, which correctly checks maxrate->tc_maxrate[i] against upper_limit_mbps. The current implementation can lead to unreliable validation behavior: - For rates between 25.5 Gbps and 255 Gbps, if max_bw_value[i] is 0 from initialization, the GBPS path may be taken regardless of whether the actual rate is within bounds - When processing multiple TCs (i > 0), max_bw_value[i] contains the value computed for the previous TC, affecting the validation logic - The overflow check for rates exceeding 255 Gbps may not trigger consistently depending on previous array values This patch ensures the validation correctly examines the requested rate value for proper bounds checking. Fixes: 43b27d1 ("net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps") Signed-off-by: Danielle Costantino <[email protected]> Reviewed-by: Gal Pressman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit aa20dcff033cb31744455db3cb45d94e13769c80) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit f5bce28 ] Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review. Fixes: 1edb9ca ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Alexey Kodanev <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 7fd789d6ea4915034eb6bcb72f6883c8151083e5) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 7fa666ab07ba9e08f52f357cb8e1aad753e83ac6 ] If the board supports IP discovery, we don't need to parse the gpu info firmware. Backport to 6.18. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4721 Fixes: fa819e3 ("drm/amdgpu: add support for cyan skillfish gpu_info") Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 5427e32fa3a0ba9a016db83877851ed277b065fb) Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 0be4d79f8a1b6ac792fdf401cbd3a7216a45c1f9) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit a18891b ] The static configuration reload saves the port speed in the static configuration tables by first converting it from the internal respresentation to the SPEED_xxx ethtool representation, and then converts it back to restore the setting. This is because sja1105_adjust_port_config() takes the speed as SPEED_xxx. However, this is unnecessarily complex. If we split sja1105_adjust_port_config() up, we can simply save and restore the mac[port].speed member in the static configuration tables. Signed-off-by: Russell King (Oracle) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: da62abaaa268 ("net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing traffic") Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit d25c17507e804743e314ed1467c247e1303e0d4e) Signed-off-by: Wentao Guan <[email protected]>
…raffic [ Upstream commit da62aba ] When using the SGMII PCS as a fixed-link chip-to-chip connection, it is easy to miss the fact that traffic passes only at 1G, since that's what any normal such connection would use. When using the SGMII PCS connected towards an on-board PHY or an SFP module, it is immediately noticeable that when the link resolves to a speed other than 1G, traffic from the MAC fails to pass: TX counters increase, but nothing gets decoded by the other end, and no local RX counters increase either. Artificially lowering a fixed-link rate to speed = <100> makes us able to see the same issue as in the case of having an SGMII PHY. Some debugging shows that the XPCS configuration is A-OK, but that the MAC Configuration Table entry for the port has the SPEED bits still set to 1000Mbps, due to a special condition in the driver. Deleting that condition, and letting the resolved link speed be programmed directly into the MAC speed field, results in a functional link at all 3 speeds. This piece of evidence, based on testing on both generations with SGMII support (SJA1105S and SJA1110A) directly contradicts the statement from the blamed commit that "the MAC is fixed at 1 Gbps and we need to configure the PCS only (if even that)". Worse, that statement is not backed by any documentation, and no one from NXP knows what it might refer to. I am unable to recall sufficient context regarding my testing from March 2020 to understand what led me to draw such a braindead and factually incorrect conclusion. Yet, there is nothing of value regarding forcing the MAC speed, either for SGMII or 2500Base-X (introduced at a later stage), so remove all such logic. Fixes: ffe10e6 ("net: dsa: sja1105: Add support for the SGMII port") Signed-off-by: Vladimir Oltean <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 90daa70a4d6239103f3d67e2b4bc0bad15297b8c) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 5ffcb7b ] The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: <IRQ> aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Fixes: 6aecbba ("net: atlantic: add check for MAX_SKB_FRAGS") Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. Signed-off-by: Jiefeng Zhang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 3be37c3c96b16462394fcb8e15e757c691377038) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 50caa74 ] The PEROUT allows the user to set a specified future time to output the periodic signal. If the future time is far from the current time, the FEC driver will use hrtimer to configure PEROUT one second before the future time. However, the hrtimer will not be canceled if the PEROUT is disabled before the hrtimer expires. So the PEROUT will be configured when the hrtimer expires, which is not as expected. Therefore, cancel the hrtimer in fec_ptp_pps_disable() to fix this issue. Fixes: 350749b ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 2d8f6acf56235e28bd55bd86b253bf7aa839e8ac) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit e97faa0c20ea8840f45569ba434e30538fff8fc9 ] If the previously set PEROUT is already active, updating it will cause the new PEROUT to start immediately instead of at the specified time. This is because fep->reload_period is updated whithout check whether the PEROUT is enabled, and the old PEROUT is not disabled. Therefore, the pulse period will be updated immediately in the pulse interrupt handler fec_pps_interrupt(). Currently, the driver does not support directly updating PEROUT and it will make the logic be more complicated. To fix the current issue, add a check before enabling the PEROUT, the driver will return an error if PEROUT is enabled. If users wants to update a new PEROUT, they should disable the old PEROUT first. Fixes: 350749b ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit b332c433489e46c9ec94c0e846701722453aca79) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit c0a1f3d ] In the current driver, PPS and PEROUT use the same channel to generate the events, so they cannot be enabled at the same time. Otherwise, the later configuration will overwrite the earlier configuration. Therefore, when configuring PPS, the driver will check whether PEROUT is enabled. Similarly, when configuring PEROUT, the driver will check whether PPS is enabled. Fixes: 350749b ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 2648b8b519925284383e390cc58fdce163be23e5) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 9a060d0fac9e75524f72864adec6d8cdb70a5bca ] There are currently two situations that can trigger the PTP interrupt, one is the PPS event, the other is the PEROUT event. However, the irq handler fec_pps_interrupt() does not check the irq event type and directly registers a PPS event into the system, but the event may be a PEROUT event. This is incorrect because PEROUT is an output signal, while PPS is the input of the kernel PPS system. Therefore, add a check for the event type, if pps_enable is true, it means that the current event is a PPS event, and then the PPS event is registered. Fixes: 350749b ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 21f867e3da98c96a2b3009f7eaa0ea9e795ce34e) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 8abbf45 ] The calibrated timestamp is calculated from the nominal value using the formula: ts_gain[ns] ≈ ts_sensitivity - (ts_trim_coeff * val) / 1000. The values of ts_sensitivity and ts_trim_coeff are not the same for all devices, so it is necessary to differentiate them based on the part name. For the correct values please consult the relevant AN. Fixes: cb3b6b8 ("iio: imu: st_lsm6dsx: add odr calibration feature") Signed-off-by: Mario Tesi <[email protected]> Acked-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit cad94b17e2760fded801907e73dea34159fb3c97) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 74851fb ] devm_pm_runtime_enable() can fail due to memory allocation. The current code ignores its return value, potentially causing pm_runtime_resume_and_get() to operate on uninitialized runtime PM state. Check the return value of devm_pm_runtime_enable() and return on failure. Fixes: 3e6e14f ("usb: gadget: udc: add Renesas RZ/N1 USBF controller support") Signed-off-by: Haotian Zhang <[email protected]> Acked-by: Herve Codina <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 826785925627fce1dd34bd0307c923340fa8e160) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 3acf1028f5003731977f750a7070f3321a9cb740 ] The debugfs_create_dir() function returns ERR_PTR() on error, not NULL. The current null-check fails to catch errors. Use IS_ERR() to correctly check for errors. Fixes: 8ea4484 ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Haotian Zhang <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 5550f9021895ea7b9203cae1d8463216d0d9f410) Signed-off-by: Wentao Guan <[email protected]>
…nction [ Upstream commit 3a675f5 ] The existing error handling logic in pcc_mbox_irq() is intermixed with the main flow of the function. The command complete check and the complete complete update/acknowledgment are nicely factored into separate functions. Moves error detection and clearing logic into a separate function called: pcc_mbox_error_check_and_clear() by extracting error-handling logic from pcc_mbox_irq(). This ensures error checking and clearing are handled separately and it improves maintainability by keeping the IRQ handler focused on processing events. Acked-by: Huisong Li <[email protected]> Tested-by: Huisong Li <[email protected]> Tested-by: Adam Young <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Stable-dep-of: ff0e4d4 ("mailbox: pcc: don't zero error register") Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit ea621f472cfe3c2a0833a22e494c0aee23d794cf) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit ff0e4d4 ] The error status mask for a type 3/4 subspace is used for reading the error status, and the bitwise inverse is used for clearing the error with the intent being to preserve any of the non-error bits. However, we were previously applying the mask to extract the status and then applying the inverse to the result which ended up clearing all bits. Instead, store the inverse mask in the preserve mask and then use that on the original value read from the error status so that only the error is cleared. Fixes: c45ded7 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)") Signed-off-by: Jamie Iles <[email protected]> Signed-off-by: Punit Agrawal <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit f29b58e974c70d7a7c4b6e6d8afd479b4fd8821e) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 3dcf44a ] This driver runs also on Tegra SoCs without a Tegra20 APB DMA controller (e.g. Tegra234). Remove the Kconfig dependency on TEGRA20_APB_DMA; in addition, amend the help text to reflect the fact that this driver works on SoCs different from Tegra114. Fixes: bb9667d ("arm64: tegra: Add SPI device tree nodes for Tegra234") Signed-off-by: Francesco Lavra <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit dbb60bd12950349f2c68d4ea8aeed9d34869e630) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit a90903c ] devm_pm_runtime_enable() can fail due to memory allocation. The current code ignores its return value, potentially causing runtime PM operations to fail silently after autosuspend configuration. Check the return value of devm_pm_runtime_enable() and return on failure. Fixes: 909fac0 ("spi: add support for Amlogic A1 SPI Flash Controller") Signed-off-by: Haotian Zhang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 99aff13bcc13305f1c56b119a3cf574a0f190c03) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 030ace4 ] There are NOR flashes (Macronix) that swap the bytes on a 16-bit boundary when configured in Octal DTR mode. The byte order of 16-bit words is swapped when read or written in Octal Double Transfer Rate (DTR) mode compared to Single Transfer Rate (STR) modes. If one writes D0 D1 D2 D3 bytes using 1-1-1 mode, and uses 8D-8D-8D SPI mode for reading, it will read back D1 D0 D3 D2. Swapping the bytes may introduce some endianness problems. It can affect the boot sequence if the entire boot sequence is not handled in either 8D-8D-8D mode or 1-1-1 mode. Therefore, it is necessary to swap the bytes back to ensure the same byte order as in STR modes. Fortunately there are controllers that could swap the bytes back at runtime, addressing the flash's endianness requirements. Provide a way for the upper layers to specify the byte order in Octal DTR mode. Merge Tudor's patch and add modifications for suiting newer version of Linux kernel. Suggested-by: Michael Walle <[email protected]> Signed-off-by: JaimeLiao <[email protected]> Signed-off-by: AlvinZhou <[email protected]> Acked-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tudor Ambarus <[email protected]> Stable-dep-of: 40ad64a ("spi: nxp-fspi: Propagate fwnode in ACPI case as well") Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 94b3c7558748672bea30c4e5d2fa0c36ee34647a) Signed-off-by: Wentao Guan <[email protected]>
…frequency [ Upstream commit 0fefead ] In the spi subsystem, the bus frequency is derived as follows: - the controller may expose a minimum and maximum operating frequency - the hardware description, through the spi peripheral properties, advise what is the maximum acceptable frequency from a device/wiring point of view. Transfers must be observed at a frequency which fits both (so in practice, the lowest maximum). Actually, this second point mixes two information and already takes the lowest frequency among: - what the spi device is capable of (what is written in the component datasheet) - what the wiring allows (electromagnetic sensibility, crossovers, terminations, antenna effect, etc). This logic works until spi devices are no longer capable of sustaining their highest frequency regardless of the operation. Spi memories are typically subject to such variation. Some devices are capable of spitting their internally stored data (essentially in read mode) at a very fast rate, typically up to 166MHz on Winbond SPI-NAND chips, using "fast" commands. However, some of the low-end operations, such as regular page read-from-cache commands, are more limited and can only be executed at 54MHz at most. This is currently a problem in the SPI-NAND subsystem. Another situation, even if not yet supported, will be with DTR commands, when the data is latched on both edges of the clock. The same chips as mentioned previously are in this case limited to 80MHz. Yet another example might be continuous reads, which, under certain circumstances, can also run at most at 104 or 120MHz. As a matter of fact, the "one frequency per chip" policy is outdated and more fine grain configuration is needed: we need to allow per-operation frequency limitations. So far, all datasheets I encountered advertise a maximum default frequency, which need to be lowered for certain specific operations. So based on the current infrastructure, we can still expect firmware (device trees in general) to continued advertising the same maximum speed which is a mix between the PCB limitations and the chip maximum capability, and expect per-operation lower frequencies when this is relevant. Add a `struct spi_mem_op` member to carry this information. Not providing this field explicitly from upper layers means that there is no further constraint and the default spi device maximum speed will be carried instead. The SPI_MEM_OP() macro is also expanded with an optional frequency argument, because virtually all operations can be subject to such a limitation, and this will allow for a smooth and discrete transition. For controller drivers which do not implement the spi-mem interface, the per-transfer speed is also set acordingly to a lower (than the maximum default) speed when relevant. Acked-by: Pratyush Yadav <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-1-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: 40ad64a ("spi: nxp-fspi: Propagate fwnode in ACPI case as well") Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit f1ea0e8b4a154f28642fa402c5ae5db1b47e71ba) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 1248c9b ] There are spi devices with multiple frequency limitations depending on the invoked command. We probably do not want to afford running at the lowest supported frequency all the time, so if we want to get the most of our hardware, we need to allow per-operation frequency limitations. Among all the SPI memory controllers, I believe all are capable of changing the spi frequency on the fly. Some of the drivers do not make any frequency setup though. And some others will derive a per chip prescaler value which will be used forever. Actually changing the frequency on the fly is something new in Linux, so we need to carefully flag the drivers which do and do not support it. A controller capability is created for that, and the presence for this capability will always be checked before accepting such pattern. Signed-off-by: Miquel Raynal <[email protected]> Reviewed-by: Tudor Ambarus <[email protected]> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-2-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: 40ad64a ("spi: nxp-fspi: Propagate fwnode in ACPI case as well") Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit a25cc746f7d0dc6b6211b0f73defba7be7c90f3e) Signed-off-by: Wentao Guan <[email protected]>
A recent change to clamp_t() in 6.1.y caused fs/nfsd/nfs4state.c to fail
to compile with gcc-9. The code in nfsd4_get_drc_mem() was written with
the assumption that when "max < min",
clamp(val, min, max)
would return max. This assumption is not documented as an API promise
and the change caused a compile failure if it could be statically
determined that "max < min".
The relevant code was no longer present upstream when commit 1519fbc8832b
("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()")
landed there, so there is no upstream change to nfsd4_get_drc_mem() to
backport.
There is no clear case that the existing code in nfsd4_get_drc_mem()
is functioning incorrectly. The goal of this patch is to permit the clean
application of commit 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for
the lo < hi test in clamp()"), and any commits that depend on it, to LTS
kernels without affecting the ability to compile those kernels. This is
done by open-coding the __clamp() macro sans the built-in type checking.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220745#c0
Signed-off-by: NeilBrown <[email protected]>
Stable-dep-of: 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()")
Signed-off-by: Chuck Lever <[email protected]>
Reviewed_by: David Laight <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit 0722d804f7ad664424480cbb5d08292fd8ca08fb)
Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 7bf1158 ] While the userspace program can be notified of gadget state changes, timing issue can lead to missed transitions when reading the state value. Introduce a trace event for usb_gadget_set_state to reliably track state transitions. Signed-off-by: Kuen-Han Tsai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Stable-dep-of: baeb66fbd420 ("usb: gadget: udc: fix use-after-free in usb_gadget_state_work") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 92234ee7fc23186346f2c659c7d36350ad4df066) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit baeb66f ] A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e ("usb: gadget: core: flush gadget workqueue after device removal") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window. Fixes: 5702f75 ("usb: gadget: udc-core: move sysfs_notify() to a workqueue") Cc: stable <[email protected]> Signed-off-by: Jimmy Hu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit f02a412c0a18f02f0f91b0a3d9788315a721b7fd) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 23379a1 ] The ucsi_psy_get_current_max function defaults to 0.1A when it is not clear how much current the partner device can support. But this does not check the port is connected, and will report 0.1A max current when nothing is connected. Update ucsi_psy_get_current_max to report 0A when there is no connection. Fixes: af833e7 ("usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2 and Default") Cc: [email protected] Signed-off-by: Jameson Thies <[email protected]> Reviewed-by: Benson Leung <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Kenneth R. Crudup <[email protected]> Rule: add Link: https://lore.kernel.org/stable/20251017000051.2094101-1-jthies%40google.com Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> [ adapted UCSI_CONSTAT() macro to direct flag access ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit eecd163fa6da94d58b7d26d1efba70863dbf5cb2) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 6d849ff ] The commit 5cff263 ("can: rcar_canfd: Fix controller mode setting") has aligned with the flow mentioned in the hardware manual for all SoCs except R-Car Gen3 and RZ/G2L SoCs. On R-Car Gen4 and RZ/G3E SoCs, due to the wrong logic in the commit[1] sets the default mode to FD-Only mode instead of CAN-FD mode. This patch sets the CAN-FD mode as the default for all SoCs by dropping the rcar_canfd_set_mode() as some SoC requires mode setting in global reset mode, and the rest of the SoCs in channel reset mode and update the rcar_canfd_reset_controller() to take care of these constraints. Moreover, the RZ/G3E and R-Car Gen4 SoCs support 3 modes compared to 2 modes on the R-Car Gen3. Use inverted logic in rcar_canfd_reset_controller() to simplify the code later to support FD-only mode. [1] commit 45721c4 ("can: rcar_canfd: Add support for r8a779a0 SoC") Fixes: 5cff263 ("can: rcar_canfd: Fix controller mode setting") Cc: [email protected] Signed-off-by: Biju Das <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> [ adapted to use existing is_gen4() helper and RCANFD_GEN4_FDCFG() macro instead of new ch_interface_mode field and fcbase struct ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 094f10f3f290d4bfcded29856c0d9892905e45c4) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 9b45744bf09fc2a3287e05287141d6e123c125a7 ] The vshunt/current reported register is a signed 16bit integer. The sign bit index should be '15', not '16'. Fixes: 4396f45 ("iio: adc: Add rtq6056 support") Reported-by: Andy Hsu <[email protected]> Signed-off-by: ChiYuan Huang <[email protected]> Reviewed-by: David Lechner <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> [ adapted switch statement to existing if-else structure for sign_extend32() fix ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit a395121fe29efdc9b41edaf0d0cd2abbae83645d) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 01b9128 ] When removing a macb device, the driver calls phy_exit() before unregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ... The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus. Fix this by moving unregister_netdev() ahead of phy_exit() in macb_remove(). Fixes: 8b73fa3 ("net: macb: Added ZynqMP-specific initialization") Signed-off-by: luoguangfei <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> [ Minor context change fixed. ] Signed-off-by: Alva Lan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 2b9719ccad38dffad7dbdd2f39896f723f9b9011) Signed-off-by: Wentao Guan <[email protected]>
commit 41e883c upstream. This driver is in the staging area since 2010. The following reasons lead to the removal: - This driver generates maintenance workload for itself and for API wext - A MAC80211 driver was available in 2016 time frame; This driver does not compile anymore but would be a better starting point than the current driver. Here the note from the TODO file: A replacement for this driver with MAC80211 support is available at https://github.com/chunkeey/rtl8192su - no progress changing to mac80211 - Using this hardware is security wise not state of the art as WPA3 is not supported. Find further discussions in the Link below. Link: https://lore.kernel.org/linux-staging/[email protected]/T/#t Signed-off-by: Philipp Hortmann <[email protected]> Tested-by: Dominik Karol Piątkowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> [groeck: Resolved conflicts; dropped statement about hardware support in longterm kernels] Signed-off-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/stable/20251204021604.GA843400@ax162/T/#t Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit f12f4c657617425924aead7b45825bda09905e8b) Signed-off-by: Wentao Guan <[email protected]>
commit 852b644 upstream. The 'run_tests' function is executed in the background, but killing its associated PID would not kill the children tasks running in the background. To properly kill all background tasks, 'kill -- -PID' could be used, but this requires kill from procps-ng. Instead, all children tasks are listed using 'ps', and 'kill' is called with all PIDs of this group. Fixes: 31ee4ad ("selftests: mptcp: join: stop transfer when check is done (part 1)") Cc: [email protected] Fixes: 04b57c9 ("selftests: mptcp: join: stop transfer when check is done (part 2)") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-6-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> [ Conflicts in mptcp_join.sh, because commit e3b47e4 ("selftests: mptcp: userspace pm remove initial subflow") and commit b9fb176 ("selftests: mptcp: userspace pm send RM_ADDR for ID 0") are not in this version. They introduced new subtests that got modified by this patch. That's OK, no need to modify them if they are not there: the conflicts can be dropped. ] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit b77075c08d7e0af0aeef80b7c17536188b8c9bd0) Signed-off-by: Wentao Guan <[email protected]>
commit ae15506 upstream. The CI reports sporadic failures of the fastclose self-tests. The root cause is a duplicate reset, not carrying the relevant MPTCP option. In the failing scenario the bad reset is received by the peer before the fastclose one, preventing the reception of the latter. Indeed there is window of opportunity at fastclose time for the following race: mptcp_do_fastclose __mptcp_close_ssk __tcp_close() tcp_set_state() [1] tcp_send_active_reset() [2] After [1] the stack will send reset to in-flight data reaching the now closed port. Such reset may race with [2]. Address the issue explicitly sending a single reset on fastclose before explicitly moving the subflow to close status. Fixes: d21f834 ("mptcp: use fastclose on more edge scenarios") Cc: [email protected] Closes: multipath-tcp/mptcp_net-next#596 Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Geliang Tang <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-6-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> [ No conflicts, but tcp_send_active_reset() doesn't take a 3rd argument (sk_rst_reason) in this version, see commit 5691276 ("rstreason: prepare for active reset"). This argument is only helpful for tracing, it is fine to drop it. ] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 3a13454fd098ed51e733958488f8ec62859a9ed8) Signed-off-by: Wentao Guan <[email protected]>
commit 2fc9fef upstream. The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Signed-off-by: Sean Heelan <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Nazar Kalashnikov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 70ad6455139e26e85f48f95d0e21f351c1909342) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit d0b8fec ] The IRQ numbers created through irq_create_mapping() are only assigned to ptpmsg_irq[n].num at the end of the IRQ setup. So if an error occurs between their creation and their assignment (for instance during the request_threaded_irq() step), we enter the error path and fail to release the newly created virtual IRQs because they aren't yet assigned to ptpmsg_irq[n].num. Move the mapping creation to ksz_ptp_msg_irq_setup() to ensure symetry with what's released by ksz_ptp_msg_irq_free(). In the error path, move the irq_dispose_mapping to the out_ptp_msg label so it will be called only on created IRQs. Cc: [email protected] Fixes: cc13ab1 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Bastien Curutchet (Schneider Electric) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 3b5a6115d6ea45df1ea65dc9b832b23db5d593ba) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit 0f80e21 ] If a port interrupt setup fails after at least one port has already been successfully initialized, the gotos miss some resource releasing: - the already initialized PTP IRQs aren't released - the already initialized port IRQs aren't released if the failure occurs in ksz_pirq_setup(). Merge 'out_girq' and 'out_ptpirq' into a single 'port_release' label. Behind this label, use the reverse loop to release all IRQ resources for all initialized ports. Jump in the middle of the reverse loop if an error occurs in ksz_ptp_irq_setup() to only release the port IRQ of the current iteration. Cc: [email protected] Fixes: c9cd961 ("net: dsa: microchip: lan937x: add interrupt support for port phy link") Signed-off-by: Bastien Curutchet (Schneider Electric) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> [ replaced dsa_switch_for_each_user_port_continue_reverse() macro with dsa_switch_for_each_port_continue_reverse() plus manual dsa_port_is_user() check ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit e7e8e9b1a1b1c8d4803fdb90354d4db04f05d210) Signed-off-by: Wentao Guan <[email protected]>
[ Upstream commit a6b87bf ] Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does. Signed-off-by: Alan Stern <[email protected]> Reported-by: [email protected] Closes: https://lore.kernel.org/linux-usb/[email protected]/ Tested-by: [email protected] Fixes: dde5845 ("[PATCH] Generic HID layer - code split") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> [ s32ton() was moved by c653ffc ("HID: stop exporting hid_snto32()"). Minor context change fixed. ] Signed-off-by: Wenshan Lan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 810189546cb6c8f36443ed091d91f1f5d2fc2ec7) Signed-off-by: Wentao Guan <[email protected]>
Link: https://lore.kernel.org/r/[email protected] Tested-by: Florian Fainelli <[email protected]> Tested-by: Hardik Garg <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Brett A C Sheffield <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 5fa4793a2d2d70ad08b85387b41020f1fcc2d19e) Signed-off-by: Wentao Guan <[email protected]>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
deepin-ci-robot
requested review from
Avenger-285714,
Ink-Paper and
hello666888999
deepin pr auto reviewI've analyzed the provided diff. It shows changes across multiple kernel subsystems, primarily related to USB, networking, and staging drivers. Here's a breakdown of the key changes:
The most significant change is the complete removal of the RTL8712 wireless driver from the staging tree, which was a Realtek driver that was likely deprecated or had licensing issues. Many other changes are adding support for new hardware IDs, particularly for Intel chipsets, and improving error handling throughout the USB subsystem. Major Changes1. RTL8712 Wireless Driver RemovalThe entire RTL8712 wireless driver has been completely removed from the staging tree:
2. USB Subsystem UpdatesMultiple USB drivers received significant updates: DWC3 Controller:
USB Gadget:
USB Serial:
USB Storage:
3. Hardware Support
4. Networking Enhancements
5. Other Improvements
SummaryThe changes primarily focus on:
The most significant change is the complete removal of the RTL8712 wireless driver, which suggests it was either obsolete or had licensing issues that prevented its inclusion in the mainline kernel. |
deepin inclusion category: other Per commit commit 41e883c upstream. This driver is in the staging area since 2010. The following reasons lead to the removal: - This driver generates maintenance workload for itself and for API wext - A MAC80211 driver was available in 2016 time frame; This driver does not compile anymore but would be a better starting point than the current driver. Here the note from the TODO file: A replacement for this driver with MAC80211 support is available at https://github.com/chunkeey/rtl8192su - no progress changing to mac80211 - Using this hardware is security wise not state of the art as WPA3 is not supported. Find further discussions in the Link below. Signed-off-by: Wentao Guan <[email protected]>
opsiff
force-pushed
the
linux-stable-update-6.6.119
branch
from
d68875d to
e65c51a
Compare
Member
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Avenger-285714 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update kernel base to 6.6.119.
git log --oneline v6.6.118..v6.6.119 |wc
94 846 6777
config:
deepin: config: remove R8712U