- 27 Jun, 2024 7 commits
-
-
Christophe Roullier authored
Add Ethernet support for STM32MP25. STM32MP25 is STM32 SOC with 2 GMACs instances. GMAC IP version is SNPS 5.3x. GMAC IP configure with 2 RX and 4 TX queue. DMA HW capability register supported RX Checksum Offload Engine supported TX Checksum insertion supported Wake-Up On Lan supported TSO supported Signed-off-by:
Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by:
Simon Horman <horms@kernel.org> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Christophe Roullier authored
New STM32 SOC have 2 GMACs instances. GMAC IP version is SNPS 5.30 Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== selftests: drv-net: rss_ctx: add tests for RSS contexts Add a few tests exercising RSS context API. In addition to basic sanity checks, tests add RSS contexts, n-tuple rule to direct traffic to them (based on dst port), and qstats to make sure traffic landed where we expected. v2 adds a test for removing contexts out of order. When testing bnxt - either the new test or running more tests after the overlap test makes the device act strangely. To the point where it may start giving out ntuple IDs of 0 for all rules.. $ export NETIF=eth0 REMOTE_... $ ./drivers/net/hw/rss_ctx.py KTAP version 1 1..8 ok 1 rss_ctx.test_rss_key_indir ok 2 rss_ctx.test_rss_context ok 3 rss_ctx.test_rss_context4 # Increasing queue count 44 -> 66 # Failed to create context 32, trying to test what we got ok 4 rss_ctx.test_rss_context32 # SKIP Tested only 31 contexts, wanted 32 ok 5 rss_ctx.test_rss_context_overlap ok 6 rss_ctx.test_rss_context_overlap2 # .. sprays traffic like a headless chicken .. not ok 7 rss_ctx.test_rss_context_out_of_order ok 8 rss_ctx.test_rss_context4_create_with_cfg # Totals: pass:6 fail:1 xfail:0 xpass:0 skip:1 error:0 v2: https://lore.kernel.org/all/20240625010210.2002310-1-kuba@kernel.org v1: https://lore.kernel.org/all/20240620232902.1343834-1-kuba@kernel.org ==================== Link: https://patch.msgid.link/20240626012456.2326192-1-kuba@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Add tests focusing on indirection table configuration and creating extra RSS contexts in drivers which support it. $ export NETIF=eth0 REMOTE_... $ ./drivers/net/hw/rss_ctx.py KTAP version 1 1..8 ok 1 rss_ctx.test_rss_key_indir ok 2 rss_ctx.test_rss_context ok 3 rss_ctx.test_rss_context4 # Increasing queue count 44 -> 66 # Failed to create context 32, trying to test what we got ok 4 rss_ctx.test_rss_context32 # SKIP Tested only 31 contexts, wanted 32 ok 5 rss_ctx.test_rss_context_overlap ok 6 rss_ctx.test_rss_context_overlap2 # .. sprays traffic like a headless chicken .. not ok 7 rss_ctx.test_rss_context_out_of_order ok 8 rss_ctx.test_rss_context4_create_with_cfg # Totals: pass:6 fail:1 xfail:0 xpass:0 skip:1 error:0 Note that rss_ctx.test_rss_context_out_of_order fails with the device I tested with, but it seems to be a device / driver bug. Reviewed-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20240626012456.2326192-5-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Teach the load generator how to wait for at least given number of packets to be received. This will be useful for filtering where we'll want to send a non-trivial number of packets and make sure they landed in right queues. Reviewed-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
-
Jakub Kicinski authored
Some devices DMA stats to the host periodically. Add a helper which can wait for that to happen, based on frequency reported by the driver in ethtool. Reviewed-by:
-
Jakub Kicinski authored
We use random ports for communication. As Willem predicted this leads to occasional failures. Try to check if port is already in use by opening a socket and binding to that port. Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by:
-
- 26 Jun, 2024 28 commits
-
-
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Reduce memory footprint of mlxsw driver Amit Cohen writes: A previous patch-set used page pool to allocate buffers, to simplify the change, we first used one continuous buffer, which was allocated with order > 0. This set improves page pool usage to allocate the exact number of pages which are required for packet. This change requires using fragmented SKB, till now all the buffer was in the linear part. Note that 'skb->truesize' is decreased for small packets. This set significantly reduces memory consumption of mlxsw driver. The footprint is reduced by 26%. Patch set overview: Patch #1 calculates number of scatter/gather entries and stores the value Patch #2 converts the driver to use fragmented buffers ==================== Link: https://patch.msgid.link/cover.1719321422.git.petrm@nvidia.comSigned-off-by:
-
Amit Cohen authored
WQE (Work Queue Element) includes 3 scatter/gather entries for buffers. The buffer can be split into 3 parts, software should set address and byte count of each part. A previous patch-set used page pool to allocate buffers, to simplify the change, we first used one continuous buffer, which was allocated with order > 0. This patch improves page pool usage to allocate the exact number of pages which are required for packet. As part of init, fill WQE.address[x] and WQE.byte_count* with pages which are allocated from the pool. Fill x entries according to number of scatter/gather entries which are required for maximum packet size. When a packet is received, check the actual size and replace only the used pages. Save bytes for software overhead only as part of the first entry. This change also requires using fragmented SKB, till now all the buffer was in the linear part. Note that 'skb->truesize' is decreased for small packets. For now the maximum buffer size is 3 * PAGE_SIZE which is enough, in case that the driver will support larger MTU, we can use 'order' to allocate more than one page per scatter/gather entry. This change significantly reduces memory consumption of mlxsw driver. The footprint is reduced by 26%. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Amit Cohen authored
A previous patch-set used page pool for Rx buffers allocations. To simplify the change, we first used page pool for one allocation per packet - one continuous buffer is allocated for each packet. This can be improved by using fragmented buffers, then memory consumption will be significantly reduced. WQE (Work Queue Element) includes up to 3 scatter/gather entries for data. As preparation for fragmented buffer usage, calculate number of scatter/gather entries which are required for packet according to maximum MTU and store it for future use. For now use PAGE_SIZE for each entry, which means that maximum buffer size is 3 * PAGE_SIZE. This is enough for the maximum MTU which is supported in the driver now (10K). Warn in an unlikely case of maximum MTU which requires more than 3 pages, for now this warn should not happen with standard page size (>=4K) and maximum MTU (10K). Signed-off-by:
-
Uwe Kleine-König authored
These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. While add it, also remove commas after the sentinel entries. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # For mlxsw Reviewed-by:
Kory Maincent <Kory.maincent@bootlin.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> # for mctp-i2c Reviewed-by:
Oleksij Rempel <o.rempel@pengutronix.de> Acked-by:
-
Jakub Kicinski authored
FUJITA Tomonori says: ==================== add ethernet driver for Tehuti Networks TN40xx chips This patchset adds a new 10G ethernet driver for Tehuti Networks TN40xx chips. Note in mainline, there is a driver for Tehuti Networks (drivers/net/ethernet/tehuti/tehuti.[hc]), which supports TN30xx chips. Multiple vendors (DLink, Asus, Edimax, QNAP, etc) developed adapters based on TN40xx chips. Tehuti Networks went out of business but the drivers are still distributed under GPL2 with some of the hardware (and also available on some sites). With some changes, I try to upstream this driver with a new PHY driver in Rust. The major change is replacing the PHY abstraction layer in the original driver with phylink. TN40xx chips are used with various PHY hardware (AMCC QT2025, TI TLK10232, Aqrate AQR105, and Marvell MV88X3120, MV88X3310, and MV88E2010). I've also been working on a new PHY driver for QT2025 in Rust [1]. For now, I enable only adapters using QT2025 PHY in the PCI ID table of this driver. I've tested this driver and the QT2025 PHY driver with Edimax EN-9320 10G adapter and 10G-SR SFP+. In mainline, there are PHY drivers for AQR105 and Marvell PHYs, which could work for some TN40xx adapters with this driver. To make reviewing easier, this patchset has only basic functions. Once merged, I'll submit features like ethtool support. v11: https://lore.kernel.org/netdev/20240618051608.95208-7-fujita.tomonori@gmail.com/ v10: https://lore.kernel.org/netdev/20240611045217.78529-7-fujita.tomonori@gmail.com/ v9: https://lore.kernel.org/netdev/20240605232608.65471-1-fujita.tomonori@gmail.com/ v8: https://lore.kernel.org/netdev/20240603064955.58327-1-fujita.tomonori@gmail.com/ v7: https://lore.kernel.org/netdev/20240527203928.38206-7-fujita.tomonori@gmail.com/ v6: https://lore.kernel.org/netdev/20240512085611.79747-2-fujita.tomonori@gmail.com/ v5: https://lore.kernel.org/netdev/20240508113947.68530-1-fujita.tomonori@gmail.com/ v4: https://lore.kernel.org/netdev/20240501230552.53185-1-fujita.tomonori@gmail.com/ v3: https://lore.kernel.org/netdev/20240429043827.44407-1-fujita.tomonori@gmail.com/ v2: https://lore.kernel.org/netdev/20240425010354.32605-1-fujita.tomonori@gmail.com/ v1: https://lore.kernel.org/netdev/20240415104352.4685-1-fujita.tomonori@gmail.com/ [1] https://lore.kernel.org/netdev/20240415104701.4772-1-fujita.tomonori@gmail.com/ ==================== Link: https://patch.msgid.link/20240623235507.108147-1-fujita.tomonori@gmail.comSigned-off-by:
-
FUJITA Tomonori authored
This patch adds supports for multiple PHY hardware with phylink. The adapters with TN40xx chips use multiple PHY hardware; AMCC QT2025, TI TLK10232, Aqrate AQR105, and Marvell 88X3120, 88X3310, and MV88E2010. For now, the PCI ID table of this driver enables adapters using only QT2025 PHY. I've tested this driver and the QT2025 PHY driver (SFP+ 10G SR) with Edimax EN-9320 10G adapter. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by:
Hans-Frieder Vogt <hfdevel@gmx.net> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20240623235507.108147-8-fujita.tomonori@gmail.comSigned-off-by:
-
FUJITA Tomonori authored
This patch adds supports for mdio bus. A later path adds PHYLIB support on the top of this. Signed-off-by:
-
FUJITA Tomonori authored
This patch adds basic Rx handling. The Rx logic uses three major data structures; two ring buffers with NIC and one database. One ring buffer is used to send information to NIC about memory to be stored packets to be received. The other is used to get information from NIC about received packets. The database is used to keep the information about DMA mapping. After a packet arrived, the db is used to pass the packet to the network stack. Signed-off-by:
-
FUJITA Tomonori authored
This patch adds device specific structures to initialize the hardware with basic Tx handling. The original driver loads the embedded firmware in the header file. This driver is implemented to use the firmware APIs. The Tx logic uses three major data structures; two ring buffers with NIC and one database. One ring buffer is used to send information about packets to be sent for NIC. The other is used to get information from NIC about packet that are sent. The database is used to keep the information about DMA mapping. After a packet is sent, the db is used to free the resource used for the packet. Signed-off-by:
-
FUJITA Tomonori authored
This adds several defines to handle registers in Tehuti Networks TN40xx chips for later patches. Signed-off-by:
-
FUJITA Tomonori authored
This just adds the scaffolding for an ethernet driver for Tehuti Networks TN40xx chips. Signed-off-by:
-
FUJITA Tomonori authored
Add the Edimax Vendor ID (0x1432) for an ethernet driver for Tehuti Networks TN40xx chips. This ID can be used for Realtek 8180 and Ralink rt28xx wireless drivers. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20240623235507.108147-2-fujita.tomonori@gmail.comSigned-off-by:
-
Chris Packham authored
Update the mt7530 binding with some minor updates that make the document easier to read. Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20240624211858.1990601-1-chris.packham@alliedtelesis.co.nzSigned-off-by:
-
Jakub Kicinski authored
Ziwei Xiao says: ==================== gve: Add flow steering support To support flow steering in GVE driver, there are two adminq changes need to be made in advance. The first one is adding adminq mutex lock, which is to allow the incoming flow steering operations to be able to temporarily drop the rtnl_lock to reduce the latency for registering flow rules among several NICs at the same time. This could be achieved by the future changes to reduce the drivers' dependencies on the rtnl lock for particular ethtool ops. The second one is to add the extended adminq command so that we can support larger adminq command such as configure_flow_rule command. In that patch, there is a new added function called gve_adminq_execute_extended_cmd with the attribute of __maybe_unused. That attribute will be removed in the third patch of this series where it will use the previously unused function. And the other three patches are needed for the actual flow steering feature support in driver. ==================== Link: https://patch.msgid.link/20240625001232.1476315-1-ziweixiao@google.comSigned-off-by:
-
Jeroen de Borst authored
Implement the ethtool commands that can be used to configure and query flow-steering rules. A large part of this change consists of translating the ethtool representation of 'ntuples' to our internal gve_flow_rule and vice-versa in the new created gve_flow_rule.c Considering the possible large amount of flow rules, the driver doesn't store all the rules locally. When the user runs 'ethtool -n <nic>' to check the registered rules, the driver will send adminq command to query a limited amount of rules/rule ids(that filled in a 4096 bytes dma memory) at a time as a cache for the ethtool queries. The adminq query commands will be repeated for several times until the ethtool has queried all the needed rules. Signed-off-by:
Jeroen de Borst <jeroendb@google.com> Co-developed-by:
Ziwei Xiao <ziweixiao@google.com> Signed-off-by:
Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by:
Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by:
-
Jeroen de Borst authored
Add new adminq commands for the driver to configure and query flow rules that are stored in the device. Flow steering rules are assigned with a location that determines the relative order of the rules. Flow rules can run up to an order of millions. In such cases, storing a full copy of the rules in the driver to prepare for the ethtool query is infeasible while querying them from the device is better. That needs to be optimized too so that we don't send a lot of adminq commands. The solution here is to store a limited number of rules/rule ids in the driver in a cache. Use dma_pool to allocate 4k bytes which lets device write at most 46 flow rules(4096/88) or 1024 rule ids(4096/4) at a time. For configuring flow rules, there are 3 sub-commands: - ADD which adds a rule at the location supplied - DEL which deletes the rule at the location supplied - RESET which clears all currently active rules in the device For querying flow rules, there are also 3 sub-commands: - QUERY_RULES corresponds to ETHTOOL_GRXCLSRULE. It fills the rules in the allocated cache after querying the device - QUERY_RULES_IDS corresponds to ETHTOOL_GRXCLSRLALL. It fills the rule_ids in the allocated cache after querying the device - QUERY_RULES_STATS corresponds to ETHTOOL_GRXCLSRLCNT. It queries the device's current flow rule number and the supported max flow rule limit Signed-off-by:
-
Jeroen de Borst authored
Add a new device option to signal to the driver that the device supports flow steering. This device option also carries the maximum number of flow steering rules that the device can store. Signed-off-by:
-
Jeroen de Borst authored
The adminq command is limited to 64 bytes per entry and it's 56 bytes for the command itself at maximum. To support larger commands, we need to dma_alloc a separate memory to put the command in that memory and send the dma memory address instead of the actual command. Introduce an extended adminq command to wrap the real command with the inner opcode and the allocated dma memory address specified. Once the device receives it, it can get the real command from the given dma memory address. As designed with the device, all the extended commands will use inner opcode larger than 0xFF. Signed-off-by:
-
Ziwei Xiao authored
We were depending on the rtnl_lock to make sure there is only one adminq command running at a time. But some commands may take too long to hold the rtnl_lock, such as the upcoming flow steering operations. For such situations, it can temporarily drop the rtnl_lock, and replace it for these operations with a new adminq lock, which can ensure the adminq command execution to be thread-safe. Signed-off-by:
-
Jakub Kicinski authored
Heng Qi says: ==================== ethtool: provide the dim profile fine-tuning channel The NetDIM library provides excellent acceleration for many modern network cards. However, the default profiles of DIM limits its maximum capabilities for different NICs, so providing a way which the NIC can be custom configured is necessary. Currently, the way is based on the commonly used "ethtool -C". For example, on the server side, the virtio-net NIC with rx dim enabled has 8 queues and runs nginx. The client uses the following command to send traffic to the server: ./wrk http://server_ip:80 -c 64 -t 5 -d 30 Then adjust the default rx-profile for server dim to {.usec = 1, .pkts = 256, .comps = n/a,}, {.usec = 8, .pkts = 256, .comps = n/a,}, {.usec = 30, .pkts = 256, .comps = n/a,}, {.usec = 64, .pkts = 256, .comps = n/a,}, {.usec = 128, .pkts = 256, .comps = n/a,} The server PPS is improved by 20%+. ==================== Link: https://patch.msgid.link/20240621101353.107425-1-hengqi@linux.alibaba.comSigned-off-by:
-
Heng Qi authored
Virtio-net has different types of back-end device implementations. In order to effectively optimize the dim library's gains for different device implementations, let's use the new interface params to initialize and query dim results from a customized profile list. Signed-off-by:
Heng Qi <hengqi@linux.alibaba.com> Reviewed-by:
-
Heng Qi authored
DIM-related mode and work have been collected in one same place, so new interfaces are added to provide convenience. Signed-off-by:
-
Heng Qi authored
The NetDIM library, currently leveraged by an array of NICs, delivers excellent acceleration benefits. Nevertheless, NICs vary significantly in their dim profile list prerequisites. Specifically, virtio-net backends may present diverse sw or hw device implementation, making a one-size-fits-all parameter list impractical. On Alibaba Cloud, the virtio DPU's performance under the default DIM profile falls short of expectations, partly due to a mismatch in parameter configuration. I also noticed that ice/idpf/ena and other NICs have customized profilelist or placed some restrictions on dim capabilities. Motivated by this, I tried adding new params for "ethtool -C" that provides a per-device control to modify and access a device's interrupt parameters. Usage ======== The target NIC is named ethx. Assume that ethx only declares support for rx profile setting (with DIM_PROFILE_RX flag set in profile_flags) and supports modification of usec and pkt fields. 1. Query the currently customized list of the device $ ethtool -c ethx ... rx-profile: {.usec = 1, .pkts = 256, .comps = n/a,}, {.usec = 8, .pkts = 256, .comps = n/a,}, {.usec = 64, .pkts = 256, .comps = n/a,}, {.usec = 128, .pkts = 256, .comps = n/a,}, {.usec = 256, .pkts = 256, .comps = n/a,} tx-profile: n/a 2. Tune $ ethtool -C ethx rx-profile 1,1,n_2,n,n_3,3,n_4,4,n_n,5,n "n" means do not modify this field. $ ethtool -c ethx ... rx-profile: {.usec = 1, .pkts = 1, .comps = n/a,}, {.usec = 2, .pkts = 256, .comps = n/a,}, {.usec = 3, .pkts = 3, .comps = n/a,}, {.usec = 4, .pkts = 4, .comps = n/a,}, {.usec = 256, .pkts = 5, .comps = n/a,} tx-profile: n/a 3. Hint If the device does not support some type of customized dim profiles, the corresponding "n/a" will display. If the "n/a" field is being modified, -EOPNOTSUPP will be reported. Signed-off-by: -
Heng Qi authored
DIMLIB's capabilities are supplied by the dim, net_dim, and rdma_dim objects, and dim's interfaces solely act as a base for net_dim and rdma_dim and are not explicitly used anywhere else. rdma_dim is utilized by the infiniband driver, while net_dim is for network devices, excluding the soc/fsl driver. In this patch, net_dim relies on some NET's interfaces, thus DIMLIB needs to explicitly depend on the NET Kconfig. The soc/fsl driver uses the functions provided by net_dim, so it also needs to depend on NET. Signed-off-by:
-
Heng Qi authored
Useful macros will be used effectively elsewhere. These will be utilized in subsequent patches. Signed-off-by:
-
Jakub Kicinski authored
Geert Uytterhoeven says: ==================== ravb: Add MII support for R-Car V4M All EtherAVB instances on R-Car Gen3/Gen4 SoCs support the RGMII interface. In addition, the first two EtherAVB instances on R-Car V4M also support the MII interface, but this is not yet supported by the driver. This patch series adds support for MII on R-Car Gen4, after the customary cleanup. The corresponding pin control support is available in [1]. Compile-tested only, as all AVB interfaces on the Gray Hawk Single development board are connected to RGMII PHYs. No regressions on R-Car V4H. [1] "[PATCH/RFC] pinctrl: renesas: r8a779h0: Add AVB MII pins and groups" https://lore.kernel.org/4a0a12227f2145ef53b18bc08f45b19dcd745fc6.1718378739.git.geert+renesas@glider.be/ v1: https://lore.kernel.org/f0ef3e00aec461beb33869ab69ccb44a23d78f51.1718378166.git.geert+renesas@glider.be ==================== Link: https://patch.msgid.link/cover.1719234830.git.geert+renesas@glider.beSigned-off-by: -
Geert Uytterhoeven authored
All EtherAVB instances on R-Car Gen3/Gen4 SoCs support the RGMII interface. In addition, the first two EtherAVB instances on R-Car V4M also support the MII interface, but this is not yet supported by the driver. Add support for MII on R-Car Gen4 by adding an R-Car Gen4-specific EMAC initialization function that selects the MII clock instead of the RGMII clock when the PHY interface is MII. Note that all implementations of EtherAVB on R-Car Gen4 SoCs have the APSR register, but only MII-capable instances are documented to have the MIISELECT bit, which has a documented value of zero when reserved. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://patch.msgid.link/3a21d1d6680864aa85afff9260234c2b8054020a.1719234830.git.geert+renesas@glider.beSigned-off-by:
-
Geert Uytterhoeven authored
Move ravb_gen2_hw_info before ravb_gen3_hw_info to match ravb_match_table[] order. Signed-off-by:
-
- 25 Jun, 2024 5 commits
-
-
Li RongQing authored
This place is fetching the stats, u64_stats_update_begin()/end() should not be used, and the fetcher of stats is in the same context as the updater of the stats, so don't need any protection Suggested-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Li RongQing <lirongqing@baidu.com> Link: https://lore.kernel.org/20240621094552.53469-1-lirongqing@baidu.comSigned-off-by:
-
Yujie Liu authored
It seems that there is no definition for config IP_GRE, and it is not a dependency of other configs, so remove it. linux$ find -name Kconfig | xargs grep "IP_GRE" <-- nothing There is a IPV6_GRE config defined in net/ipv6/Kconfig. It only depends on NET_IPGRE_DEMUX but not IP_GRE. Signed-off-by:
Yujie Liu <yujie.liu@intel.com> Acked-by:
-
James Chapman authored
This fixes a sparse warning. Fixes: d18d3f0a ("l2tp: replace hlist with simple list for per-tunnel session list") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406220754.evK8Hrjw-lkp@intel.com/Signed-off-by:
James Chapman <jchapman@katalix.com> Link: https://patch.msgid.link/20240624082945.1925009-1-jchapman@katalix.comSigned-off-by:
-
Elad Yifee authored
Introduce an additional validation to ensure that the PPE index is modified exclusively for mtk_eth ingress devices. This primarily addresses the issue related to WED operation with multiple PPEs. Fixes: dee4dd10 ("net: ethernet: mtk_eth_soc: ppe: add support for multiple PPEs") Signed-off-by:
Elad Yifee <eladwf@gmail.com> Link: https://lore.kernel.org/r/20240623175113.24437-1-eladwf@gmail.comSigned-off-by:
-
Paolo Abeni authored
Vineeth Karumanchi says: ==================== net: macb: WOL enhancements - Add provisioning for queue tie-off and queue disable during suspend. - Add support for ARP packet types to WoL. - Advertise WoL attributes by default. - Extend MACB supported WoL modes to the PHY supported WoL modes. - Deprecate magic-packet property. v6: https://lore.kernel.org/netdev/20240617070413.2291511-1-vineeth.karumanchi@amd.com/ v5: https://lore.kernel.org/netdev/20240611162827.887162-1-vineeth.karumanchi@amd.com/ v4: https://lore.kernel.org/lkml/20240610053936.622237-1-vineeth.karumanchi@amd.com/ v3: https://lore.kernel.org/netdev/20240605102457.4050539-1-vineeth.karumanchi@amd.com/ v2: https://lore.kernel.org/netdev/20240222153848.2374782-1-vineeth.karumanchi@amd.com/ v1: https://lore.kernel.org/lkml/20240130104845.3995341-1-vineeth.karumanchi@amd.com/#t ==================== Link: https://lore.kernel.org/r/20240621045735.3031357-1-vineeth.karumanchi@amd.comSigned-off-by:
-
