- 15 Jul, 2014 12 commits
-
-
Tom Gundersen authored
Based on a patch by David Herrmann. The name_assign_type attribute gives hints where the interface name of a given net-device comes from. These values are currently defined: NET_NAME_ENUM: The ifname is provided by the kernel with an enumerated suffix, typically based on order of discovery. Names may be reused and unpredictable. NET_NAME_PREDICTABLE: The ifname has been assigned by the kernel in a predictable way that is guaranteed to avoid reuse and always be the same for a given device. Examples include statically created devices like the loopback device and names deduced from hardware properties (including being given explicitly by the firmware). Names depending on the order of discovery, or in any other way on the existence of other devices, must not be marked as PREDICTABLE. NET_NAME_USER: The ifname was provided by user-space during net-device setup. NET_NAME_RENAMED: The net-device has been renamed from userspace. Once this type is set, it cannot change again. NET_NAME_UNKNOWN: This is an internal placeholder to indicate that we yet haven't yet categorized the name. It will not be exposed to userspace, rather -EINVAL is returned. The aim of these patches is to improve user-space renaming of interfaces. As a general rule, userspace must rename interfaces to guarantee that names stay the same every time a given piece of hardware appears (at boot, or when attaching it). However, there are several situations where userspace should not perform the renaming, and that depends on both the policy of the local admin, but crucially also on the nature of the current interface name. If an interface was created in repsonse to a userspace request, and userspace already provided a name, we most probably want to leave that name alone. The main instance of this is wifi-P2P devices created over nl80211, which currently have a long-standing bug where they are getting renamed by udev. We label such names NET_NAME_USER. If an interface, unbeknown to us, has already been renamed from userspace, we most probably want to leave also that alone. This will typically happen when third-party plugins (for instance to udev, but the interface is generic so could be from anywhere) renames the interface without informing udev about it. A typical situation is when you switch root from an installer or an initrd to the real system and the new instance of udev does not know what happened before the switch. These types of problems have caused repeated issues in the past. To solve this, once an interface has been renamed, its name is labelled NET_NAME_RENAMED. In many cases, the kernel is actually able to name interfaces in such a way that there is no need for userspace to rename them. This is the case when the enumeration order of devices, or in fact any other (non-parent) device on the system, can not influence the name of the interface. Examples include statically created devices, or any naming schemes based on hardware properties of the interface. In this case the admin may prefer to use the kernel-provided names, and to make that possible we label such names NET_NAME_PREDICTABLE. We want the kernel to have tho possibilty of performing predictable interface naming itself (and exposing to userspace that it has), as the information necessary for a proper naming scheme for a certain class of devices may not be exposed to userspace. The case where renaming is almost certainly desired, is when the kernel has given the interface a name using global device enumeration based on order of discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM. Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has not yet been ported. This is mostly useful as a transitionary measure, allowing us to label the various naming schemes bit by bit. v8: minor documentation fixes v9: move comment to the right commit Signed-off-by: Tom Gundersen <teg@jklm.no> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Kay Sievers <kay@vrfy.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ezequiel Garcia authored
The proper string for this license is "GPL v2", instead of "GPLv2". This commit fixes that. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Varka Bhadram says: ==================== This series cleanup for AMD8111E ethernet driver v1: fix checkpatch warnings. v2: added new line in debug messages ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Varka Bhadram authored
This patch fix the 'foo*' bar with 'foo *bar' and (foo*) with (foo *). Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Varka Bhadram authored
Normally any device ids will be above the corresponding device driver structure. This patch moves the pci device ids and MODULE_DEVICE_TABLE() above the pci driver structure. Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Varka Bhadram authored
This patch fixes the comment style issues Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Varka Bhadram authored
This patch convert printk() to netdev_dbg/info/err or dev_info/err/dbg Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Varka Bhadram authored
This patch replace ioremap() with the devm_ioremap() so that the resource will be freed automatically with the probe failed. Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Varka Bhadram authored
This patch moves the remove functionalities after the probe so that we can see the registered and released resources properly. Every driver follows the same concept. Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Shradha Shah says: ==================== sfc: Add 40G support This patch series adds support for Solarflare 7000 series 40G Solarflare network adapters starting with the SFN7X42Q. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Edward Cree authored
Needed to select 40G mode on a 10G/40G capable card. Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mateusz Wrzesinski authored
Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 14 Jul, 2014 17 commits
-
-
David S. Miller authored
Tom Herbert says: ==================== udp: UDP tunnel enhancements - Add udp_sock_create in new helper module udp_tunnel. Tunnel implementations call this function to create listener UDP ports. - Make vxlan and l2tp call udp_sock_create. - Move udp_tunnel_segment into udp_offload.c. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tom Herbert authored
Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tom Herbert authored
In l2tp driver call common function udp_sock_create to create the listener UDP port. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tom Herbert authored
In vxlan driver call common function udp_sock_create to create the listener UDP port. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tom Herbert authored
Added udp_tunnel.c which can contain some common functions for UDP tunnels. The first function in this is udp_sock_create which is used to open the listener port for a UDP tunnel. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Fabian Frederick says: ==================== drivers/net: remove unnecessary break after goto Small patchset addressing break redundancy on drivers/net branch (suggested by Joe Perches). V2: cc to maintainers of each section. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabian Frederick authored
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabian Frederick authored
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabian Frederick authored
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabian Frederick authored
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabian Frederick authored
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabian Frederick authored
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabian Frederick authored
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabian Frederick authored
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabian Frederick authored
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Add const attribute to filter argument to make clear it is no longer modified. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-nextDavid S. Miller authored
John W. Linville says: ==================== Please pull this batch of updates intended for the 3.17 stream... This is primarily a Bluetooth pull. Gustavo says: "A lot of patches to 3.17. The bulk of changes here are for LE support. The 6loWPAN over Bluetooth now has it own module, we also have support for background auto-connection and passive scanning, Bluetooth device address provisioning, support for reading Bluetooth clock values and LE connection parameters plus many many fixes." The balance is just a pull of the wireless.git tree, to avoid some pending merge problems. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 11 Jul, 2014 11 commits
-
-
Himangi Saraogi authored
The semantic patch that makes this transformation is as follows: // <smpl> @@ expression e; @@ -if (e) BUG(); +BUG_ON(e); // </smpl> Signed-off-by: Himangi Saraogi <himangi774@gmail.com> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Himangi Saraogi authored
The semantic patch that makes the transformation is as follows: // <smpl> @@ expression e; @@ -if (e) BUG(); +BUG_ON(e); // </smpl> Signed-off-by: Himangi Saraogi <himangi774@gmail.com> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
This patch introduces a possibility for userspace to set various (so far two) modes of generating addresses. This is useful for example for NetworkManager because it can set the mode to NONE and take care of link local addresses itself. That allow it to have the interface up, monitoring carrier but still don't have any addresses on it. One more use-case by Dan Williams: <quote> WWAN devices often have their LL address provided by the firmware of the device, which sometimes refuses to respond to incorrect LL addresses when doing DHCPv6 or IPv6 ND. The kernel cannot generate the correct LL address for two reasons: 1) WWAN pseudo-ethernet interfaces often construct a fake MAC address, or read a meaningless MAC address from the firmware. Thus the EUI64 and the IPv6LL address the kernel assigns will be wrong. The real LL address is often retrieved from the firmware with AT or proprietary commands. 2) WWAN PPP interfaces receive their LL address from IPV6CP, not from kernel assignments. Only after IPV6CP has completed do we know the LL address of the PPP interface and its peer. But the kernel has already assigned an incorrect LL address to the interface. So being able to suppress the kernel LL address generation and assign the one retrieved from the firmware is less complicated and more robust. </quote> Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arvid Brodin authored
MacAddressB is an array (unsigned char MacAddressB[ETH_ALEN]) and is allocated as a part of *node_dst (which is a struct hsr_node). So the condition is always false. Detected by Dan Carpenter. Signed-off-by: Arvid Brodin <arvid.brodin@alten.se> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Hayes Wang says: ==================== r8169: support IPv6 The RTL8168C and the later chips support the hardware checksum for IPv6. Adjust some code and add the relative code. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
hayeswang authored
Support the IPv6 hw checksum for RTL8111C and later chips. Note that the hw has the limitation for the transport offset. The checksum must be calculated by sw, when the transport offset is out of the range which the hw accepts. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
hayeswang authored
Replace large send with giant send for TSO for RTL8111C and later ICs. The large send setting of the RTL8111DP is different from the other chips. However, the giant send setting is the same for all the chips which support it. Use the giant send to synchronize the settings. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
hayeswang authored
According to the txd_version, split rtl8169_tso_csum() into rtl8169_tso_csum_v1() and rtl8169_tso_csum_v2(). Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Li RongQing authored
Signed-off-by: Li RongQing <roy.qing.li@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stefan Sørensen authored
Event timestamp values should be adjusted by 3*reference clock period + 11 ns = 35 ns to compensate for input path and synchronization delays. So subtract 35ns from event timestamps. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
-