summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-26wifi: iwlwifi: mld: fix NAN max channel switch time unitIsrael Kozitz
The max_channel_switch_time in wiphy_nan_capa is in microseconds, but the value was set to 4, which is only 4 microseconds instead of the intended 4 milliseconds. Fix by using 4 * USEC_PER_MSEC. Signed-off-by: Israel Kozitz <israel.kozitz@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260510234534.cb3c05e5d334.I89d9f336aaf388c6e48769de5fe1e5db19295057@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: Do not declare NAN support for Extended Key IDIlan Peer
Do not declare support for Extended Key ID for NAN, as defined in section 7.4 in the WiFi Aware specification v4.0 (in order to support security association upgrade). Signed-off-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260510234534.42f0e92d0ee1.Ic3e47a926539a1d8f20103c40ebe5cfeaf671a96@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: Do not declare support for NDPEIlan Peer
Do not declare support for NAN Data Path Extension attribute as this is handled by user space and should be set by it. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260510234534.a76eb7235116.I160f1232e51711d5e2c063f0e1539ef71db50e1e@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: Fix number of antennas in NAN capabilitiesIlan Peer
Instead of hardcoding the number of supported antennas for Tx/Rx, set them according to hardware capabilities. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260510234534.26f8653d44a3.Ib8b9769e7a598b01f6285bd0782aa3bf13f144a2@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: extract NAN capabilities setting to a functionMiri Korenblit
There are now quite a lot of capabilities to set, so move it to a dedicated function, for better clarity. Link: https://patch.msgid.link/20260510234534.da1f380ced3b.I02013e9d5946a1b3372d2fcd570057fdb4416b65@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: use host rate for NAN management framesMiri Korenblit
Frames that are sent to an NMI station are always NAN management frames. Therefore there is no need to configure TLC for such a station. Always use host rate for the frames going to that station. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.fb7272ddbb45.I843dba36f52363bc7e9c81f937547ead12147539@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: add peer schedule supportJohannes Berg
Add support for NAN peer schedule configuration and update. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260510234534.ede42401c3ee.I8e483edd1e917dfa59901b520db595cea28906e3@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: implement NAN peer station managementJohannes Berg
Implement peer station management for NAN, i.e. support for adding, removing, and updating NMI and NDI stations. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260510234534.cbf6bac4744f.I3bd01266e47f24fb7f1240db62ac3bd47c479127@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: add NAN schedule command supportJohannes Berg
Add the NAN schedule command API definition and implementation of the schedule updates. Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.95fabd44a598.I7cbe877f3b13a44554d95e56b10d930dde4704c9@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: add NAN link managementJohannes Berg
The firmware requires links for NAN which mac80211 doesn't use, so introduce a new NAN link data structure that the driver has for itself only, and handle the link command sending code for NAN using this data structure, most of the bss_conf data isn't used for NAN anyway, so those structures aren't useful. With that, add, activate, deactivate or remove links depending on the local NAN schedule updates. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260510234534.39ee3533ef30.I81ff6dc02e912396040f922e21888fd94b3c26e6@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: support NAN and NAN_DATA interfacesJohannes Berg
Until now we maintained the NAN vif in the driver only. The fw used the AUX MAC for sync and discovery operations. But when we want to configure a local schedule, we need to add the MAC first. NAN_DATA interfaces are not added to the FW. Instead, the local address of these interfaces are configured to the FW via the NAN MAC. Add the add/remove/update operations for the NAN interface, and fill the NAN special parameters in it. Note that this doesn't fully implement the schedule change, but only the addition/removal of the NAN MAC. The full schedule management implementation will come in a later patch. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260510234534.dd12944c140b.I3578198660a533faf9f6a94432ef2114f4a9dfae@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: disable queue hang detection for NAN dataJohannes Berg
Since peers on NAN data might just use ULW and/or break the schedule, disable queue hang detection for them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.9886987db700.Ifd879478bc30af25de0eada6143dbc3e6a548068@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: tlc: separate from link STAJohannes Berg
While NAN stations have the deflink link STA and that even carries their information, having link STAs mostly implies having real links, and NAN muddies that by having stations with deflink carrying their capabilities and links at the NAN level, but no link stations corresponding to NAN links. Separate out the data needed to build TLC commands into a new struct iwl_mld_tlc_sta_capa data structure so that the whole data usage in the TLC code is clarified and we won't make assumptions, say about being able to look up the link of an interface from the (NAN) link sta correctly, which would result in a link but not with a chanctx. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.2c6589aab9db.I01729ec8be4687884831fc8761bf3fd8bba83056@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: set NAN phy capabilitiesMiri Korenblit
Copy the HT, VHT and HE capabilities from the sbands: - The HT capabilities from the 2.4 GHz sband (there is no difference between the bands anyway). - The VHT capabilities from the 5 GHz sband, obviously. - The HE capabilities from the 2.4 GHz and for NL80211_IFTYPE_STATION. Fix it up to include also the needed 5 GHz bits. For HE, there are bits that are band-dependent and iftype-dependent. For those set to what makes most sense, and leave a comment to re-visit. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.3a5e5251dbaf.I566e1749cd17baa672bdd43712114e434f810a69@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: validate sta_mask before ffs() in BA session handlersJunrui Luo
Three BA session handlers use ffs(ba_data->sta_mask) - 1 to derive a station ID without checking that sta_mask is non-zero. When sta_mask is zero, ffs() returns 0 and the subtraction wraps to 0xFFFFFFFF, causing an out-of-bounds access on fw_id_to_link_sta[]. Add WARN_ON_ONCE(!ba_data->sta_mask) guards before each ffs() call, consistent with the existing check in iwl_mld_ampdu_rx_start(). Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Link: https://patch.msgid.link/SYBPR01MB788115C6CE873271A9A15A25AF51A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: remove unused header inclusionsJay Ng
Remove header files that are included but provide no symbols, types, or macros used by the including translation unit. In iwl-trans.c, fw/api/tx.h defines TX command structures (iwl_tx_cmd, iwl_tx_resp, TX_CMD_* flags) used by the PCIe TX path, not by the transport core itself. Similarly, iwl-fh.h defines Flow Handler register addresses and DMA-related constants (FH_*, RFH_*, TFD_*) that are consumed by PCIe-specific code, none of which are referenced in iwl-trans.c. In iwl-nvm-parse.c, fw/acpi.h defines ACPI/SAR/GEO/PPAG interfaces (iwl_acpi_*, iwl_sar_*, iwl_geo_*). No references to any of these interfaces exist in this file. Signed-off-by: Jay Ng <jayng9663@gmail.com> Link: https://patch.msgid.link/20260408034413.1875915-1-jayng9663@gmail.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mvm: fix race condition in PTP removalJunjie Cao
iwl_mvm_ptp_remove() calls cancel_delayed_work_sync() only after ptp_clock_unregister() and clearing ptp_data state (ptp_clock, ptp_clock_info, last_gp2). This creates a race where the delayed work iwl_mvm_ptp_work() can execute between ptp_clock_unregister() and cancel_delayed_work_sync(), observing partially cleared PTP state. Move cancel_delayed_work_sync() before ptp_clock_unregister() to ensure the delayed work is fully stopped before any PTP cleanup begins. Cc: stable@vger.kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Junjie Cao <junjie.cao@intel.com> Link: https://patch.msgid.link/20260212125035.1345718-1-junjie.cao@intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: fix race condition in PTP removalJunjie Cao
iwl_mld_ptp_remove() calls cancel_delayed_work_sync() only after ptp_clock_unregister() and clearing ptp_data state (ptp_clock, last_gp2, wrap_counter). This creates a race where the delayed work iwl_mld_ptp_work() can execute between ptp_clock_unregister() and cancel_delayed_work_sync(), observing partially cleared PTP state. Move cancel_delayed_work_sync() before ptp_clock_unregister() to ensure the delayed work is fully stopped before any PTP cleanup begins. Cc: stable@vger.kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Junjie Cao <junjie.cao@intel.com> Link: https://patch.msgid.link/20260212125035.1345718-2-junjie.cao@intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26firmware: ti_sci: Add support for restoring clock context during resumeThomas Richard (TI)
Some DM-Firmware are not able to restore the clock rates and the clock parents after a suspend-resume. The CLK_CONTEXT_LOST firmware capability has been introduced to identify this characteristic. In this case the responsibility is therefore delegated to the ti_sci driver, which uses clk_restore_context() to trigger the context_restore() operation for all registered clocks, including those managed by the sci-clk. The sci-clk driver implements the context_restore() operation to ensure rates and clock parents are correctly restored. Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Kendall Willis <k-willis@ti.com> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com> Link: https://patch.msgid.link/20260519-ti-sci-jacinto-s2r-restore-irq-v9-4-c550a8ae0f31@bootlin.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-26clk: keystone: sci-clk: Add restore_context() operationThomas Richard (TI)
Implement the restore_context() operation to restore the clock rate and the clock parent state. The clock rate is saved in sci_clk struct during set_rate() and recalc_rate() operations. The parent index is saved in sci_clk struct during set_parent() operation. During clock registration, the core retrieves each clock’s parent using get_parent() operation to ensure the internal clock tree reflects the actual hardware state, including any configurations made by the bootloader. So we also save the parent index in get_parent(). Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Kendall Willis <k-willis@ti.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com> Link: https://patch.msgid.link/20260519-ti-sci-jacinto-s2r-restore-irq-v9-3-c550a8ae0f31@bootlin.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-26firmware: ti_sci: Add support for restoring IRQs during resumeThomas Richard (TI)
Some DM-Firmware are not able to restore the IRQ context after a suspend-resume. The IRQ_CONTEXT_LOST firmware capability has been introduced to identify this characteristic. In this case the responsibility is delegated to the ti_sci driver, which maintains an internal list of all requested IRQs. This list is updated on each set()/free() operation, and all IRQs are restored during the resume_noirq() phase. Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Kendall Willis <k-willis@ti.com> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com> Link: https://patch.msgid.link/20260519-ti-sci-jacinto-s2r-restore-irq-v9-2-c550a8ae0f31@bootlin.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-26firmware: ti_sci: Add BOARDCFG_MANAGED mode supportThomas Richard (TI)
In BOARDCFG_MANAGED mode, the low power mode configuration is done statically for the DM via the boardcfg. Constraints are not supported, and prepare_sleep() is not needed. Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Kendall Willis <k-willis@ti.com> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com> Link: https://patch.msgid.link/20260519-ti-sci-jacinto-s2r-restore-irq-v9-1-c550a8ae0f31@bootlin.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-26pinctrl: spacemit: move over to generic pinmux dt_node_to_map implementationConor Dooley
Replace the custom implementation of dt_node_to_map with pinctrl_generic_dt_node_to_map() to demonstrate its use. spacemit_pin_mux_config didn't provide much value in the first place, because the group contains the information required to look up the spacemit_pin struct corresponding to a pin, so there's no loss in functionality as a result of the generic function carrying only the mux data in the group's data pointer rather than having an array of spacemit_pin_mux_config structs. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-26pinctrl: spacemit: delete spacemit_pctrl_check_power()Conor Dooley
As far as I can tell spacemit_pctrl_check_power(), called during the custom implementation of dt_node_to_map, is redundant because the driver's implementation generate_config performs the check too. Removing this would allow the driver to use the newly added common function pinctrl_generic_pinmux_dt_node_to_map(). Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-26pinctrl: add new generic groups/function creation function for pinmuxConor Dooley
Akin to my recently added pinctrl_generic_pins_functions_dt_node_to_map(), create an analogue that performs the same role of dynamically creating groups at runtime for controllers using the pinmux property. The pinmux property is freeform, so this function mandates that the upper 16 bits contain the pin and the lower 16 bits contains the mux setting. The group's data pointer is populated with an array of the mux settings for each pin it contains. Since the node parsing and subsequent pinctrl core function calls are practically identical to the pins + functions case, other than which properties are examined, it makes sense to extract the common code from pinctrl_generic_pins_function_dt_node_to_map() into a generic function that takes the case-specific devicetree parsing function as an argument. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-26pinctrl: generic: change signature of pinctrl_generic_to_map() to pass void dataConor Dooley
In order to make pinctrl_generic_to_map() usable for controllers that use pinmux, change the functions char array pointer that it passes to pinctrl_generic_add_group() to a void pointer. In the pinmux case this property will contain the mux setting as a number rather than as strings in the pins + functions case. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-26firmware: meson: sm: Add thermal calibration SMC callRonald Claveau
Add SM_THERMAL_CALIB_READ at SMC ID 0x82000047 in the command table and implement meson_sm_get_thermal_calib(), which forwards the tsensor_id argument to the secure monitor and returns the calibration data. Also realign the CMD() column to improve readability. Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> [ dlezcano: Fixed kernel-doc format warning ] Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260424-add-thermal-t7-vim4-v5-3-9040ca36afe2@aliel.fr
2026-05-26thermal/core: Use devm_add_action_or_reset() when registering a cooling deviceDaniel Lezcano
Use devm_add_action_or_reset() which does the replaced code. It results in a simpler and more concise code. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260429161430.3802970-2-daniel.lezcano@oss.qualcomm.com
2026-05-26thermal/drivers/tegra/soctherma: Switch to devm cooling device registrationDaniel Lezcano
Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/20260424160019.41710-2-daniel.lezcano@oss.qualcomm.com
2026-05-26thermal/drivers/tegra/soctherm: Use devm_add_action_or_reset() for clock disableDaniel Lezcano
Replace the manual error handling paths disabling the clocks with devm_add_action_or_reset(). This ensures the clocks are properly disabled on probe failure and driver removal, while simplifying the code by removing the explicit error paths. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/20260424160019.41710-1-daniel.lezcano@oss.qualcomm.com
2026-05-26net: enetc: dynamically allocate rxmsg based on VF countWei Fang
The constant ENETC_MAX_NUM_VFS is defined as 2 when enabling support for LS1028A. This works for LS1028A because its ENETC hardware supports up to 2 VFs. However, ENETC v4 has varying VF capabilities depending on the SoC: i.MX94 standalone ENETC: 0 VFs i.MX94 internal ENETC: 3 VFs i.MX952: 1 VF Using a fixed ENETC_MAX_NUM_VFS for memory allocation leads to over-allocation on SoCs with fewer or no VF support. To better match hardware capabilities and avoid unnecessary memory usage, change rxmsg memory allocation from a fixed-size array to dynamic allocation based on the actual VF count retrieved via pci_sriov_get_totalvfs(). Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-13-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: use MADDR_TYPE for MAC filter array sizeWei Fang
The mac_filter array in struct enetc_pf is sized as ENETC_MAX_NUM_MAC_FLT, defined as (ENETC_MAX_NUM_VFS + 1) * MADDR_TYPE. This resulted in an array of 6 elements (for 2 VFs), but only the first 2 entries are actually used. The PF driver maintains MAC filters for unicast (UC) and multicast (MC) addresses, indexed by the enum enetc_mac_addr_type (UC=0, MC=1). The code only iterates over MADDR_TYPE (2) entries and directly accesses mac_filter[UC] and mac_filter[MC]. The extra space allocated for (ENETC_MAX_NUM_VFS * MADDR_TYPE) entries is never used because VF MAC filtering is not implemented yet. Remove the ENETC_MAX_NUM_MAC_FLT macro and size the array as MADDR_TYPE, reducing the allocation from 6 to 2 entries. This saves 48 bytes per PF and better reflects the actual usage. This change has no functional impact. Future VF MAC filtering support will move mac_filter into struct enetc_si, allowing each SI (PF or VF) to maintain its own independent filter table. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-12-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: add generic helper to initialize SR-IOV resourcesWei Fang
The upcoming ENETC v4 PF driver will support SR-IOV, and its logic for initializing VF resources is identical to the existing ENETC v1 PF implementation. To avoid code duplication across PF drivers, factor out the common SR-IOV initialization logic into the enetc-pf-common driver. Add enetc_init_sriov_resources() to handle: - Querying the total number of VFs supported by the device via pci_sriov_get_totalvfs() - Allocating memory for the VF state array (struct enetc_vf_state) The implementation uses devm_kcalloc() instead of kzalloc() to simplify memory management. This automatically frees VF state memory when the PF device is removed, eliminating the need for explicit cleanup in error and remove paths. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-11-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: add CBDR setup/teardown hooks to enetc_si_ops for VF supportWei Fang
The upcoming ENETC v4 VF will share the enetc-vf driver with the existing v1 VF. However, ENETC v4 uses a revised CBDR (command BD ring) setup/teardown API that differs from v1. To support both versions in the same driver, add setup_cbdr() and teardown_cbdr() function pointers to struct enetc_si_ops. This allows each hardware version to register its own CBDR implementation: - ENETC v1 VF registers enetc_setup_cbdr/enetc_teardown_cbdr (existing) - ENETC v4 VF will register enetc4_setup_cbdr/enetc4_teardown_cbdr Update the enetc-vf driver to call CBDR operations through si->ops instead of directly invoking the v1 functions. This enables runtime selection of the correct CBDR backend based on hardware version. Changes: - Add setup_cbdr() and teardown_cbdr() hooks to struct enetc_si_ops - Register v1 CBDR functions in enetc_vsi_ops - Replace direct calls with si->ops->setup_cbdr() and si->ops->teardown_cbdr() in enetc_vf.c No functional changes to existing v1 VF behavior. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-10-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: align v1 CBDR API with v4 for VF driver sharingWei Fang
The upcoming ENETC v4 VF will share the enetc-vf driver with the v1 VF. However, ENETC v4 introduces different CBDR (command BD ring) setup and teardown semantics that are incompatible with v1. To support both versions in the same driver, the .setup_cbdr() and .teardown_cbdr() hooks will be added to struct enetc_si_ops, allowing the driver to register version-specific implementations. So refactor the v1 CBDR functions to match the v4-style interface (taking struct enetc_si* instead of individual parameters), enabling them to be registered via si_ops in the subsequent patch. Changes: - Update enetc_setup_cbdr() and enetc_teardown_cbdr() prototypes to take 'struct enetc_si *' as the sole parameter - Extract parameters (dev, hw) from the enetc_si structure within the function implementations - ENETC_CBDR_DEFAULT_SIZE has always been used as the number of command BDs, and there is no need to adjust the size of the command BD ring. Therefore, ENETC_CBDR_DEFAULT_SIZE is moved into the enetc_setup_cbdr() - Update all call sites in enetc_pf.c and enetc_vf.c No functional changes. This prepares for adding v4-specific CBDR handling in subsequent patches. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-9-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: add VF-PF messaging support for IP minor revision queryWei Fang
For ENETC v4, different SoCs use different minor revisions, such as i.MX95 v4.1, i.MX94 v4.3, and i.MX952 v4.6. Unlike the PF, the VF does not have access to a global register that exposes the IP minor revision. In the current driver model, the VF must select the appropriate driver data based on this revision information. To support this requirement, the VF now sends a minor revision query message to the PF through the VSI-to-PSI mailbox mechanism. The PF responds with the IP minor revision so that the VF can match the correct driver data. This patch adds PF-side support for replying to the minor revision message and VF-side support for sending the query. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-8-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: convert mailbox messages to new formatsWei Fang
On the LS1028A platform, the PF-VF mailbox was only used to update the VF's MAC address. The original message format is minimal, lacks a clear structure, and provides no means for the receiver to validate message integrity, making it difficult to extend for new features. With the introduction of i.MX ENETC v4, the interaction between PF and VF has become significantly more complex. Typical deployments now include scenarios where the PF is controlled by an M core while the VF is driven by either the Linux kernel or DPDK, or where the PF is controlled by the Linux kernel while the VF is controlled by DPDK. These heterogeneous driver combinations require a unified and extensible message format to ensure compatibility across different operating environments. This patch introduces a newly defined PF-VF message structure and converts the existing MAC-update mechanism to use the new format. The redesigned message layout provides: - extensibility to support future PF-VF features on ENETC v4, - consistent framing for all message types, - improved data integrity checking, - a common protocol usable across Linux, M core firmware, and DPDK. Additional PF-VF message types will be added in subsequent patches. Note that switch to the new message format will not affect ENETC v1 (LS1028A). Due to a hardware limitation of ENETC v1, the ENETC PF and VFs can only be controlled by the same OS. If the PF is controlled by the Linux kernel driver, then the VFs must also be controlled by the Linux kernel driver. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-7-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: use read_poll_timeout() for VF mailbox pollingWei Fang
Replace the manual do-while polling loop in enetc_msg_vsi_send() with the standard read_poll_timeout() helper to simplify the code. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-6-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: integrate enetc_msg.c into enetc-pf-common driverWei Fang
Move enetc_msg.c from the fsl-enetc driver to the nxp-enetc-pf-common driver so that SR-IOV mailbox handling can be shared between ENETC v1 and v4 PF drivers. Changes: - Move enetc_msg.o compilation from fsl-enetc to nxp-enetc-pf-common - Export enetc_sriov_configure() with EXPORT_SYMBOL_GPL for use by both PF drivers The fsl-enetc driver now depends on nxp-enetc-pf-common for SR-IOV functionality. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-5-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: relocate SR-IOV configuration helper for common PF supportWei Fang
Move enetc_sriov_configure() from enetc_pf.c to enetc_msg.c to prepare for integrating enetc_msg.c into the enetc-pf-common driver, where it will be shared between ENETC v1 and v4 PF drivers. Since enetc_msg_psi_init() and enetc_msg_psi_free() are now only called from enetc_sriov_configure() within the same file, make them static. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-4-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: move VF message handlers to enetc_msg.cWei Fang
Move enetc_msg_pf_set_vf_primary_mac_addr() and enetc_msg_handle_rxmsg() to enetc_msg.c to consolidate VF mailbox message handling logic. Make enetc_msg_handle_rxmsg() static since it's only called from enetc_msg_task() within the same file. This prepares for integrating enetc_msg.c into the enetc-pf-common driver to be shared between ENETC v1 and v4 PF drivers. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-3-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: use enetc_set_si_hw_addr() for setting MAC addressWei Fang
Replace enetc_pf_set_primary_mac_addr() with the generic enetc_set_si_hw_addr() function. This prepares for moving enetc_msg_pf_set_vf_primary_mac_addr() to the enetc-pf-common driver, where it can be shared between ENETC v1 and v4 PF drivers. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-2-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26PM: sleep: Use complete() in device_pm_sleep_init()Jiakai Xu
Replace complete_all() with complete() in device_pm_sleep_init() to allow it to be called in atomic contexts without triggering a false-positive WARNING from lockdep_assert_RT_in_threaded_ctx() when CONFIG_PROVE_RAW_LOCK_NESTING is enabled. device_pm_sleep_init() may be called during device initialization while holding a raw_spinlock (e.g., from within device_initialize()), and complete_all() is unsafe in atomic contexts on PREEMPT_RT kernels. complete(), which is safe to call from any context, is sufficient here. complete_all() sets the completion count to UINT_MAX/2 (permanently signaled), while complete() increments it by 1. Since no threads can be waiting during device initialization, both are functionally equivalent. The completion is always reinitialized via reinit_completion() in dpm_clear_async_state() before each suspend/resume cycle. However, changing to complete() introduces a potential deadlock for devices with no PM support (dev->power.no_pm = true). Such devices are never added to the dpm_list and never go through dpm_clear_async_state(), so their completion is never reinitialized. A parent device waiting on a no_pm child across multiple suspend phases would consume the single-use token in the first phase and block forever in the second. Fix this by adding an early return in dpm_wait() when dev->power.no_pm is set, since no_pm devices do not participate in system suspend/resume. Fixes: 152e1d592071 ("PM: Prevent waiting forever on asynchronous resume after failing suspend") Signed-off-by: Jiakai Xu <xujiakai24@mails.ucas.ac.cn> [ rjw: Subject adjustment ] Link: https://patch.msgid.link/20260523022314.2657232-1-xujiakai24@mails.ucas.ac.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-05-26cpufreq/amd-pstate-ut: Disable dynamic_epp after the mode switchK Prateek Nayak
Dan reported a possible NULL pointer dereference in amd-pstate-ut.c from static analysis and sure enough, running amd-pstate-ut in active mode with amd_dynamic_epp=enable results in a crash as a reult of the policy reference being set to NULL early, before disabling dynamic EPP. Kalpana also reported seeing amd-pstate-ut error out with -EBUSY for "amd_pstate_ut_epp" test when starting from the passive mode and amd_dynamic_epp=enable in the command line. The reason for the failure is that the command line enables dynamic_epp by default after the mode switch and the modifications to EPP values are blocked when running in dynamic EPP mode. Solution to both problems is to toggle off dynamic_epp *after* the mode switch when the driver grabs the policy reference again since the unit test is in full control of the policy after that point. The final restoration step will reset the dynamic_epp state via mode switch based on the initial conditions of the system. Reported-by: Kalpana Shetty <kalpana.shetty@amd.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/linux-pm/ahEq0CvdBX0T7_cO@stanley.mountain/ Fixes: f9f16835d4dc ("cpufreq/amd-pstate-ut: Drop policy reference before driver switch") Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://patch.msgid.link/20260523055503.7651-1-kprateek.nayak@amd.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-05-26drm/bridge: ite-it66121: Select HDMI or DVI mode based on sink typeJavier Martinez Canillas
The driver unconditionally sets the transmission mode to HDMI, which leads to display output not working with DVI monitors. Check the connector's display information sink type to identify the correct mode to configure the bridge. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260523-it66121-fix-dvi-mode-v5-v5-3-33b4468162f9@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-26drm/bridge: ite-it66121: Move .mode_set logic to .atomic_enableJavier Martinez Canillas
Move the existing .mode_set logic to the .atomic_enable callback. The former is deprecated and drivers are supposed to use the latter instead. Also, drop the struct it66121_ctx.connector field because the connector can be accessed through the atomic state and there is no need to store it anymore. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260523-it66121-fix-dvi-mode-v5-v5-2-33b4468162f9@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-26drm/bridge: ite-it66121: Switch to the HDMI connector helpersJavier Martinez Canillas
Instead of open coding the HDMI AVI Infoframes buffer management, use the helpers provided by the HDMI connector framework. Also, add callbacks to implement HDMI Vendor Specific Infoframe and Audio InfoFrame support. The driver was not sending these before, but they are required when using the HDMI helpers. These were implemented following the IT66121 Programming Guide. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260523-it66121-fix-dvi-mode-v5-v5-1-33b4468162f9@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-26mv88e6xxx: Remove locks for 6352's has_serdesFidan Aliyeva
There is no register access anymore in mv88e6352_g2_scratch_port_has_serdes. So, remove the locks surrounding the function. Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Link: https://patch.msgid.link/20260521202924.727929-5-fidan.aliyeva.ext@ericsson.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26mv88e6xxx: Use cached config3 in 6352 has_serdesFidan Aliyeva
1. Refactor mv88e6352_g2_scratch_port_has_serdes to use the cached scratch config3 value instead of reading it everytime. 2. Remove err<0 check from mv88e6352_phylink_get_caps as it is never true anymore Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Link: https://patch.msgid.link/20260521202924.727929-4-fidan.aliyeva.ext@ericsson.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26mv88e6xxx: Cache scratch config3 of 6352Fidan Aliyeva
Changes: 1. Add g2_scratch_config3 member to mv88e6xxx_chip. 2. Add mv88e6352_g2_cache_global_scratch_config3 which reads the CONFIG3 value from the scratch register and caches it. 3. Call this function in mv88e6352_reset. Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Link: https://patch.msgid.link/20260521202924.727929-3-fidan.aliyeva.ext@ericsson.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-08 03:20:18 +0000