- 13 Sep, 2020 4 commits
-
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'rocker_dma_ring_create()' GFP_KERNEL can be used because it is already used in the same function just a few lines above. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'sc92031_open()' GFP_KERNEL can be used because it is a '.ndo_open' function and no lock is taken in the between. '.ndo_open' functions are synchronized with the rtnl_lock() semaphore. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'tlan_init()' GFP_KERNEL can be used because it is only called from a probe function or a module_init function and no lock is taken in the between. The call chain is: tlan_probe (module_init function) --> tlan_eisa_probe or tlan_init_one (probe function) then in both cases: --> tlan_probe1 --> tlan_init @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: -
Luo Jiaxing authored
We found a set but not used variable 'ring_cons' in mlx4_en_xmit(), it will cause a warning when build the kernel. And after checking the commit record of this function, we found that it was introduced by a previous patch. So, We delete this redundant assignment code. Fixes: 488a9b48 ("net/mlx4_en: Wake TX queues only when there's enough room") Signed-off-by:
Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by:
-
- 12 Sep, 2020 27 commits
-
-
Divya Koppera authored
LAN8814 is a low-power, quad-port triple-speed (10BASE-T/100BASETX/1000BASE-T) Ethernet physical layer transceiver (PHY). It supports transmission and reception of data on standard CAT-5, as well as CAT-5e and CAT-6, unshielded twisted pair (UTP) cables. LAN8814 supports industry-standard QSGMII (Quad Serial Gigabit Media Independent Interface) and Q-USGMII (Quad Universal Serial Gigabit Media Independent Interface) providing chip-to-chip connection to four Gigabit Ethernet MACs using a single serialized link (differential pair) in each direction. The LAN8814 SKU supports high-accuracy timestamping functions to support IEEE-1588 solutions using Microchip Ethernet switches, as well as customer solutions based on SoCs and FPGAs. The LAN8804 SKU has same features as that of LAN8814 SKU except that it does not support 1588, SyncE, or Q-USGMII with PCH/MCH. This adds support for 10BASE-T, 100BASE-TX, and 1000BASE-T, QSGMII link with the MAC. Signed-off-by: Divya Koppera<divya.koppera@microchip.com> Signed-off-by: -
Barry Song authored
Rather than doing request_irq and then disabling the irq immediately, it should be safer to use IRQ_NOAUTOEN flag for the irq. It removes any gap between request_irq() and disable_irq(). Cc: Salil Mehta <salil.mehta@huawei.com> Reviewed-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
Barry Song <song.bao.hua@hisilicon.com> Signed-off-by:
-
David S. Miller authored
Grygorii Strashko says: ==================== net: ethernet: ti: ale: add static configuration As existing, as newly introduced CPSW ALE versions have differences in supported features and ALE table formats. Especially it's actual for the recent AM65x/J721E/J7200 and future AM64x SoCs, which supports more features like: auto-aging, classifiers, Link aggregation, additional HW filtering, etc. The existing ALE configuration interface is not practical in terms of adding new features and requires consumers to program a lot static parameters. And any attempt to add new features will case endless adding and maintaining different combination of flags and options. Because CPSW ALE configuration is static and fixed for SoC (or set of SoC), It is reasonable to add support for static ALE configurations inside ALE module. This series introduces static ALE configuration table for different ALE variants and provides option for consumers to select required ALE configuration by providing ALE const char *dev_id identifier (Patch 2). And all existing driver have been switched to use new approach (Patches 3-6). After this ALE HW auto-ageing feature can be enabled for AM65x CPSW ALE variant (Patch 7). Finally, Patches 8-9 introduces tables to describe the ALE VLAN entries fields as the ALE VLAN entries are too much differ between different TI CPSW ALE versions. So, handling them using flags, defines and get/set functions are became over-complicated. Patch 1 - is preparation patch Changes in v3: - fixed comment for Patch 2 Changes in v2: - fixed sparse warnings v2: https://lore.kernel.org/patchwork/cover/1301684/ v1: https://lore.kernel.org/patchwork/cover/1301048/ ==================== Signed-off-by:
-
Grygorii Strashko authored
The TI J721E (CPSW9g) ALE version is similar, in general, to Sitara AM3/4/5 CPSW ALE, but has more extended functions and different ALE VLAN entry format. This patch adds support for for multi port TI J721E (CPSW9g) ALE variant. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Grygorii Strashko authored
The ALE VLAN entries are too much differ between different TI CPSW ALE versions. So, handling them using flags, defines and get/set functions became over-complicated. This patch introduces tables to describe the ALE VLAN entries fields, which are different between TI CPSW ALE versions, and new get/set access functions. It also allows to detect incorrect access to not available ALL entry fields. Signed-off-by:
-
Grygorii Strashko authored
The AM65x ALE supports HW auto-ageing which can be enabled by programming ageing interval in ALE_AGING_TIMER register. For this CPSW fck_clk frequency has to be know by ALE. This patch extends cpsw_ale_params with bus_freq field and enables ALE HW auto ageing for AM65x CPSW2G ALE version. Signed-off-by:
-
Grygorii Strashko authored
Hence all existing driver updated to use ALE dev_id the usage of ale dev_id can be made mandatory and cpsw_ale_create() can be updated to use "features" property from ALE static configuration. Signed-off-by:
-
Grygorii Strashko authored
The previous patch has introduced possibility to select CPSW ALE by using ALE dev_id identifier. Switch TI TI AM65x/J721E CPSW NUSS driver to use dev_id. Signed-off-by:
-
Grygorii Strashko authored
The previous patch has introduced possibility to select CPSW ALE by using ALE dev_id identifier. Switch TI Keystone 2 NETCP driver to use dev_id and perform clean up by removing "ale_entries" configuration code. Signed-off-by:
-
Grygorii Strashko authored
The previous patch has introduced possibility to select CPSW ALE by using ALE dev_id identifier. Switch TI cpsw driver to use dev_id="cpsw" and perform clean up by removing "ale_entries" configuration code. Signed-off-by:
-
Grygorii Strashko authored
As existing, as newly introduced CPSW ALE versions have differences in supported features and ALE table formats. Especially it's actual for the recent AM65x/J721E/J7200 SoC and feature AM64x, which supports features like: auto-aging, classifiers, Link aggregation, additional hw filtering, etc. Existing ALE configuration interface is not practical in terms of adding new features and requires consumers to program a lot static parameters. Any attempt to add new options will case endless adding and maintaining different combination of flags and options. Hence CPSW ALE configuration is static and fixed for SoC (or set of SoC) It is reasonable to add support for static ALE configurations inside ALE module. This patch adds static ALE configuration table for different ALE versions and provides option for consumers to select required ALE configuration by providing ALE const char *dev_id identifier. This feature is not enabled by default until existing CPSW drivers will be modified by follow up patches. Signed-off-by:
-
Grygorii Strashko authored
Add cpsw_ale_get_num_entries() API to return number of ALE table entries and update existing drivers to use it. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== DSA tag_8021q cleanup This small series tries to consolidate the VLAN handling in DSA a little bit. It reworks tag_8021q to be minimally invasive to the dsa_switch_ops structure. This makes the rest of the code a bit easier to follow. ==================== Signed-off-by: -
Vladimir Oltean authored
This reverts commit 314f76d7. Citing that commit message, the call graph was: dsa_slave_vlan_rx_add_vid dsa_port_setup_8021q_tagging | | | | | +-------------+ | | v v dsa_port_vid_add dsa_slave_port_obj_add | | +-------+ +-------+ | | v v dsa_port_vlan_add Now that tag_8021q has its own ops structure, it no longer relies on dsa_port_vid_add, and therefore on the dsa_switch_ops to install its VLANs. So dsa_port_vid_add now only has one single caller. So we can simplify the call graph to what it was before, aka: dsa_slave_vlan_rx_add_vid dsa_slave_port_obj_add | | +-------+ +-------+ | | v v dsa_port_vlan_add Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
While working on another tag_8021q driver implementation, some things became apparent: - It is not mandatory for a DSA driver to offload the tag_8021q VLANs by using the VLAN table per se. For example, it can add custom TCAM rules that simply encapsulate RX traffic, and redirect & decapsulate rules for TX traffic. For such a driver, it makes no sense to receive the tag_8021q configuration through the same callback as it receives the VLAN configuration from the bridge and the 8021q modules. - Currently, sja1105 (the only tag_8021q user) sets a priv->expect_dsa_8021q variable to distinguish between the bridge calling, and tag_8021q calling. That can be improved, to say the least. - The crosschip bridging operations are, in fact, stateful already. The list of crosschip_links must be kept by the caller and passed to the relevant tag_8021q functions. So it would be nice if the tag_8021q configuration was more self-contained. This patch attempts to do that. Create a struct dsa_8021q_context which encapsulates a struct dsa_switch, and has 2 function pointers for adding and deleting a VLAN. These will replace the previous channel to the driver, which was through the .port_vlan_add and .port_vlan_del callbacks of dsa_switch_ops. Also put the list of crosschip_links into this dsa_8021q_context. Drivers that don't support cross-chip bridging can simply omit to initialize this list, as long as they dont call any cross-chip function. The sja1105_vlan_add and sja1105_vlan_del functions are refactored into a smaller sja1105_vlan_add_one, which now has 2 entry points: - sja1105_vlan_add, from struct dsa_switch_ops - sja1105_dsa_8021q_vlan_add, from the tag_8021q ops But even this change is fairly trivial. It just reflects the fact that for sja1105, the VLANs from these 2 channels end up in the same hardware table. However that is not necessarily true in the general sense (and that's the reason for making this change). The rest of the patch is mostly plain refactoring of "ds" -> "ctx". The dsa_8021q_context structure needs to be propagated because adding a VLAN is now done through the ops function pointers inside of it. Signed-off-by:
-
Vladimir Oltean authored
There is no point in calling dsa_port_setup_8021q_tagging for each individual port. Additionally, it will become more difficult to do that when we'll have a context structure to tag_8021q (next patch). So refactor this now. Signed-off-by:
-
Vladimir Oltean authored
The previous assumption was that the caller would already have this header file included. Signed-off-by:
-
Rohit Maheshwari authored
This patch moves complete nic tls offload (kTLS) code from crypto directory to drivers/net/ethernet/chelsio/inline_crypto/ch_ktls directory. nic TLS is made a separate ULD of cxgb4. Signed-off-by:
Rohit Maheshwari <rohitm@chelsio.com> Signed-off-by:
-
David S. Miller authored
Edward Cree says: ==================== sfc: encap offloads on EF10 EF10 NICs from the 8000 series onwards support TX offloads (checksumming, TSO) on VXLAN- and NVGRE-encapsulated packets. This series adds driver support for these offloads. Changes from v1: * Fix 'no TXQ of type' error handling in patch #1 (and clear up the misleading comment that inspired the wrong version) * Add comment in patch #5 explaining what the deal with TSOv3 is ==================== Signed-off-by: -
Edward Cree authored
Necessitates an .ndo_features_check, as the EF10 datapath has several limitations on what it can handle. Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Edward Cree authored
>From the 8000 series onwards, EF10 NICs with suitable firmware are able to perform TSO within VXLAN or NVGRE encapsulation. Signed-off-by:
-
Edward Cree authored
Remove the tx_queue->handle_tso function pointer, and just use tx_queue->tso_version to decide which function to call, thus removing an indirect call from the fast path. Instead of passing a tso_v2 flag to efx_mcdi_tx_init(), set the desired tx_queue->tso_version before calling it. In efx_mcdi_tx_init(), report back failure to obtain a TSOv2 context by setting tx_queue->tso_version to 0, which will cause the TX path to use the GSO-based fallback. Signed-off-by:
-
Edward Cree authored
Won't actually be exercised until we start advertising the corresponding offload features. Signed-off-by:
-
Edward Cree authored
If the MC reports the VXLAN_NVGRE datapath capability, then these queues can be used for checksum offload of encapsulated packets. Signed-off-by:
-
Edward Cree authored
Nothing yet creates inner csum TXQs; just change all references to EFX_TXQ_TYPE_OFFLOAD to the new EFX_TXQ_TYPE_OUTER_CSUM. Signed-off-by:
-
Edward Cree authored
Make it possible to have an arbitrary mapping from types to labels, because when we add inner-csum-offload TXQs there will no longer be a convenient nesting hierarchy of NIC types (EF10 will have inner-csum TXQs, while Siena will have HIGHPRI). Correct a misleading comment on efx_hard_start_xmit(). Signed-off-by:
-
Rikard Falkeborn authored
These are never modified, so constify them to allow the compiler to place them in read-only memory. This moves about 25kB to read-only memory as seen by the output of the size command. Before: text data bss dec hex filename 296203 65464 1248 362915 589a3 drivers/net/ethernet/marvell/octeontx2/af/octeontx2_af.ko After: text data bss dec hex filename 321003 40664 1248 362915 589a3 drivers/net/ethernet/marvell/octeontx2/af/octeontx2_af.ko Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
- 11 Sep, 2020 9 commits
-
-
David S. Miller authored
Edward Cree says: ==================== sfc: misc cleanups Clean up a few nits I noticed while working on TXQ stuff. ==================== Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Edward Cree authored
The old_channel argument is never used, so remove it. The function is only called from elsewhere in efx_channels.c, so make it static and remove the declaration from the header file. Signed-off-by:
-
Edward Cree authored
The statement above it already returns, so there is no way to get here. Signed-off-by:
-
Edward Cree authored
efx_init_struct already calls this, we don't need to do it again. Signed-off-by:
-
Ido Schimmel authored
Each MDB entry is encoded in a nested netlink attribute called 'MDBA_MDB_ENTRY'. In turn, this attribute contains another nested attributed called 'MDBA_MDB_ENTRY_INFO', which encodes a single port group entry within the MDB entry. The cited commit added the ability to restart a dump from a specific port group entry. However, on failure to add a port group entry to the dump the entire MDB entry (stored in 'nest2') is removed, resulting in missing port group entries. Fix this by finalizing the MDB entry with the partial list of already encoded port group entries. Fixes: 5205e919 ("net: bridge: mcast: add support for src list and filter mode dumping") Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Colin Ian King authored
The variable err is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Also re-order variable declarations in reverse Christmas tree ordering. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
David S. Miller authored
Oleksij Rempel says: ==================== ag71xx: add ethtool and flow control support The main target of this patches is to provide flow control support for ag71xx driver. To be able to validate this functionality, I also added ethtool support with HW counters. So, this patches was validated with iperf3 and counters showing Pause frames send or received by this NIC. ==================== Signed-off-by: -
Oleksij Rempel authored
Add flow control support. The functionality was tested on AR9331 SoC and confirmed by iperf3 results and HW counters exported over ethtool. Following test configurations was used: iMX6S receiver <--- TL-SG1005D switch <---- AR9331 sender The switch is supporting symmytric flow control: Settings for eth0: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full --->> Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Auto-negotiation: on Port: MII PHYAD: 4 Transceiver: external Link detected: yes The iMX6S system was configured to 10Mbit, to let the switch use flow control: - ethtool -s eth0 speed 10 With flow control disabled on AR9331: - ethtool -A eth0 rx off tx off - iperf3 -u -c 172.17.0.1 -b100M -l1472 -t10 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 66.2 MBytes 55.5 Mbits/sec 0.000 ms 0/47155 (0%) sender [ 5] 0.00-10.04 sec 11.5 MBytes 9.57 Mbits/sec 1.309 ms 38986/47146 (83%) receiver With flow control enabled on AR9331: - ethtool -A eth0 rx on tx on - iperf3 -u -c 172.17.0.1 -b100M -l1472 -t10 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 15.1 MBytes 12.6 Mbits/sec 0.000 ms 0/10727 (0%) sender [ 5] 0.00-10.05 sec 11.5 MBytes 9.57 Mbits/sec 1.371 ms 2525/10689 (24%) receiver Similar results are get in opposite direction by introducing extra CPU load on AR9331: - chrt 40 dd if=/dev/zero of=/dev/null & Signed-off-by:Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by:
-
Oleksij Rempel authored
Add basic ethtool support. The functionality was tested on AR9331 SoC. Signed-off-by:
-
