summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
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>
2025-10-17soc: qcom: pd-mapper: Add Kaanapali compatiblePrasad Kumpatla
Add support for the Qualcomm Kaanapali SoC to the protection domain mapper. Kaanapali shares the same protection domain configuration as SM8550, except charger_pd as it move to SoCCP. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251014-knp-pdmapper-v2-v2-1-ba44422ac503@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-10-17clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resetsKonrad Dybcio
Currently, some of the USB4 clocks/resets are described, but not all of the back-end muxes are present. Configuring them properly is necessary for proper operation of the hardware. Add all the resets & muxes and wire up any unaccounted USB4 clock paths. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251003-topic-hamoa_gcc_usb4-v2-2-61d27a14ee65@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-10-17drm/i915/dp: Fix panel replay when DSC is enabledImre Deak
Prevent enabling panel replay if the sink doesn't support this due to DSC being enabled. Panel replay has two modes, updating full frames or only selected regions of the frame. If the sink doesn't support Panel Replay in full frame update mode with DSC prevent Panel Replay completely if DSC is enabled. If the sink doesn't support Panel Replay only in the selective update mode while DSC is enabled, it will still support Panel Replay in the full frame update mode, so only prevent selective updates in this case. v2: - Use Panel Replay instead of PR in debug prints. (Jouni) - Rebase on change tracking the link DSC state in the crtc state. Cc: Jouni Högander <jouni.hogander@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14869 Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-8-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the linkImre Deak
The state of all the CRTCs on an MST link must be recomputed, if DSC gets enabled on any of the CRTCs on the link. For instance an MST docking station's Panel Replay capability may depend on whether DSC is enabled on any of the dock's streams (aka CRTCs). To assist the Panel Replay state computation for a CRTC based on the above, track in the CRTC state if DSC is enabled on any CRTC on an MST link. The intel_link_bw_limits::force_fec_pipes mask is used for a reason similar to the above: enable FEC on all CRTCs of a non-UHBR (8b10b) MST link if DSC is enabled on any of the link's CRTCs. The FEC enabled state for a CRTC doesn't indicate if DSC is enabled on a UHBR MST link (FEC is always enabled by the HW for UHBR, hence it's not tracked by the intel_crtc_state::fec_enable flag for such links, where this flag is always false). Based on the above, to be able to determine the DSC state on both non-UHBR and UHBR MST links, track the more generic DSC-enabled-on-link state (instead of the FEC-enabled-on-link state) for each CRTC in intel_link_bw_limits. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-7-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Track DSC enabled status on the MST linkImre Deak
Track whether DSC is enabled on any CRTC on a link. On DP-SST (and DSI) this will always match the CRTC's DSC state, those links having only a single stream (aka CRTC). For instance, on DP-MST if DSC is enabled for CRTC#0, but disabled for CRTC#1, the DSC/FEC state for these CRTCs will be as follows: CRTC#0: - compression_enable = true - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b CRTC#1: - compression_enable = false - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b This patch only sets compression_enabled_on_link for CRTC#0 above and enables FEC on CRTC#0 if DSC was enabled on any other CRTC on the 8b10b MST link. A follow-up change will make sure that the state of all the CRTCs (CRTC#1 above) on an MST link is recomputed if DSC gets enabled on any CRTC, setting compression_enabled_on_link and fec_enable for these. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-6-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC configImre Deak
Reuse the DP-SST helper to compute the state for the FEC enabled state for DP-MST as well. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-5-imre.deak@intel.com
2025-10-17drm/i915/dp: Export helper to determine if FEC on non-UHBR links is requiredImre Deak
Export the helper function to determine if FEC is required on a non-UHBR (8b10b) SST or MST link. A follow up change will take this into use for MST as well. While at it determine the output type from the CRTC state, which allows dropping the intel_dp argument. Also make the function return the required FEC state, instead of setting this in the CRTC state, which allows only querying this requirement, without changing the state. Also rename the function to intel_dp_needs_8b10b_fec(), to clarify that the function determines if FEC is required on an 8b10b link (on 128b132b links FEC is always enabled by the HW implicitly, so the function will return false for that case). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-4-imre.deak@intel.com
2025-10-17drm/i915/dp: Ensure the FEC state stays disabled for UHBR linksImre Deak
Atm, in the DP SST case the FEC state is computed before intel_crtc_state::port_clock is initialized, hence intel_dp_is_uhbr() will always return false and the FEC state will be always computed assuming a non-UHBR link. This happens to work, since the FEC state is recomputed later in intel_dp_mtp_tu_compute_config(), where port_clock will be set already, so intel_crtc_state::fec_enable will be reset as expected for UHBR. This also depends on link rates being tried in an increasing order (i.e. from non-UHBR -> UHBR link rates) in dsc_compute_link_config(), thus intel_crtc_state::fec_enable being set for the non-UHBR rates and getting reset for the first UHBR rate as expected. A follow-up change will reuse intel_dp_fec_compute_config() for the DP MST state computation, prepare for that here, making sure that the function determines the correct intel_crtc_state::fec_enable=false state for UHBR link rates based on the above. The DP SST and MST state computation should be further unified to avoid computing/setting the intel_crtc_state::fec_enable state multiple times, but that's left for a follow-up change. For now add only code comments about this. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-3-imre.deak@intel.com
2025-10-17drm/i915/dsc: Add helper to enable the DSC configuration for a CRTCImre Deak
Add a helper to enable the DSC compression configuration for a CRTC. Follow-up changes will introduce tracking for the same DSC state on the whole link, which will need to be set whenever DSC is enabled for the CRTC. Also, according to the above, when querying the DSC state on the link, both the CRTC's and the link's DSC state must be considered. Setting the DSC configuration for a CRTC and querying the DSC configuration for the link (added by follow-up changes) is better done via helper functions based on the above, prepare for that here. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-2-imre.deak@intel.com
2025-10-17spi: airoha: driver fixes & improvementsMark Brown
Merge series from Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>: This patch series greatly improve airoha snfi driver and fix a number of serious bugs. Fixed bugs: * Fix reading/writing of flashes with more than one plane per lun * Fill the buffer with 0xff before writing * Fix reading of flashes supporting continuous reading mode * Fix error paths Improvements: * Add support of dual/quad wires spi modes in exec_op(). This also fix flash reading/writing if dirmap can't be created. * Support of dualio/quadio flash reading commands * Remove dirty hack that reads flash page settings from SNFI registers during driver startup * Add support of EN7523 SoC Patched kernel tests: root@OpenWrt:/lib/modules/6.6.79# insmod mtd_oobtest.ko dev=1 [ 263.191711] [ 263.193218] ================================================= [ 263.199014] mtd_oobtest: MTD device: 1 [ 263.202768] mtd_oobtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 263.216791] mtd_test: scanning for bad eraseblocks [ 263.221956] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 263.227361] mtd_oobtest: test 1 of 5 [ 265.077216] mtd_oobtest: writing OOBs of whole device [ 265.121767] mtd_oobtest: written up to eraseblock 0 [ 275.174147] mtd_oobtest: written up to eraseblock 256 [ 285.210279] mtd_oobtest: written up to eraseblock 512 [ 295.241724] mtd_oobtest: written up to eraseblock 768 [ 305.280167] mtd_oobtest: written up to eraseblock 1024 [ 315.326883] mtd_oobtest: written up to eraseblock 1280 [ 325.364049] mtd_oobtest: written up to eraseblock 1536 [ 335.398609] mtd_oobtest: written up to eraseblock 1792 [ 345.358981] mtd_oobtest: written 2047 eraseblocks [ 345.363694] mtd_oobtest: verifying all eraseblocks [ 345.386088] mtd_oobtest: verified up to eraseblock 0 [ 349.830833] mtd_oobtest: verified up to eraseblock 256 [ 354.276245] mtd_oobtest: verified up to eraseblock 512 [ 358.721496] mtd_oobtest: verified up to eraseblock 768 [ 363.166881] mtd_oobtest: verified up to eraseblock 1024 [ 367.612694] mtd_oobtest: verified up to eraseblock 1280 [ 372.058211] mtd_oobtest: verified up to eraseblock 1536 [ 376.503820] mtd_oobtest: verified up to eraseblock 1792 [ 380.914843] mtd_oobtest: verified 2047 eraseblocks [ 380.919660] mtd_oobtest: test 2 of 5 [ 384.202620] mtd_oobtest: writing OOBs of whole device [ 384.247584] mtd_oobtest: written up to eraseblock 0 [ 394.305121] mtd_oobtest: written up to eraseblock 256 [ 404.342199] mtd_oobtest: written up to eraseblock 512 [ 414.374204] mtd_oobtest: written up to eraseblock 768 [ 424.409891] mtd_oobtest: written up to eraseblock 1024 [ 434.453378] mtd_oobtest: written up to eraseblock 1280 [ 444.494321] mtd_oobtest: written up to eraseblock 1536 [ 454.534480] mtd_oobtest: written up to eraseblock 1792 [ 464.490962] mtd_oobtest: written 2047 eraseblocks [ 464.495681] mtd_oobtest: verifying all eraseblocks [ 464.518015] mtd_oobtest: verified up to eraseblock 0 [ 468.955635] mtd_oobtest: verified up to eraseblock 256 [ 473.395502] mtd_oobtest: verified up to eraseblock 512 [ 477.834373] mtd_oobtest: verified up to eraseblock 768 [ 482.272717] mtd_oobtest: verified up to eraseblock 1024 [ 486.712148] mtd_oobtest: verified up to eraseblock 1280 [ 491.150704] mtd_oobtest: verified up to eraseblock 1536 [ 495.589439] mtd_oobtest: verified up to eraseblock 1792 [ 499.993138] mtd_oobtest: verified 2047 eraseblocks [ 499.997951] mtd_oobtest: test 3 of 5 [ 503.404228] mtd_oobtest: writing OOBs of whole device [ 503.448822] mtd_oobtest: written up to eraseblock 0 [ 513.480773] mtd_oobtest: written up to eraseblock 256 [ 523.489361] mtd_oobtest: written up to eraseblock 512 [ 533.506896] mtd_oobtest: written up to eraseblock 768 [ 543.506268] mtd_oobtest: written up to eraseblock 1024 [ 553.506503] mtd_oobtest: written up to eraseblock 1280 [ 563.511266] mtd_oobtest: written up to eraseblock 1536 [ 573.519567] mtd_oobtest: written up to eraseblock 1792 [ 583.455111] mtd_oobtest: written 2047 eraseblocks [ 583.459837] mtd_oobtest: verifying all eraseblocks [ 583.499358] mtd_oobtest: verified up to eraseblock 0 [ 592.382953] mtd_oobtest: verified up to eraseblock 256 [ 601.267297] mtd_oobtest: verified up to eraseblock 512 [ 610.150907] mtd_oobtest: verified up to eraseblock 768 [ 619.034702] mtd_oobtest: verified up to eraseblock 1024 [ 627.919683] mtd_oobtest: verified up to eraseblock 1280 [ 636.821168] mtd_oobtest: verified up to eraseblock 1536 [ 645.705487] mtd_oobtest: verified up to eraseblock 1792 [ 654.520336] mtd_oobtest: verified 2047 eraseblocks [ 654.525134] mtd_oobtest: test 4 of 5 [ 657.578146] mtd_oobtest: attempting to start write past end of OOB [ 657.584336] mtd_oobtest: an error is expected... [ 657.588974] mtd_oobtest: error occurred as expected [ 657.593848] mtd_oobtest: attempting to start read past end of OOB [ 657.599953] mtd_oobtest: an error is expected... [ 657.604569] mtd_oobtest: error occurred as expected [ 657.609450] mtd_oobtest: attempting to write past end of device [ 657.615367] mtd_oobtest: an error is expected... [ 657.619990] mtd_oobtest: error occurred as expected [ 657.624864] mtd_oobtest: attempting to read past end of device [ 657.630715] mtd_oobtest: an error is expected... [ 657.635333] mtd_oobtest: error occurred as expected [ 657.641043] mtd_oobtest: attempting to write past end of device [ 657.646966] mtd_oobtest: an error is expected... [ 657.651574] mtd_oobtest: error occurred as expected [ 657.656451] mtd_oobtest: attempting to read past end of device [ 657.662277] mtd_oobtest: an error is expected... [ 657.666901] mtd_oobtest: error occurred as expected [ 657.671774] mtd_oobtest: test 5 of 5 [ 659.382333] mtd_oobtest: writing OOBs of whole device [ 659.388056] mtd_oobtest: written up to eraseblock 0 [ 659.393526] mtd_oobtest: written up to eraseblock 0 [ 659.704525] mtd_oobtest: written up to eraseblock 256 [ 659.710187] mtd_oobtest: written up to eraseblock 256 [ 660.021093] mtd_oobtest: written up to eraseblock 512 [ 660.026752] mtd_oobtest: written up to eraseblock 512 [ 660.338427] mtd_oobtest: written up to eraseblock 768 [ 660.344048] mtd_oobtest: written up to eraseblock 768 [ 660.655718] mtd_oobtest: written up to eraseblock 1024 [ 660.661462] mtd_oobtest: written up to eraseblock 1024 [ 660.970676] mtd_oobtest: written up to eraseblock 1280 [ 660.976386] mtd_oobtest: written up to eraseblock 1280 [ 661.286858] mtd_oobtest: written up to eraseblock 1536 [ 661.292587] mtd_oobtest: written up to eraseblock 1536 [ 661.605397] mtd_oobtest: written up to eraseblock 1792 [ 661.611142] mtd_oobtest: written up to eraseblock 1792 [ 661.918754] mtd_oobtest: written 2046 eraseblocks [ 661.923458] mtd_oobtest: verifying all eraseblocks [ 661.928812] mtd_oobtest: verified up to eraseblock 0 [ 662.072499] mtd_oobtest: verified up to eraseblock 256 [ 662.216152] mtd_oobtest: verified up to eraseblock 512 [ 662.359956] mtd_oobtest: verified up to eraseblock 768 [ 662.503238] mtd_oobtest: verified up to eraseblock 1024 [ 662.646847] mtd_oobtest: verified up to eraseblock 1280 [ 662.790603] mtd_oobtest: verified up to eraseblock 1536 [ 662.934269] mtd_oobtest: verified up to eraseblock 1792 [ 663.076329] mtd_oobtest: verified 2046 eraseblocks [ 663.081114] mtd_oobtest: finished with 0 errors [ 663.085647] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_pagetest.ko dev=1 [ 1142.213082] [ 1142.214590] ================================================= [ 1142.220433] mtd_pagetest: MTD device: 1 [ 1142.224278] mtd_pagetest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 1142.238388] mtd_test: scanning for bad eraseblocks [ 1142.243536] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 1142.248935] mtd_pagetest: erasing whole device [ 1143.962562] mtd_pagetest: erased 2047 eraseblocks [ 1143.967301] mtd_pagetest: writing whole device [ 1144.011729] mtd_pagetest: written up to eraseblock 0 [ 1154.137933] mtd_pagetest: written up to eraseblock 256 [ 1164.265201] mtd_pagetest: written up to eraseblock 512 [ 1174.393365] mtd_pagetest: written up to eraseblock 768 [ 1184.525700] mtd_pagetest: written up to eraseblock 1024 [ 1194.650920] mtd_pagetest: written up to eraseblock 1280 [ 1204.773676] mtd_pagetest: written up to eraseblock 1536 [ 1214.896934] mtd_pagetest: written up to eraseblock 1792 [ 1224.942600] mtd_pagetest: written 2047 eraseblocks [ 1224.947410] mtd_pagetest: verifying all eraseblocks [ 1225.053133] mtd_pagetest: verified up to eraseblock 0 [ 1250.760034] mtd_pagetest: verified up to eraseblock 256 [ 1276.448242] mtd_pagetest: verified up to eraseblock 512 [ 1302.138825] mtd_pagetest: verified up to eraseblock 768 [ 1327.824020] mtd_pagetest: verified up to eraseblock 1024 [ 1353.532178] mtd_pagetest: verified up to eraseblock 1280 [ 1379.234385] mtd_pagetest: verified up to eraseblock 1536 [ 1404.943865] mtd_pagetest: verified up to eraseblock 1792 [ 1430.468816] mtd_pagetest: verified 2047 eraseblocks [ 1430.473702] mtd_pagetest: crosstest [ 1430.477717] mtd_pagetest: reading page at 0x0 [ 1430.482328] mtd_pagetest: reading page at 0xffdf800 [ 1430.487469] mtd_pagetest: reading page at 0x0 [ 1430.492084] mtd_pagetest: verifying pages read at 0x0 match [ 1430.497668] mtd_pagetest: crosstest ok [ 1430.501409] mtd_pagetest: erasecrosstest [ 1430.505323] mtd_pagetest: erasing block 0 [ 1430.511511] mtd_pagetest: writing 1st page of block 0 [ 1430.517166] mtd_pagetest: reading 1st page of block 0 [ 1430.522505] mtd_pagetest: verifying 1st page of block 0 [ 1430.527739] mtd_pagetest: erasing block 0 [ 1430.532565] mtd_pagetest: writing 1st page of block 0 [ 1430.538229] mtd_pagetest: erasing block 2046 [ 1430.544181] mtd_pagetest: reading 1st page of block 0 [ 1430.549498] mtd_pagetest: verifying 1st page of block 0 [ 1430.554718] mtd_pagetest: erasecrosstest ok [ 1430.558900] mtd_pagetest: erasetest [ 1430.562381] mtd_pagetest: erasing block 0 [ 1430.567208] mtd_pagetest: writing 1st page of block 0 [ 1430.572858] mtd_pagetest: erasing block 0 [ 1430.577680] mtd_pagetest: reading 1st page of block 0 [ 1430.582990] mtd_pagetest: verifying 1st page of block 0 is all 0xff [ 1430.589279] mtd_pagetest: erasetest ok [ 1430.593023] mtd_pagetest: finished with 0 errors [ 1430.597651] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_readtest.ko dev=1 [ 1478.691648] [ 1478.693158] ================================================= [ 1478.698981] mtd_readtest: MTD device: 1 [ 1478.702829] mtd_readtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 1478.716939] mtd_test: scanning for bad eraseblocks [ 1478.722072] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 1478.727475] mtd_readtest: testing page read [ 1548.352125] mtd_readtest: finished [ 1548.355553] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_speedtest.ko dev=1 [ 1617.353002] [ 1617.354511] ================================================= [ 1617.360332] mtd_speedtest: MTD device: 1 [ 1617.364258] mtd_speedtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 1617.380150] mtd_test: scanning for bad eraseblocks [ 1617.385428] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 1621.021861] mtd_speedtest: testing eraseblock write speed [ 1700.915306] mtd_speedtest: eraseblock write speed is 3279 KiB/s [ 1700.921250] mtd_speedtest: testing eraseblock read speed [ 1734.931886] mtd_speedtest: eraseblock read speed is 7705 KiB/s [ 1738.682742] mtd_speedtest: testing page write speed [ 1818.818644] mtd_speedtest: page write speed is 3269 KiB/s [ 1818.824058] mtd_speedtest: testing page read speed [ 1852.913595] mtd_speedtest: page read speed is 7687 KiB/s [ 1856.674492] mtd_speedtest: testing 2 page write speed [ 1936.437284] mtd_speedtest: 2 page write speed is 3285 KiB/s [ 1936.442869] mtd_speedtest: testing 2 page read speed [ 1970.498124] mtd_speedtest: 2 page read speed is 7694 KiB/s [ 1970.503624] mtd_speedtest: Testing erase speed [ 1974.343389] mtd_speedtest: erase speed is 68316 KiB/s [ 1974.348479] mtd_speedtest: Testing 2x multi-block erase speed [ 1976.068855] mtd_speedtest: 2x multi-block erase speed is 152811 KiB/s [ 1976.075309] mtd_speedtest: Testing 4x multi-block erase speed [ 1977.790232] mtd_speedtest: 4x multi-block erase speed is 153301 KiB/s [ 1977.796693] mtd_speedtest: Testing 8x multi-block erase speed [ 1979.511905] mtd_speedtest: 8x multi-block erase speed is 153273 KiB/s [ 1979.518367] mtd_speedtest: Testing 16x multi-block erase speed [ 1981.230700] mtd_speedtest: 16x multi-block erase speed is 153539 KiB/s [ 1981.237249] mtd_speedtest: Testing 32x multi-block erase speed [ 1982.948381] mtd_speedtest: 32x multi-block erase speed is 153648 KiB/s [ 1982.954918] mtd_speedtest: Testing 64x multi-block erase speed [ 1984.665992] mtd_speedtest: 64x multi-block erase speed is 153655 KiB/s [ 1984.672531] mtd_speedtest: finished [ 1984.676054] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_stresstest.ko dev=1 [ 2190.651750] [ 2190.653263] ================================================= [ 2190.659087] mtd_stresstest: MTD device: 1 [ 2190.663105] mtd_stresstest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 2190.679846] mtd_test: scanning for bad eraseblocks [ 2190.684981] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 2190.690389] mtd_stresstest: doing operations [ 2190.694655] mtd_stresstest: 0 operations done [ 2214.262705] mtd_stresstest: 1024 operations done [ 2239.019612] mtd_stresstest: 2048 operations done [ 2262.820899] mtd_stresstest: 3072 operations done [ 2285.061376] mtd_stresstest: 4096 operations done [ 2308.297322] mtd_stresstest: 5120 operations done [ 2330.530459] mtd_stresstest: 6144 operations done [ 2352.651759] mtd_stresstest: 7168 operations done [ 2375.188275] mtd_stresstest: 8192 operations done [ 2397.738174] mtd_stresstest: 9216 operations done [ 2414.792572] mtd_stresstest: finished, 10000 operations done [ 2414.798257] ================================================= Speed test of original driver (with patch to fix support of flashes with more than one plane per lun) root@OpenWrt:/lib/modules/6.6.79# insmod mtd_speedtest.ko dev=1 [ 2894.142208] [ 2894.143719] ================================================= [ 2894.149556] mtd_speedtest: MTD device: 1 [ 2894.153486] mtd_speedtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 2894.168888] mtd_test: scanning for bad eraseblocks [ 2894.174023] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 2897.500416] mtd_speedtest: testing eraseblock write speed [ 2977.807233] mtd_speedtest: eraseblock write speed is 3262 KiB/s [ 2977.813171] mtd_speedtest: testing eraseblock read speed [ 3013.906597] mtd_speedtest: eraseblock read speed is 7260 KiB/s [ 3017.440320] mtd_speedtest: testing page write speed [ 3097.833394] mtd_speedtest: page write speed is 3259 KiB/s [ 3097.838812] mtd_speedtest: testing page read speed [ 3134.004981] mtd_speedtest: page read speed is 7245 KiB/s [ 3137.538423] mtd_speedtest: testing 2 page write speed [ 3217.906288] mtd_speedtest: 2 page write speed is 3260 KiB/s [ 3217.911883] mtd_speedtest: testing 2 page read speed [ 3254.049757] mtd_speedtest: 2 page read speed is 7251 KiB/s [ 3254.055254] mtd_speedtest: Testing erase speed [ 3257.599146] mtd_speedtest: erase speed is 74027 KiB/s [ 3257.604213] mtd_speedtest: Testing 2x multi-block erase speed [ 3259.320945] mtd_speedtest: 2x multi-block erase speed is 153139 KiB/s [ 3259.327413] mtd_speedtest: Testing 4x multi-block erase speed [ 3261.044585] mtd_speedtest: 4x multi-block erase speed is 153098 KiB/s [ 3261.051047] mtd_speedtest: Testing 8x multi-block erase speed [ 3262.786520] mtd_speedtest: 8x multi-block erase speed is 151479 KiB/s [ 3262.792979] mtd_speedtest: Testing 16x multi-block erase speed [ 3264.509898] mtd_speedtest: 16x multi-block erase speed is 153130 KiB/s [ 3264.516454] mtd_speedtest: Testing 32x multi-block erase speed [ 3266.233403] mtd_speedtest: 32x multi-block erase speed is 153125 KiB/s [ 3266.239961] mtd_speedtest: Testing 64x multi-block erase speed [ 3267.957985] mtd_speedtest: 64x multi-block erase speed is 153029 KiB/s [ 3267.964525] mtd_speedtest: finished [ 3267.968039] ================================================= It looks like a patched driver is a bit faster write speed: 3260 KiB/s vs 3277 KiB/s read speed: 7252 KiB/s vs 7695 KiB/s
2025-10-17spi: aspeed: Fix an IS_ERR() vs NULL bug in probe()Dan Carpenter
The platform_get_resource() function doesn't return error pointers, it returns NULL on error. Update the error checking to match. Fixes: 64d87ccfae33 ("spi: aspeed: Only map necessary address window region") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aPJpEnfK31pHz8_w@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-17HID: intel-ish-hid: ipc: Separate hibernate callbacks in dev_pm_opsZhang Lixu
The same suspend and resume callbacks are used for both suspend-to-RAM/idle and hibernation. These callbacks invoke pm_suspend_via_firmware() and pm_resume_via_firmware(), respectively. In the .freeze() of hibernation, pm_suspend_via_firmware() returns false, causing the driver to put ISH into D0i3. However, during the .thaw(), pm_resume_via_firmware() returns true, leading the driver to treat ISH as resuming from D3 instead of D0i3. The asymmetric behavior between .freeze() and .thaw() during hibernation can cause the client connection states on the firmware side and the driver side to become inconsistent. To address the inconsistent client connection states issue, separate hibernate-related callbacks (freeze, thaw) in dev_pm_ops. Since ISH does not need to save any firmware-related state when entering hibernation, it is sufficient to call pci_save_state() in .freeze() to prevent the PCI bus from changing the ISH power state. No actions are required in .thaw(). Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: Use IPC RESET instead of void message in ish_wakeup()Zhang Lixu
On ISH power-up, the bootloader enters sleep after preparing to load the main firmware, waiting for the driver to be ready. When the driver is ready, it sends a void message to wake up the bootloader and load the main firmware. The main firmware then sends MNG_RESET_NOTIFY to the driver for handshake. This void message-based IPC handshake only works if the main firmware has not been loaded. During hibernation resume, if the restore kernel has the ISH driver, the driver wakes up the bootloader to load the main firmware and perform IPC handshake. However, when switching to the image kernel, since the main firmware is already loaded, sending a void message in the .restore() callback does not trigger IPC handshake. By sending MNG_RESET_NOTIFY (IPC RESET message) in ish_wakeup() instead of a void message, we can explicitly wake up the bootloader and perform IPC handshake, regardless of the firmware state. Additionally, since ish_ipc_reset() already waits for recvd_hw_ready, the redundant wait for recvd_hw_ready in ish_hw_start() is removed. The timeout for waiting for HW ready is set to 10 seconds, matching the original timeout value used in ish_wakeup(), to ensure reliable wakeup on hardware that requires more time, such as the Lenovo ThinkPad X1 Titanium Gen 1. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-02 01:38:03 +0000