summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-06ice: implement GTP RSS context tracking and configurationAleksandr Loktionov
This commit implements the core RSS context management and configuration logic for GTP (GTPU) protocol support in VF RSS operations. Key implementation features: - GTPU hash context management with pre/post processing functions - Context index calculation and mapping for different GTPU scenarios - Integration with main RSS configuration flow via wrapper functions - Support for IPv4/IPv6 GTPU RSS configurations - Rollback mechanism for handling RSS rule conflicts - Hash context reset and cleanup functionality The implementation provides comprehensive GTPU RSS support by: 1. Adding ice_add_rss_cfg_pre_gtpu() for preprocessing GTPU contexts 2. Adding ice_add_rss_cfg_post_gtpu() for postprocessing configurations 3. Adding ice_calc_gtpu_ctx_idx() for context index calculation 4. Integrating GTPU logic into ice_add_rss_cfg_wrap() and ice_rem_rss_cfg_wrap() 5. Supporting context tracking in VF hash_ctx structures This completes the GTP RSS infrastructure enabling VFs to configure RSS hashing on GTP-encapsulated traffic. Co-developed-by: Dan Nowlin <dan.nowlin@intel.com> Signed-off-by: Dan Nowlin <dan.nowlin@intel.com> Co-developed-by: Jie Wang <jie1x.wang@intel.com> Signed-off-by: Jie Wang <jie1x.wang@intel.com> Co-developed-by: Junfeng Guo <junfeng.guo@intel.com> Signed-off-by: Junfeng Guo <junfeng.guo@intel.com> Co-developed-by: Qi Zhang <qi.z.zhang@intel.com> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com> Co-developed-by: Ting Xu <ting.xu@intel.com> Signed-off-by: Ting Xu <ting.xu@intel.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-11-06ice: add virtchnl definitions and static data for GTP RSSAleksandr Loktionov
Add virtchnl protocol header and field definitions for advanced RSS configuration including GTPC, GTPU, L2TPv2, ECPRI, PPP, GRE, and IP fragment headers. - Define new virtchnl protocol header types - Add RSS field selectors for tunnel protocols - Extend static mapping arrays for protocol field matching - Add L2TPv2 session ID and length+session ID field support This provides the foundational definitions needed for VF RSS configuration of tunnel protocols. Co-developed-by: Dan Nowlin <dan.nowlin@intel.com> Signed-off-by: Dan Nowlin <dan.nowlin@intel.com> Co-developed-by: Jie Wang <jie1x.wang@intel.com> Signed-off-by: Jie Wang <jie1x.wang@intel.com> Co-developed-by: Junfeng Guo <junfeng.guo@intel.com> Signed-off-by: Junfeng Guo <junfeng.guo@intel.com> Co-developed-by: Qi Zhang <qi.z.zhang@intel.com> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com> Co-developed-by: Ting Xu <ting.xu@intel.com> Signed-off-by: Ting Xu <ting.xu@intel.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-11-06ice: add flow parsing for GTP and new protocol field supportAleksandr Loktionov
Introduce new protocol header types and field sizes to support GTPU, GTPC tunneling protocols. - Add field size macros for GTP TEID, QFI, and other headers - Extend ice_flow_field_info and enum definitions - Update hash macros for new protocols - Add support for IPv6 prefix matching and fragment headers This patch lays the groundwork for enhanced RSS and flow classification capabilities. Co-developed-by: Dan Nowlin <dan.nowlin@intel.com> Signed-off-by: Dan Nowlin <dan.nowlin@intel.com> Co-developed-by: Junfeng Guo <junfeng.guo@intel.com> Signed-off-by: Junfeng Guo <junfeng.guo@intel.com> Co-developed-by: Ting Xu <ting.xu@intel.com> Signed-off-by: Ting Xu <ting.xu@intel.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-11-06Merge branch ↵Jakub Kicinski
'net-dsa-lantiq_gswip-add-support-for-maxlinear-gsw1xx-switch-family' Daniel Golle says: ==================== net: dsa: lantiq_gswip: Add support for MaxLinear GSW1xx switch family This patch series extends the existing lantiq_gswip DSA driver to support the MaxLinear GSW1xx family of dedicated Ethernet switch ICs. These switches are based on the same IP as the Lantiq/Intel GSWIP found in VR9 and xRX MIPS router SoCs which are currently supported by the lantiq_gswip driver, but they are dedicated ICs connected via MDIO rather than built-in components of a SoC accessible via memory-mapped I/O. The series includes several improvements and refactoring to implement support for GSW1xx switch ICs by reusing the existing lantiq_gswip driver. The GSW1xx family includes several variants: - GSW120: 4 ports, 2 PHYs, RGMII & SGMII/2500Base-X - GSW125: 4 ports, 2 PHYs, RGMII & SGMII/2500Base-X, industrial temperature - GSW140: 6 ports, 4 PHYs, RGMII & SGMII/2500Base-X - GSW141: 6 ports, 4 PHYs, RGMII & SGMII - GSW145: 6 ports, 4 PHYs, RGMII & SGMII/2500Base-X, industrial temperature Key features implemented: - MDIO-based register access using regmap - Support for SGMII/1000Base-X/2500Base-X SerDes interfaces - Configurable RGMII delays via device tree properties - Configurable RMII clock direction - Energy Efficient Ethernet (EEE) support - enabling/disabling learning ==================== Link: https://patch.msgid.link/cover.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: add driver for MaxLinear GSW1xx switch familyDaniel Golle
Add driver for the MaxLinear GSW1xx family of Ethernet switch ICs which are based on the same IP as the Lantiq/Intel GSWIP found in the Lantiq VR9 and Intel GRX MIPS router SoCs. The main difference is that instead of using memory-mapped I/O to communicate with the host CPU these ICs are connected via MDIO (or SPI, which isn't supported by this driver). Implement the regmap API to access the switch registers over MDIO to allow reusing lantiq_gswip_common for all core functionality. The GSW1xx also comes with a SerDes port capable of 1000Base-X, SGMII and 2500Base-X, which can either be used to connect an external PHY or SFP cage, or as the CPU port. Support for the SerDes interface is implemented in this driver using the phylink_pcs interface. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://patch.msgid.link/b567ec1b4beb08fd37abf18b280c56d5d8253c26.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: add tagging driver for MaxLinear GSW1xx switch familyDaniel Golle
Add support for a new DSA tagging protocol driver for the MaxLinear GSW1xx switch family. The GSW1xx switches use a proprietary 8-byte special tag inserted between the source MAC address and the EtherType field to indicate the source and destination ports for frames traversing the CPU port. Implement the tag handling logic to insert the special tag on transmit and parse it on receive. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://patch.msgid.link/0e973ebfd9433c30c96f50670da9e9449a0d98f2.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06dt-bindings: net: dsa: lantiq,gswip: add support for MaxLinear GSW1xx switchesDaniel Golle
Extend the Lantiq GSWIP device tree binding to also cover MaxLinear GSW1xx switches which are based on the same hardware IP but connected via MDIO instead of being memory-mapped. Add compatible strings for MaxLinear GSW120, GSW125, GSW140, GSW141, and GSW145 switches and adjust the schema to handle the different connection methods with conditional properties. Add MaxLinear GSW125 example showing MDIO-connected configuration. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/fc96f1dedb2b418a63e69960356dde7f6eb86424.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: lantiq_gswip: allow adjusting MII delaysDaniel Golle
Currently the MII clk vs. data delay is configured based on the PHY interface mode. In addition to that add support for setting up MII delays using the standard Device Tree properties 'tx-internal-delay-ps' and 'rx-internal-delay-ps', using the values determined by the PHY interface mode as default to maintain backward compatibility with legacy device trees. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/37203e831cff87dc46e5ef9e8cbd68fb8689773d.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06dt-bindings: net: dsa: lantiq,gswip: add support for MII delay propertiesDaniel Golle
Add support for standard tx-internal-delay-ps and rx-internal-delay-ps properties on port nodes to allow fine-tuning of RGMII clock delays. The GSWIP switch hardware supports delay values in 500 picosecond increments from 0 to 3500 picoseconds, with a post-reset default of 2000 picoseconds for both TX and RX delays. The driver currently sets the delay to 0 in case the PHY is setup to carry out the delay by the corresponding interface modes ("rgmii-id", "rgmii-rxid", "rgmii-txid"). This corresponds to the driver changes that allow adjusting MII delays using Device Tree properties instead of relying solely on the PHY interface mode. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/9e007d4f85c2c6d69e0b91f3663d99e0f6fc8eac.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: lantiq_gswip: add vendor property to setup MII refclk outputDaniel Golle
Read boolean Device Tree property "maxlinear,rmii-refclk-out" and switch the RMII reference clock to be a clock output rather than an input if it is set. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://patch.msgid.link/947d14970f74f760e4a60c777aabee64e7e4f356.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06dt-bindings: net: dsa: lantiq,gswip: add MaxLinear RMII refclk output propertyDaniel Golle
Add support for the maxlinear,rmii-refclk-out boolean property on port nodes to configure the RMII reference clock to be an output rather than an input. This property is only applicable for ports in RMII mode and allows the switch to provide the reference clock for RMII-connected PHYs instead of requiring an external clock source. This corresponds to the driver changes that read this Device Tree property to configure the RMII clock direction. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/9813bb916ecce9bae366e6c50c081014fe5371ea.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: lantiq_gswip: define and use GSWIP_TABLE_MAC_BRIDGE_VAL1_VALIDDaniel Golle
When adding FDB entries to the MAC bridge table on GSWIP 2.2 or later it is needed to set an (undocumented) bit to mark the entry as valid. If this bit isn't set for entries in the MAC bridge table, then those entries won't be considered as valid MAC addresses. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/e02fe0d946c98920bc55b5f389a8f56382aae7df.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: lantiq_gswip: set link parameters also for CPU portDaniel Golle
On standalone switch ICs the link parameters of the CPU port need to be setup just like user ports. The destinction in the driver to not carry out link parameter setup for the CPU port does make sense for in-SoC switches on which the CPU port is internally connected to the SoC's Ethernet MAC. Set link parameters also for the CPU port unless it is an internal interface. Note that the internal TP PHYs anyway cannot be used as CPU ports, hence it doesn't matter that they are now also covered by that condition. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/07c6b8d3a12296123be5e5938b454fc620f819e6.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: lantiq_gswip: support Energy Efficient EthernetDaniel Golle
Introduce support for Energy Efficient Ethernet (EEE) on hardware version 2.2 or later. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/753e45acb25e185689ca1afd8a9bd0c199d1c15b.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: lantiq_gswip: support enable/disable learningDaniel Golle
Switch API 2.2 or later supports enabling or disabling learning on each port. Implement support for BR_LEARNING bridge flag and announce support for BR_LEARNING on GSWIP 2.2 or later. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/0aa4621e01c998378ad5812464bc17d23aa3bf62.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: lantiq_gswip: split into common and MMIO partsDaniel Golle
Move all parts specific for the MMIO/SoC driver into a module of its own to prepare for supporting MDIO-connected switch ICs. Modify gswip_probe() functions by splitting it into a common function gswip_probe_common() which covers allocating, initializing and registering the DSA switch, while keeping transport-specific regmap initialization as well as PHY firmware loading in the new MMIO/SoC-specific gswip_probe() function. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/dc7da5b65ec220ba8e9bc4bd04fe1ed7de046656.1762170107.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06rtc: atcrtc100: Add ATCRTC100 RTC driverCL Wang
RTC driver for Andes ATCRTC100 Real-Time Clock. Signed-off-by: CL Wang <cl634@andestech.com> Link: https://patch.msgid.link/20250915031439.2680364-4-cl634@andestech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-06MAINTAINERS: Add entry for ATCRTC100 RTC driverCL Wang
Add support entry for the Andes ATCRTC100 RTC driver in the MAINTAINERS file. Signed-off-by: CL Wang <cl634@andestech.com> Link: https://patch.msgid.link/20250915031439.2680364-3-cl634@andestech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-06dt-bindings: rtc: Add support for ATCRTC100 RTCCL Wang
Document Device Tree bindings for the Andes ATCRTC100 Real-Time Clock. Signed-off-by: CL Wang <cl634@andestech.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20250915031439.2680364-2-cl634@andestech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-06hisi_acc_vfio_pci: Add .match_token_uuid callback in hisi_acc_vfio_pci_migrn_opsRaghavendra Rao Ananta
The commit, <86624ba3b522> ("vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD") accidentally ignored including the .match_token_uuid callback in the hisi_acc_vfio_pci_migrn_ops struct. Introduce the missed callback here. Fixes: 86624ba3b522 ("vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD") Cc: stable@vger.kernel.org Suggested-by: Longfang Liu <liulongfang@huawei.com> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com> Reviewed-by: Longfang Liu <liulongfang@huawei.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20251031170603.2260022-3-rananta@google.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2025-11-06vfio: Fix ksize arg while copying user struct in vfio_df_ioctl_bind_iommufd()Raghavendra Rao Ananta
For the cases where user includes a non-zero value in 'token_uuid_ptr' field of 'struct vfio_device_bind_iommufd', the copy_struct_from_user() in vfio_df_ioctl_bind_iommufd() fails with -E2BIG. For the 'minsz' passed, copy_struct_from_user() expects the newly introduced field to be zero-ed, which would be incorrect in this case. Fix this by passing the actual size of the kernel struct. If working with a newer userspace, copy_struct_from_user() would copy the 'token_uuid_ptr' field, and if working with an old userspace, it would zero out this field, thus still retaining backward compatibility. Fixes: 86624ba3b522 ("vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD") Cc: stable@vger.kernel.org Signed-off-by: Raghavendra Rao Ananta <rananta@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20251031170603.2260022-2-rananta@google.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2025-11-06drm/i915/xe3p_lpd: Adapt to updates on MBUS_CTL/DBUF_CTL registersRavi Kumar Vodapalli
Xe3p_LPD updated fields of registers MBUS_CTL and DBUF_CTL to accommodate for higher MDCLK:CDCLK ratios. Update the code to use the new fields. The field MBUS_TRANSLATION_THROTTLE_MIN_MASK was changed from range [15:13] to [16:13]. Since bit 16 is not reserved in previous display IPs and already used for something else, we can't simply extend the mask definition to include it, but rather define an Xe3p-specific mask and select the correct one to use based on the IP version. Similarly, DBUF_MIN_TRACKER_STATE_SERVICE_MASK was changed from range [18:16] to [20:16]. For the same reasons stated above, it needs a Xe3p-specific mask definition. v2: - Keep definitions in the same line (i.e. without line continuation breaks) for better readability. (Jani) v3: - Keep mask fields sorted by the upper limit. (Matt) - Extend commit message to indicate why we need Xe3p-specific definitions of the masks instead of just extending the existing ones. (Matt) Bspec: 68868, 68872 Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-18-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Always apply WaWmMemoryReadLatencyGustavo Sousa
When reading memory latencies for watermark calculations, previous display releases instructed to apply an adjustment of adding a certain value (e.g. 6us) to all levels when the level 0's memory latency read from hardware was zero. For Xe3p_LPD, the instruction is to always use 6us for level 0 and to add that value to the other levels. Add the necessary code in sanitize_wm_latency() so that WaWmMemoryReadLatency is always applied for Xe3p_LPD and beyond. v2: - Rebased after addition of prep patch "drm/i915/wm: Reorder adjust_wm_latency() for Xe3_LPD" (dropped in v3). v3: - Back to the simpler approach of doing the 'wm[0] = 0' step without modifying the rest of the code, and that inside sanitize_wm_latency(). (Matt Roper, Ville) Bspec: 68986, 69126 Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-20-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/dram: Add field ecc_impacting_de_bwGustavo Sousa
Starting with Xe3p_LPD, we now have a new field in MEM_SS_INFO_GLOBAL that indicates whether the memory has enabled ECC that limits display bandwidth. Add the field ecc_impacting_de_bw to struct dram_info to contain that information and set it appropriately when probing for memory info. Currently there are no instructions in Bspec on how to handle that case, so let's throw a warning if we ever find such a scenario. v2: - s/ecc_impacting_de/ecc_impacting_de_bw/ to be more specific. (Matt Atwood) - Add warning if ecc_impacting_de_bw is true, since we currently do not have instructions on how to handle it. (Matt Roper) v3: - Check on ecc_impacting_de_bw for the warning only for Xe3p_LPD and beyond. - Change warning macro from drm_WARN_ON_ONCE() to drm_WARN_ON(). Bspec: 69131 Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-15-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/wm: don't use method1 in Xe3p_LPD onwardsLuca Coelho
Starting from display version 35, we don't need to use method1 to calculate the watermark values anymore, so skip it. Bspec: 68985 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-14-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Reload DMC MMIO for pipes C and DGustavo Sousa
Xe3p_LPD has the same behavior as for Xe3_LPD with respect to DMC context data for pipes C and D, which are lost when their power wells are disabled. As such, let's extend the condition for Xe3_LPD in need_pipedmc_load_mmio() to also catch Xe3p_LPD. Bspec: 68851 Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-13-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Don't allow odd ypan or ysize with semiplanar formatJuha-pekka Heikkila
Disable support for odd panning and size in y direction when running on display version 35 and using semiplanar formats. Bspec: 68903 Signed-off-by: Juha-pekka Heikkila <juha-pekka.heikkila@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-12-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Extend Wa_16025573575Gustavo Sousa
Wa_16025573575 also applies to Xe3p_LPD, so let's include it in the IP version checks. Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-11-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Drop support for interlace modeAnkit Nautiyal
Interlace mode is officially removed from HW from Xe3p_LPD. The register TRANS_VSYNCSHIFT and the bits in TRANS_CONF are now removed, so make sure we do not set/get these anymore. Bspec: 69961, 70000 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-10-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Load DMC firmwareGustavo Sousa
Load the DMC firmware for Xe3p_LPD. Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-9-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Add CDCLK tableGustavo Sousa
Add CDCLK table for Xe3p_LPD. Just as with Xe3_LPD, we don't need to send voltage index info in the PMDemand message, so we are able to re-use xe3lpd_cdclk_funcs. With the new CDCLK table, we also need to update the maximum CDCLK value returned by intel_update_max_cdclk(). Bspec: 68861, 68863 Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-8-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Remove gamma,csc bottom color checksSai Teja Pottumuttu
With Xe3p_LPD, the SKL_BOTTOM_COLOR_GAMMA_ENABLE and SKL_BOTTOM_COLOR_CSC_ENABLE bits are being removed. Thus, we need not set gamma_enable nor csc_enable in crtc_state. Note that GAMMA_MODE.POST_CSC_GAMMA_ENABLE and CSC_MODE.ICL_CSC_ENABLE are the documented alternatives for the bottom color bits being removed. But as these suggested bits are being checked in state checker as part of gamma_mode, csc_mode fields and as gamma_enable/csc_enable are not being used anywhere else functionally post ICL, we need not set these fields in crtc_state. Bspec: 69734 Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-7-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Horizontal flip support for linear surfacesSai Teja Pottumuttu
Starting from Xe3p_LPD, linear surfaces also support horizontal flip. Bspec: 68904 Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-6-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Expand bifield masks dbuf blocks fieldsSai Teja Pottumuttu
On Xe3p_LPD, the dbuf blocks fields of different registers are now documented as 13-bit fields. The dbuf isn't really large enough to need the 13th bit, but let's go ahead and update the definition now just in case some new display IP in future ends up needing the larger size. The extra bit is an unused bit in previous display versions, so we can safely just extend the existing definition. Bspec: 69847, 69880, 72053 Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-5-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Update bandwidth parametersMatt Atwood
Bandwidth parameters for Xe3p_LPD are the same as for Xe3_LPD. Re-use them. Since handling for Xe3_LPD version 30.02 is more like a special case, let's use a "== 3002" check for it inside the ">= 30" branch instead of adding a new branch for version 35. That allows us to re-use the ">= 30" branch for Xe3p_LPD. v2: - Do not have a special case for ecc_impacting_de_bw, since there are no specific instructions in Bspec for this scenario. (Matt Roper) v3: - Re-use the ">= 30" branch in the if-ladder. (Matt Roper) Bspec: 68859 Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-4-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/display: Use braces for if-ladder in intel_bw_init_hw()Gustavo Sousa
Looking at the current if-ladder in intel_bw_init_hw(), we see that Xe2_HPD contains two entries, differing only for ECC memories. Let's improve readability by using braces and allowing adding extra conditions for each case. v2: - Tweaked commit message, since we are not going to add the ECC case for Xe3p_LPD anymore. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-3-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Drop north display reset option programmingMatt Roper
The NDE_RSTWRN_OPT has been removed on Xe3p platforms and reset option programming is no longer necessary during display init. Bspec: 68846, 69137 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-2-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06drm/i915/xe3p_lpd: Add Xe3p_LPD display IP featuresSai Teja Pottumuttu
Xe3p_LPD (display version 35) is similar to Xe2_LPD with respect to the features described by struct intel_display_device_info, so reuse its device descriptor. v2: - Add reference to Bspec 74201. (Shekhar) Bspec: 74201, 74304 Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://patch.msgid.link/20251103-xe3p_lpd-basic-enabling-v3-1-00e87b510ae7@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-11-06Merge branches 'acpi-cppc' and 'acpi-docs'Rafael J. Wysocki
Merge two documentation fixes for 6.18-rc5, a commet typo fix in the ACPI CPPC library (Chu Guangqing) and fixes for two ASL examples in the firmware guide (Jonas Gorski). * acpi-cppc: ACPI: CPPC: Fix typo in a comment * acpi-docs: Documentation: ACPI: i2c-muxes: fix I2C device references
2025-11-06i40e: support generic devlink param "max_mac_per_vf"Mohammad Heib
Currently the i40e driver enforces its own internally calculated per-VF MAC filter limit, derived from the number of allocated VFs and available hardware resources. This limit is not configurable by the administrator, which makes it difficult to control how many MAC addresses each VF may use. This patch adds support for the new generic devlink runtime parameter "max_mac_per_vf" which provides administrators with a way to cap the number of MAC addresses a VF can use: - When the parameter is set to 0 (default), the driver continues to use its internally calculated limit. - When set to a non-zero value, the driver applies this value as a strict cap for VFs, overriding the internal calculation. Important notes: - The configured value is a theoretical maximum. Hardware limits may still prevent additional MAC addresses from being added, even if the parameter allows it. - Since MAC filters are a shared hardware resource across all VFs, setting a high value may cause resource contention and starve other VFs. - This change gives administrators predictable and flexible control over VF resource allocation, while still respecting hardware limitations. - Previous discussion about this change: https://lore.kernel.org/netdev/20250805134042.2604897-2-dhill@redhat.com https://lore.kernel.org/netdev/20250823094952.182181-1-mheib@redhat.com Signed-off-by: Mohammad Heib <mheib@redhat.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-11-06devlink: Add new "max_mac_per_vf" generic device paramMohammad Heib
Add a new device generic parameter to controls the maximum number of MAC filters allowed per VF. For example, to limit a VF to 3 MAC addresses: $ devlink dev param set pci/0000:3b:00.0 name max_mac_per_vf \ value 3 \ cmode runtime Signed-off-by: Mohammad Heib <mheib@redhat.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-11-06Merge tag 'libcrypto-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux Pull crypto library fixes from Eric Biggers: "Two Curve25519 related fixes: - Re-enable KASAN support on curve25519-hacl64.c with gcc. - Disable the arm optimized Curve25519 code on CPU_BIG_ENDIAN kernels. It has always been broken in that configuration" * tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC
2025-11-06Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linuxLinus Torvalds
Pull fscrypt fix from Eric Biggers: "Fix an UBSAN warning that started occurring when the block layer started supporting logical_block_size > PAGE_SIZE" * tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux: fscrypt: fix left shift underflow when inode->i_blkbits > PAGE_SHIFT
2025-11-06KVM: SVM: Ensure SPEC_CTRL[63:32] is context switched between guest and hostUros Bizjak
SPEC_CTRL is an MSR, i.e. a 64-bit value, but the VMRUN assembly code assumes bits 63:32 are always zero. The bug is _currently_ benign because neither KVM nor the kernel support setting any of bits 63:32, but it's still a bug that needs to be fixed. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Suggested-by: Sean Christopherson <seanjc@google.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20251106191230.182393-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-11-06soc: qcom: socinfo: Add reserve field to support future extensionMukesh Ojha
Some of the new field added to socinfo structure with version 21, 22 and 23 which is only used by boot firmware and it is of no use for Linux.Add reserve field in socinfo so that the structure remain updated and prepared if we get any new field in future which could be used by Linux. While at it, also updates switch case for backward compatibility if the SoC runs with boot firmware which has these new version added. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251104130906.167666-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-06soc: qcom: socinfo: Add support for new fields in revision 20Mukesh Ojha
Add support for socinfo version 20. Version 20 adds a new field package id and its zeroth bit contain information that can be can be used to tune temperature thresholds on devices which might be able to withstand higher temperatures. Zeroth bit value 1 means that its heat dissipation is better and more relaxed thermal scheme can be put in place and 0 means a more aggressive scheme may be needed. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251104130906.167666-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-07erofs: avoid infinite loop due to incomplete zstd-compressed dataGao Xiang
Currently, the decompression logic incorrectly spins if compressed data is truncated in crafted (deliberately corrupted) images. Fixes: 7c35de4df105 ("erofs: Zstandard compression support") Reported-by: Robert Morris <rtm@csail.mit.edu> Closes: https://lore.kernel.org/r/50958.1761605413@localhost Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Chunhai Guo <guochunhai@vivo.com> Reviewed-by: Chao Yu <chao@kernel.org>
2025-11-06arm64: dts: qcom: kodiak: add coresight nodesJie Gan
Add TPDM, TPDA, CTI and funnel coresight devices for AOSS and QDSS blocks. Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251104-add-coresight-nodes-for-sc7280-v2-1-c67fa3890c2a@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-06Merge tag 'hardening-v6.18-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull hardening fixes from Kees Cook: "This is a work-around for a (now fixed) corner case in the arm32 build with Clang KCFI enabled. - Introduce __nocfi_generic for arm32 Clang (Nathan Chancellor)" * tag 'hardening-v6.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: libeth: xdp: Disable generic kCFI pass for libeth_xdp_tx_xmit_bulk() ARM: Select ARCH_USES_CFI_GENERIC_LLVM_PASS compiler_types: Introduce __nocfi_generic
2025-11-06hfs: fix potential use after free in hfs_correct_next_unused_CNID()Dan Carpenter
This code calls hfs_bnode_put(node) which drops the refcount and then dreferences "node" on the next line. It's only safe to use "node" when we're holding a reference so flip these two lines around. Fixes: a06ec283e125 ("hfs: add logic of correcting a next unused CNID") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/aN-Xw8KnbSnuIcLk@stanley.mountain Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-11 19:41:51 +0000