- 20 Feb, 2020 33 commits
-
-
Julian Wiedmann authored
Trivial cleanup, so that all bridge port-specific code can be found in one go. CC: Johannes Berg <johannes@sipsolutions.net> CC: Roopa Prabhu <roopa@cumulusnetworks.com> CC: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ilias Apalodimas authored
Functions starting with __ usually indicate those which are exported, but should not be called directly. Update some of those declared in the API and make it more readable. page_pool_unmap_page() and page_pool_release_page() were doing exactly the same thing calling __page_pool_clean_page(). Let's rename __page_pool_clean_page() to page_pool_release_page() and export it in order to show up on perf logs and get rid of page_pool_unmap_page(). Finally rename __page_pool_put_page() to page_pool_put_page() since we can now directly call it from drivers and rename the existing page_pool_put_page() to page_pool_put_full_page() since they do the same thing but the latter is trying to sync the full DMA area. This patch also updates netsec, mvneta and stmmac drivers which use those functions. Suggested-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Preparation for RTNL removal The driver currently acquires RTNL in its route insertion path, which contributes to very large control plane latencies. This patch set prepares mlxsw for RTNL removal from its route insertion path in a follow-up patch set. Patches #1-#2 protect shared resources - KVDL and counter pool - with their own locks. All allocations of these resources are currently performed under RTNL, so no locks were required. Patches #3-#7 ensure that updates to mirroring sessions only take place in case there are active mirroring sessions. This allows us to avoid taking RTNL when it is unnecessary, as updating of the mirroring sessions must be performed under RTNL for the time being. Patches #8-#10 replace the use of APIs that assume that RTNL is taken with their RCU counterparts. Specifically, patches #8 and #9 replace __in_dev_get_rtnl() with __in_dev_get_rcu() under RCU read-side critical section. Patch #10 replaces __dev_get_by_index() with dev_get_by_index_rcu(). Patches #11-#15 perform small adjustments in the code to make it easier to later introduce a router lock instead of relying on RTNL. ==================== Signed-off-by: -
Ido Schimmel authored
The device supports a single VTEP whose configuration is shared between all VXLAN tunnels. While the shared configuration is cleared upon the destruction of the last tunnel - in mlxsw_sp_nve_tunnel_fini() - it is set in mlxsw_sp_nve_fid_enable(), after calling mlxsw_sp_nve_tunnel_init(). Make tunnel initialization and destruction symmetric and set the configuration in mlxsw_sp_nve_tunnel_init(). This will later allow us to protect the shared configuration with a lock. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
After the previous patch, all the callers of mlxsw_sp_rif_find_by_dev() outside of the routing code use it to understand if a RIF exists for the passed netdev. Therefore, export a function to check if a RIF exists and make mlxsw_sp_rif_find_by_dev() internal to the routing code. This will later allow us to more easily introduce the router lock which will also protect the RIFs. Signed-off-by:
-
Ido Schimmel authored
There are currently 5 users of mlxsw_sp_rif_find_by_dev() outside of the routing code. Only one call site actually needs to dereference the router interface (RIF). The rest merely need to know if a RIF exists for the provided netdev. Convert this call site to query the needed information directly from the routing code instead of dereferencing the RIF. This will later allow us to replace mlxsw_sp_rif_find_by_dev() with a function that checks if a RIF exist. Signed-off-by:
-
Ido Schimmel authored
The function de-associates the port-vlan from its router interface (RIF). It is called both from the netdev notifier block and the inetaddr notifier block that will soon hold the router lock. Make sure that router code calls the internal version, as it will already have the router lock held when the function is called. Signed-off-by:
-
Ido Schimmel authored
The function removes the FDB entry that directs the macvlan's MAC to the router port. It is called from both the netdev notifier block and the inetaddr notifier block that will soon hold the router lock. Make sure that only the netdev notifier calls the exported version, so that is will take the router lock, which will already be held by the inetaddr notifier. Signed-off-by:
-
Ido Schimmel authored
The function that resolves the underlay device of the IPIP tunnel assumes that RTNL is taken, but this will not be correct when RTNL is removed from the route insertion path. Convert the function to use dev_get_by_index_rcu() instead of __dev_get_by_index() and make sure it is always called from an RCU read-side critical section. Signed-off-by:
-
Ido Schimmel authored
IPv6 addresses are deleted in an atomic context, so the driver defers the potential teardown of the associated router interface (RIF) to a work item that takes RTNL. The RIF is only destroyed if the associated netdev does not have any IP addresses (both IPv4 and IPv6). The IPv4 device ('struct in_device') is currently fetched via __in_dev_get_rtnl() which assumes RTNL is taken. Since RTNL is going to be removed, convert it to use __in_dev_get_rcu() from an RCU read-side critical section. Note that the IPv6 device ('struct inet6_dev') is fetched via __in6_dev_get(), which does not require RTNL. Signed-off-by: -
Ido Schimmel authored
RTNL is going to be removed from route insertion path, so use __in_dev_get_rcu() from an RCU read-side critical section instead of __in_dev_get_rtnl() which assumes RTNL is taken. Signed-off-by:
-
Ido Schimmel authored
In order not to needlessly schedule the work item that updates the mirroring agents, only schedule it if there are any mirroring agents present. This is done by adding an atomic counter that counts the active mirroring agents. It is incremented / decremented whenever a mirroring agent is created / destroyed. It is read before scheduling the work item and in the devlink-resource occupancy callback. Signed-off-by:
-
Ido Schimmel authored
Previous patch added a work item in the mirroring code that will take care of updating the active mirroring agents in response to different events. Change the mirroring agents update function - mlxsw_sp_span_respin() - to invoke this work item when called. Therefore there is no need for callers to schedule a work item themselves. Signed-off-by:
-
Ido Schimmel authored
The driver updates its mirroring agents whenever it receives a notification about an event that can affect these. For example, the addition of a route might require the driver to change the egress port of an ERSPAN session. Currently, RTNL needs to be held when these agents are updates, so the driver either: 1. Calls directly into the mirroring code, in case RTNL is held 2. Schedules a work item that will take RTNL and call into the mirroring code Simplify this by having the mirroring code schedule the work item for the update instead of requiring callers to schedule a work item themselves. The conversion of the callers will be done in the next patch to make review easier. This will later allow us to remove RTNL from different parts of the driver. It will also allow us to only schedule the work item in case there are active mirroring agents, which is information private to the mirroring code. Signed-off-by:
-
Ido Schimmel authored
Allocate the main mirroring struct and the individual structs for the different mirroring agents in a single allocation. Signed-off-by:
-
Ido Schimmel authored
The struct holding the different mirroring agents is currently allocated as part of the main driver struct. This is unlike other driver modules. Allocate the memory required to store the different mirroring agents as part of the initialization of the mirroring module. Signed-off-by:
-
Ido Schimmel authored
The counter pool is a shared resource. It is used by both the ACL code to allocate counters for actions and by the routing code to allocate counters for adjacency entries (for example). Currently, all allocations are protected by RTNL, but this is going to change with the removal of RTNL from the routing code. Therefore, protect counter allocations with a spin lock. Signed-off-by:
-
Ido Schimmel authored
The KVDL is used to store objects allocated throughout various places in the driver. For example, both nexthops (adjacency entries) and ACL actions are stored in the KVDL. Currently, all allocations are protected by RTNL, but this is going to change with the removal of RTNL from the routing code. Therefore, protect KVDL allocations with a lock. A mutex is used since the free operation can block in Spectrum-2. Signed-off-by:
-
Li RongQing authored
TNODE_KMALLOC_MAX and VERSION are not used, so remove them Signed-off-by:
Li RongQing <lirongqing@baidu.com> Signed-off-by:
-
Li RongQing authored
this macro is never used, so remove it Signed-off-by:
-
Roman Mashak authored
Added tests for 'u32' extended match rules for u8 alignment. Signed-off-by:
Roman Mashak <mrv@mojatatu.com> Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: phy: Better support for BCM54810 This patch series updates the broadcom PHY driver to better support the BCM54810 and allow it to make use of the exiting bcm54xx_adjust_rxrefclk() as well as fix suspend/resume for it. Changes in v2: - added Reviewed-by tags from Andrew for patches #1 and #3 - expanded commit message in #2 to explain the change ==================== Signed-off-by: -
Florian Fainelli authored
The BCM54810 PHY can use the standard BMCR Power down suspend, but needs a custom resume routine which first clear the Power down bit, and then re-initializes the PHY. While in low-power mode, the PHY only accepts writes to the BMCR register. The datasheet clearly says it: Reads or writes to any MII register other than MII Control register (address 00h) while the device is in the standby power-down mode may cause unpredictable results. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
bcm54xx_adjust_rxrefclk() already checks for PHY_BRCM_AUTO_PWRDWN_ENABLE and PHY_BRCM_DIS_TXCRXC_NOENRGY in order to set the appropriate bit. The situation is a bit more complicated with the flag PHY_BRCM_RX_REFCLK_UNUSED but essentially amounts to the same situation. The default setting for the 125MHz clock is to be on for all PHYs and we still treat BCM50610 and BCM50610M specifically with the polarity of the bit reversed. Signed-off-by:
-
Florian Fainelli authored
The function bcm54xx_adjust_rxrefclk() works correctly on the BCM54810 PHY, allow this device ID to proceed through. Reviewed-by:
-
YueHaibing authored
drivers/net/ethernet/sfc/efx.c:116:38: warning: efx_default_channel_type defined but not used [-Wunused-const-variable=] commit 83975485 ("sfc: move channel alloc/removal code") left behind this, remove it. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 83975485 ("sfc: move channel alloc/removal code") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Martin Habets <mhabets@solarflare.com> Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: misc updates for -net-next This series includes some misc updates for the HNS3 ethernet driver. [patch 1] modifies an unsuitable print when setting dulex mode. [patch 2] adds some debugfs info for TC and DWRR. [patch 3] adds some debugfs info for loopback. [patch 4] adds a missing help info for QS shaper in debugfs. ==================== Signed-off-by: -
Yonglong Liu authored
HNS3 driver can dump QS shaper configs via debugfs, but missing help info in debugfs for this operation. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Yufeng Mo authored
The MAC ID and loopback status information are obtained from the hardware, which will be helpful for debugging. This patch adds support for these two items in debugfs. Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
-
Yonglong Liu authored
The actual enabled TC numbers and the DWRR weight of each TC may be helpful for debugging, so adds them into debugfs. Signed-off-by:
-
Guangbin Huang authored
Currently, if device is in link down status and user uses 'ethtool -s' command to set speed but not specify duplex mode, the duplex mode passed from ethtool to driver is unknown value(255), and the fibre port will identify this value as half duplex mode and print "only copper port supports half duplex!". This message is confusing. So for fibre port, only the setting duplex is half, prints error and returns. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
-
Petr Oros authored
commit 93c09704 ("net: phy: consider latched link-down status in polling mode") removed double-read of latched link-state register for polling mode from genphy_update_link(). This added extra ~1s delay into sequence link down->up. Following scenario: - After boot link goes up - phy_start() is called triggering an aneg restart, hence link goes down and link-down info is latched. - After aneg has finished link goes up. In phy_state_machine is checked link state but it is latched "link is down". The state machine is scheduled after one second and there is detected "link is up". This extra delay can be avoided when we keep link-state register double read in case when link was down previously. With this solution we don't miss a link-down event in polling mode and link-up is faster. Details about this quirky behavior on Realtek phy: Without patch: T0: aneg is started, link goes down, link-down status is latched T0+3s: state machine runs, up-to-date link-down is read T0+4s: state machine runs, aneg is finished (BMSR_ANEGCOMPLETE==1), here i read link-down (BMSR_LSTATUS==0), T0+5s: state machine runs, aneg is finished (BMSR_ANEGCOMPLETE==1), up-to-date link-up is read (BMSR_LSTATUS==1), phydev->link goes up, state change PHY_NOLINK to PHY_RUNNING With patch: T0: aneg is started, link goes down, link-down status is latched T0+3s: state machine runs, up-to-date link-down is read T0+4s: state machine runs, aneg is finished (BMSR_ANEGCOMPLETE==1), first BMSR read: BMSR_ANEGCOMPLETE==1 and BMSR_LSTATUS==0, second BMSR read: BMSR_ANEGCOMPLETE==1 and BMSR_LSTATUS==1, phydev->link goes up, state change PHY_NOLINK to PHY_RUNNING Signed-off-by:
Petr Oros <poros@redhat.com> Reviewed-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
- 19 Feb, 2020 7 commits
-
-
David S. Miller authored
Heiner Kallweit says: ==================== net: core: add helper tcp_v6_gso_csum_prep Several network drivers for chips that support TSO6 share the same code for preparing the TCP header, so let's factor it out to a helper. A difference is that some drivers reset the payload_len whilst others don't do this. This value is overwritten by TSO anyway, therefore the new helper resets it in general. ==================== Signed-off-by: -
Heiner Kallweit authored
Use new helper tcp_v6_gso_csum_prep in additional network drivers. Signed-off-by:
-
Heiner Kallweit authored
Use new helper tcp_v6_gso_csum_prep in additional network drivers. Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
-
Heiner Kallweit authored
Use new helper tcp_v6_gso_csum_prep in additional network drivers. Signed-off-by:
-
Heiner Kallweit authored
Use new helper tcp_v6_gso_csum_prep in additional network drivers. Signed-off-by:
-
Heiner Kallweit authored
Use new helper tcp_v6_gso_csum_prep in additional network drivers. Signed-off-by:
-
Heiner Kallweit authored
Use new helper tcp_v6_gso_csum_prep in additional network drivers. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
