summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet
AgeCommit message (Collapse)AuthorFilesLines
2025-05-09net: enetc: move generic VLAN hash filter functions to enetc_pf_common.cWei Fang3-57/+62
The VLAN hash filters of ENETC v1 and v4 are basically the same, the only difference is that the offset of the VLAN hash filter registers has been changed in ENETC v4. So some functions like enetc_vlan_rx_add_vid() and enetc_vlan_rx_del_vid() only need to be slightly modified to be reused by ENETC v4. Currently, we just move these functions from enetc_pf.c to enetc_pf_common.c. Appropriate modifications will be made for ENETC4 in a subsequent patch. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-13-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: extract enetc_refresh_vlan_ht_filter()Wei Fang1-12/+8
Extract the common function enetc_refresh_vlan_ht_filter() from enetc_sync_vlan_ht_filter() so that it can be reused by the ENETC v4 PF and VF drivers in the future. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-12-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: enable RSS feature by defaultWei Fang3-16/+23
Receive side scaling (RSS) is a network driver technology that enables the efficient distribution of network receive processing across multiple CPUs in multiprocessor systems. Therefore, it is better to enable RSS by default so that the CPU load can be balanced and network performance can be improved when then network is enabled. Signed-off-by: Wei Fang <wei.fang@nxp.com> Acked-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-11-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: change enetc_set_rss() to void typeWei Fang1-3/+1
Actually enetc_set_rss() does not need a return value, so change its type to void. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-10-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: add RSS support for i.MX95 ENETC PFWei Fang6-13/+74
Compared with LS1028A, there are two main differences: first, i.MX95 ENETC uses NTMP 2.0 to manage the RSS table, and second, the offset of the RSS Key registers is different. Some modifications have been made in the previous patches based on these differences to ensure that the relevant interfaces are compatible with i.MX95. So it's time to add RSS support to i.MX95 ENETC PF. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-9-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: make enetc_set_rss_key() reusableWei Fang6-28/+28
Since the offset of the RSS key registers of i.MX95 ENETC is different from that of LS1028A, so add enetc_get_rss_key_base() to get the base offset for the different chips, so that enetc_set_rss_key() can be reused for this trivial thing. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-8-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: add set/get_rss_table() hooks to enetc_si_opsWei Fang5-7/+32
Since i.MX95 ENETC (v4) uses NTMP 2.0 to manage the RSS table, which is different from LS1028A ENETC (v1). In order to reuse some functions related to the RSS table, so add .get_rss_table() and .set_rss_table() hooks to enetc_si_ops. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-7-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: add debugfs interface to dump MAC filterWei Fang5-0/+116
ENETC's MAC filter consists of hash MAC filter and exact MAC filter. Hash MAC filter is a 64-bit entry hash table consisting of two 32-bit registers. Exact MAC filter is implemented by configuring MAC address filter table through command BD ring. The table is stored in ENETC's internal memory and needs to be read through command BD ring. In order to facilitate debugging, added a debugfs interface to get the relevant information about MAC filter. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-6-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: add MAC filtering for i.MX95 ENETC PFWei Fang4-0/+274
The i.MX95 ENETC supports both MAC hash filter and MAC exact filter. MAC hash filter is implenented through a 64-bit hash table to match against the hashed addresses, PF and VFs each have two MAC hash tables, one is for unicast and the other one is for multicast. But MAC exact filter is shared between SIs (PF and VFs), each table entry contains a MAC address that may be unicast or multicast and the entry also contains an SI bitmap field that indicates for which SIs the entry is valid. For i.MX95 ENETC, MAC exact filter only has 4 entries. According to the observation of the system default network configuration, the MAC filter will be configured with multiple multicast addresses, so MAC exact filter does not have enough entries to implement multicast filtering. Therefore, the current MAC exact filter is only used for unicast filtering. If the number of unicast addresses exceeds 4, then MAC hash filter is used. Note that both MAC hash filter and MAC exact filter can only be accessed by PF, VFs can notify PF to set its corresponding MAC filter through the mailbox mechanism of ENETC. But currently MAC filter is only added for i.MX95 ENETC PF. The MAC filter support of ENETC VFs will be supported in subsequent patches. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-5-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: move generic MAC filtering interfaces to enetc-coreWei Fang4-45/+51
Although only ENETC PF can access the MAC address filter table, the table entries can specify MAC address filtering for one or more SIs based on SI_BITMAP, which means that the table also supports MAC address filtering for VFs. Currently, only the ENETC v1 PF driver supports MAC address filtering. In order to add the MAC address filtering support for the ENETC v4 PF driver and VF driver in the future, the relevant generic interfaces are moved to the enetc-core driver. This lays the basis for i.MX95 ENETC PF and VFs to support MAC address filtering. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-4-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: add command BD ring support for i.MX95 ENETCWei Fang3-2/+84
The command BD ring is used to configure functionality where the underlying resources may be shared between different entities or being too large to configure using direct registers (such as lookup tables). Because the command BD and table formats of i.MX95 and LS1028A are very different, the software processing logic is also different. So add enetc4_setup_cbdr() and enetc4_teardown_cbdr() for ENETC v4 drivers. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-3-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: enetc: add initial netc-lib driver to support NTMPWei Fang4-0/+576
Some NETC functionality is controlled using control messages sent to the hardware using BD ring interface with 32B descriptor similar to transmit BD ring used on ENETC. This BD ring interface is referred to as command BD ring. It is used to configure functionality where the underlying resources may be shared between different entities or being too large to configure using direct registers. Therefore, a messaging protocol called NETC Table Management Protocol (NTMP) is provided for exchanging configuration and management information between the software and the hardware using the command BD ring interface. For the management protocol of LS1028A has been retroactively named NTMP 1.0, and its implementation is in enetc_cbdr.c and enetc_qos.c. However, NTMP of i.MX95 has been upgraded to version 2.0, which is incompatible with LS1028A, because the message formats have been changed. Therefore, add the netc-lib driver to support NTMP 2.0 to operate various tables. Note that, only MAC address filter table and RSS table are supported at the moment. More tables will be supported in subsequent patches. It is worth mentioning that the purpose of the netc-lib driver is to provide some NTMP-based generic interfaces for ENETC and NETC Switch drivers. Currently, it only supports the configurations of some tables. Interfaces such as tc flower and debugfs will be added in the future. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250506080735.3444381-2-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-09net: qede: Initialize qede_ll_ops with designated initializerNathan Chancellor1-1/+1
After a recent change [1] in clang's randstruct implementation to randomize structures that only contain function pointers, there is an error because qede_ll_ops get randomized but does not use a designated initializer for the first member: drivers/net/ethernet/qlogic/qede/qede_main.c:206:2: error: a randomized struct can only be initialized with a designated initializer 206 | { | ^ Explicitly initialize the common member using a designated initializer to fix the build. Cc: stable@vger.kernel.org Fixes: 035f7f87b729 ("randstruct: Enable Clang support") Link: https://github.com/llvm/llvm-project/commit/04364fb888eea6db9811510607bed4b200bcb082 [1] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20250507-qede-fix-clang-randstruct-v1-1-5ccc15626fba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski13-193/+294
Cross-merge networking fixes after downstream PR (net-6.15-rc6). No conflicts. Adjacent changes: net/core/dev.c: 08e9f2d584c4 ("net: Lock netdevices during dev_shutdown") a82dc19db136 ("net: avoid potential race between netdev_get_by_index_lock() and netns switch") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-08fbnic: Do not allow mailbox to toggle to ready outside fbnic_mbx_poll_tx_readyAlexander Duyck1-17/+10
We had originally thought to have the mailbox go to ready in the background while we were doing other things. One issue with this though is that we can't disable it by clearing the ready state without also blocking interrupts or calls to mbx_poll as it will just pop back to life during an interrupt. In order to prevent that from happening we can pull the code for toggling to ready out of the interrupt path and instead place it in the fbnic_mbx_poll_tx_ready path so that it becomes the only spot where the Rx/Tx can toggle to the ready state. By doing this we can prevent races where we disable the DMA and/or free buffers only to have an interrupt fire and undo what we have done. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/174654722518.499179.11612865740376848478.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-08fbnic: Pull fbnic_fw_xmit_cap_msg use out of interrupt contextAlexander Duyck1-27/+16
This change pulls the call to fbnic_fw_xmit_cap_msg out of fbnic_mbx_init_desc_ring and instead places it in the polling function for getting the Tx ready. Doing that we can avoid the potential issue with an interrupt coming in later from the firmware that causes it to get fired in interrupt context. Fixes: 20d2e88cc746 ("eth: fbnic: Add initial messaging to notify FW of our presence") Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/174654721876.499179.9839651602256668493.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-08fbnic: Improve responsiveness of fbnic_mbx_poll_tx_readyAlexander Duyck1-8/+11
There were a couple different issues found in fbnic_mbx_poll_tx_ready. Among them were the fact that we were sleeping much longer than we actually needed to as the actual FW could respond in under 20ms. The other issue was that we would just keep polling the mailbox even if the device itself had gone away. To address the responsiveness issues we can decrease the sleeps to 20ms and use a jiffies based timeout value rather than just counting the number of times we slept and then polled. To address the hardware going away we can move the check for the firmware BAR being present from where it was and place it inside the loop after the mailbox descriptor ring is initialized and before we sleep so that we just abort and return an error if the device went away during initialization. With these two changes we see a significant improvement in boot times for the driver. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/174654721224.499179.2698616208976624755.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-08fbnic: Cleanup handling of completionsAlexander Duyck1-0/+17
There was an issue in that if we were to shutdown we could be left with a completion in flight as the mailbox went away. To address that I have added an fbnic_mbx_evict_all_cmpl function that is meant to essentially create a "broken pipe" type response so that all callers will receive an error indicating that the connection has been broken as a result of us shutting down the mailbox. Fixes: 378e5cc1c6c6 ("eth: fbnic: hwmon: Add completion infrastructure for firmware requests") Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/174654720578.499179.380252598204530873.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-08fbnic: Actually flush_tx instead of stalling outAlexander Duyck1-15/+16
The fbnic_mbx_flush_tx function had a number of issues. First, we were waiting 200ms for the firmware to process the packets. We can drop this to 20ms and in almost all cases this should be more than enough time. So by changing this we can significantly reduce shutdown time. Second, we were not making sure that the Tx path was actually shut off. As such we could still have packets added while we were flushing the mailbox. To prevent that we can now clear the ready flag for the Tx side and it should stay down since the interrupt is disabled. Third, we kept re-reading the tail due to the second issue. The tail should not move after we have started the flush so we can just read it once while we are holding the mailbox Tx lock. By doing that we are guaranteed that the value should be consistent. Fourth, we were keeping a count of descriptors cleaned due to the second and third issues called out. That count is not a valid reason to be exiting the cleanup, and with the tail only being read once we shouldn't see any cases where the tail moves after the disable so the tracking of count can be dropped. Fifth, we were using attempts * sleep time to determine how long we would wait in our polling loop to flush out the Tx. This can be very imprecise. In order to tighten up the timing we are shifting over to using a jiffies value of jiffies + 10 * HZ + 1 to determine the jiffies value we should stop polling at as this should be accurate within once sleep cycle for the total amount of time spent polling. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/174654719929.499179.16406653096197423749.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-08fbnic: Add additional handling of IRQsAlexander Duyck4-59/+110
We have two issues that need to be addressed in our IRQ handling. One is the fact that we can end up double-freeing IRQs in the event of an exception handling error such as a PCIe reset/recovery that fails. To prevent that from becoming an issue we can use the msix_vector values to indicate that we have successfully requested/freed the IRQ by only setting or clearing them when we have completed the given action. The other issue is that we have several potential races in our IRQ path due to us manipulating the mask before the vector has been truly disabled. In order to handle that in the case of the FW mailbox we need to not auto-enable the IRQ and instead will be enabling/disabling it separately. In the case of the PCS vector we can mitigate this by unmapping it and synchronizing the IRQ before we clear the mask. The general order of operations after this change is now to request the interrupt, poll the FW mailbox to ready, and then enable the interrupt. For the shutdown we do the reverse where we disable the interrupt, flush any pending Tx, and then free the IRQ. I am renaming the enable/disable to request/free to be equivilent with the IRQ calls being used. We may see additions in the future to enable/disable the IRQs versus request/free them for certain use cases. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Fixes: 69684376eed5 ("eth: fbnic: Add link detection") Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/174654719271.499179.3634535105127848325.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-08fbnic: Gate AXI read/write enabling on FW mailboxAlexander Duyck3-13/+33
In order to prevent the device from throwing spurious writes and/or reads at us we need to gate the AXI fabric interface to the PCIe until such time as we know the FW is in a known good state. To accomplish this we use the mailbox as a mechanism for us to recognize that the FW has acknowledged our presence and is no longer sending any stale message data to us. We start in fbnic_mbx_init by calling fbnic_mbx_reset_desc_ring function, disabling the DMA in both directions, and then invalidating all the descriptors in each ring. We then poll the mailbox in fbnic_mbx_poll_tx_ready and when the interrupt is set by the FW we pick it up and mark the mailboxes as ready, while also enabling the DMA. Once we have completed all the transactions and need to shut down we call into fbnic_mbx_clean which will in turn call fbnic_mbx_reset_desc_ring for each ring and shut down the DMA and once again invalidate the descriptors. Fixes: 3646153161f1 ("eth: fbnic: Add register init to set PCIe/Ethernet device config") Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/174654718623.499179.7445197308109347982.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-08fbnic: Fix initialization of mailbox descriptor ringsAlexander Duyck1-9/+23
Address to issues with the FW mailbox descriptor initialization. We need to reverse the order of accesses when we invalidate an entry versus writing an entry. When writing an entry we write upper and then lower as the lower 32b contain the valid bit that makes the entire address valid. However for invalidation we should write it in the reverse order so that the upper is marked invalid before we update it. Without this change we may see FW attempt to access pages with the upper 32b of the address set to 0 which will likely result in DMAR faults due to write access failures on mailbox shutdown. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/174654717972.499179.8083789731819297034.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-08net: ibmveth: Refactored veth_pool_store for better maintainabilityDave Marquardt1-44/+67
Make veth_pool_store detect requested pool changes, close device if necessary, update pool, and reopen device. Signed-off-by: Dave Marquardt <davemarq@linux.ibm.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250506160004.328347-1-davemarq@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-08net: ti: icssg-prueth: Report BQL before sending XDP packetsMeghana Malladi1-1/+7
When sending out any kind of traffic, it is essential that the driver keeps reporting BQL of the number of bytes that have been sent so that BQL can track the amount of data in the queue and prevents it from overflowing. If BQL is not reported, the driver may continue sending packets even when the queue is full, leading to packet loss, congestion and decreased network performance. Currently this is missing in emac_xmit_xdp_frame() and this patch fixes it. Fixes: 62aa3246f462 ("net: ti: icssg-prueth: Add XDP support") Signed-off-by: Meghana Malladi <m-malladi@ti.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250506110546.4065715-4-m-malladi@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-08net: ti: icssg-prueth: Fix kernel panic during concurrent Tx queue accessMeghana Malladi2-2/+12
Add __netif_tx_lock() to ensure that only one packet is being transmitted at a time to avoid race conditions in the netif_txq struct and prevent packet data corruption. Failing to do so causes kernel panic with the following error: [ 2184.746764] ------------[ cut here ]------------ [ 2184.751412] kernel BUG at lib/dynamic_queue_limits.c:99! [ 2184.756728] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP logs: https://gist.github.com/MeghanaMalladiTI/9c7aa5fc3b7fb03f87c74aad487956e9 The lock is acquired before calling emac_xmit_xdp_frame() and released after the call returns. This ensures that the TX queue is protected from concurrent access during the transmission of XDP frames. Fixes: 62aa3246f462 ("net: ti: icssg-prueth: Add XDP support") Signed-off-by: Meghana Malladi <m-malladi@ti.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250506110546.4065715-3-m-malladi@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-08net: ti: icssg-prueth: Set XDP feature flags for ndevMeghana Malladi1-5/+4
xdp_features demonstrates what all XDP capabilities are supported on a given network device. The driver needs to set these xdp_features flag to let the network stack know what XDP features a given driver is supporting. These flags need to be set for a given ndev irrespective of any XDP program being loaded or not. Fixes: 62aa3246f462 ("net: ti: icssg-prueth: Add XDP support") Signed-off-by: Meghana Malladi <m-malladi@ti.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250506110546.4065715-2-m-malladi@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-08net: airoha: Add missing field to ppe_mbox_data structLorenzo Bianconi1-4/+6
The official Airoha EN7581 firmware requires adding max_packet field in ppe_mbox_data struct while the unofficial one used to develop the Airoha EN7581 flowtable support does not require this field. This patch does not introduce any real backwards compatible issue since EN7581 fw is not publicly available in linux-firmware or other repositories (e.g. OpenWrt) yet and the official fw version will use this new layout. For this reason this change needs to be backported. Moreover, make explicit the padding added by the compiler introducing the rsv array in init_info struct. At the same time use u32 instead of int for init_info and set_info struct definitions in ppe_mbox_data struct. Fixes: 23290c7bc190d ("net: airoha: Introduce Airoha NPU support") Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250506-airoha-en7581-fix-ppe_mbox_data-v5-1-29cabed6864d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-07ice: use DSN instead of PCI BDF for ice_adapter indexPrzemek Kitszel2-31/+22
Use Device Serial Number instead of PCI bus/device/function for the index of struct ice_adapter. Functions on the same physical device should point to the very same ice_adapter instance, but with two PFs, when at least one of them is PCI-e passed-through to a VM, it is no longer the case - PFs will get seemingly random PCI BDF values, and thus indices, what finally leds to each of them being on their own instance of ice_adapter. That causes them to don't attempt any synchronization of the PTP HW clock usage, or any other future resources. DSN works nicely in place of the index, as it is "immutable" in terms of virtualization. Fixes: 0e2bddf9e5f9 ("ice: add ice_adapter for shared data across PFs on the same NIC") Suggested-by: Jacob Keller <jacob.e.keller@intel.com> Suggested-by: Jakub Kicinski <kuba@kernel.org> Suggested-by: Jiri Pirko <jiri@resnulli.us> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20250505161939.2083581-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06net: ethernet: mtk_eth_soc: do not reset PSE when setting FEFrank Wunderlich1-3/+0
Remove redundant PSE reset. When setting FE register there is no need to reset PSE, doing so may cause FE to work abnormal. Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/3a5223473e086a4b54a2b9a44df7d9ddcc2bc75a Fixes: dee4dd10c79aa ("net: ethernet: mtk_eth_soc: ppe: add support for multiple PPEs") Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Link: https://patch.msgid.link/18f0ac7d83f82defa3342c11ef0d1362f6b81e88.1746406763.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: ethernet: mtk_eth_soc: reset all TX queues on DMA freeDaniel Golle1-4/+12
The purpose of resetting the TX queue is to reset the byte and packet count as well as to clear the software flow control XOFF bit. MediaTek developers pointed out that netdev_reset_queue would only resets queue 0 of the network device. Queues that are not reset may cause unexpected issues. Packets may stop being sent after reset and "transmit timeout" log may be displayed. Import fix from MediaTek's SDK to resolve this issue. Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/319c0d9905579a46dc448579f892f364f1f84818 Fixes: f63959c7eec31 ("net: ethernet: mtk_eth_soc: implement multi-queue support for per-port queues") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/c9ff9adceac4f152239a0f65c397f13547639175.1746406763.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06eth: fbnic: fix `tx_dropped` countingMohsin Bashir1-2/+2
Fix the tracking of rtnl_link_stats.tx_dropped. The counter `tmi.drop.frames` is being double counted whereas, the counter `tti.cm_drop.frames` is being skipped. Fixes: f2957147ae7a ("eth: fbnic: add support for TTI HW stats") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Reviewed-by: Joe Damato <jdamato@fastly.com> Link: https://patch.msgid.link/20250503020145.1868252-1-mohsin.bashr@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: ibmveth: added KUnit tests for some buffer pool functionsDave Marquardt2-0/+142
Added KUnit tests for ibmveth_remove_buffer_from_pool and ibmveth_rxq_get_buffer under new IBMVETH_KUNIT_TEST config option. Signed-off-by: Dave Marquardt <davemarq@linux.ibm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250501194944.283729-4-davemarq@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: ibmveth: Reset the adapter when unexpected states are detectedDave Marquardt2-19/+100
Reset the adapter through new function ibmveth_reset, called in WARN_ON situations. Removed conflicting and unneeded forward declaration. Signed-off-by: Dave Marquardt <davemarq@linux.ibm.com> Link: https://patch.msgid.link/20250501194944.283729-3-davemarq@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: ibmveth: Indented struct ibmveth_adapter correctlyDave Marquardt1-32/+32
Made struct ibmveth_adapter follow indentation rules Signed-off-by: Dave Marquardt <davemarq@linux.ibm.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250501194944.283729-2-davemarq@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-03net: stmmac: remove speed_mode_2500() methodRussell King (Oracle)1-3/+0
Remove the speed_mode_2500() platform method which is no longer used or necessary, being superseded by the more flexible get_interfaces() method. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASM3-0021R3-2B@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-03net: stmmac: intel: convert speed_mode_2500() to get_interfaces()Russell King (Oracle)2-15/+16
TGL platforms support either SGMII or 2500BASE-X, which is determined by reading a SERDES register. Thus, plat->phy_interface (and phylink's supported_interfaces) depend on this. Use the new .get_interfaces() method to set both plat->phy_interface and the supported_interfaces bitmap. This removes the only user of the .speed_mode_2500() method. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASLx-0021Qs-Uz@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-03net: stmmac: intel: move phy_interface init to tgl_common_data()Russell King (Oracle)1-4/+1
Move the initialisation of plat->phy_interface to tgl_common_data() as all callers set this same interface mode. This moves it to a single location to make the change to get_interfaces() more obvious. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASLs-0021Qk-Qt@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-03net: stmmac: add get_interfaces() platform methodRussell King (Oracle)1-3/+13
Add a get_interfaces() platform method to allow platforms to indicate to phylink which interface modes they support - which then allows phylink to validate on initialisation that the configured PHY interface mode is actually supported. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uASLn-0021Qd-Mi@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-03net: stmmac: use priv->plat->phy_interface directlyRussell King (Oracle)1-3/+3
Avoid using a local variable for priv->plat->phy_interface as this may be modified in the .get_interfaces() method added in a future commit. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASLi-0021QX-HG@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-03net: stmmac: use a local variable for priv->phylink_configRussell King (Oracle)1-19/+18
Use a local variable for priv->phylink_config in stmmac_phy_setup() which makes the code a bit easier to read, allowing some lines to be merged. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASLd-0021QR-Cu@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-02net: phy: factor out provider part from mdio_bus.cHeiner Kallweit1-2/+1
After 52358dd63e34 ("net: phy: remove function stubs") there's a problem if CONFIG_MDIO_BUS is set, but CONFIG_PHYLIB is not. mdiobus_scan() uses phylib functions like get_phy_device(). Bringing back the stub wouldn't make much sense, because it would allow to compile mdiobus_scan(), but the function would be unusable. The stub returned NULL, and we have the following in mdiobus_scan(): phydev = get_phy_device(bus, addr, c45); if (IS_ERR(phydev)) return phydev; So calling mdiobus_scan() w/o CONFIG_PHYLIB would cause a crash later in mdiobus_scan(). In general the PHYLIB functionality isn't optional here. Consequently, MDIO bus providers depend on PHYLIB. Therefore factor it out and build it together with the libphy core modules. In addition make all MDIO bus providers under /drivers/net/mdio depend on PHYLIB. Same applies to enetc MDIO bus provider. Note that PHYLIB selects MDIO_DEVRES, therefore we can omit this here. Fixes: 52358dd63e34 ("net: phy: remove function stubs") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202504270639.mT0lh2o1-lkp@intel.com/ Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/c74772a9-dab6-44bf-a657-389df89d85c2@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-02net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHYDaniel Golle3-16/+203
The MediaTek MT7988 SoC comes with an single built-in Ethernet PHY for 2500Base-T/1000Base-T/100Base-TX/10Base-T link partners in addition to the built-in 1GE switch. The built-in PHY only supports full duplex. Add muxes allowing to select GMAC2->2.5G PHY path and add basic support for XGMAC as the built-in 2.5G PHY is internally connected via XGMII. The XGMAC features will also be used by 5GBase-R, 10GBase-R and USXGMII SerDes modes which are going to be added once support for standalone PCS drivers is in place. In order to make use of the built-in 2.5G PHY the appropriate PHY driver as well as (proprietary) PHY firmware has to be present as well. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/9072cefbff6db969720672ec98ed5cef65e8218c.1745715380.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-02Merge branch '1GbE' of ↵Jakub Kicinski17-97/+618
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2025-04-29 (igb, igc, ixgbe, idpf) For igb: Kurt Kanzenbach adds linking of IRQs and queues to NAPI instances and adds persistent NAPI config. Lastly, he removes undesired IRQs that occur while busy polling. For igc: Kurt Kanzenbach switches the Tx mode for MQPRIO offload to harmonize the current implementation with TAPRIO. For ixgbe: Jedrzej adds separate ethtool ops for E610 devices to account for device differences. Slawomir adds devlink region support for E610 devices. For idpf: Mateusz assigns and utilizes the ptype field out of libeth_rqe_info. Michal removes unreachable code. * '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: idpf: remove unreachable code from setting mailbox idpf: assign extracted ptype to struct libeth_rqe_info field ixgbe: devlink: add devlink region support for E610 ixgbe: add E610 .set_phys_id() callback implementation ixgbe: apply different rules for setting FC on E610 ixgbe: add support for ACPI WOL for E610 ixgbe: create E610 specific ethtool_ops structure igc: Change Tx mode for MQPRIO offloading igc: Limit netdev_tc calls to MQPRIO igb: Get rid of spurious interrupts igb: Add support for persistent NAPI config igb: Link queues to NAPI instances igb: Link IRQs to NAPI instances ==================== Link: https://patch.msgid.link/20250429234651.3982025-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski40-211/+369
Cross-merge networking fixes after downstream PR (net-6.15-rc5). No conflicts or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-01net: vertexcom: mse102x: Fix RX error handlingStefan Wahren1-4/+16
In case the CMD_RTS got corrupted by interferences, the MSE102x doesn't allow a retransmission of the command. Instead the Ethernet frame must be shifted out of the SPI FIFO. Since the actual length is unknown, assume the maximum possible value. Fixes: 2f207cbf0dd4 ("net: vertexcom: Add MSE102x SPI support") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250430133043.7722-5-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-01net: vertexcom: mse102x: Add range check for CMD_RTSStefan Wahren1-2/+4
Since there is no protection in the SPI protocol against electrical interferences, the driver shouldn't blindly trust the length payload of CMD_RTS. So introduce a bounds check for incoming frames. Fixes: 2f207cbf0dd4 ("net: vertexcom: Add MSE102x SPI support") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250430133043.7722-4-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-01net: vertexcom: mse102x: Fix LEN_MASKStefan Wahren1-1/+1
The LEN_MASK for CMD_RTS doesn't cover the whole parameter mask. The Bit 11 is reserved, so adjust LEN_MASK accordingly. Fixes: 2f207cbf0dd4 ("net: vertexcom: Add MSE102x SPI support") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250430133043.7722-3-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-01net: vertexcom: mse102x: Fix possible stuck of SPI interruptStefan Wahren1-0/+8
The MSE102x doesn't provide any SPI commands for interrupt handling. So in case the interrupt fired before the driver requests the IRQ, the interrupt will never fire again. In order to fix this always poll for pending packets after opening the interface. Fixes: 2f207cbf0dd4 ("net: vertexcom: Add MSE102x SPI support") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250430133043.7722-2-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-01net: hns3: defer calling ptp_clock_register()Jian Shen1-6/+7
Currently the ptp_clock_register() is called before relative ptp resource ready. It may cause unexpected result when upper layer called the ptp API during the timewindow. Fix it by moving the ptp_clock_register() to the function end. Fixes: 0bf5eb788512 ("net: hns3: add support for PTP") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20250430093052.2400464-5-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-01net: hns3: fixed debugfs tm_qset sizeHao Lan1-1/+1
The size of the tm_qset file of debugfs is limited to 64 KB, which is too small in the scenario with 1280 qsets. The size needs to be expanded to 1 MB. Fixes: 5e69ea7ee2a6 ("net: hns3: refactor the debugfs process") Signed-off-by: Hao Lan <lanhao@huawei.com> Signed-off-by: Peiyang Wang <wangpeiyang1@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20250430093052.2400464-4-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>