- 03 Aug, 2017 11 commits
-
-
William Tu authored
Save the ifindex before it gets zeroed so the invalid ifindex can be printed out. Signed-off-by:
William Tu <u9012063@gmail.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== This feature/cleanup patchset includes the following patches: - bump version strings, by Simon Wunderlich - Remove unnecessary length qualifier, by Joe Perches - Remove too short %pM field width, by Sven Eckelmann - Remove return value handling from skb_put_data, by Sven Eckelmann - Spelling fixes, by Colin Ian King - Convert batman-adv.txt to reStructuredText, by Sven Eckelmann ==================== Signed-off-by: -
Lin Yun Sheng authored
When deal with low and high throughput, it is hard to achiece both high performance and low latency. In order to achiece that, this patch calculates the rx rate, and adjust the interrupt coalesce parameter accordingly. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Tested-by:
Weiwei Deng <dengweiwei@huawei.com> Signed-off-by:
-
Julia Lawall authored
null_x25_address is only used to access the string it contains, so it can be const. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== ipv4: fib: Provide per-nexthop offload indication Ido says: Offload indication for IPv4 routes is currently set in the FIB info's flags. When multipath routes are employed, this can lead to a route being marked as offloaded although only one of its nexthops is actually offloaded. Instead, this patchset aims to proivde a higher resolution for the offload indication and report it on a per-nexthop basis. Example output from patched iproute: $ ip route show 192.168.200.0/24 192.168.200.0/24 nexthop via 192.168.100.2 dev enp3s0np7 weight 1 offload nexthop via 192.168.101.3 dev enp3s0np8 weight 1 And once the second gateway is resolved: $ ip route show 192.168.200.0/24 192.168.200.0/24 nexthop via 192.168.100.2 dev enp3s0np7 weight 1 offload nexthop via 192.168.101.3 dev enp3s0np8 weight 1 offload First patch teaches the kernel to look for the offload indication in the nexthop flags. Patches 2-5 adjust current capable drivers to provide offload indication on a per-nexthop basis. Last patch removes no longer used functions to set offload indication in the FIB info's flags. ==================== Signed-off-by: -
Ido Schimmel authored
Previous patches converted users of these functions to provide offload indication using the nexthop's flags instead of the FIB info's. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Acked-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Ido Schimmel authored
Now that we provide offload indication using the nexthop's flags we must refresh the offload indication whenever the offload state within the group changes. This didn't matter until now, as offload indication was provided using the FIB info flags and multipath routes were marked as offloaded as long as one of the nexthops was offloaded. Signed-off-by:
-
Ido Schimmel authored
Previous patch removed the reliance on the counter in the FIB info to set the offload indication, so we no longer need to keep an offload state on each FIB entry and can just set or unset the RTNH_F_OFFLOAD flag in each nexthop. This is also necessary because we're going to need to refresh the offload indication whenever the nexthop group associated with the FIB entry is refreshed. Current check would prevent us from marking a newly resolved nexthop as offloaded if the FIB entry is already marked as offloaded. Signed-off-by:
-
Ido Schimmel authored
In a similar fashion to previous patch, use the nexthop flags to provide offload indication instead of the FIB info's flags. In case a nexthop in a multipath route can't be offloaded (gateway's MAC can't be resolved, for example), then its offload flag isn't set. Signed-off-by:
-
Ido Schimmel authored
We want to stop using the FIB info's flags to provide the offlaod indication and instead do that on a per-nexthop basis. Convert rocker to do just that. It only supports one nexthop per-route, so conversion is simple. Signed-off-by:
-
Ido Schimmel authored
We're going to have capable drivers indicate route offload using the nexthop flags, but for non-multipath routes these flags aren't dumped to user space. Instead, set the offload indication in the route message flags. Signed-off-by:
-
- 02 Aug, 2017 29 commits
-
-
Ido Schimmel authored
'trans->tid' is only assigned later in the function, resulting in a zero transaction ID. Use 'tid' instead. Signed-off-by:
-
David S. Miller authored
Stephen Hemminger says: ==================== netvsc: transparent VF support This patch set changes how SR-IOV Virtual Function devices are managed in the Hyper-V network driver. This version is rebased onto current net-next. Background In Hyper-V SR-IOV can be enabled (and disabled) by changing guest settings on host. When SR-IOV is enabled a matching PCI device is hot plugged and visible on guest. The VF device is an add-on to an existing netvsc device, and has the same MAC address. How is this different? The original support of VF relied on using bonding driver in active standby mode to handle the VF device. With the new netvsc VF logic, the Linux hyper-V network virtual driver will directly manage the link to SR-IOV VF device. When VF device is detected (hot plug) it is automatically made a slave device of the netvsc device. The VF device state reflects the state of the netvsc device; i.e. if netvsc is set down, then VF is set down. If netvsc is set up, then VF is brought up. Packet flow is independent of VF status; all packets are sent and received as if they were associated with the netvsc device. If VF is removed or link is down then the synthetic VMBUS path is used. What was wrong with using bonding script? A lot of work went into getting the bonding script to work on all distributions, but it was a major struggle. Linux network devices can be configured many, many ways and there is no one solution from userspace to make it all work. What is really hard is when configuration is attached to synthetic device during boot (eth0) and then the same addresses and firewall rules needs to also work later if doing bonding. The new code gets around all of this. How does VF work during initialization? Since all packets are sent and received through the logical netvsc device, initialization is much easier. Just configure the regular netvsc Ethernet device; when/if SR-IOV is enabled it just works. Provisioning and cloud init only need to worry about setting up netvsc device (eth0). If SR-IOV is enabled (even as a later step), the address and rules stay the same. What devices show up? Both netvsc and PCI devices are visible in the system. The netvsc device is active and named in usual manner (eth0). The PCI device is visible to Linux and gets renamed by udev to a persistent name (enP2p3s0). The PCI device name is now irrelevant now. The logic also sets the PCI VF device SLAVE flag on the network device so network tools can see the relationship if they are smart enough to understand how layered devices work. This is a lot like how I see Windows working. The VF device is visible in Device Manager, but is not configured. Is there any performance impact? There is no visible change in performance. The bonding and netvsc driver both have equivalent steps. Is it compatible with old bonding script? It turns out that if you use the old bonding script, then everything still works but in a sub-optimum manner. What happens is that bonding is unable to steal the VF from the netvsc device so it creates a one legged bond. Packet flow then is: bond0 <--> eth0 <- -> VF (enP2p3s0). In other words, if you get it wrong it still works, just awkward and slower. What if I add address or firewall rule onto the VF? Same problems occur with now as already occur with bonding, bridging, teaming on Linux if user incorrectly does configuration onto an underlying slave device. It will sort of work, packets will come in and out but the Linux kernel gets confused and things like ARP don’t work right. There is no way to block manipulation of the slave device, and I am sure someone will find some special use case where they want it. ==================== Signed-off-by: -
stephen hemminger authored
No longer needed, now all managed by transparent VF logic. Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
stephen hemminger authored
Add some background documentation on netvsc device options and limitations. Signed-off-by:
-
stephen hemminger authored
This patch implements transparent fail over from synthetic NIC to SR-IOV virtual function NIC in Hyper-V environment. It is a better alternative to using bonding as is done now. Instead, the receive and transmit fail over is done internally inside the driver. Using bonding driver has lots of issues because it depends on the script being run early enough in the boot process and with sufficient information to make the association. This patch moves all that functionality into the kernel. Signed-off-by:
-
Amitoj Kaur Chawla authored
Functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 35740 28424 832 64996 fde4 drivers/atm/solos-pci.o File size after: text data bss dec hex filename 35932 28232 832 64996 fde4 drivers/atm/solos-pci.o This change was made with the help of Coccinelle. Signed-off-by:
Amitoj Kaur Chawla <amitoj1606@gmail.com> Signed-off-by:
-
Amitoj Kaur Chawla authored
Functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 2033 1448 0 3481 d99 drivers/atm/adummy.o File size after: text data bss dec hex filename 2129 1352 0 3481 d99 drivers/atm/adummy.o This change was made with the help of Coccinelle. Signed-off-by:
-
Derek Chickles authored
The file /sys/devices/pci000.../sriov_totalvfs is showing a wrong value. Fix it by calling pci_sriov_set_totalvfs() to set the total number of VFs available after calculations for the number of PF and VF queues are made. Signed-off-by:
Derek Chickles <derek.chickles@cavium.com> Signed-off-by:
Raghu Vatsavayi <raghu.vatsavayi@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
-
Florian Fainelli authored
DSA slave network devices maintain a pair of bytes and packets counters for each directions, but these are not 64-bit capable. Re-use pcpu_sw_netstats which contains exactly what we need for that purpose and update the code path to report 64-bit capable statistics. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
WANG Cong authored
They are introduced by commit f70ea018 ("net: Add functions to get skb->hash based on flow structures") but never gets used in tree. Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Eric Dumazet authored
Commit c13ee2a4 ("tcp: reindent two spots after prequeue removal") removed code in tcp_data_queue(). We can go a little farther, removing an always true test, and removing initializers for fragstolen and eaten variables. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Florian Westphal <fw@strlen.de> Signed-off-by:
-
Arnd Bergmann authored
The last patch added the dependency on 'OF && HAS_IOMEM' but left COMPILE_TEST as an alternative, which kind of defeats the purpose of adding the dependency, we still get randconfig build warnings: warning: (NET_DSA_BCM_SF2 && BCMGENET) selects MDIO_BCM_UNIMAC which has unmet direct dependencies (NETDEVICES && MDIO_BUS && HAS_IOMEM && OF_MDIO) For compile-testing purposes, we don't really need this anyway, as CONFIG_OF can be enabled on all architectures, and HAS_IOMEM is present on all architectures we do meaningful compile-testing on (the exception being arch/um). This makes both OF and HAS_IOMEM hard dependencies. Fixes: 5af74bb4 ("net: bcmgenet: Add dependency on HAS_IOMEM && OF") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Joe Perches authored
Repeated dereference of nvmsg.msg.v1_msg.send_rndis_pkt can be shortened by using a temporary. Do so. No change in object code. Miscellanea: o Use * const for rpkt and nvchan Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: rework EEE support EEE implies configuring the port's PHY and MAC of both ends of the wire. The current EEE support in DSA mixes PHY and MAC configuration, which is bad because PHYs must be configured through a proper PHY driver. The DSA switch operations for EEE are only meant for configuring the port's MAC, which are integrated in the Ethernet switch device. This patchset fixes the EEE support in qca8k driver, makes the DSA layer call phy_init_eee for all drivers, and remove the EEE support from the mv88e6xxx driver since the Marvell PHY driver should be enough for it. Changes in v2: - make PHY device and DSA EEE ops mandatory for slave EEE operations. - simply return 0 in drivers which don't need to do anything to configure the port' MAC. Subsequent PHY calls will be enough. ==================== Signed-off-by: -
Vivien Didelot authored
To avoid confusion with the PHY EEE settings, rename the .set_eee and .get_eee ops to respectively .set_mac_eee and .get_mac_eee. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Vivien Didelot authored
The PHY's EEE settings are already accessed by the DSA layer through the Marvell PHY driver and there is nothing to be done for switch's MACs. Remove all EEE support from the mv88e6xxx driver and simply return 0 from the EEE ops. Signed-off-by:
-
Vivien Didelot authored
The DSA switch operations for EEE are only meant to configure a port's MAC EEE settings. The port's PHY EEE settings are accessed by the DSA layer and must be made available via a proper PHY driver. In order to reduce this confusion, remove the phy_device argument from the .set_eee operation. Signed-off-by:
-
Vivien Didelot authored
All DSA drivers are calling phy_init_eee if eee_enabled is true. Move up this statement in the DSA layer to simplify the DSA drivers. qca8k does not require to cache the ethtool_eee structures from now on. Signed-off-by:
-
Vivien Didelot authored
It is safer to init the EEE before the DSA layer call phy_ethtool_set_eee, as sf2 and qca8k are doing. Signed-off-by:
-
Vivien Didelot authored
The SF2 driver is masking the supported bitfield of its private copy of the ports' ethtool_eee structures. It is used nowhere, thus remove it. Signed-off-by:
-
Vivien Didelot authored
phy_ethtool_get_eee is already called by the DSA layer, thus remove the duplicated call in the qca8k driver. Signed-off-by:
-
Vivien Didelot authored
The qca8k driver is currently caching a bitfield of the supported member of a ethtool_eee private structure, which is unused. Only the eee_enabled field of the private ethtool_eee copy is updated, thus using p->advertised and p->lp_advertised is also erroneous. Remove the usage of these private ethtool_eee members and only rely on phy_ethtool_get_eee to assign the eee_active member. Signed-off-by:
-
Vivien Didelot authored
If EEE is queried enabled, qca8k_set_eee calls qca8k_eee_enable_set twice (because it is already called in qca8k_eee_init). Fix that. Signed-off-by:
-
Vivien Didelot authored
The qca8k obviously copied code from the sf2 driver as how to set EEE: if (e->eee_enabled) { p->eee_enabled = qca8k_eee_init(ds, port, phydev); if (!p->eee_enabled) ret = -EOPNOTSUPP; } But it did not use the same logic for the EEE init routine, which is "Returns 0 if EEE was not enabled, or 1 otherwise". This results in returning -EOPNOTSUPP on success and caching EEE enabled on failure. This patch fixes the returned value of qca8k_eee_init. Signed-off-by: -
Vivien Didelot authored
The port's PHY and MAC are both implied in EEE. The current code does not call the PHY operations if the related device is NULL. Change that by returning -ENODEV if there's no PHY device attached to the interface. Signed-off-by:
-
David S. Miller authored
Niklas Söderlund says: ==================== ravb: add wake-on-lan support via magic packet WoL is enabled in the suspend callback by setting MagicPacket detection and disabling all interrupts expect MagicPacket. In the resume path the driver needs to reset the hardware to rearm the WoL logic, this prevents the driver from simply restoring the registers and to take advantage of that ravb was not suspended to reduce resume time. To reset the hardware the driver closes the device, sets it in reset mode and reopens the device just like it would do in a normal suspend/resume scenario without WoL enabled, but it both closes and opens the device in the resume callback since the device needs to be reset for WoL to work. One quirk needed for WoL is that the module clock needs to be prevented from being switched off by Runtime PM. To keep the clock alive the suspend callback need to call clk_enable() directly to increase the usage count of the clock. Then when Runtime PM decreases the clock usage count it won't reach 0 and be switched off. Changes since v2 - Only do the clock dance to workaround PSCI sleep when resuming if WoL is enabled. This was a bug in v2 which resulted in a WARN if resuming from PSCI sleep with WoL disabled, thanks Sergei for pointing this out! - Break out clock dance workaround in separate patch to make it easier to revert once a fix is upstream for the clock driver as suggested by Sergei. Changes since v1 - Fix issue where device would fail to resume from PSCI suspend if WoL was enabled, reported by Geert. The fault was that the clock driver thinks the clock is on, but PSCI have disabled it, added workaround for this in ravb driver which can be removed once the clock driver is aware of the PSCI behavior. - Only try to restore from wol wake up if netif is running, since this is a condition to enable wol in the first place this was a bug in v1. ==================== Signed-off-by: -
Niklas Söderlund authored
The renesas-cpg-mssr clock driver are not yet aware of PSCI sleep where power is cut to the SoC. When resuming from this state with WoL enabled the enable count of the ravb clock is 1 and the clock driver thinks the clock is already on when PM core enables the clock and increments the enable count to 2. This will result in the ravb driver failing to talk to the hardware since the module clock is off. Work around this by forcing the enable count to 0 and then back to 2 when resuming with WoL enabled. This workaround should be reverted once the renesas-cpg-mssr clock driver becomes aware of this PSCI sleep behavior. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Niklas Söderlund authored
WoL is enabled in the suspend callback by setting MagicPacket detection and disabling all interrupts expect MagicPacket. In the resume path the driver needs to reset the hardware to rearm the WoL logic, this prevents the driver from simply restoring the registers and to take advantage of that ravb was not suspended to reduce resume time. To reset the hardware the driver closes the device, sets it in reset mode and reopens the device just like it would do in a normal suspend/resume scenario without WoL enabled, but it both closes and opens the device in the resume callback since the device needs to be reset for WoL to work. One quirk needed for WoL is that the module clock needs to be prevented from being switched off by Runtime PM. To keep the clock alive the suspend callback need to call clk_enable() directly to increase the usage count of the clock. Then when Runtime PM decreases the clock usage count it won't reach 0 and be switched off. Signed-off-by:
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2017-08-01 Here's our first batch of Bluetooth patches for the 4.14 kernel: - Several new USB IDs for the btusb driver - Memory leak fix in btusb driver - Cleanups & fixes to hci_nokia, hci_serdev and hci_bcm drivers - Fixed cleanup path in mrf24j40 (802.15.4) driver probe function - A few other smaller cleanups & fixes to drivers Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by:
-
