summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-01drm/i915/cx0: Move the HDMI FRL function to intel_hdmiSuraj Kandpal
Move the is_hdmi_frl to intel_hdmi.c. Rename it appropriately and make it non static. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patch.msgid.link/20251101032513.4171255-5-suraj.kandpal@intel.com
2025-11-01drm/i915/ltphy: Phy lane reset for LT PhySuraj Kandpal
Define function to bring phy lane out of reset for LT Phy and the corresponding pre-requisite steps before we follow the steps for Phy lane reset. Also create a skeleton of LT PHY PLL enable sequence function in which we can place this function Bspec: 77449, 74749, 74499, 74495, 68960 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patch.msgid.link/20251101032513.4171255-4-suraj.kandpal@intel.com
2025-11-01drm/i915/cx0: Change register bit naming for powerdown valuesSuraj Kandpal
Change the register bit naming for powerdown values from CX0 to XELPDP so that it can be used with LT Phy too. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patch.msgid.link/20251101032513.4171255-3-suraj.kandpal@intel.com
2025-11-01drm/i915/ltphy: Add LT Phy related VDR and Pipe RegistersSuraj Kandpal
Add LT Phy related VDR and pipe registers into its own new file. Bspec: 74500 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patch.msgid.link/20251101032513.4171255-2-suraj.kandpal@intel.com
2025-10-31Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfLinus Torvalds
Pull bpf fixes from Alexei Starovoitov: - Mark migrate_disable/enable() as always_inline to avoid issues with partial inlining (Yonghong Song) - Fix powerpc stack register definition in libbpf bpf_tracing.h (Andrii Nakryiko) - Reject negative head_room in __bpf_skb_change_head (Daniel Borkmann) - Conditionally include dynptr copy kfuncs (Malin Jonsson) - Sync pending IRQ work before freeing BPF ring buffer (Noorain Eqbal) - Do not audit capability check in x86 do_jit() (Ondrej Mosnacek) - Fix arm64 JIT of BPF_ST insn when it writes into arena memory (Puranjay Mohan) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf/arm64: Fix BPF_ST into arena memory bpf: Make migrate_disable always inline to avoid partial inlining bpf: Reject negative head_room in __bpf_skb_change_head bpf: Conditionally include dynptr copy kfuncs libbpf: Fix powerpc's stack register definition in bpf_tracing.h bpf: Do not audit capability check in do_jit() bpf: Sync pending IRQ work before freeing ring buffer
2025-10-31Documentation: ARCnet: Update obsolete contact infoBagas Sanjaya
ARCnet docs states that inquiries on the subsystem should be emailed to Avery Pennarun <apenwarr@worldvisions.ca>, for whom has been in CREDITS since the beginning of kernel git history and her email address is unreachable (bounce). The subsystem is now maintained by Michael Grzeschik since c38f6ac74c9980 ("MAINTAINERS: add arcnet and take maintainership"). In addition, there used to be a dedicated ARCnet mailing list but its archive at epistolary.org has been shut down. ARCnet discussion nowadays take place in netdev list. The arcnet.com domain mentioned has become AIoT (Artificial Intelligence of Things) related Typeform page and ARCnet info now resides on arcnet.cc (ARCnet Resource Center) instead. Update contact information. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251028014451.10521-2-bagasdotme@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31Merge branch 'dpll-add-support-for-phase-adjustment-granularity'Jakub Kicinski
Ivan Vecera says: ==================== dpll: Add support for phase adjustment granularity Phase-adjust values are currently limited only by a min-max range. Some hardware requires, for certain pin types, that values be multiples of a specific granularity, as in the zl3073x driver. Patch 1: Adds 'phase-adjust-gran' pin attribute and an appropriate handling Patch 2: Adds a support for this attribute into zl3073x driver ==================== Link: https://patch.msgid.link/20251029153207.178448-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31dpll: zl3073x: Specify phase adjustment granularity for pinsIvan Vecera
Output pins phase adjustment values in the device are expressed in half synth clock cycles. Use this number of cycles as output pins' phase adjust granularity and simplify both get/set callbacks. Reviewed-by: Michal Schmidt <mschmidt@redhat.com> Reviewed-by: Petr Oros <poros@redhat.com> Tested-by: Prathosh Satish <Prathosh.Satish@microchip.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20251029153207.178448-3-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31dpll: add phase-adjust-gran pin attributeIvan Vecera
Phase-adjust values are currently limited by a min-max range. Some hardware requires, for certain pin types, that values be multiples of a specific granularity, as in the zl3073x driver. Add a `phase-adjust-gran` pin attribute and an appropriate field in dpll_pin_properties. If set by the driver, use its value to validate user-provided phase-adjust values. Reviewed-by: Michal Schmidt <mschmidt@redhat.com> Reviewed-by: Petr Oros <poros@redhat.com> Tested-by: Prathosh Satish <Prathosh.Satish@microchip.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20251029153207.178448-2-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31Merge branch 'net-pse-pd-add-tps23881b-support'Jakub Kicinski
Thomas Wismer says: ==================== net: pse-pd: Add TPS23881B support This patch series aims at adding support for the TI TPS23881B PoE PSE controller. ==================== Link: https://patch.msgid.link/20251029212312.108749-1-thomas@wismer.xyz Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31dt-bindings: pse-pd: ti,tps23881: Add TPS23881BThomas Wismer
Add the TPS23881B I2C power sourcing equipment controller to the list of supported devices. Falling back to the TPS23881 predecessor device is not suitable as firmware loading needs to handled differently by the driver. The TPS23881 and TPS23881B devices require different firmware. Trying to load the TPS23881 firmware on a TPS23881B device fails and must therefore be omitted. Signed-off-by: Thomas Wismer <thomas.wismer@scs.ch> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20251029212312.108749-3-thomas@wismer.xyz Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net: pse-pd: tps23881: Add support for TPS23881BThomas Wismer
The TPS23881B uses different firmware than the TPS23881. Trying to load the TPS23881 firmware on a TPS23881B device fails and must be omitted. The TPS23881B ships with a more recent ROM firmware. Moreover, no updated firmware has been released yet and so the firmware loading step must be skipped. As of today, the TPS23881B is intended to use its ROM firmware. Signed-off-by: Thomas Wismer <thomas.wismer@scs.ch> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20251029212312.108749-2-thomas@wismer.xyz Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31netconsole: Acquire su_mutex before navigating configs hierarchyGustavo Luiz Duarte
There is a race between operations that iterate over the userdata cg_children list and concurrent add/remove of userdata items through configfs. The update_userdata() function iterates over the nt->userdata_group.cg_children list, and count_extradata_entries() also iterates over this same list to count nodes. Quoting from Documentation/filesystems/configfs.rst: > A subsystem can navigate the cg_children list and the ci_parent pointer > to see the tree created by the subsystem. This can race with configfs' > management of the hierarchy, so configfs uses the subsystem mutex to > protect modifications. Whenever a subsystem wants to navigate the > hierarchy, it must do so under the protection of the subsystem > mutex. Without proper locking, if a userdata item is added or removed concurrently while these functions are iterating, the list can be accessed in an inconsistent state. For example, the list_for_each() loop can reach a node that is being removed from the list by list_del_init() which sets the nodes' .next pointer to point to itself, so the loop will never end (or reach the WARN_ON_ONCE in update_userdata() ). Fix this by holding the configfs subsystem mutex (su_mutex) during all operations that iterate over cg_children. This includes: - userdatum_value_store() which calls update_userdata() to iterate over cg_children - All sysdata_*_enabled_store() functions which call count_extradata_entries() to iterate over cg_children The su_mutex must be acquired before dynamic_netconsole_mutex to avoid potential lock ordering issues, as configfs operations may already hold su_mutex when calling into our code. Fixes: df03f830d099 ("net: netconsole: cache userdata formatted string in netconsole_target") Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com> Link: https://patch.msgid.link/20251029-netconsole-fix-warn-v1-1-0d0dd4622f48@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net: vlan: sync VLAN features with lower deviceHangbin Liu
After registering a VLAN device and setting its feature flags, we need to synchronize the VLAN features with the lower device. For example, the VLAN device does not have the NETIF_F_LRO flag, it should be synchronized with the lower device based on the NETIF_F_UPPER_DISABLES definition. As the dev->vlan_features has changed, we need to call netdev_update_features(). The caller must run after netdev_upper_dev_link() links the lower devices, so this patch adds the netdev_update_features() call in register_vlan_dev(). Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/20251030073539.133779-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31selftests: netdevsim: Fix ethtool-coalesce.sh fail by installing ↵Wang Liang
ethtool-common.sh The script "ethtool-common.sh" is not installed in INSTALL_PATH, and triggers some errors when I try to run the test 'drivers/net/netdevsim/ethtool-coalesce.sh': TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-coalesce.sh # ./ethtool-coalesce.sh: line 4: ethtool-common.sh: No such file or directory # ./ethtool-coalesce.sh: line 25: make_netdev: command not found # ethtool: bad command line argument(s) # ./ethtool-coalesce.sh: line 124: check: command not found # ./ethtool-coalesce.sh: line 126: [: -eq: unary operator expected # FAILED /0 checks not ok 1 selftests: drivers/net/netdevsim: ethtool-coalesce.sh # exit=1 Install this file to avoid this error. After this patch: TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-coalesce.sh # PASSED all 22 checks ok 1 selftests: drivers/net/netdevsim: ethtool-coalesce.sh Fixes: fbb8531e58bd ("selftests: extract common functions in ethtool-common.sh") Signed-off-by: Wang Liang <wangliang74@huawei.com> Link: https://patch.msgid.link/20251030040340.3258110-1-wangliang74@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()Abdun Nihaal
In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style. Compile tested only. Issue found using a prototype static analysis tool. Fixes: 69f52adb2d53 ("mISDN: Add HFC USB driver") Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Link: https://patch.msgid.link/20251030042524.194812-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31selftests/net: use destination options instead of hop-by-hopAnubhav Singh
The GRO self-test, gro.c, currently constructs IPv6 packets containing a Hop-by-Hop Options header (IPPROTO_HOPOPTS) to ensure the GRO path correctly handles IPv6 extension headers. However, network elements may be configured to drop packets with the Hop-by-Hop Options header (HBH). This causes the self-test to fail in environments where such network elements are present. To improve the robustness and reliability of this test in diverse network environments, switch from using IPPROTO_HOPOPTS to IPPROTO_DSTOPTS (Destination Options). The Destination Options header is less likely to be dropped by intermediate routers and still serves the core purpose of the test: validating GRO's handling of an IPv6 extension header. This change ensures the test can execute successfully without being incorrectly failed by network policies outside the kernel's control. Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test") Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Anubhav Singh <anubhavsinggh@google.com> Link: https://patch.msgid.link/20251030060436.1556664-1-anubhavsinggh@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31selftests/net: fix out-of-order delivery of FIN in gro:tcp testAnubhav Singh
Due to the gro_sender sending data packets and FIN packets in very quick succession, these are received almost simultaneously by the gro_receiver. FIN packets are sometimes processed before the data packets leading to intermittent (~1/100) test failures. This change adds a delay of 100ms before sending FIN packets in gro:tcp test to avoid the out-of-order delivery. The same mitigation already exists for the gro:ip test. Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test") Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Anubhav Singh <anubhavsinggh@google.com> Link: https://patch.msgid.link/20251030062818.1562228-1-anubhavsinggh@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31Documentation: netconsole: Separate literal code blocks for full and short ↵Bagas Sanjaya
netcat command name versions Both full and short (abbreviated) command name versions of netcat example are combined in single literal code block due to 'or::' paragraph being indented one more space than the preceding paragraph (before the short version example). Unindent it to separate the versions. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251030075013.40418-1-bagasdotme@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31Merge branch 'net-phy-microchip_t1s-add-support-for-lan867x-rev-d0-phy'Jakub Kicinski
Parthiban Veerasooran says: ==================== net: phy: microchip_t1s: Add support for LAN867x Rev.D0 PHY This patch series adds support for the latest Microchip LAN8670/1/2 Rev.D0 10BASE-T1S PHYs to the microchip_t1s driver. The new Rev.D0 silicon introduces updated initialization requirements and link status handling behavior compared to earlier revisions (Rev.C2 and below). These updates are necessary for full compliance with the OPEN Alliance 10BASE-T1S specification and are documented in Microchip Application Note AN1699 Revision G (DS60001699G – October 2025). Summary of changes: - Implements Rev.D0-specific configuration sequence as described in AN1699 Rev.G. - Introduces link status control configuration for LAN867x Rev.D0. ==================== Link: https://patch.msgid.link/20251030102258.180061-1-parthiban.veerasooran@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net: phy: microchip_t1s: configure link status control for LAN867x Rev.D0Parthiban Veerasooran
Configure the link status in the Link Status Control register for LAN8670/1/2 Rev.D0 PHYs, depending on whether PLCA or CSMA/CD mode is enabled. When PLCA is enabled, the link status reflects the PLCA status. When PLCA is disabled (CSMA/CD mode), the PHY does not support autonegotiation, so the link status is forced active by setting the LINK_STATUS_SEMAPHORE bit. The link status control is configured: - During PHY initialization, for default CSMA/CD mode. - Whenever PLCA configuration is updated. This ensures correct link reporting and consistent behavior for LAN867x Rev.D0 devices. Signed-off-by: Parthiban Veerasooran <parthiban.veerasooran@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251030102258.180061-3-parthiban.veerasooran@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net: phy: microchip_t1s: add support for Microchip LAN867X Rev.D0 PHYParthiban Veerasooran
Add support for the LAN8670/1/2 Rev.D0 10BASE-T1S PHYs from Microchip. The new Rev.D0 silicon requires a specific set of initialization settings to be configured for optimal performance and compliance with OPEN Alliance specifications, as described in Microchip Application Note AN1699 (Revision G, DS60001699G – October 2025). https://www.microchip.com/en-us/application-notes/an1699 Signed-off-by: Parthiban Veerasooran <parthiban.veerasooran@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251030102258.180061-2-parthiban.veerasooran@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net: stmmac: qcom-ethqos: remove MAC_CTRL_REG modificationRussell King (Oracle)
When operating in "SGMII" mode (Cisco SGMII or 2500BASE-X), qcom-ethqos modifies the MAC control register in its ethqos_configure_sgmii() function, which is only called from one path: stmmac_mac_link_up() +- reads MAC_CTRL_REG +- masks out priv->hw->link.speed_mask +- sets bits according to speed (2500, 1000, 100, 10) from priv->hw.link.speed* +- ethqos_fix_mac_speed() | +- qcom_ethqos_set_sgmii_loopback(false) | +- ethqos_update_link_clk(speed) | `- ethqos_configure(speed) | `- ethqos_configure_sgmii(speed) | +- reads MAC_CTRL_REG, | +- configures PS/FES bits according to speed | `- writes MAC_CTRL_REG as the last operation +- sets duplex bit(s) +- stmmac_mac_flow_ctrl() +- writes MAC_CTRL_REG if changed from original read ... As can be seen, the modification of the control register that stmmac_mac_link_up() overwrites the changes that ethqos_fix_mac_speed() does to the register. This makes ethqos_configure_sgmii()'s modification questionable at best. Analysing the values written, GMAC4 sets the speed bits as: speed_mask = GMAC_CONFIG_FES | GMAC_CONFIG_PS speed2500 = GMAC_CONFIG_FES B14=1 B15=0 speed1000 = 0 B14=0 B15=0 speed100 = GMAC_CONFIG_FES | GMAC_CONFIG_PS B14=1 B15=1 speed10 = GMAC_CONFIG_PS B14=0 B15=1 Whereas ethqos_configure_sgmii(): 2500: clears ETHQOS_MAC_CTRL_PORT_SEL B14=X B15=0 1000: clears ETHQOS_MAC_CTRL_PORT_SEL B14=X B15=0 100: sets ETHQOS_MAC_CTRL_PORT_SEL | B14=1 B15=1 ETHQOS_MAC_CTRL_SPEED_MODE 10: sets ETHQOS_MAC_CTRL_PORT_SEL B14=0 B15=1 clears ETHQOS_MAC_CTRL_SPEED_MODE Thus, they appear to be doing very similar, with the exception of the FES bit (bit 14) for 1G and 2.5G speeds. Given that stmmac_mac_link_up() will write the MAC_CTRL_REG after ethqos_configure_sgmii(), remove the unnecessary update in the glue driver's ethqos_configure_sgmii() method, simplifying the code. Konrad states: Without any additional knowledge, the register description says: 2500: B14=1 B15=0 1000: B14=0 B15=0 100: B14=1 B15=1 10: B14=0 B15=1 Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vEPlg-0000000CFHY-282A@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31Merge branch 'convert-mlx5e-and-ipoib-to-ndo_hwtstamp_get-set'Jakub Kicinski
Tariq Toukan says: ==================== Convert mlx5e and IPoIB to ndo_hwtstamp_get/set This series by Carolina migrates mlx5e and IPoIB to the ndo_hwtstamp_get/set interface and removes legacy hardware timestamp ioctl handling. While doing so, it also cleans up naming and removes redundant code. No functional change in timestamp behavior. Cleanup patches: - net/mlx5e: Remove redundant tstamp pointer from channel structures - net/mlx5e: Remove unnecessary tstamp local variable in mlx5i_complete_rx_cqe - net/mlx5e: Rename hwstamp functions to hwtstamp - net/mlx5e: Rename timestamp fields to hwtstamp_config Add suppport in ipoib: - IB/IPoIB: Add support for hwtstamp get/set ndos Convert mlx5: - net/mlx5e: Convert to new hwtstamp_get/set interface ==================== Link: https://patch.msgid.link/1761819910-1011051-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net/mlx5e: Convert to new hwtstamp_get/set interfaceCarolina Jubran
Migrate from the legacy ioctl hardware timestamping interface to the ndo_hwtstamp_get/set operations. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1761819910-1011051-7-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31IB/IPoIB: Add support for hwtstamp get/set ndosCarolina Jubran
Add support for the ndo_hwtstamp_get and ndo_hwtstamp_set operations in IPoIB. This allows lower devices to handle hardware timestamp configuration through the new ndos instead of the legacy ioctls. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1761819910-1011051-6-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net/mlx5e: Rename timestamp fields to hwtstamp_configCarolina Jubran
Rename hardware timestamp-related fields from 'tstamp' to 'hwtstamp_config' throughout the MLX5 driver. The new name is more descriptive as it clearly indicates these fields contain hardware timestamp configuration. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1761819910-1011051-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net/mlx5e: Rename hwstamp functions to hwtstampCarolina Jubran
Rename mlx5e_hwstamp_set/get() functions to mlx5e_hwtstamp_set/get() to better reflect that these functions handle hardware timestamping, not just hardware stamping. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1761819910-1011051-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net/mlx5e: Remove unnecessary tstamp local variable in mlx5i_complete_rx_cqeCarolina Jubran
Remove the tstamp local variable in mlx5i_complete_rx_cqe() and directly pass the tstamp field from priv to mlx5e_rx_hw_stamp(). The local variable was only used once and provided no additional value. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1761819910-1011051-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net/mlx5e: Remove redundant tstamp pointer from channel structuresCarolina Jubran
Remove the tstamp pointer field from mlx5e_channel, mlx5e_ptp, and mlx5e_trap structures, since it was only used to reference the tstamp field in the priv structure. Instead, directly use the tstamp field from priv when initializing RQ structures. Also remove the unused hwtstamp_config field from mlx5_clock structure as part of the cleanup. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1761819910-1011051-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net: dsa: tag_brcm: legacy: fix untagged rx on unbridged ports for bcm63xxJonas Gorski
The internal switch on BCM63XX SoCs will unconditionally add 802.1Q VLAN tags on egress to CPU when 802.1Q mode is enabled. We do this unconditionally since commit ed409f3bbaa5 ("net: dsa: b53: Configure VLANs while not filtering"). This is fine for VLAN aware bridges, but for standalone ports and vlan unaware bridges this means all packets are tagged with the default VID, which is 0. While the kernel will treat that like untagged, this can break userspace applications processing raw packets, expecting untagged traffic, like STP daemons. This also breaks several bridge tests, where the tcpdump output then does not match the expected output anymore. Since 0 isn't a valid VID, just strip out the VLAN tag if we encounter it, unless the priority field is set, since that would be a valid tag again. Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20251027194621.133301-1-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31ptp: Allow exposing cycles only for clocks with free-running counterCarolina Jubran
The PTP core falls back to gettimex64 and getcrosststamp when getcycles64 or getcyclesx64 are not implemented. This causes the CYCLES ioctls to retrieve PHC real time instead of free-running cycles. Reject PTP_SYS_OFFSET_{PRECISE,EXTENDED}_CYCLES for clocks without free-running counter support since the result would represent PHC real time and system time rather than cycles and system time. Fixes: faf23f54d366 ("ptp: Add ioctl commands to expose raw cycle counter values") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20251029083813.2276997-1-cjubran@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31net: mana: Support HW link state eventsHaiyang Zhang
Handle the NIC hardware link state events received from the HW channel, then set the proper link state accordingly. And, add a feature bit, GDMA_DRV_CAP_FLAG_1_HW_VPORT_LINK_AWARE, to inform the NIC hardware this handler exists. Our MANA NIC only sends out the link state down/up messages when we need to let the VM rerun DHCP client and change IP address. So, add netif_carrier_on() in the probe(), let the NIC show the right initial state in /sys/class/net/ethX/operstate. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/1761770601-16920-1-git-send-email-haiyangz@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31Merge branch 'gve-fix-null-dereferencing-with-ptp-clock'Jakub Kicinski
Tim Hostetler says: ==================== gve: Fix NULL dereferencing with PTP clock This patch series fixes NULL dereferences that are possible with gve's PTP clock due to not stubbing certain ptp_clock_info callbacks. ==================== Link: https://patch.msgid.link/20251029184555.3852952-1-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31gve: Implement settime64 with -EOPNOTSUPPTim Hostetler
ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. Fixes: acd16380523b ("gve: Add initial PTP device support") Reported-by: syzbot+a546141ca6d53b90aba3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a546141ca6d53b90aba3 Signed-off-by: Tim Hostetler <thostet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251029184555.3852952-3-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31gve: Implement gettimex64 with -EOPNOTSUPPTim Hostetler
gve implemented a ptp_clock for sole use of do_aux_work at this time. ptp_clock_gettime() and ptp_sys_offset() assume every ptp_clock has implemented either gettimex64 or gettime64. Stub gettimex64 and return -EOPNOTSUPP to prevent NULL dereferencing. Fixes: acd16380523b ("gve: Add initial PTP device support") Reported-by: syzbot+c8c0e7ccabd456541612@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c8c0e7ccabd456541612 Signed-off-by: Tim Hostetler <thostet@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251029184555.3852952-2-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-31arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2Diederik de Haas
Page 13 of the PineTab2 v2 schematic dd 20230417 shows VCCIO4's power source is VCCIO_WL. Page 19 shows that VCCIO_WL is connected to VCCA1V8_PMU, so fix the PineTab2 dtsi to reflect that. Fixes: 1b7e19448f8f ("arm64: dts: rockchip: Add devicetree for Pine64 PineTab2") Cc: stable@vger.kernel.org Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Diederik de Haas <diederik@cknow-tech.com> Link: https://patch.msgid.link/20251027155724.138096-1-diederik@cknow-tech.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-31arm64: dts: rockchip: include rk3399-base instead of rk3399 in rk3399-op1Quentin Schulz
In commit 296602b8e5f7 ("arm64: dts: rockchip: Move RK3399 OPPs to dtsi files for SoC variants"), everything shared between variants of RK3399 was put into rk3399-base.dtsi and the rest in variant-specific DTSI, such as rk3399-t, rk3399-op1, rk3399, etc. Therefore, the variant-specific DTSI should include rk3399-base.dtsi and not another variant's DTSI. rk3399-op1 wrongly includes rk3399 (a variant) DTSI instead of rk3399-base DTSI, let's fix this oversight by including the intended DTSI. Fortunately, this had no impact on the resulting DTB since all nodes were named the same and all node properties were overridden in rk3399-op1.dtsi. This was checked by doing a checksum of rk3399-op1 DTBs before and after this commit. No intended change in behavior. Fixes: 296602b8e5f7 ("arm64: dts: rockchip: Move RK3399 OPPs to dtsi files for SoC variants") Cc: stable@vger.kernel.org Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://patch.msgid.link/20251029-rk3399-op1-include-v1-1-2472ee60e7f8@cherry.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-31ARM: dts: rockchip: Add spi_flash label to rk3288-veyronJohan Jonker
The u-boot,spl-boot-order property requires a label at a boot device node. In order to migrate to OF_UPSTREAM more easier add a spi_flash label to the rk3288-veyron.dtsi file. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://patch.msgid.link/8a423a6f-bfdc-4947-aef9-35ee7c4f6ca2@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-31ARM: dts: rockchip: Remove mshc aliases from RK3288Johan Jonker
The use of mshc aliases is deprecated for some while, so remove them from the rk3288.dtsi file. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://patch.msgid.link/3e461bce-e8e6-48f1-a296-34040447ff25@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-31ARM: dts: rockchip: Adapt tps65910 nodes on RK3066 boardsJohan Jonker
The binding for tps65910 has been converted to yaml and instead of the deprecated regulator-compatible, the node-names are now used to identify the individual regulators. Also some additional required properties were added. Adapt the tps65910 nodes on Rockchip boards to adhere to the updated binding, which also allows us to drop the tps65910.dtsi include. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://patch.msgid.link/b3d05df4-a916-48e1-8d9e-590782806bd5@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-31selftests/bpf: Add checks in tc_tunnel when entering net namespacesAlexis Lothoré (eBPF Foundation)
test_tc_tunnel is missing checks on any open_netns. Add those checks anytime we try to enter a net namespace, and skip the related operations if we fail. While at it, reduce the number of open_netns/close_netns for cases involving operations in two distinct namespaces: the test currently does the following: nstoken = open_netns("foo") do_operation(); close(nstoken); nstoken = open_netns("bar") do_another_operation(); close(nstoken); As already stated in reviews for the initial test, we don't need to go back to the root net namespace to enter a second namespace, so just do: ntoken_client = open_netns("foo") do_operation(); nstoken_server = open_netns("bar") do_another_operation(); close(nstoken_server); close(nstoken_client); Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://patch.msgid.link/20251031-tc_tunnel_improv-v1-2-0ffe44d27eda@bootlin.com
2025-10-31selftests/bpf: Skip tc_tunnel subtest if its setup failsAlexis Lothoré (eBPF Foundation)
A subtest setup can fail in a wide variety of ways, so make sure not to run it if an issue occurs during its setup. The return value is already representing whether the setup succeeds or fails, it is just about wiring it. Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://patch.msgid.link/20251031-tc_tunnel_improv-v1-1-0ffe44d27eda@bootlin.com
2025-10-31x86/mm: Ensure clear_page() variants always have __kcfi_typeid_ symbolsNathan Chancellor
When building with CONFIG_CFI=y and CONFIG_LTO_CLANG_FULL=y, there is a series of errors from the various versions of clear_page() not having __kcfi_typeid_ symbols. $ cat kernel/configs/repro.config CONFIG_CFI=y # CONFIG_LTO_NONE is not set CONFIG_LTO_CLANG_FULL=y $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config bzImage ld.lld: error: undefined symbol: __kcfi_typeid_clear_page_rep >>> referenced by ld-temp.o >>> vmlinux.o:(__cfi_clear_page_rep) ld.lld: error: undefined symbol: __kcfi_typeid_clear_page_orig >>> referenced by ld-temp.o >>> vmlinux.o:(__cfi_clear_page_orig) ld.lld: error: undefined symbol: __kcfi_typeid_clear_page_erms >>> referenced by ld-temp.o >>> vmlinux.o:(__cfi_clear_page_erms) With full LTO, it is possible for LLVM to realize that these functions never have their address taken (as they are only used within an alternative, which will make them a direct call) across the whole kernel and either drop or skip generating their kCFI type identification symbols. clear_page_{rep,orig,erms}() are defined in clear_page_64.S with SYM_TYPED_FUNC_START as a result of 2981557cb040 ("x86,kcfi: Fix EXPORT_SYMBOL vs kCFI"), as exported functions are free to be called indirectly thus need kCFI type identifiers. Use KCFI_REFERENCE with these clear_page() functions to force LLVM to see these functions as address-taken and generate then keep the kCFI type identifiers. Fixes: 2981557cb040 ("x86,kcfi: Fix EXPORT_SYMBOL vs kCFI") Closes: https://github.com/ClangBuiltLinux/linux/issues/2128 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Link: https://patch.msgid.link/20251013-x86-fix-clear_page-cfi-full-lto-errors-v1-1-d69534c0be61@kernel.org
2025-10-31Merge tag 'drm-fixes-2025-10-31' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Simona Vetter: "Looks like stochastics conspired to make this one a bit bigger, but nothing scary at all. Also first examples of the new Link: tags, yay! Next week Dave should be back. Drivers: - mediatek: uaf in unbind, fixes -rc2 boot regression - radeon: devm conversion fixes - amdgpu: VPE idle handler, re-enable DM idle optimization, DCN3, SMU, vblank, HDP eDP, powerplay fixes for fiji/iceland - msm: bunch of gem error path fixes, gmu fw parsing fix, dpu fixes - intel: fix dmc/dc6 asserts on ADL-S - xe: fix xe_validation_guard(), wake device handling around gt reset - ast: fix display output on AST2300 - etnaviv: fix gpu flush - imx: fix parallel bridge handling - nouveau: scheduler locking fix - panel: fixes for kingdisplay-kd097d04 and sitronix-st7789v Core Changes: - CI: disable broken sanity job - sysfb: fix NULL pointer access - sched: fix SIGKILL handling, locking for race condition - dma_fence: better timeline name for signalled fences" * tag 'drm-fixes-2025-10-31' of https://gitlab.freedesktop.org/drm/kernel: (44 commits) drm/ast: Clear preserved bits from register output value drm/imx: parallel-display: add the bridge before attaching it drm/imx: parallel-display: convert to devm_drm_bridge_alloc() API drm/panel: kingdisplay-kd097d04: Disable EoTp drm/panel: sitronix-st7789v: fix sync flags for t28cp45tn89 drm/xe: Do not wake device during a GT reset drm/xe: Fix uninitialized return value from xe_validation_guard() drm/msm/dpu: Fix adjusted mode clock check for 3d merge drm/msm/dpu: Disable broken YUV on QSEED2 hardware drm/msm/dpu: Require linear modifier for writeback framebuffers drm/msm/dpu: Fix pixel extension sub-sampling drm/msm/dpu: Disable scaling for unsupported scaler types drm/msm/dpu: Propagate error from dpu_assign_plane_resources drm/msm/dpu: Fix allocation of RGB SSPPs without scaling drm/msm: dsi: fix PLL init in bonded mode drm/i915/dmc: Clear HRR EVT_CTL/HTP to zero on ADL-S drm/amd/display: Fix incorrect return of vblank enable on unconfigured crtc drm/amd/display: Add HDR workaround for a specific eDP drm/amdgpu: fix SPDX header on cyan_skillfish_reg_init.c drm/amdgpu: fix SPDX header on irqsrcs_vcn_5_0.h ...
2025-10-31genirq/proc: Fix race in show_irq_affinity()Muchun Song
Reading /proc/irq/N/smp_affinity* races with irq_set_affinity() and irq_move_masked_irq(), leading to old or torn output for users. After a user writes a new CPU mask to /proc/irq/N/affinity*, the syscall returns success, yet a subsequent read of the same file immediately returns a value different from what was just written. That's due to a race between show_irq_affinity() and irq_move_masked_irq() which lets the read observe a transient, inconsistent affinity mask. Cure it by guarding the read with irq_desc::lock. [ tglx: Massaged change log ] Signed-off-by: Muchun Song <songmuchun@bytedance.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251028090408.76331-1-songmuchun@bytedance.com
2025-10-31genirq: Fix percpu_devid irq affinity documentationMarc Zyngier
Stephen points out that some of the percpu_devid irq affinity documentation is either missing or not matching the data structures. Address all the issues in one go. Fixes: 87b0031f7f73 ("irqdomain: Add firmware info reporting interface") Fixes: 258e7d28a3dc ("genirq: Add affinity to percpu_devid interrupt requests") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251030143032.2035987-1-maz@kernel.org
2025-10-31Merge tag 'pci-v6.18-fixes-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fixes from Bjorn Helgaas: - Restore custom qcom ASPM enablement code so L1 PM Substates are enabled as they were in v6.17 even though the PCI core now enables just L0s and L1 by default (Bjorn Helgaas) - Size prefetchable bridge windows only when they actually exist, to avoid a WARN_ON() regression (Ilpo Järvinen) * tag 'pci-v6.18-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: Do not size non-existing prefetchable window Revert "PCI: qcom: Remove custom ASPM enablement code"
2025-10-31PCI: qcom: Use frequency and level based OPP lookupKrishna Chaitanya Chundru
PCIe link configurations such as 8GT/s x2 and 16GT/s x1 may operate at the same frequency, but differ in other characteristics like RPMh votes. But the existing OPP selection which is solely based on frequency (the 'opp-hz' DT property) cannot distinguish between such cases. Hence, use the newly introduced dev_pm_opp_find_key_exact() API to match both frequency and level (the 'opp-level' property) when selecting an OPP, here level indicates PCIe data rate. To support older device trees where opp-level is not defined, check if opp-level is present or not using dev_pm_opp_find_level_exact(). If not present fallback to frequency only match. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [mani: zero initialize dev_pm_opp_key struct] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: add 'opp-hz' and 'opp-level' in commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20251013-opp_pcie-v5-5-eb64db2b4bd3@oss.qualcomm.com
2025-10-31Merge tag 'vfio-v6.18-rc4' of https://github.com/awilliam/linux-vfioLinus Torvalds
Pull VFIO fixes from Alex Williamson: - Fix overflows in vfio type1 backend for mappings at the end of the 64-bit address space, resulting in leaked pinned memory. New selftest support included to avoid such issues in the future (Alex Mastro) * tag 'vfio-v6.18-rc4' of https://github.com/awilliam/linux-vfio: vfio: selftests: add end of address space DMA map/unmap tests vfio: selftests: update DMA map/unmap helpers to support more test kinds vfio/type1: handle DMA map/unmap up to the addressable limit vfio/type1: move iova increment to unmap_unpin_*() caller vfio/type1: sanitize for overflow using check_*_overflow()
generated by cgit v1.3 (git 2.53.0) at 2026-11-06 17:08:08 +0000