summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-10-18soc: samsung: exynos-chipid: add exynos8890 SoC supportIvaylo Ivanov
Add exynos8890 information to soc_ids tables. This SoC product id is "0xE8890000". Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-10-18clk: samsung: clk-pll: simplify samsung_pll_lock_wait()André Draszik
readl_relaxed_poll_timeout_atomic() has been updated in 2023 in commit 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") to avoid usage of timekeeping APIs. It also never used udelay() when no delay was given. With the implementation avoiding timekeeping APIs, and with a caller not passing a delay, the timeout argument simply becomes a loop counter. Therefore the code here can be simplified to unconditionally use readl_relaxed_poll_timeout_atomic(). The difference being the last argument, the timeout (loop counter). Simply adjust it to pass the more generous counter in all cases. This change also allows us to drop all code around the pll_early_timeout variable as it is unused now. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://patch.msgid.link/20251013-samsung-clk-pll-simplification-v2-1-b9aab610878c@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-10-18dma-buf: heaps: cma: Create CMA heap for each CMA reserved regionMaxime Ripard
Aside from the main CMA region, it can be useful to allow userspace to allocate from the other CMA reserved regions. Indeed, those regions can have specific properties that can be useful to a specific us-case. For example, one of them platform I've been with has ECC enabled on the entire memory but for a specific region. Using that region to allocate framebuffers can be particular beneficial because enabling the ECC has a performance and memory footprint cost. Thus, exposing these regions as heaps user-space can allocate from and import wherever needed allows to cover that use-case. For now, only shared-dma-pools regions with the reusable property (ie, backed by CMA) are supported, but eventually we'll want to support other DMA pools types. Since we collected all the CMA regions created during boot, we can simply iterate over all of them to create the heaps. This has a weird interaction with the recent work on the CMA name, in particular the backward compatibility code created by commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name"). Indeed, the old name was either 'reserved', or the name of the reserved-memory region device tree node if the linux,cma-default property was set. In both these cases, we have now collected this region during boot, and we're using the same name. So we're now largely redundant with the code to handle backward compatibility code, and we can thus remove it and the associated Kconfig option. Reviewed-by: T.J. Mercier <tjmercier@google.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> [sumits: rebased the doc to latest] Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-5-04ce150ea3d9@kernel.org
2025-10-18dma-buf: heaps: cma: Register list of CMA regions at bootMaxime Ripard
In order to create a CMA heap instance for each CMA region found in the system, we need to register each of these instances. While it would appear trivial, the CMA regions are created super early in the kernel boot process, before most of the subsystems are initialized. Thus, we can't just create an exported function to create a heap from the CMA region being initialized. What we can do however is create a two-step process, where we collect all the CMA regions into an array early on, and then when we initialize the heaps we iterate over that array and create the heaps from the CMA regions we collected. Reviewed-by: T.J. Mercier <tjmercier@google.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-2-04ce150ea3d9@kernel.org
2025-10-18wifi: ath12k: Add MODULE_FIRMWARE() entriesTakashi Iwai
Some systems such as live-image or installer require the firmware information for each module declared by MODULE_FIRMWARE(), which is currently missing in ath12k driver. For addressing it, this patch adds the MODULE_FIRMWARE() entries. Like ath11k driver, we can just put the currently used firmware entries for QCN9274 and WCN7850 with wildcards. Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251003082955.11436-1-tiwai@suse.de Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-10-18drm/client: Remove holds_console_lock parameter from suspend/resumeThomas Zimmermann
No caller of the client resume/suspend helpers holds the console lock. The last such cases were removed from radeon in the patch series at [1]. Now remove the related parameter and the TODO items. v2: - update placeholders for CONFIG_DRM_CLIENT=n Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/series/151624/ # [1] Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251001143709.419736-1-tzimmermann@suse.de
2025-10-18iio: accel: fix ADXL355 startup race conditionValek Andrej
There is an race-condition where device is not full working after SW reset. Therefore it's necessary to wait some time after reset and verify shadow registers values by reading and comparing the values before/after reset. This mechanism is described in datasheet at least from revision D. Fixes: 12ed27863ea3 ("iio: accel: Add driver support for ADXL355") Signed-off-by: Valek Andrej <andrej.v@skyrain.eu> Signed-off-by: Kessler Markus <markus.kessler@hilti.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-18tpm_crb: Add idle support for the Arm FF-A start methodStuart Yoder
According to the CRB over FF-A specification [1], a TPM that implements the ABI must comply with the TCG PTP specification. This requires support for the Idle and Ready states. This patch implements CRB control area requests for goIdle and cmdReady on FF-A based TPMs. The FF-A message used to notify the TPM of CRB updates includes a locality parameter, which provides a hint to the TPM about which locality modified the CRB. This patch adds a locality parameter to __crb_go_idle() and __crb_cmd_ready() to support this. [1] https://developer.arm.com/documentation/den0138/latest/ Signed-off-by: Stuart Yoder <stuart.yoder@arm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2025-10-17Input: zforce_ts - omit error message when memory allocation failsXichao Zhao
The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Link: https://patch.msgid.link/20250822034751.244248-3-zhao.xichao@vivo.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-10-17Input: qnap-mcu-input - omit error message when memory allocation failsXichao Zhao
The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Link: https://patch.msgid.link/20250822034751.244248-2-zhao.xichao@vivo.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-10-18firewire: core: handle device quirk of TASCAM FW-1884/FW-1804/FW-1082Takashi Sakamoto
TASCAM FW-1884/FW-1804/FW-1082 is too lazy to repspond to asynchronous request at S400. The asynchronous transaction often results in timeout. This is a problematic quirk. This commit adds support for the quirk. When identifying the new quirk flag, then the transaction speed is configured at S200. Link: https://lore.kernel.org/r/20251018035532.287124-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-10-18firewire: core: determine transaction speed after detecting quirksTakashi Sakamoto
Current implementation determines the maximum transaction speed supported by the target device after reading bus information block of configuration ROM. The read operations for root directory block are then performed at the determined speed. However, some devices have quirks that cause issues when transactions are performed at the determined speed. In the first place, all devices are required to support the lowest speed (S100) and must respond successfully to any read request within the configuration ROM space. Therefore it is safe to postpone speed determination until the entire configuration ROM has been read. This commit moves the speed determination after reading root directory. Link: https://lore.kernel.org/r/20251018035532.287124-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-10-18firewire: core: code refactoring to compute transaction speedTakashi Sakamoto
This commit refactors the helper function to read the content of configuration ROM with the passed speed. Link: https://lore.kernel.org/r/20251018035532.287124-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-10-17ACPI: RIMT: Fix unused function warnings when CONFIG_IOMMU_API is disabledSunil V L
When CONFIG_IOMMU_API is disabled, some functions defined outside its conditional scope become unused, triggering compiler warnings reported by the kernel test robot. Move these function definitions inside the #ifdef CONFIG_IOMMU_API block to prevent unused function warnings when the configuration is disabled. Fixes: 8f7729552582 ("ACPI: RISC-V: Add support for RIMT") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202509280031.8Sjkr4bh-lkp@intel.com/ Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Link: https://lore.kernel.org/r/20251013181947.261759-1-sunilvl@ventanamicro.com
2025-10-17drm/xe/nvl: Define NVL-S platformMatt Roper
Provide the basic platform definitions and PCI IDs for NVL-S. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-11-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/i915/vrr: Use optimized guardband whenever VRR TG is activeAnkit Nautiyal
Currently the guardband is optimized only for platforms where the VRR timing generator is always ON. Extend the usage of optimized guardband to all VRR supporting platforms. v2: Drop check for `crtc_state->vrr.enable` and just return true unconditionally from intel_vrr_use_optimized_guardband(). (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-6-ankit.k.nautiyal@intel.com
2025-10-18drm/i915/vrr: Use the min static optimized guardbandAnkit Nautiyal
In the current VRR implementation, vrr.vmin and vrr.guardband are set such that they do not need to change when switching from fixed refresh rate to variable refresh rate. Specifically, vrr.guardband is always set to match the vblank length. This approach works for most cases, but not for LRR, where the guardband would need to change while the VRR timing generator is still active. With the VRR TG always active, live updates to guardband are unsafe and not recommended. To ensure hardware safety, guardband was moved out of the !fastset block, meaning any change now requires a full modeset. This breaks seamless LRR switching, which was previously supported. Since the problem arises from guardband being matched to the vblank length, solution is to use a minimal, sufficient static value, instead. So we use a static guardband defined during mode-set that fits within the smallest expected vblank and remains unchanged in case of features like LRR where vtotal changes. To compute this minimum guardband we take into account latencies/delays due to different features as mentioned in the Bspec. Introduce a helper to compute the minimal sufficient guardband. On platforms where the VRR timing generator is always ON, we optimize the guardband regardless of whether the display is operating in fixed or variable refresh rate mode. v2: - Use max of sagv latency and skl_wm_latency(1) for PM delay computation. (Ville) - Avoid guardband optimization for HDMI for now. (Ville) - Allow guardband optimization only for platforms with intel_vrr_always_use_vrr_tg = true. (Ville) - Add comments for PM delay and a #TODO note for HDMI. v3: Drop the variable prefill_min_guardband. (Ville) Bspec: 70151 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-5-ankit.k.nautiyal@intel.com
2025-10-18drm/i915/dp: Check if guardband can accommodate sdp latenciesAnkit Nautiyal
Check if guardband is sufficient for all DP SDP latencies. If its not, fail .compute_config_late(). Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-4-ankit.k.nautiyal@intel.com
2025-10-18drm/i915/dp: Add helper to get min sdp guardbandAnkit Nautiyal
Add a helper to compute vblank time needed for transmitting specific DisplayPort SDPs like PPS, GAMUT_METADATA, and VSC_EXT. Latency is based on line count per packet type. This will be used to ensure adequate guardband when features like DSC/HDR are enabled. v2: Correct the lines required for PPS SDP. (Jouni) Bspec: 70151 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-3-ankit.k.nautiyal@intel.com
2025-10-18drm/i915/psr: Add helper to get min psr guardbandAnkit Nautiyal
Introduce a helper to compute the max link wake latency when using Auxless/Aux wake mechanism for PSR/Panel Replay/LOBF features. This will be used to compute the minimum guardband so that the link wake latencies are accounted and these features work smoothly for higher refresh rate panels. v2: - Account for flag `req_psr2_sdp_prior_scanline` and scl lines while computing min guardband. (Jouni) - Use wake lines only for eDP with panel_replay and sel_update flags set. (Jouni) Bspec: 70151, 71477 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-2-ankit.k.nautiyal@intel.com
2025-10-17Input: pegasus-notetaker - fix potential out-of-bounds accessSeungjin Bae
In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access. Fixes: 1afca2b66aac ("Input: add Pegasus Notetaker tablet driver") Signed-off-by: Seungjin Bae <eeodqql09@gmail.com> Link: https://lore.kernel.org/r/20251007214131.3737115-2-eeodqql09@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-10-17net: dsa: lantiq_gswip: treat VID 0 like the PVIDVladimir Oltean
Documentation/networking/switchdev.rst says that VLAN-aware bridges must treat packets tagged with VID 0 the same as untagged. It appears from the documentation that setting the GSWIP_PCE_VCTRL_VID0 flag (which this driver already had defined) might achieve this. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/b220ac149922839a261b754202c05df5bb253c98.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: drop untagged on VLAN-aware bridge ports with no PVIDVladimir Oltean
Implement the required functionality, as written in Documentation/networking/switchdev.rst section "Bridge VLAN filtering", by using the "VLAN Ingress Tag Rule" feature of the switch. The bit field definitions for this were found while browsing the Intel dual BSD/GPLv2 licensed drivers for this switch IP. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/787aa807d00b726d75db2a40add215c8b8ba7466.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: put a more descriptive error print in ↵Vladimir Oltean
gswip_vlan_remove() Improve the error message printed in case of a port VLAN entry not being found upon removal. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/abd4ec58e0f0f53eb3d7027097a20af0bd7b1d6d.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: remove vlan_aware and pvid arguments from ↵Vladimir Oltean
gswip_vlan_remove() "bool pvid" is unused since commit "net: dsa: lantiq_gswip: remove legacy configure_vlan_while_not_filtering option". "bool vlan_aware" shouldn't have a role in finding the bridge VLAN. It should be identified by VID regardless of VLAN-aware or VLAN-unaware. The driver sets up VID 0 for the VLAN-unaware PVID. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/c63f89ca19269ef6c8bf00a62cacc739164b4441.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: disallow changes to privately set up VID 0Vladimir Oltean
User space can force the altering of VID 0 as it was privately set up by this driver. For example, when the port joins a VLAN-aware bridge, dsa_user_manage_vlan_filtering() will set NETIF_F_HW_VLAN_CTAG_FILTER. If the port is subsequently brought up and CONFIG_VLAN_8021Q is enabled, the vlan_vid0_add() function will want to make sure we are capable of accepting packets tagged with VID 0. Generally, DSA/switchdev drivers want to suppress that bit of help from the 8021q layer, and handle VID 0 filters themselves. The 8021q layer might actually be even detrimential, because VLANs added through vlan_vid_add() pass through dsa_user_vlan_rx_add_vid(), which is documented as this: /* This API only allows programming tagged, non-PVID VIDs */ .flags = 0, so it will force VID 0 to be reconfigured as egress-tagged, non-PVID. Whereas the driver configures it as PVID and egress-untagged, the exact opposite. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/9f68340c34b5312c3b8c6c7ecf3cfce574a3f65d.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: permit dynamic changes to VLAN filtering stateVladimir Oltean
The driver should now tolerate these changes, now that the PVID is automatically recalculated on a VLAN awareness state change. The VLAN-unaware PVID must be installed to hardware even if the joined bridge is currently VLAN-aware. Otherwise, when the bridge VLAN filtering state dynamically changes to VLAN-unaware later, this PVID will be missing. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/c58759074fb699581336dc2c2c6bf106257b134e.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: remove legacy configure_vlan_while_not_filtering optionVladimir Oltean
This driver doesn't support dynamic VLAN filtering changes, for simplicity. It expects that on a port, either gswip_vlan_add_unaware() or gswip_vlan_add_aware() is called, but not both. When !br_vlan_enabled(), the configure_vlan_while_not_filtering = false option is exactly what will prevent calls to gswip_port_vlan_add() from being issued by DSA. In fact, at the time these features were submitted: https://patchwork.ozlabs.org/project/netdev/patch/20190501204506.21579-3-hauke@hauke-m.de/ "configure_vlan_while_not_filtering = false" did not even have a name, it was implicit behaviour. It only became legacy in commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always receive bridge VLANs"). Section "Bridge VLAN filtering" of Documentation/networking/switchdev.rst describes the exact set of rules. Notably, the PVID of the port must follow the VLAN awareness state of the bridge port. A VLAN-unaware bridge port should not respond to the addition of a bridge VLAN with the PVID flag. In fact, the pvid_change() test in tools/testing/selftests/net/forwarding/bridge_vlan_unaware.sh tests exactly this. The lantiq_gswip driver indeed does not respond to the addition of PVID VLANs while VLAN-unaware in the way described above, but only because of configure_vlan_while_not_filtering. Our purpose here is to get rid of configure_vlan_while_not_filtering, so we must add more complex logic which follows the VLAN awareness state and walks through the Active VLAN table entries, to find the index of the PVID register that should be committed to hardware on each port. As a side-effect of now having a proper implementation to assign the PVID all the "VLAN upper: ..." tests of the local_termination.sh self- tests which would previously all FAIL now all PASS (or XFAIL, but that's ok). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/47dab8a8b69ebb92624b9795b723114475d3fe4e.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: merge gswip_vlan_add_unaware() and ↵Vladimir Oltean
gswip_vlan_add_aware() The two functions largely duplicate functionality. The differences consist in: - the "fid" passed to gswip_vlan_active_create(). The unaware variant always passes -1, the aware variant passes fid = priv->vlans[i].fid, where i is an index into priv->vlans[] for which priv->vlans[i].bridge is equal to the given bridge. - the "vid" is not passed to gswip_vlan_add_unaware(). It is implicitly GSWIP_VLAN_UNAWARE_PVID (zero). - The "untagged" is not passed to gswip_vlan_add_unaware(). It is implicitly true. Also, the CPU port must not be a tag member of the PVID used for VLAN-unaware bridging. - The "pvid" is not passed to gswip_vlan_add_unaware(). It is implicitly true. - The GSWIP_PCE_DEFPVID(port) register is written by the aware variant with an "idx", but with a hardcoded 0 by the unaware variant. Merge the two functions into a single unified function without any functional changes. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/2be190701d4c17038ce4b8047f9fb0bdf8abdf6e.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: remove duplicate assignment to vlan_mapping.val[0]Vladimir Oltean
When idx == -1 in gswip_vlan_add(), we set vlan_mapping.val[0] = vid, even though we do the exact same thing again outside the if/else block. Remove the duplicate assignment. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/039ecb48e038cea856a9a6230ad1543db2bc382d.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: define VLAN ID 0 constantVladimir Oltean
This patch adds an explicit definition for VID 0 to the Lantiq GSWIP DSA driver, clarifying its special meaning. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/e8862239d0bb727723cf60947d2262473b46c96d.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: dsa: lantiq_gswip: support bridge FDB entries on the CPU portVladimir Oltean
Currently, the driver takes the bridge from dsa_port_bridge_dev_get(), which only works for user ports. This is why it has to ignore FDB entries installed on the CPU port. Commit c26933639b54 ("net: dsa: request drivers to perform FDB isolation") introduced the possibility of getting the originating bridge from the passed dsa_db argument, so let's do that instead. This way, we can act on the local FDB entries coming from the bridge. Note that we do not expect FDB events for the DSA_DB_PORT database, because this driver doesn't fulfill the dsa_switch_supports_uc_filtering() requirements. So we can just return -EOPNOTSUPP and expect it will never be triggered. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/ed9d847c0356f0fec81422bdad9ebdcc6a59da79.1760566491.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17r8169: reconfigure rx unconditionally before chip reset when resumingHeiner Kallweit
There's a good chance that more chip versions suffer from the same hw issue. So let's reconfigure rx unconditionally before the chip reset when resuming. This shouldn't have any side effect on unaffected chip versions. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/a5c2e2d2-226f-4896-b8f6-45e2d91f0e24@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: phy: realtek: fix rtl8221b-vm-cg nameAleksander Jan Bajkowski
When splitting the RTL8221B-VM-CG into C22 and C45 variants, the name was accidentally changed to RTL8221B-VN-CG. This patch brings back the previous part number. Fixes: ad5ce743a6b0 ("net: phy: realtek: Add driver instances for rtl8221b via Clause 45") Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251016192325.2306757-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17dpaa2-eth: fix the pointer passed to PTR_ALIGN on Tx pathIoana Ciornei
The blamed commit increased the needed headroom to account for alignment. This means that the size required to always align a Tx buffer was added inside the dpaa2_eth_needed_headroom() function. By doing that, a manual adjustment of the pointer passed to PTR_ALIGN() was no longer correct since the 'buffer_start' variable was already pointing to the start of the skb's memory. The behavior of the dpaa2-eth driver without this patch was to drop frames on Tx even when the headroom was matching the 128 bytes necessary. Fix this by removing the manual adjust of 'buffer_start' from the PTR_MODE call. Closes: https://lore.kernel.org/netdev/70f0dcd9-1906-4d13-82df-7bbbbe7194c6@app.fastmail.com/T/#u Fixes: f422abe3f23d ("dpaa2-eth: increase the needed headroom to account for alignment") Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Tested-by: Mathew McBride <matt@traverse.com.au> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251016135807.360978-1-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: bonding: update the slave array for broadcast modeTonghao Zhang
This patch fixes ce7a381697cb ("net: bonding: add broadcast_neighbor option for 802.3ad"). Before this commit, on the broadcast mode, all devices were traversed using the bond_for_each_slave_rcu. This patch supports traversing devices by using all_slaves. Therefore, we need to update the slave array when enslave or release slave. Fixes: ce7a381697cb ("net: bonding: add broadcast_neighbor option for 802.3ad") Cc: Simon Horman <horms@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: <stable@vger.kernel.org> Reported-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/all/a97e6e1e-81bc-4a79-8352-9e4794b0d2ca@kernel.org/ Signed-off-by: Tonghao Zhang <tonghao@bamaicloud.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Link: https://patch.msgid.link/20251016125136.16568-1-tonghao@bamaicloud.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: enetc: correct the value of ENETC_RXB_TRUESIZEWei Fang
The ENETC RX ring uses the page halves flipping mechanism, each page is split into two halves for the RX ring to use. And ENETC_RXB_TRUESIZE is defined to 2048 to indicate the size of half a page. However, the page size is configurable, for ARM64 platform, PAGE_SIZE is default to 4K, but it could be configured to 16K or 64K. When PAGE_SIZE is set to 16K or 64K, ENETC_RXB_TRUESIZE is not correct, and the RX ring will always use the first half of the page. This is not consistent with the description in the relevant kernel doc and commit messages. This issue is invisible in most cases, but if users want to increase PAGE_SIZE to receive a Jumbo frame with a single buffer for some use cases, it will not work as expected, because the buffer size of each RX BD is fixed to 2048 bytes. Based on the above two points, we expect to correct ENETC_RXB_TRUESIZE to (PAGE_SIZE >> 1), as described in the comment. Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com> Link: https://patch.msgid.link/20251016080131.3127122-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: enetc: fix the deadlock of enetc_mdio_lockJianpeng Chang
After applying the workaround for err050089, the LS1028A platform experiences RCU stalls on RT kernel. This issue is caused by the recursive acquisition of the read lock enetc_mdio_lock. Here list some of the call stacks identified under the enetc_poll path that may lead to a deadlock: enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdio After enetc_poll acquires the read lock, a higher-priority writer attempts to acquire the lock, causing preemption. The writer detects that a read lock is already held and is scheduled out. However, readers under enetc_poll cannot acquire the read lock again because a writer is already waiting, leading to a thread hang. Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent recursive lock acquisition. Fixes: 6d36ecdbc441 ("net: enetc: take the MDIO lock only once per NAPI poll cycle") Signed-off-by: Jianpeng Chang <jianpeng.chang.cn@windriver.com> Acked-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251015021427.180757-1-jianpeng.chang.cn@windriver.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17ipv6: Move ipv6_fl_list from ipv6_pinfo to inet_sock.Kuniyuki Iwashima
In {tcp6,udp6,raw6}_sock, struct ipv6_pinfo is always placed at the beginning of a new cache line because 1. __alignof__(struct tcp_sock) is 64 due to ____cacheline_aligned of __cacheline_group_begin(tcp_sock_write_tx) 2. __alignof__(struct udp_sock) is 64 due to ____cacheline_aligned of struct numa_drop_counters 3. in raw6_sock, struct numa_drop_counters is placed before struct ipv6_pinfo . struct ipv6_pinfo is 136 bytes, but the last cache line is only used by ipv6_fl_list: $ pahole -C ipv6_pinfo vmlinux struct ipv6_pinfo { ... /* --- cacheline 2 boundary (128 bytes) --- */ struct ipv6_fl_socklist * ipv6_fl_list; /* 128 8 */ /* size: 136, cachelines: 3, members: 23 */ Let's move ipv6_fl_list from struct ipv6_pinfo to struct inet_sock to save a full cache line for {tcp6,udp6,raw6}_sock. Now, struct ipv6_pinfo is 128 bytes, and {tcp6,udp6,raw6}_sock have 64 bytes less, while {tcp,udp,raw}_sock retain the same size. Before: # grep -E "^(RAW|UDP[^L\-]|TCP)" /proc/slabinfo | awk '{print $1, "\t", $4}' RAWv6 1408 UDPv6 1472 TCPv6 2560 RAW 1152 UDP 1280 TCP 2368 After: # grep -E "^(RAW|UDP[^L\-]|TCP)" /proc/slabinfo | awk '{print $1, "\t", $4}' RAWv6 1344 UDPv6 1408 TCPv6 2496 RAW 1152 UDP 1280 TCP 2368 Also, ipv6_fl_list and inet_flags (SNDFLOW bit) are placed in the same cache line. $ pahole -C inet_sock vmlinux ... /* --- cacheline 11 boundary (704 bytes) was 56 bytes ago --- */ struct ipv6_pinfo * pinet6; /* 760 8 */ /* --- cacheline 12 boundary (768 bytes) --- */ struct ipv6_fl_socklist * ipv6_fl_list; /* 768 8 */ unsigned long inet_flags; /* 776 8 */ Doc churn is due to the insufficient Type column (only 1 space short). Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20251014224210.2964778-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17net: hibmcge: support pci_driver.shutdown()Jijie Shao
support pci_driver.shutdown() for hibmcge driver. Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20251014134018.1178385-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-17drm/xe/xe3p: Dump CSMQDEBUG registerWang Xin
The CSMQDEBUG is useful for the development of MQ feature. Start dumping the debug register. Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Wang Xin <x.wang@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-10-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe: Dump CURRENT_LRCA registerWang Xin
Add CURRENT_LRCA to register dump to help debugging. Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Wang Xin <x.wang@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-9-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p: Determine service copy availability from fuseMatt Roper
Xe3p introduces a dedicated SERVICE_COPY_ENABLE fuse register to reflect the availability of the service copy engines (BCS1-BCS8). Bspec: 74624 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-8-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p: Stop programming RCU_MODE's fixed slice mode settingMatt Roper
Since the hardware load balancing is no longer supported, the programming in RCU_MODE is no longer necessary. Bspec: 60382 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-7-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p_lpm: Handle MCR steeringMatt Roper
Xe3p_LPM's MCR steering has the same ranges and behavior as Xe3_LPM. However one register range that was reserved on Xe3_LPM has now become a unicast range (0x384200-0x38427F), so we need to stop consolidating the adjacent MCR ranges into a single table entry in the table. With this change to the Xe3_LPM table, we can continue to use the same table for both IP families. While we're touching this table, take the opportunity to fix a whitespace mistake and clarify that one of the other consolidated range entries includes a reserved range. Bspec: 76445 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-6-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p_lpm: Skip disabling NOA on unsupported IPsBalasubramani Vivekanandan
IP version 35 has removed "NOA Enable Signal" bit from RPM_CONFIG1 register. Skip clearing that bit on unsupported IPs. Bspec: 62391 Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-5-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe: Add GT_VER() to check version specific to gt typeLucas De Marchi
In some situations we will need to check the version of the specific gt being passed as argument, not if the device has a certain graphics/media version. This is extracted from a patch by Balasubramani Vivekanandan that may need some rework, but this helper is still useful for other enabling parts of Xe3p. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-4-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe: Drop CTC_MODE register readBalasubramani Vivekanandan
The warning was added for a condition that never triggered even for platforms prior to Xe2. It's not supported in Xe2 and in Xe3p the register is removed from the main GT. Just drop the entire function as it doesn't bring any benefit. Bspec: 62395 Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> [ Drop the entire check for CTC_MODE ] Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-3-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p: Add support for media IP versions 35.00 & 35.03Shekhar Chauhan
Xe3p_LPM/Xe3p_HPM are very similar to Xe3_LPM on the kmd interface, so it can use the same descriptor structure. Add both 35.00 and 35.03 IP versions. BSpec: 74201, 74202, 77977, 77979 Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-2-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3: Add support for graphics IP versions 30.04 & 30.05Shekhar Chauhan
Add graphics IP versions 30.04 & 30.05 and initial workarounds for these IP versions. BSpec: 74201 Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-1-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-05 02:13:45 +0000