- 15 Dec, 2017 24 commits
-
-
William Tu authored
Similar to support for ipv4 erspan, this patch adds erspan v2 to ip6erspan tunnel. Signed-off-by: William Tu <u9012063@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
William Tu authored
The patch adds support for erspan version 2. Not all features are supported in this patch. The SGT (security group tag), GRA (timestamp granularity), FT (frame type) are set to fixed value. Only hardware ID and direction are configurable. Optional subheader is also not supported. Signed-off-by: William Tu <u9012063@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
William Tu authored
The patch refactors the existing erspan implementation in order to support erspan version 2, which has additional metadata. So, in stead of having one 'struct erspanhdr' holding erspan version 1, breaks it into 'struct erspan_base_hdr' and 'struct erspan_metadata'. Signed-off-by: William Tu <u9012063@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Kicinski says: ==================== nfp: ethtool flash updates Dirk says: This series adds the ability to update the control FW with ethtool. It should be noted that the locking scheme here is to release the RTNL lock before the flashing operation and to take it again afterwards to ensure consistent state from the core code point of view. In this time, we take a reference to the device to prevent the device being freed while its being flashed. This provides protection for the device being flashed while at the same time not holding up any networking related functions which would otherwise be locked out due to RTNL being held. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dirk van der Merwe authored
Firmware flashing takes around 60s (specified to not take more than 70s). Prevent hogging the RTNL lock in this time and make use of the longer timeout for the NSP command. The timeout is set to 2.5 * 70 seconds. We only allow flashing the firmware from reprs or PF netdevs. VFs do not have an app reference. Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dirk van der Merwe authored
The firmware flashing NSP operation takes longer to execute than the current default timeout. We need a mechanism to set a longer timeout for some commands. This patch adds the infrastructure to this. The default timeout is still 30 seconds. Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Mahesh Bandewar says: ==================== ipvlan: packet scrub While crossing namespace boundary IPvlan aggressively scrubs packets. This is creating problems. First thing is that scrubbing changes the packet type in skb meta-data to PACKET_HOST. This causes erroneous packet delivery when dev_forward_skb() has already marked the packet type as OTHER_HOST. On the egress side scrubbing just before calling dev_queue_xmit() creates another set of problems. Scrubbing remove skb->sk so the prio update gets missed and more seriously, socket back-pressure fails making TSQ not function correctly. The first patch in the series just reverts the earlier change which was adding a mac-check, but that is unnecessary if packet_type that dev_forward_skb() has set is honored. The second path removes two of the scrubs which are causing problems described above. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mahesh Bandewar authored
IPvlan currently scrubs packets at every location where packets may be crossing namespace boundary. Though this is desirable, currently IPvlan does it more than necessary. e.g. packets that are going to take dev_forward_skb() path will get scrubbed so no point in scrubbing them before forwarding. Another side-effect of scrubbing is that pkt-type gets set to PACKET_HOST which overrides what was already been set by the earlier path making erroneous delivery of the packets. Also scrubbing packets just before calling dev_queue_xmit() has detrimental effects since packets lose skb->sk and because of that miss prio updates, incorrect socket back-pressure and would even break TSQ. Fixes: b93dd49c ('ipvlan: Scrub skb before crossing the namespace boundary') Signed-off-by: Mahesh Bandewar <maheshb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mahesh Bandewar authored
This reverts commit 92ff4264. Even though the check added is not that taxing, it's not really needed. First of all this will be per packet cost and second thing is that the eth_type_trans() already does this correctly. The excessive scrubbing in IPvlan was changing the pkt-type skb metadata of the packet which made it necessary to re-check the mac. The subsequent patch in this series removes the faulty packet-scrub. Signed-off-by: Mahesh Bandewar <maheshb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-nextDavid S. Miller authored
Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2017-12-15 1) Currently we can add or update socket policies, but not clear them. Support clearing of socket policies too. From Lorenzo Colitti. 2) Add documentation for the xfrm device offload api. From Shannon Nelson. 3) Fix IPsec extended sequence numbers (ESN) for IPsec offloading. From Yossef Efraim. 4) xfrm_dev_state_add function returns success even for unsupported options, fix this to fail in such cases. From Yossef Efraim. 5) Remove a redundant xfrm_state assignment. From Aviv Heller. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Update the compatible string and Device Tree binding document for 7278B0. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Salil Mehta says: ==================== Hisilicon Network Subsystem 3 VF Ethernet Driver This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3) Virtual Function Ethernet driver for hip08 family of SoCs. The Physical Function driver is already part of the Linux mainline. This VF driver has its Hardware Compatibility Layer and has commom/unified ENET layer/client/ethtool code with the PF driver. It also has support of mailbox to communicate with the HNS3 PF driver. The basic architecture of VF driver is derivative of the PF driver. Just like PF driver, this driver is also PCI Express based. This driver is the ongoing development work and HNS3 VF Ethernet driver would be incrementally enhanced with more new features. High Level Architecture: [ Ethtool ] | [ Ethernet Client ] ... [ RoCE Client ] | | [ HNAE Device ] |________ | | | --------------------------------------------- | | [ HNAE3 Framework (Register/unregister) ] | | --------------------------------------------- | | | [ VF HCLGE Layer ] | | | | | | | | | | | [ VF Mailbox (To PF via IMP) ] | | | | [ IMP command Interface ] [ IMP command Interface ] | | | | (A B O V E R U N S O N G U E S T S Y S T E M) ------------------------------------------------------------- Q E M U / V F I O / K V M (on Host System) ------------------------------------------------------------- HIP08 H A R D W A R E (limited to VF by SMMU) [ IMP/Mgmt Processor (hardware common to system/cmd based) ] Fig 1. HNS3 Virtual Function Driver [ dcbnl ] [ Ethtool ] | | [ Ethernet Client ] [ ODP/UIO Client ] . . .[ RoCE Client ] |_____________________| | | _________| [ HNAE Device ] | | | | | --------------------------------------------- | | [ HNAE3 Framework (Register/unregister) ] | | --------------------------------------------- | | | [ HCLGE Layer ] | ________________|_________________ | | | | | [ DCB ] | | | | | | | [ Scheduler/Shaper ] [ MDIO ] [ PF Mailbox ] | | | | | |________________|_________________| | | | [ IMP command Interface ] [ IMP command Interface ] ---------------------------------------------------------------- HIP08 H A R D W A R E [ IMP/Mgmt Processor (hardware common to system/cmd based) ] Fig 2. Existing HNS3 PF Driver (added with mailbox) Change Log Summary: Patch V4: Addressed SPDX related comment by Philippe Ombredanne Patch V3: Addressed SPDX change requested by Philippe Ombredanne Patch V2: 1. Addressed some comments by David Miller. 2. Addressed some internal comments on various patches Patch V1: Initial Submit ==================== Acked-by: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salil Mehta authored
All PF mailbox events are conveyed through a common interrupt (vector 0). This interrupt vector is shared by reset and mailbox. This patch adds the handling of mailbox interrupt event and its deferred processing in context to a separate mailbox task. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: lipeng <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salil Mehta authored
This patch is required to support ring-vector binding and reset of TQPs requested by the VF driver to the PF driver. Mailbox handler is added with corresponding VF commands/messages to handle the request. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: lipeng <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salil Mehta authored
Command queue provides the provision of Mailbox command which can be used for communication between PF and VF. PF handles messages from various VFs for fetching various information like, queue, vlan, link status related etc. It also handles the request from various VFs to perform certain privileged operations. This patch adds the support of a message handler for handling such various command requests from VF. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: lipeng <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salil Mehta authored
Most of the NAPI handling interface, skb buffer management, management of the RX/TX descriptors, ethool interface etc. has quite a bit of code which is common to VF and PF driver. This patch makes the exisitng PF's HNS3 ENET driver as the common ENET driver for both Virtual & Physical Function. This will help in reduction of redundancy and better management of code. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: lipeng <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salil Mehta authored
This patch introduces the new Makefiles and updates existing Makefiles required to build the HNS3 Virtual Function driver. This also updates the Kconfig for introduction of new menuconfig entries related to VF driver. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: lipeng <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salil Mehta authored
This patch adds the support of hardware compatibiltiy layer to the HNS3 VF Driver. This layer implements various {set|get} operations over MAC address for a virtual port, RSS related configuration, fetches the link status info from PF, does various VLAN related configuration over the virtual port, queries the statistics from the hardware etc. This layer can directly interact with hardware through the IMP(Integrated Mangement Processor) interface or can use mailbox to interact with the PF driver. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: lipeng <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salil Mehta authored
This patch adds the support of the mailbox to the VF driver. The mailbox shall be used as an interface to communicate with the PF driver for various purposes like {set|get} MAC related operations, reset, link status etc. The mailbox supports both synchronous and asynchronous command send to PF driver. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: lipeng <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salil Mehta authored
This patch adds support of command interface for communication with the IMP(Integrated Management Processor) for HNS3 Virtual Function Driver. Each VF has support of CQP(Command Queue Pair) ring interface. Each CQP consis of send queue CSQ and receive queue CRQ. There are various commands a VF may support, like to query frimware version, TQP management, statistics, interrupt related, mailbox etc. This also contains code to initialize the command queue, manage the command queue descriptors and Rx/Tx protocol with the command processor in the form of various commands/results and acknowledgements. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: lipeng <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Sean Wang says: ==================== add VLAN support to DSA MT7530 Changes sicne v2: update to the latest code base from net-next and fix up all building errors with -Werror. Changes since v1: - fix up the typo - prefer ordering declarations longest to shortest - update that vlan_prepare callback should not change any state - use lower case letter for function naming The patchset extends DSA MT7530 to VLAN support through filling required callbacks in patch 1 and merging the special tag with VLAN tag in patch 2 for allowing that the hardware can handle these packets with VID from the CPU port. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Wang authored
I work for MediaTek and maintain SoC targeting to home gateway and also will keep extending and testing the function from MediaTek switch. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Wang authored
In order to let MT7530 switch can recognize well those egress packets having both special tag and VLAN tag, the information about the special tag should be carried on the existing VLAN tag. On the other hand, it's unnecessary for extra handling for ingress packets when VLAN tag is present since it is able to put the VLAN tag after the special tag and then follow the existing way to parse. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Wang authored
MT7530 can treat each port as either VLAN-unaware port or VLAN-aware port through the implementation of port matrix mode or port security mode on the ingress port, respectively. On one hand, Each port has been acting as the VLAN-unaware one whenever the device is created in the initial or certain port joins or leaves into/from the bridge at the runtime. On the other hand, the patch just filling the required callbacks for VLAN operations is achieved via extending the port to be into port security mode when the port is configured as VLAN-aware port. Which mode can make the port be able to recognize VID from incoming packets and look up VLAN table to validate and judge which port it should be going to. And the range for VID from 1 to 4094 is valid for the hardware. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 13 Dec, 2017 16 commits
-
-
Egil Hjelmeland authored
Simplify lan9303_indirect_phy_wait_for_completion() and lan9303_switch_wait_for_completion() by using a new function lan9303_read_wait() Changes v1 -> v2: - param 'mask' type u32 - removed param 'value' (will probably never be used) - add newline before return Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Stephen Hemminger says: ==================== hv_netvsc: minor changes This includes minor cleanup of code in send and receive path and also a new statistic to check for allocation failures. This also eliminates some of the extra RCU when not needed. There is a theoritical bug where buffered data could be blocked for longer than necessary if the ring buffer got full. This has not been seen in the wild, found by inspection. The reference count between net device and internal RNDIS is not needed. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
If the transmit queue is known full, then don't keep aggregating data. And the cp_partial flag which indicates that the current aggregation buffer is full can be folded in to avoid more conditionals. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
There is only ever a single instance of network device object referencing the internal rndis object. Therefore the open_cnt atomic is not necessary. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
The netvsc_receive_callback function was using RCU to find the appropriate underlying netvsc_device. Since calling function already had that pointer, this was unnecessary. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
The caller (netvsc_receive) already has the net device pointer, and should just pass that to functions rather than the hyperv device. This eliminates several impossible error paths in the process. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
When skb can not be allocated, update ethtool statisitics rather than rx_dropped which is intended for netif_receive. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Since only caller does not care about return value. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Florian Fainelli says: ==================== PHYLINK preparatory patches for DSA In preparation for having DSA migrate to PHYLINK, I had to come up with a number of preparatory patches: - we need to be able to pass phy_flags from an external component calling phylink_of_phy_connect() - DSA tries to connect through OF first, then fallsback using its own internal MDIO bus, in that case we would both show an error, but also not know what the correct phy_interface_t would be, instead use the PHY device/driver provided one - Finally bcm_sf2 makes use of all possible PHYs out there: internal, external, fixed, and MoCA, the latter requires a bit of help to signal link notifications through a MMIO interrupt, as well a report a correct PORT type Changes in v2: - rebased against latest net-next/master - added kernel doc documentation - dropped error message in phylink_of_phy_connect() as suggested by Russell ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Similarly to what PHYLIB already does, make sure that PHY_INTERFACE_MODE_MOCA is reported as PORT_BNC. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
phylink_get_fixed_state() currently consults an optional "link_gpio" GPIO descriptor, expand this mechanism to allow specifying a custom callback. This is necessary to support out of band link notifcation (e.g: from an interrupt within a MMIO register). Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Some subsystems like DSA may be trying to connect to a PHY through OF first, and then attempt a connect using a local MDIO bus, remove the error message: "unable to find PHY node" so we can let MAC drivers whether to print it or not. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
We may not always be able to resolve a correct phy_interface_t value before actually connecting to the PHY device, when that happens, just have phylink_connect_phy() utilize what the PHY device/driver provided. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
In order to let subsystems like DSA fully utilize PHYLINK, we need to be able to communicate phy_device::flags from of_phy_{connect,attach} even when using PHYLINK APIs. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuchung Cheng authored
Prior to this patch, active Fast Open is paused on a specific destination IP address if the previous connections to the IP address have experienced recurring timeouts . But recent experiments by Microsoft (https://goo.gl/cykmn7) and Mozilla browsers indicate the isssue is often caused by broken middle-boxes sitting close to the client. Therefore it is much better user experience if Fast Open is disabled out-right globally to avoid experiencing further timeouts on connections toward other destinations. This patch changes the destination-IP disablement to global disablement if a connection experiencing recurring timeouts or aborts due to timeout. Repeated incidents would still exponentially increase the pause time, starting from an hour. This is extremely conservative but an unfortunate compromise to minimize bad experience due to broken middle-boxes. Reported-by: Dragana Damjanovic <ddamjanovic@mozilla.com> Reported-by: Patrick McManus <mcmanus@ducksong.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Reviewed-by: Wei Wang <weiwan@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ivan Khoronzhuk authored
It's not correct to return NULL when that is actually an error and function returns errors in any other wrong case. In the same time, the cpsw driver and davinci emac doesn't check error case while creating channel and it can miss actual error. Also remove WARNs replacing them on dev_err msgs. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-