- Mar 20, 2021
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== 1GbE Intel Wired LAN Driver Updates 2021-03-19 This series contains updates to igc and e1000e drivers. Sasha removes unused defines in igc driver. Jiapeng Zhong changes bool assignments from 0/1 to false/true for igc. Wei Yongjun marks e1000e_pm_prepare() as __maybe_unused to resolve a defined but not used warning under certain configurations. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wei Yongjun authored
The function e1000e_pm_prepare() may have no callers depending on configuration, so it must be marked __maybe_unused to avoid harmless warning: drivers/net/ethernet/intel/e1000e/netdev.c:6926:12: warning: 'e1000e_pm_prepare' defined but not used [-Wunused-function] 6926 | static int e1000e_pm_prepare(struct device *dev) | ^~~~~~~~~~~~~~~~~ Fixes: ccf8b940 ("e1000e: Leverage direct_complete to speed up s2ram") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Jiapeng Zhong authored
Fix the following coccicheck warnings: ./drivers/net/ethernet/intel/igc/igc_main.c:4961:2-14: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4955:2-14: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4933:1-13: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4592:1-24: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4438:2-25: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4396:2-25: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4018:2-25: WARNING: Assignment of 0/1 to bool variable. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Tested-by:
Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Sasha Neftin authored
MII_CR_LOOPBACK masks not in use in i225 device and can be removed. Signed-off-by:
Sasha Neftin <sasha.neftin@intel.com> Tested-by:
Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Sasha Neftin authored
Force PHY speed not supported for i225 devices. MII_CR_SPEED masks not in use in i225 device and can be removed. Signed-off-by:
Sasha Neftin <sasha.neftin@intel.com> Tested-by:
Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Eric Dumazet authored
I was working on a syzbot issue, claiming one device could not be dismantled because its refcount was -1 unregister_netdevice: waiting for sit0 to become free. Usage count = -1 It would be nice if syzbot could trigger a warning at the time this reference count became negative. This patch adds CONFIG_PCPU_DEV_REFCNT options which defaults to per cpu variables (as before this patch) on SMP builds. v2: free_dev label in alloc_netdev_mqs() is moved to avoid a compiler warning (-Wunused-label), as reported by kernel test robot <lkp@intel.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Alex Elder says: ==================== net: ipa: update configuration data Each IPA version has a "data" file defining how various things are configured. This series gathers a few updates to this information: - The first patch makes all configuration data constant - The second fixes an incorrect (but seemingly harmless) value - The third simplifies things a bit by using implicit zero initialization for memory regions that are empty - The fourth adds definitions for memory regions that exist but are not yet used - The fifth use configuration data rather than conditional code to set some bus parameters ====================
-
Alex Elder authored
Define the maximum number of reads and writes to configure for the QSB masters used for IPA in configuration data. We don't use these values yet; the next commit takes care of that. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alex Elder authored
There are several memory regions that are defined starting with IPA v4.0, but which were not used for the SC7180 SoC (IPA v4.2). Even though they're not used (yet), define them so they are ready to be used for SoCs when they become supported. There are two QUOTA statistics memory regions, one for the modem and one for the AP. Define distinct names for these regions, and get rid of the definition of IPA_MEM_STATS_QUOTA. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alex Elder authored
The AP_HEADER memory region for both the SDM845 and SC7180 SoCs has zero size, and has no canaries. Defining an offset for such a zero-length region is not meaningful, so it's better not to define it at all. The size of this region is used in the code, but its value will still be zero because the memory regions are defined in statically initialized memory. For the SC7180, the STATS_DROP memory region has a zero size and no canaries as well. These regions are the only place where a zero-sized region is defined despite having no canaries. Remove them. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alex Elder authored
There should be no canary values written before the beginning of the UC_INFO memory region. This was correct for SDM845, but somehow was committed with the wrong value for SC7180. This bug seems to cause no harm, so we'll just correct it without back-porting. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alex Elder authored
All of the platform configuration data should be constant, but that isn't the case for the memory regions, interconnects, and clocks. Fix this. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sasha Neftin authored
MII_CR_RESET mask not in use in i225 device and can be removed Signed-off-by:
Sasha Neftin <sasha.neftin@intel.com> Tested-by:
Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
David S. Miller authored
Bjarni Jonasson says: ==================== Fixes applied to VCS8584 family Three different fixes applied to VSC8584 family: 1. LCPLL reset 2. Serdes calibration 3. Coma mode disabled The same fixes has already been applied to VSC8514 and most of the functionality can be reused for the VSC8584. v1 -> v2: Preserved reversed christmas tree ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjarni Jonasson authored
This patch releases coma mode for VSC8584 as done for VSC8514 in commit ca0d7fd0 ("net: phy: mscc: coma mode disabled for VSC8514") Fixes: a5afc167 ("net: phy: mscc: add support for VSC8584 PHY.") Signed-off-by:
Bjarni Jonasson <bjarni.jonasson@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjarni Jonasson authored
Introduced 'FOJI' serdes calibration in commit 85e97f0b ("net: phy: mscc: improved serdes calibration applied to VSC8514") Now including the VSC8584 family. Fixes: a5afc167 ("net: phy: mscc: add support for VSC8584 PHY.") Signed-off-by:
Bjarni Jonasson <bjarni.jonasson@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjarni Jonasson authored
Introduced LCPLL reset in commit d15e08d9fb82 ("net: phy: mscc: adding LCPLL reset to VSC8514"). Now applying this reset to the VSC8584 phy familiy. Fixes: a5afc167 ("net: phy: mscc: add support for VSC8584 PHY.") Signed-off-by:
Bjarni Jonasson <bjarni.jonasson@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Michael reports that after the blamed patch, unbinding a VF would cause these transactions to remain pending, and trigger some warnings with the DMA API debug: $ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fsl_enetc_vf 0000:00:01.0: Adding to iommu group 19 fsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002) fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0 $ echo 0 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs DMA-API: pci 0000:00:01.0: device driver has pending DMA allocations while released from device [count=1] One of leaked entries details: [size=2048 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent] WARNING: CPU: 0 PID: 2547 at kernel/dma/debug.c:853 dma_debug_device_change+0x174/0x1c8 (...) Call trace: dma_debug_device_change+0x174/0x1c8 blocking_notifier_call_chain+0x74/0xa8 device_release_driver_internal+0x18c/0x1f0 device_release_driver+0x20/0x30 pci_stop_bus_device+0x8c/0xe8 pci_stop_and_remove_bus_device+0x20/0x38 pci_iov_remove_virtfn+0xb8/0x128 sriov_disable+0x3c/0x110 pci_disable_sriov+0x24/0x30 enetc_sriov_configure+0x4c/0x108 sriov_numvfs_store+0x11c/0x198 (...) DMA-API: Mapped at: dma_entry_alloc+0xa4/0x130 debug_dma_alloc_coherent+0xbc/0x138 dma_alloc_attrs+0xa4/0x108 enetc_setup_cbdr+0x4c/0x1d0 enetc_vf_probe+0x11c/0x250 pci 0000:00:01.0: Removing from iommu group 19 This happens because stupid me moved enetc_teardown_cbdr outside of enetc_free_si_resources, but did not bother to keep calling enetc_teardown_cbdr from all the places where enetc_free_si_resources was called. In particular, now it is no longer called from the main unbind function, just from the probe error path. Fixes: 4b47c0b8 ("net: enetc: don't initialize unused ports from a separate code path") Reported-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by:
Michael Walle <michael@walle.cc> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
There is a spelling mistake in an error message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wei Yongjun authored
The driver allocates the spinlock but not initialize it. Use spin_lock_init() on it to initialize it correctly. Fixes: d8ce30e0 ("octeontx2-pf: add tc flower stats handler for hw offloads") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Use the lower_32_bits/upper_32_bits macros to simplify the code. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c: In function ‘mgmt_recv_msg_handler’: drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c:443:18: warning: unused variable ‘pdev’ [-Wunused-variable] 443 | struct pci_dev *pdev = pf_to_mgmt->hwif->pdev; | ^~~~ Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Daode Huang says: ==================== net: hinic; make some cleanup for hinic This set try to remove the unnecessary output message, add a blank line, remove the dupliate word and change the deprecated strlcp functions in hinic driver, for details, please refer to each patch. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daode Huang authored
Usage of strlcpy in linux kernel has been recently deprecated[1], so convert hinic driver to strscpy [1] https://lore.kernel.org/lkml/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL =V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by:
Daode Huang <huangdaode@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daode Huang authored
There is a duplicate "the" in the comment, so delete it. Signed-off-by:
Daode Huang <huangdaode@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daode Huang authored
There should be a blank line after declarations, so just add it. Signed-off-by:
Daode Huang <huangdaode@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daode Huang authored
This patch removes unnecessary out of memory message in hinic driver, fixes the following checkpatch.pl warning: "WARNING: Possible unnecessary 'out of memory' message" Signed-off-by:
Daode Huang <huangdaode@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sieng Piaw Liew authored
Using napi_alloc_skb in NAPI context avoids enable/disable IRQs, which increases iperf3 result by a few Mbps. Since napi_alloc_skb() uses NET_IP_ALIGN, convert other alloc methods to the same padding. Tested on Intel Core2 and AMD K10 platforms. Signed-off-by:
Sieng Piaw Liew <liew.s.piaw@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sieng Piaw Liew authored
Changing to napi_gro_receive() improves efficiency significantly. Tested on Intel Core2-based motherboards and iperf3. Signed-off-by:
Sieng Piaw Liew <liew.s.piaw@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michael Walle authored
Here is what Vladimir says about it: at803x_aneg_done() keeps the aneg reporting as "not done" even when the copper-side link was reported as up, but the in-band autoneg has not finished. That was the _intended_ behavior when that code was introduced, and Heiner have said about it [1]: | That's not nice from the PHY: | It signals "link up", and if the system asks the PHY for link details, | then it sheepishly says "well, link is *almost* up". If the specification of phy_aneg_done behavior does not include in-band autoneg (and it doesn't), then this piece of code does not belong here. The fact that we can no longer trigger this code from phylib is yet another reason why it fails at its intended (and wrong) purpose and should be removed. Removing the SGMII link check, would just keep the call to genphy_aneg_done(), which is also the fallback. Thus we can just remove at803x_aneg_done() altogether. [1] https://lore.kernel.org/netdev/fdf0074a-2572-5914-6f3e-77202cbf96de@gmail.com/ Suggested-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Kurt Kanzenbach authored
When using short intervals e.g. below one millisecond, large packets won't be transmitted at all. The software implementations checks whether the packet can be fit into the remaining interval. Therefore, it takes the packet length and the transmission speed into account. That is correct. However, for large packets it may be that the transmission time exceeds the interval resulting in no packet transmission. The same situation works fine with hardware offloading applied. The problem has been observed with the following schedule and iperf3: |tc qdisc replace dev lan1 parent root handle 100 taprio \ | num_tc 8 \ | map 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 \ | queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ | base-time $base \ | sched-entry S 0x40 500000 \ | sched-entry S 0xbf 500000 \ | clockid CLOCK_TAI \ | flags 0x00 [...] |root@tsn:~# iperf3 -c 192.168.2.105 |Connecting to host 192.168.2.105, port 5201 |[ 5] local 192.168.2.121 port 52610 connected to 192.168.2.105 port 5201 |[ ID] Interval Transfer Bitrate Retr Cwnd |[ 5] 0.00-1.00 sec 45.2 KBytes 370 Kbits/sec 0 1.41 KBytes |[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes After debugging, it seems that the packet length stored in the SKB is about 7000-8000 bytes. Using a 100 Mbit/s link the transmission time is about 600us which larger than the interval of 500us. Therefore, segment the SKB into smaller chunks if the packet is too big. This yields similar results than the hardware offload: |root@tsn:~# iperf3 -c 192.168.2.105 |Connecting to host 192.168.2.105, port 5201 |- - - - - - - - - - - - - - - - - - - - - - - - - |[ ID] Interval Transfer Bitrate Retr |[ 5] 0.00-10.00 sec 48.9 MBytes 41.0 Mbits/sec 0 sender |[ 5] 0.00-10.02 sec 48.7 MBytes 40.7 Mbits/sec receiver Furthermore, the segmentation can be skipped for the full offload case, as the driver or the hardware is expected to handle this. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Mar 19, 2021
-
-
Bhaskar Chowdhury authored
s/verfied/verified/ Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Alexander Lobakin says: ==================== net: avoid retpoline overhead on VLAN and TEB GRO dev_gro_receive() uses indirect calls for IP GRO functions, but it works only for the outermost headers and untagged frames. Simple VLAN tag before an IP header restores the performance hit. This simple series straightens the GRO calls for IP headers going after VLAN tag or inner Ethernet header (GENEVE, NvGRE, VxLAN) for retpolined kernels. ====================
-
Alexander Lobakin authored
The two most popular headers going after Ethernet are IPv4 and IPv6. Retpoline overhead for them is addressed only in dev_gro_receive(), when they lie right after the outermost Ethernet header. Use the indirect call wrappers in TEB (Transparent Ethernet Bridging, such as GENEVE, NvGRE, VxLAN etc.) GRO receive code to reduce the penalty when processing the inner headers. Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexander Lobakin authored
The two most popular headers going after VLAN are IPv4 and IPv6. Retpoline overhead for them is addressed only in dev_gro_receive(), when they lie right after the outermost Ethernet header. Use the indirect call wrappers in VLAN GRO receive code to reduce the penalty on receiving tagged frames (when hardware stripping is off or not available). Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexander Lobakin authored
call_gro_receive() is used to limit GRO recursion, but it works only with callback pointers. There's a combined version of call_gro_receive() + INDIRECT_CALL_2() in <net/inet_common.h>, but it doesn't check for IPv6 modularity. Add a similar new helper to cover both of these. It can and will be used to avoid retpoline overhead when IP header lies behind another offloaded proto. Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexander Lobakin authored
If some source file includes <net/gro.h>, but doesn't include <linux/indirect_call_wrapper.h>: In file included from net/8021q/vlan_core.c:7: ./include/net/gro.h:6:1: warning: data definition has no type or storage class 6 | INDIRECT_CALLABLE_DECLARE(struct sk_buff *ipv6_gro_receive(struct list_head *, | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./include/net/gro.h:6:1: error: type defaults to ‘int’ in declaration of ‘INDIRECT_CALLABLE_DECLARE’ [-Werror=implicit-int] [...] Include <linux/indirect_call_wrapper.h> directly. It's small and won't pull lots of dependencies. Also add some incomplete struct declarations to be fully stacked. Fixes: 04f00ab2 ("net/core: move gro function declarations to separate header ") Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bhaskar Chowdhury authored
s/serisouly/seriously/ ...and the sentence construction. Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Shannon Nelson says: ==================== ionic fixes These are a few little fixes and cleanups found while working on other features and more testing. ====================
-
Shannon Nelson authored
Don't destroy the adminq while there is an outstanding request. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-