- 30 Mar, 2018 18 commits
-
-
Kirill Tkhai authored
Register netdevice notifier for every iptable entry is not good, since this breaks modularity, and the hidden synchronization is based on rtnl_lock(). This patch reworks the synchronization via new lock, while the rest of logic remains as it was before. This is required for the next patch. Tested via: while :; do unshare -n iptables -t mangle -A OUTPUT -j TEE --gateway 1.1.1.2 --oif lo; done Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Kirill Tkhai authored
Currently, driver registers it from pernet_operations::init method, and this breaks modularity, because initialization of net namespace and netdevice notifiers are orthogonal actions. We don't have per-namespace netdevice notifiers; all of them are global for all devices in all namespaces. Signed-off-by:
-
David S. Miller authored
Mike Looijmans says: ==================== of_net: Implement of_get_nvmem_mac_address helper Posted this as a small set now, with an (optional) second patch that shows how the changes work and what I've used to test the code on a Topic Miami board. I've taken the liberty to add appropriate "Acked" and "Review" tags. v4: Replaced "6" with ETH_ALEN v3: Add patch that implements mac in nvmem for the Cadence MACB controller Remove the integrated of_get_mac_address call v2: Use of_nvmem_cell_get to avoid needing the assiciated device Use void* instead of char* Add devicetree binding doc ==================== Signed-off-by: -
Mike Looijmans authored
Call of_get_nvmem_mac_address() to fetch the MAC address from an nvmem cell, if one is provided in the device tree. This allows the address to be stored in an I2C EEPROM device for example. Signed-off-by:
Mike Looijmans <mike.looijmans@topic.nl> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Mike Looijmans authored
It's common practice to store MAC addresses for network interfaces into nvmem devices. However the code to actually do this in the kernel lacks, so this patch adds of_get_nvmem_mac_address() for drivers to obtain the address from an nvmem cell provider. This is particulary useful on devices where the ethernet interface cannot be configured by the bootloader, for example because it's in an FPGA. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== nfp: flower: handle MTU changes This set improves MTU handling for flower offload. The max MTU is correctly capped and physical port MTU is communicated to the FW (and indirectly HW). ==================== Signed-off-by: -
John Hurley authored
Trigger a port mod message to request an MTU change on the NIC when any physical port representor is assigned a new MTU value. The driver waits 10 msec for an ack that the FW has set the MTU. If no ack is received the request is rejected and an appropriate warning flagged. Rather than maintain an MTU queue per repr, one is maintained per app. Because the MTU ndo is protected by the rtnl lock, there can never be contention here. Portmod messages from the NIC are also protected by rtnl so we first check if the portmod is an ack and, if so, handle outside rtnl and the cmsg work queue. Acks are detected by the marking of a bit in a portmod response. They are then verfied by checking the port number and MTU value expected by the app. If the expected MTU is 0 then no acks are currently expected. Also, ensure that the packet headroom reserved by the flower firmware is considered when accepting an MTU change on any repr. Signed-off-by:
John Hurley <john.hurley@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
John Hurley authored
Rename the 'change_mtu' app callback to 'check_mtu'. This is called whenever an MTU change is requested on a netdev. It can reject the change but is not responsible for implementing it. Introduce a new 'repr_change_mtu' app callback that is hit when the MTU of a repr is to be changed. This is responsible for performing the MTU change and verifying it. Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== phylink: API changes This patch series contains two API changes to PHYLINK which will later be used by DSA to migrate to PHYLINK. Because these are API changes that impact other outstanding work (e.g: MVPP2) I would rather get them included sooner to minimize conflicts. Thank you! Changes in v2: - added missing documentation to mac_link_{up,down} that the interface must be configured in mac_config() - added Russell's, Andrew's and my tags ==================== Signed-off-by: -
Russell King authored
Provide a pointer to the SFP bus in struct net_device, so that the ethtool module EEPROM methods can access the SFP directly, rather than needing every user to provide a hook for it. Reviewed-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Florian Fainelli authored
In preparation for having DSA transition entirely to PHYLINK, we need to pass a PHY interface type to the mac_link_{up,down} callbacks because we may have to make decisions on that (e.g: turn on/off RGMII interfaces etc.). We do not pass an entire phylink_link_state because not all parameters (pause, duplex etc.) are defined when the link is down, only link and interface are. Update mvneta accordingly since it currently implements phylink_mac_ops. Acked-by: -
Ronak Doshi authored
Shrikrishna Khare would no longer maintain the vmxnet3 driver. Taking over the role of vmxnet3 maintainer. Signed-off-by:
Ronak Doshi <doshir@vmware.com> Signed-off-by:
Shrikrishna Khare <skhare@vmware.com> Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: Broadcom drivers coalescing fixes Following Tal's review of the adaptive RX/TX coalescing feature added to the SYSTEMPORT and GENET driver a number of things showed up: - adaptive TX coalescing is not actually a good idea with the current way the estimator will program the ring, this results in a higher CPU load, NAPI on TX already does a reasonably good job at maintaining the interrupt count low - both SYSTEMPORT and GENET would suffer from the same issues while configuring coalescing parameters where the values would just not be applied correctly based on user settings, so we fix that too Tal, thanks again for your feedback, I would appreciate if you could review that the new behavior appears to be implemented correctly. Thanks! Changes in v2: - added Tal's reviewed-by to the first patch - split DIM initialization from coalescing parameters initialization - avoid duplicating the same code in bcmgenet_set_coalesce() when configuring RX rings - fixed the condition where default DIM parameters would be applied when adaptive RX coalescing would be enabled, do this only if it was disabled before ==================== Signed-off-by: -
Florian Fainelli authored
There were a number of issues with setting the RX coalescing parameters: - we would not be preserving values that would have been configured across close/open calls, instead we would always reset to no timeout and 1 interrupt per packet, this would also prevent DIM from setting its default usec/pkts values - when adaptive RX would be turned on, we woud not be fetching the default parameters, we would stay with no timeout/1 packet per interrupt until the estimator kicks in and changes that - finally disabling adaptive RX coalescing while providing parameters would not be honored, and we would stay with whatever DIM had previously determined instead of the user requested parameters Fixes: 9f4ca058 ("net: bcmgenet: Add support for adaptive RX coalescing") Signed-off-by:
Tal Gilboa <talgi@mellanox.com> Signed-off-by:
-
Florian Fainelli authored
There were a number of issues with setting the RX coalescing parameters: - we would not be preserving values that would have been configured across close/open calls, instead we would always reset to no timeout and 1 interrupt per packet, this would also prevent DIM from setting its default usec/pkts values - when adaptive RX would be turned on, we woud not be fetching the default parameters, we would stay with no timeout/1 packet per interrupt until the estimator kicks in and changes that - finally disabling adaptive RX coalescing while providing parameters would not be honored, and we would stay with whatever DIM had previously determined instead of the user requested parameters Fixes: b6e0e875 ("net: systemport: Implement adaptive interrupt coalescing") Signed-off-by:
-
Florian Fainelli authored
Adaptive TX coalescing is not currently giving us any advantages and ends up making the CPU spin more frequently until TX completion. Deny and disable adaptive TX coalescing for now and rely on static configuration, we can always add it back later. Reviewed-by:
-
Gal Pressman authored
NETIF_F_HW_VLAN_[CS]TAG_FILTER features require more than just a bit flip in dev->features in order to keep the driver in a consistent state. These features notify the driver of each added/removed vlan, but toggling of vlan-filter does not notify the driver accordingly for each of the existing vlans. This patch implements a similar solution to NETIF_F_RX_UDP_TUNNEL_PORT behavior (which notifies the driver about UDP ports in the same manner that vids are reported). Each toggling of the features propagates to the 8021q module, which iterates over the vlans and call add/kill ndo accordingly. Signed-off-by:
Gal Pressman <galp@mellanox.com> Reviewed-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Wei Yongjun authored
Fix to return a negative error code from the hash filter init error handling case instead of 0, as done elsewhere in this function. Fixes: 5c31254e ("cxgb4: initialize hash-filter configuration") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
- 29 Mar, 2018 22 commits
-
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2018-03-29' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.17 Smaller new features to various drivers but nothing really out of ordinary. Major changes: ath10k * enable chip temperature measurement for QCA6174/QCA9377 * add firmware memory dump for QCA9984 * enable buffer STA on TDLS link for QCA6174 * support different beacon internals in multiple interface scenario for QCA988X/QCA99X0/QCA9984/QCA4019 iwlwifi * support for new PCI IDs for the 9000 family * support for a new firmware API version * support for advanced dwell and Optimized Connectivity Experience (OCE) in scanning btrsi * fix kconfig dependencies wil6210 * support multiple virtual interfaces ==================== Signed-off-by:
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2018-03-29' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== We have a fair number of patches, but many of them are from the first bullet here: * EAPoL-over-nl80211 from Denis - this will let us fix some long-standing issues with bridging, races with encryption and more * DFS offload support from the qtnfmac folks * regulatory database changes for the new ETSI adaptivity requirements * various other fixes and small enhancements ==================== Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== Add ATU/VTU statistics Previous patches have added basic support for Address Translation Unit and VLAN translation Unit violation interrupts. Add statistics counters for when these occur, which can be accessed using ethtool. Downgrade one of the particularly spammy warnings from VTU violations to debug only, now that we have a counter for it. ==================== Signed-off-by: -
Andrew Lunn authored
VTU miss violations can happen under normal conditions. Don't spam the kernel log, downgrade the output to debug level only. The statistics counter will indicate it is happening, if anybody not debugging is interested. Signed-off-by:
-
Andrew Lunn authored
Count the numbers of various ATU and VTU violation statistics and return them as part of the ethtool -S statistics. Signed-off-by:
-
Arnd Bergmann authored
The proc file cleanup left a label possibly unused: net/sctp/protocol.c: In function 'sctp_defaults_init': net/sctp/protocol.c:1304:1: error: label 'err_init_proc' defined but not used [-Werror=unused-label] This adds an #ifdef around it to match the respective 'goto'. Fixes: d47d08c8 ("sctp: use proc_remove_subtree()") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Wei Yongjun authored
Use the module_pci_driver() macro to make the code simpler by eliminating module_init and module_exit calls. Signed-off-by:
-
Wei Yongjun authored
Fixes the following sparse warning: drivers/net/ethernet/broadcom/genet/bcmgenet.c:1351:16: warning: Using plain integer as NULL pointer Signed-off-by:
-
Dan Carpenter authored
The skb_segment() function returns error pointers on error. It never returns NULL. Fixes: 76db8087 ("net: bpf: add a test for skb_segment in test_bpf module") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Reviewed-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
-
Russell King authored
Cotsworks modules fail the checksums - it appears that Cotsworks reprograms the EEPROM at the end of production with the final product information (serial, date code, and exact part number for module options) and fails to update the checksum. Work around this by detecting the Cotsworks name in the manufacturer field, and reducing the checksum failures to warnings rather than a hard error. Signed-off-by:
-
David S. Miller authored
Sudarsana Reddy Kalluru says: ==================== qed*: Flash upgrade support. The patch series adds adapter flash upgrade support for qed/qede drivers. Please consider applying it to net-next branch. ==================== Signed-off-by: -
Sudarsana Reddy Kalluru authored
The patch adds ethtool callback implementation for flash update. Signed-off-by:
Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com> Signed-off-by:
Ariel Elior <ariel.elior@cavium.com> Signed-off-by:
-
Sudarsana Reddy Kalluru authored
This patch adds the required driver support for updating the flash or non volatile memory of the adapter. At highlevel, flash upgrade comprises of reading the flash images from the input file, validating the images and writing them to the respective paritions. Signed-off-by:
-
Sudarsana Reddy Kalluru authored
This patch adds APIs for flash access. Signed-off-by:
-
Sudarsana Reddy Kalluru authored
Signed-off-by:
-
Sudarsana Reddy Kalluru authored
This patch adds support for populating the flash image attributes. Signed-off-by:
-
Michal Kalderon authored
This FW contains several fixes and features RDMA Features - SRQ support - XRC support - Memory window support - RDMA low latency queue support - RDMA bonding support RDMA bug fixes - RDMA remote invalidate during retransmit fix - iWARP MPA connect interop issue with RTR fix - iWARP Legacy DPM support - Fix MPA reject flow - iWARP error handling - RQ WQE validation checks MISC - Fix some HSI types endianity - New Restriction: vlan insertion in core_tx_bd_data can't be set for LB packets ETH - HW QoS offload support - Fix vlan, dcb and sriov flow of VF sending a packet with inband VLAN tag instead of default VLAN - Allow GRE version 1 offloads in RX flow - Allow VXLAN steering iSCSI / FcoE - Fix bd availability checking flow - Support 256th sge proerly in iscsi/fcoe retransmit - Performance improvement - Fix handle iSCSI command arrival with AHS and with immediate - Fix ipv6 traffic class configuration DEBUG - Update debug utilities Signed-off-by:
Michal Kalderon <Michal.Kalderon@cavium.com> Signed-off-by:
Tomer Tayar <Tomer.Tayar@cavium.com> Signed-off-by:
Manish Rangankar <Manish.Rangankar@cavium.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Eric Dumazet authored
IPv4 was changed in commit 52a773d6 ("net: Export ip fragment sysctl to unprivileged users") The only sysctl that is not per-netns is not used : ip6frag_secret_interval Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Nikolay Borisov <kernel@kyup.com> Signed-off-by:
-
Intiyaz Basha authored
During heavy tx traffic, control messages (sent by liquidio driver to NIC firmware) sometimes do not get processed in a timely manner. Reason is: the low-level metadata of control messages and that of egress network packets indicate that they have the same priority. Fix it by setting a higher priority for control messages through the new ctrl_qpg field in the oct_txpciq struct. It is the NIC firmware that does the actual setting of priority by writing to the new ctrl_qpg field; the host driver treats that value as opaque and just assigns it to pki_ih3->qpg Signed-off-by:
Intiyaz Basha <intiyaz.basha@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
-
David S. Miller authored
David Ahern says: ==================== net: Allow FIB notifiers to fail add and replace I wanted to revisit how resource overload is handled for hardware offload of FIB entries and rules. At the moment, the in-kernel fib notifier can tell a driver about a route or rule add, replace, and delete, but the notifier can not affect the action. Specifically, in the case of mlxsw if a route or rule add is going to overflow the ASIC resources the only recourse is to abort hardware offload. Aborting offload is akin to taking down the switch as the path from data plane to the control plane simply can not support the traffic bandwidth of the front panel ports. Further, the current state of FIB notifiers is inconsistent with other resources where a driver can affect a user request - e.g., enslavement of a port into a bridge or a VRF. As a result of the work done over the past 3+ years, I believe we are at a point where we can bring consistency to the stack and offloads, and reliably allow the FIB notifiers to fail a request, pushing an error along with a suitable error message back to the user. Rather than aborting offload when the switch is out of resources, userspace is simply prevented from adding more routes and has a clear indication of why. This set does not resolve the corner case where rules or routes not supported by the device are installed prior to the driver getting loaded and registering for FIB notifications. In that case, hardware offload has not been established and it can refuse to offload anything, sending errors back to userspace via extack. Since conceptually the driver owns the netdevices associated with its asic, this corner case mainly applies to unsupported rules and any races during the bringup phase. Patch 1 fixes call_fib_notifiers to extract the errno from the encoded response from handlers. Patches 2-5 allow the call to call_fib_notifiers to fail the add or replace of a route or rule. Patch 6 adds a simple resource controller to netdevsim to illustrate how a FIB resource controller can limit the number of route entries. Changes since RFC - correct return code for call_fib_notifier - dropped patch 6 exporting devlink symbols - limited example resource controller to init_net only - updated Kconfig for netdevsim to use MAY_USE_DEVLINK - updated cover letter regarding startup case noted by Ido ==================== Signed-off-by: -
David Ahern authored
Add devlink support to netdevsim and use it to implement a simple, profile based resource controller. Only one controller is needed per namespace, so the first netdevsim netdevice in a namespace registers with devlink. If that device is deleted, the resource settings are deleted. The resource controller allows a user to limit the number of IPv4 and IPv6 FIB entries and FIB rules. The resource paths are: /IPv4 /IPv4/fib /IPv4/fib-rules /IPv6 /IPv6/fib /IPv6/fib-rules The IPv4 and IPv6 top level resources are unlimited in size and can not be changed. From there, the number of FIB entries and FIB rule entries are unlimited by default. A user can specify a limit for the fib and fib-rules resources: $ devlink resource set netdevsim/netdevsim0 path /IPv4/fib size 96 $ devlink resource set netdevsim/netdevsim0 path /IPv4/fib-rules size 16 $ devlink resource set netdevsim/netdevsim0 path /IPv6/fib size 64 $ devlink resource set netdevsim/netdevsim0 path /IPv6/fib-rules size 16 $ devlink dev reload netdevsim/netdevsim0 such that the number of rules or routes is limited (96 ipv4 routes in the example above): $ for n in $(seq 1 32); do ip ro add 10.99.$n.0/24 dev eth1; done Error: netdevsim: Exceeded number of supported fib entries. $ devlink resource show netdevsim/netdevsim0 netdevsim/netdevsim0: name IPv4 size unlimited unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables non resources: name fib size 96 occ 96 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables ... With this template in place for resource management, it is fairly trivial to extend and shows one way to implement a simple counter based resource controller typical of network profiles. Currently, devlink only supports initial namespace. Code is in place to adapt netdevsim to a per namespace controller once the network namespace issues are resolved. Signed-off-by:David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
David Ahern authored
Move call to call_fib6_entry_notifiers for new IPv6 routes to right before the insertion into the FIB. At this point notifier handlers can decide the fate of the new route with a clean path to delete the potential new entry if the notifier returns non-0. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
