summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-02-07staging: rtl8723bs: use unaligned access macros in rtw_security.cArchit Anant
The driver defines custom functions secmicgetuint32() and secmicputuint32() to handle little-endian byte-to-integer conversion. This is redundant as the kernel provides optimized standard macros for this purpose in <linux/unaligned.h>. Replace the custom implementations with get_unaligned_le32() and put_unaligned_le32() and delete the now-unused local functions. Signed-off-by: Archit Anant <architanant5@gmail.com> Reviewed-by: Ethan Tidmore <ethantidmore06@gmail.com> Link: https://patch.msgid.link/20260130075113.34666-1-architanant5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07ALSA: hda/conexant: Add quirk for HP ZBook Studio G4Takashi Iwai
It was reported that we need the same quirk for HP ZBook Studio G4 (SSID 103c:826b) as other HP models to make the mute-LED working. Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/64d78753-b9ff-4c64-8920-64d8d31cd20c@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=221002 Link: https://patch.msgid.link/20260207131324.2428030-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-02-07staging: rtl8723bs: fix potential race in expire_timeout_chkMinu Jin
The expire_timeout_chk function currently do lock and unlock inside the loop before calling rtw_free_stainfo(). This can be risky as the list might be changed when the lock is briefly released. To fix this, move expired sta_info entries into a local free_list while holding the lock, and then perform the actual freeing after the lock is released. Signed-off-by: Minu Jin <s9430939@naver.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20260131171153.3729458-1-s9430939@naver.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: remove dead debugging code in rtw_mlme_ext.cLuka Gejak
Remove the unused local variable 'pattrib' and the unreachable 'if (0)' debug block in OnAction_sa_query to clean up the driver code. Signed-off-by: Luka Gejak <lukagejak5@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20260130185658.207785-6-lukagejak5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: modernize hex output in rtw_report_sec_ieLuka Gejak
Replace the manual hex-printing loop with the standard kernel '%*ph' format string. This simplifies the code and uses modern logging practices. Signed-off-by: Luka Gejak <lukagejak5@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20260130185658.207785-5-lukagejak5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: fix spacing around operatorsLuka Gejak
Fix coding style issues by adding missing spaces around operators. Signed-off-by: Luka Gejak <lukagejak5@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20260130185658.207785-4-lukagejak5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: rename u1bTmp to valLuka Gejak
Rename the variable u1bTmp to val to remove Hungarian notation. This improves readability and aligns the code with kernel naming standards. Signed-off-by: Luka Gejak <lukagejak5@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20260130185658.207785-3-lukagejak5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: remove unused private debug countersEthan Tidmore
The driver maintains a private `struct debug_priv` embedded within `struct dvobj_priv` to track various error counters (e.g., suspend errors, alloc failures, RX drops). These counters are incremented in various files but the data is never read or exposed to userspace. Remove the unused `debug_priv` structure definition, the instance in `dvobj_priv`, and all associated increment operations across the driver to clean up the code. This also removes the following helper functions which were used solely to update these counters: - rtw_reset_rx_info() - recv_indicatepkts_pkt_loss_cnt() Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20260131212128.25548-1-ethantidmore06@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: remove thread wraper functions and add IS_ERR() checkSamasth Norway Ananda
The rtl8723b_start_thread() and rtl8723b_stop_thread() functions are wrappers that are only called from one place each. Remove these wrapper functions and inline the thread handling directly in rtw_start_drv_threads() and rtw_stop_drv_threads(). This also fixes a bug where kthread_run() was not checked for errors using IS_ERR(). kthread_run() returns ERR_PTR(-ENOMEM) on failure, not NULL. Without this check, the SdioXmitThread pointer could contain an error value, causing issues when rtw_stop_drv_threads() later attempts to use it. The inlined code now follows the same pattern as xmitThread and cmdThread in rtw_start_drv_threads(), with proper IS_ERR() checking. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com> Link: https://patch.msgid.link/20260130001641.17941-4-samasth.norway.ananda@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: fix firmware memory leak on errorSamasth Norway Ananda
After successfully calling request_firmware(), if the firmware size check fails or if kmemdup() fails, the code jumps to the exit label without calling release_firmware(), causing a memory leak. Call release_firmware() directly in each error path before jumping to cleanup label. Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20260130001641.17941-2-samasth.norway.ananda@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: remove unnecessary parenthesesSiwanan Bungtong
Remove redundant parentheses around 'address of' expressions to comply with kernel coding style. Signed-off-by: Siwanan Bungtong <horstaufmental@gmail.com> Link: https://patch.msgid.link/20260129221719.943285-1-horstaufmental@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: remove redundant check on statusColin Ian King
The check on status can be removed because all previous assignments on status are followed by a goto statement that bypasses the status check. This minor issue was detected with Coverity Scan static analysis. Remove the redundant check and some empty lines. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20260129161058.197372-1-colin.i.king@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: standardize comment style in HALMahad Ibrahim
The kernel coding style for comments requires a single space after the "/*". Currently, many files in HAL contain two spaces after the "/*", or use irregular indentation. The modified files also suffer from this. Fix line comment style inconsistencies by removing additional space after "/*" to adhere to kernel coding standards. Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com> Link: https://patch.msgid.link/20260129160426.13737-6-mahad.ibrahim.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: fix line length checkMahad Ibrahim
Fix checkpatch.pl check regarding: - Line length of X exceeds 100 columns Redistribute comments to multiple lines to adhere to kernel coding standards. Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com> Link: https://patch.msgid.link/20260129160426.13737-5-mahad.ibrahim.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: fix missing blank line after declarationMahad Ibrahim
Fix checkpatch.pl warning regarding: - Missing a blank line after declarations Adhere to kernel coding standards by adding a blank line after variable declaration. Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com> Link: https://patch.msgid.link/20260129160426.13737-4-mahad.ibrahim.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: fix multiple blank line checkMahad Ibrahim
Fix checkpatch.pl check regarding: - Please don't use multiple blank lines Remove multiple blank lines to adhere to kernel coding standards. Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com> Link: https://patch.msgid.link/20260129160426.13737-3-mahad.ibrahim.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: fix open parenthesis alignmentMahad Ibrahim
Fix checkpatch.pl check regarding: - Lines should not end with a '(' Collapse the multi-line function signature of CheckPositive() into a single line to adhere to kernel coding standards. Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com> Link: https://patch.msgid.link/20260129160426.13737-2-mahad.ibrahim.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: most: video: fix potential race in list iterationMinu Jin
There is a pattern in the loops where the lock is dropped to call a specific function and then re-acquired. The list can be exposed during this short gap, creating a potential race condition. This patch fixes the problem by replacing the list head with a local free list using list_replace_init(), instead of using the lock/unlock pattern in the loop. Signed-off-by: Minu Jin <s9430939@naver.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20260205021620.1165137-1-s9430939@naver.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: constify _action_public_str arrayTanjim Kamal
This array is never modified. Add a second const to make the array itself be placed in read-only .rodata instead of just the strings it points to. Fix a WARNING issued by scripts/checkpatch.pl. Signed-off-by: Tanjim Kamal <tanjimkamal1@gmail.com> Reviewed-by: Ethan Tidmore <ethantidmore06@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20260128113900.44852-1-tanjimkamal1@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: remove unnecessary bracesLouis Lesniak
Remove braces from single statement if blocks to adhere to the Linux kernel coding style. Signed-off-by: Louis Lesniak <louis.lesniak2@gmail.com> Link: https://patch.msgid.link/20260128154407.42421-1-louis.lesniak2@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: clean up _rtw_pktfile_read()Minu Jin
Clean up the function by changing 'uint' to 'unsigned int' to comply with the kernel coding style, as suggested by Andy Shevchenko. Signed-off-by: Minu Jin <s9430939@naver.com> Link: https://patch.msgid.link/20260127153811.1592900-3-s9430939@naver.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-07staging: rtl8723bs: update _rtw_pktfile_read() to return error codesMinu Jin
The function _rtw_pktfile_read() currently returns a uint and clamps the requested read length if it exceeds the remaining data. This behavior makes it impossible to propagate error codes from internal calls like skb_copy_bits() and leads to incomplete data processing. This patch updates the function to: 1. Return -EINVAL if the remaining data is less than the requested length, ensuring callers always get the full amount of data they expect. 2. Propagate the negative error code from skb_copy_bits(). 3. Change the return type from uint to int to support these error codes. To avoid breaking git bisect, this patch also updates all call sites (set_qos, update_attrib, and rtw_xmitframe_coalesce) in the same commit. By doing so, the error-producing function and its error-handling callers remain in sync, preventing runtime failures at this commit point. Signed-off-by: Minu Jin <s9430939@naver.com> Link: https://patch.msgid.link/20260127153811.1592900-2-s9430939@naver.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-06nfc: nxp-nci: remove interrupt trigger typeCarl Lee
For NXP NCI devices (e.g. PN7150), the interrupt is level-triggered and active high, not edge-triggered. Using IRQF_TRIGGER_RISING in the driver can cause interrupts to fail to trigger correctly. Remove IRQF_TRIGGER_RISING and rely on the IRQ trigger type configured via Device Tree. Signed-off-by: Carl Lee <carl.lee@amd.com> Link: https://patch.msgid.link/20260205-fc-nxp-nci-remove-interrupt-trigger-type-v2-1-79d2ed4a7e42@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net: hns3: fix double free issue for tx spare bufferJian Shen
In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers. Fixes: 907676b130711 ("net: hns3: use tx bounce buffer for small packets") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260205121719.3285730-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06Merge branch 'big-tcp-without-hbh-in-ipv6'Jakub Kicinski
Alice Mikityanska says: ==================== BIG TCP without HBH in IPv6 Resubmitting after the grace period. This series is part 1 of "BIG TCP for UDP tunnels". Due to the number of patches, I'm splitting it into two logical parts: * Remove hop-by-hop header for BIG TCP IPv6 to align with BIG TCP IPv4. * Fix up things that prevent BIG TCP from working with UDP tunnels. The current BIG TCP IPv6 code inserts a hop-by-hop extension header with 32-bit length of the packet. When the packet is encapsulated, and either the outer or the inner protocol is IPv6, or both are IPv6, there will be 1 or 2 HBH headers that need to be dealt with. The issues that arise: 1. The drivers don't strip it, and they'd all need to know the structure of each tunnel protocol in order to strip it correctly, also taking into account all combinations of IPv4/IPv6 inner/outer protocols. 2. Even if (1) is implemented, it would be an additional performance penalty per aggregated packet. 3. The skb_gso_validate_network_len check is skipped in ip6_finish_output_gso when IP6SKB_FAKEJUMBO is set, but it seems that it would make sense to do the actual validation, just taking into account the length of the HBH header. When the support for tunnels is added, it becomes trickier, because there may be one or two HBH headers, depending on whether it's IPv6 in IPv6 or not. At the same time, having an HBH header to store the 32-bit length is not strictly necessary, as BIG TCP IPv4 doesn't do anything like this and just restores the length from skb->len. The same thing can be done for BIG TCP IPv6. Removing HBH from BIG TCP would allow to simplify the implementation significantly, and align it with BIG TCP IPv4, which has been a long-standing goal. ==================== Link: https://patch.msgid.link/20260205133925.526371-1-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net/ipv6: Remove HBH helpersAlice Mikityanska
Now that the HBH jumbo helpers are not used by any driver or GSO, remove them altogether. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-13-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06bng_en: Remove jumbo_remove step from TX pathAlice Mikityanska
Now that the kernel doesn't insert HBH for BIG TCP IPv6 packets, remove unnecessary steps from the bng_en TX path, that used to check and remove HBH. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Link: https://patch.msgid.link/20260205133925.526371-12-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net: mana: Remove jumbo_remove step from TX pathAlice Mikityanska
Now that the kernel doesn't insert HBH for BIG TCP IPv6 packets, remove unnecessary steps from the mana TX path, that used to check and remove HBH. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-11-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06gve: Remove jumbo_remove step from TX pathAlice Mikityanska
Now that the kernel doesn't insert HBH for BIG TCP IPv6 packets, remove unnecessary steps from the gve TX path, that used to check and remove HBH. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-10-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06bnxt_en: Remove jumbo_remove step from TX pathAlice Mikityanska
Now that the kernel doesn't insert HBH for BIG TCP IPv6 packets, remove unnecessary steps from the bnxt_en TX path, that used to check and remove HBH. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260205133925.526371-9-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06ice: Remove jumbo_remove step from TX pathAlice Mikityanska
Now that the kernel doesn't insert HBH for BIG TCP IPv6 packets, remove unnecessary steps from the ice TX path, that used to check and remove HBH. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-8-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net/mlx4: Remove jumbo_remove step from TX pathAlice Mikityanska
Now that the kernel doesn't insert HBH for BIG TCP IPv6 packets, remove unnecessary steps from the mlx4 TX path, that used to check and remove HBH. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-7-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net/mlx5e: Remove jumbo_remove step from TX pathAlice Mikityanska
Now that the kernel doesn't insert HBH for BIG TCP IPv6 packets, remove unnecessary steps from the mlx5e and mlx5i TX path, that used to check and remove HBH. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-6-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net/ipv6: Remove jumbo_remove step from TX pathAlice Mikityanska
Now that the kernel doesn't insert HBH for BIG TCP IPv6 packets, remove unnecessary steps from the GSO TX path, that used to check and remove HBH. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-5-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net/ipv6: Drop HBH for BIG TCP on RX sideAlice Mikityanska
Complementary to the previous commit, stop inserting HBH when building BIG TCP GRO SKBs. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-4-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net/ipv6: Drop HBH for BIG TCP on TX sideAlice Mikityanska
BIG TCP IPv6 inserts a hop-by-hop extension header to indicate the real IPv6 payload length when it doesn't fit into the 16-bit field in the IPv6 header itself. While it helps tools parse the packet, it also requires every driver that supports TSO and BIG TCP to remove this 8-byte extension header. It might not sound that bad until we try to apply it to tunneled traffic. Currently, the drivers don't attempt to strip HBH if skb->encapsulation = 1. Moreover, trying to do so would require dissecting different tunnel protocols and making corresponding adjustments on case-by-case basis, which would slow down the fastpath (potentially also requiring adjusting checksums in outer headers). At the same time, BIG TCP IPv4 doesn't insert any extra headers and just calculates the payload length from skb->len, significantly simplifying implementing BIG TCP for tunnels. Stop inserting HBH when building BIG TCP GSO SKBs. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-3-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net/ipv6: Introduce payload_len helpersAlice Mikityanska
The next commits will transition away from using the hop-by-hop extension header to encode packet length for BIG TCP. Add wrappers around ip6->payload_len that return the actual value if it's non-zero, and calculate it from skb->len if payload_len is set to zero (and a symmetrical setter). The new helpers are used wherever the surrounding code supports the hop-by-hop jumbo header for BIG TCP IPv6, or the corresponding IPv4 code uses skb_ip_totlen (e.g., in include/net/netfilter/nf_tables_ipv6.h). No behavioral change in this commit. Signed-off-by: Alice Mikityanska <alice@isovalent.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260205133925.526371-2-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06Merge branch ↵Jakub Kicinski
'dpll-zl3073x-include-current-frequency-in-supported-frequencies-list' Ivan Vecera says: ==================== dpll: zl3073x: Include current frequency in supported frequencies list This series ensures that the current operating frequency of a DPLL pin is always reported in its supported frequencies list. Problem: When a ZL3073x DPLL pin is registered, its supported frequencies are read from the firmware node's "supported-frequencies-hz" property. However, if the firmware node is missing, or doesn't include the current operating frequency, the pin reports a frequency that isn't in its supported list. This inconsistency can confuse userspace tools that expect the current frequency to be among the supported values. Solution: Always include the current pin frequency as the first entry in the supported frequencies list, followed by any additional frequencies from the firmware node (with duplicates filtered out). Patch 1 refactors the output pin frequency calculation into a reusable helper function zl3073x_dev_output_pin_freq_get(), which mirrors the existing zl3073x_dev_ref_freq_get() for input pins. Patch 2 modifies zl3073x_pin_props_get() to obtain the current frequency early and place it at index 0 of the supported frequencies array, ensuring it is always present regardless of firmware node contents. ==================== Link: https://patch.msgid.link/20260205154350.3180465-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06dpll: zl3073x: Include current frequency in supported frequencies listIvan Vecera
Ensure the current pin frequency is always present in the list of supported frequencies reported to userspace. Previously, if the firmware node was missing or didn't include the current operating frequency in the supported-frequencies-hz property, the pin would report a frequency that wasn't in its supported list. Get the current frequency early in zl3073x_pin_props_get(): - For input pins: use zl3073x_dev_ref_freq_get() - For output pins: use zl3073x_dev_output_pin_freq_get() Place the current frequency at index 0 of the supported frequencies array, then append frequencies from the firmware node (if present), skipping any duplicate of the current frequency. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260205154350.3180465-3-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06dpll: zl3073x: Add output pin frequency helperIvan Vecera
Introduce zl3073x_dev_output_pin_freq_get() helper function to compute the output pin frequency based on synthesizer frequency, output divisor, and signal format. For N-div signal formats, the N-pin frequency is additionally divided by esync_n_period. Add zl3073x_out_is_ndiv() helper to check if an output is configured in N-div mode (2_NDIV or 2_NDIV_INV signal formats). Refactor zl3073x_dpll_output_pin_frequency_get() callback to use the new helper, reducing code duplication and enabling reuse of the frequency calculation logic in other contexts. This is a preparatory change for adding current frequency to the supported frequencies list in pin properties. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260205154350.3180465-2-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06dpll: zl3073x: Fix output pin phase adjustment signIvan Vecera
The output pin phase adjustment functions incorrectly negate the phase compensation value. Per the ZL3073x datasheet, the output phase compensation register is simply a signed two's complement integer where: - Positive values move the phase later in time - Negative values move the phase earlier in time No negation is required. The erroneous negation caused phase adjustments to be applied in the wrong direction. Note that input pin phase adjustment correctly uses negation because the hardware has an inverted convention for input references (positive moves phase earlier, negative moves phase later). Fixes: 6287262f761e ("dpll: zl3073x: Add support to adjust phase") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260205181055.129768-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06Merge branch 'mptcp-misc-fixes-for-v6-19-rc8'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: misc fixes for v6.19-rc8 Here are various unrelated fixes: - Patch 1: when removing an MPTCP in-kernel PM endpoint, always mark the corresponding ID as "available". Syzbot found a corner case where it is not marked as such. A fix for up to v5.10. - Patch 2: Linked to the previous patch, the variable name was confusing and was probably partly responsible for the issue fixed by patch 1. No "Fixes" tag: no need to backport that for the moment, but better to avoid confusion now. - Patch 3: fix all existing kdoc warnings linked to MPTCP code. No "Fixes" tag: they were there for a while, and not considered as important to backport. - Patch 4: silence a compiler (false-positive) warning in the selftests. No "Fixes" tag: it is a false-positive warning, only seen with some versions. ==================== Link: https://patch.msgid.link/20260205-net-mptcp-misc-fixes-6-19-rc8-v2-0-c2720ce75c34@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06selftests: mptcp: connect: fix maybe-uninitialize warnMatthieu Baerts (NGI0)
This warning can be seen with GCC 15.2: mptcp_connect.c: In function ‘main_loop’: mptcp_connect.c:1422:37: warning: ‘peer’ may be used uninitialized [-Wmaybe-uninitialized] 1422 | if (connect(fd, peer->ai_addr, peer->ai_addrlen)) | ~~~~^~~~~~~~~ mptcp_connect.c:1377:26: note: ‘peer’ was declared here 1377 | struct addrinfo *peer; | ^~~~ This variable is set in sock_connect_mptcp() in some conditions. If not, this helper returns an error, and the program stops. So this is a false positive, but better removing it by initialising peer to NULL. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260205-net-mptcp-misc-fixes-6-19-rc8-v2-4-c2720ce75c34@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06mptcp: fix kdoc warningsMatthieu Baerts (NGI0)
The following warnings were visible: $ ./scripts/kernel-doc -Wall -none \ net/mptcp/ include/net/mptcp.h include/uapi/linux/mptcp*.h \ include/trace/events/mptcp.h Warning: net/mptcp/token.c:108 No description found for return value of 'mptcp_token_new_request' Warning: net/mptcp/token.c:151 No description found for return value of 'mptcp_token_new_connect' Warning: net/mptcp/token.c:246 No description found for return value of 'mptcp_token_get_sock' Warning: net/mptcp/token.c:298 No description found for return value of 'mptcp_token_iter_next' Warning: net/mptcp/protocol.c:4431 No description found for return value of 'mptcp_splice_read' Warning: include/uapi/linux/mptcp_pm.h:13 missing initial short description on line: * enum mptcp_event_type Address all of them: either by using the 'Return:' keyword, or by adding a missing initial short description. The MPTCP CI will soon report issues with kdoc to avoid introducing new issues and being flagged by the Netdev CI. Reviewed-by: Geliang Tang <geliang@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260205-net-mptcp-misc-fixes-6-19-rc8-v2-3-c2720ce75c34@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06mptcp: pm: in-kernel: clarify mptcp_pm_remove_anno_addr()Matthieu Baerts (NGI0)
The variable 'ret' was used, but it was not cleared what it was, and probably led to an issue [1]. Rename it to 'announced' to avoid confusions. While at it, remove the returned value of the helper: it is only used in one place, and the returned value is not used. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/606 [1] Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260205-net-mptcp-misc-fixes-6-19-rc8-v2-2-c2720ce75c34@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06mptcp: pm: in-kernel: always set ID as avail when rm endpMatthieu Baerts (NGI0)
Syzkaller managed to find a combination of actions that was generating this warning: WARNING: net/mptcp/pm_kernel.c:1074 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538, CPU#1: syz.7.48/2535 Modules linked in: CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e676cf5 #17 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline] RIP: 0010:mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538 Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 89 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 <0f> 0b 90 e9 3d ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89 RSP: 0018:ffffc9001535b820 EFLAGS: 00010287 netdevsim0: tun_chr_ioctl cmd 1074025677 RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7 netdevsim0: linktype set to 823 RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800 FS: 00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000000 netlink: 'syz.3.50': attribute type 5 has an invalid length. CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 netlink: 1232 bytes leftover after parsing attributes in process `syz.3.50'. CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0 Call Trace: <TASK> mptcp_pm_set_flags net/mptcp/pm_netlink.c:277 [inline] mptcp_pm_nl_set_flags_doit+0x1d7/0x210 net/mptcp/pm_netlink.c:282 genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4ab/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:733 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2608 ___sys_sendmsg+0x2de/0x320 net/socket.c:2662 __sys_sendmsg net/socket.c:2694 [inline] __do_sys_sendmsg net/socket.c:2699 [inline] __se_sys_sendmsg net/socket.c:2697 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2697 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xed/0x360 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc6adb66f6d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 netlink: 'syz.5.51': attribute type 2 has an invalid length. R13: 00007fff25e91fe0 R14: 00007fc6ac5a7ce4 R15: 00007fff25e920d7 </TASK> The actions that caused that seem to be: - Create an MPTCP endpoint for address A without any flags - Create a new MPTCP connection from address A - Remove the MPTCP endpoint: the corresponding subflows will be removed - Recreate the endpoint with the same ID, but with the subflow flag - Change the same endpoint to add the fullmesh flag In this case, msk->pm.local_addr_used has been kept to 0 as expected, but the corresponding bit in msk->pm.id_avail_bitmap was still unset after having removed the endpoint, causing the splat later on. When removing an endpoint, the corresponding endpoint ID was only marked as available for "signal" types with an announced address, plus all "subflow" types, but not the other types like an endpoint corresponding to the initial subflow. In these cases, re-creating an endpoint with the same ID didn't signal/create anything. Here, adding the fullmesh flag was creating the splat when calling __mark_subflow_endp_available() from mptcp_pm_nl_fullmesh(), because msk->pm.local_addr_used was set to 0 while the ID was marked as used. To fix this issue, the corresponding bit in msk->pm.id_avail_bitmap can always be set as available when removing an MPTCP in-kernel endpoint. In other words, moving the call to __set_bit() to do it in all cases, except for "subflow" types where this bit is handled in a dedicated helper. Note: instead of adding a new spin_(un)lock_bh that would be taken in all cases, do all the actions requiring the spin lock under the same block. This modification potentially fixes another issue reported by syzbot, see [1]. But without a reproducer or more details about what exactly happened before, it is hard to confirm. Fixes: e255683c06df ("mptcp: pm: re-using ID of unused removed ADD_ADDR") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/606 Reported-by: syzbot+f56f7d56e2c6e11a01b6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/68fcfc4a.050a0220.346f24.02fb.GAE@google.com [1] Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260205-net-mptcp-misc-fixes-6-19-rc8-v2-1-c2720ce75c34@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06ipv6: do not use skb_header_pointer() in icmpv6_filter()Eric Dumazet
Prefer pskb_may_pull() to avoid a stack canary in raw6_local_deliver(). Note: skb->head can change, hence we reload ip6h pointer in ipv6_raw_deliver() $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-86 (-86) Function old new delta raw6_local_deliver 780 694 -86 Total: Before=24889784, After=24889698, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260205211909.4115285-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06net: ti: icssg: Remove dedicated workqueue for ndo_set_rx_mode callbackKevin Hao
Currently, both the icssg-prueth and icssg-prueth-sr1 drivers create a dedicated 'emac->cmd_wq' workqueue. In the icssg-prueth-sr1 driver, this workqueue is not utilized at all. In the icssg-prueth driver, the workqueue is only used to execute the actual processing of ndo_set_rx_mode. However, creating a dedicated workqueue for such a simple use case is unnecessary. To simplify the code, switch to using the system default workqueue instead. Signed-off-by: Kevin Hao <haokexin@gmail.com> Tested-by: Meghana Malladi <m-malladi@ti.com> Reviewed-by: MD Danish Anwar <danishanwar@ti.com> Link: https://patch.msgid.link/20260205-icssg-prueth-workqueue-v2-1-cf5cf97efb37@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06tcp: inline tcp_filter()Eric Dumazet
This helper is already (auto)inlined from IPv4 TCP stack. Make it an inline function to benefit IPv6 as well. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/2 grow/shrink: 1/0 up/down: 30/-49 (-19) Function old new delta tcp_v6_rcv 3448 3478 +30 __pfx_tcp_filter 16 - -16 tcp_filter 33 - -33 Total: Before=24891904, After=24891885, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260205164329.3401481-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-06myri10ge: avoid uninitialized variable useArnd Bergmann
While compile testing on less common architectures, I noticed that gcc-10 on s390 finds a bug that all other configurations seem to miss: drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_set_multicast_list': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:391:25: error: 'cmd.data0' is used uninitialized in this function [-Werror=uninitialized] 391 | buf->data0 = htonl(data->data0); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:25: error: '*((void *)&cmd+4)' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_allocate_rings': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:13: error: 'cmd.data1' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data1' was declared here 1939 | struct myri10ge_cmd cmd; | ^~~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:393:13: error: 'cmd.data2' is used uninitialized in this function [-Werror=uninitialized] 393 | buf->data2 = htonl(data->data2); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data2' was declared here 1939 | struct myri10ge_cmd cmd; It would be nice to understand how to make other compilers catch this as well, but for the moment I'll just shut up the warning by fixing the undefined behavior in this driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260205162935.2126442-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>