These netif flags are unnecessary convolutions. It is more
straightforward to just use NETIF_F_HW_CSUM, NETIF_F_IP_CSUM,
and NETIF_F_IPV6_CSUM directly.

This patch also:
    - Cleans up can_checksum_protocol
    - Simplifies netdev_intersect_features
Signed-off-by: NTom Herbert <tom@herbertland.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
set of features for offloading all checksums. This is a mask of the
checksum offload related features bits. It is incorrect to set both
NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
features of a device.

This patch:
  - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
    NETIF_F_ALL_CSUM is being used as a mask).
  - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
    use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.
Signed-off-by: NTom Herbert <tom@herbertland.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When setting up CRC offload set ip_summed to CHECKSUM_PARTIAL
instead of CHECKSUM_UNNECESSARY. This is consistent with the
definition of CHECKSUM_PARTIAL.

The only driver that seems to be advertising NETIF_F_FCOE_CRC is
ixgbe. AFICT the driver does not look at ip_summed for FCOE and
just assumes that CRC is being offloaded.
Signed-off-by: NTom Herbert <tom@herbertland.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The SCTP checksum is really a CRC and is very different from the
standards 1's complement checksum that serves as the checksum
for IP protocols. This offload interface is also very different.
Rename NETIF_F_SCTP_CSUM to NETIF_F_SCTP_CRC to highlight these
differences. The term CSUM should be reserved in the stack to refer
to the standard 1's complement IP checksum.
Signed-off-by: NTom Herbert <tom@herbertland.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Same thing as skb_transport_offset but returns the offset of the inner
transport header (when skb->encpasulation is set).
Signed-off-by: NTom Herbert <tom@herbertland.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds support of the fixed PHY.
This patch is based on commit 87009814 ("ucc_geth: use the new fixed
PHY helpers").
Signed-off-by: NKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Ido Schimmel says:

====================
This patchset introduces support for the offloading of 802.1D bridges
between VLAN devices. These can either be VLAN devices configured on top
of the physical ports or on top of LAG devices.

Patches 1-2 deal with the necessary infrastructure changes needed in order
to enable the above. The main change is that switchdev drivers can now know
the device from which the switchdev op originated from.

Patches 3-10 lay the groundwork for 802.1D bridges support in the mlxsw
driver, with patch 4 doing most of the heavy lifting.

Patch 11 finally offloads these bridges to hardware by listening to the
notifications sent when the VLAN device joins or leaves a bridge. It is
very similar to the already existing 802.1Q bridge we support.

Patches 12-14 add minor modifications to allow one to bridge a VLAN device
configured on top of LAG.
====================
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When creating a VLAN device on top of LAG, we are basically creating a
vPort on top of each of the port netdevs member in the LAG. Therefore,
these vPorts should inherit both the LAG status and LAG ID from the
underlying port netdevs.

In addition, when the VLAN device joins or leaves a bridge each of the
underlying vPorts should know about it and act accordingly. This is
achieved by propagating the VLAN event down to the lower devices.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When adding or removing FDB records of VLAN devices on top of LAG we
should set the lag_vid parameter to the VLAN ID of the VLAN device. It
is reserved otherwise.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Unicast LAG records in the Switch Filtering Database (SFD) register have
a lag_vid field indicating the VLAN ID in case of vFIDs. This field is
no longer reserved since we are going to add support for VLAN devices on
top of LAG.

Add the lag_vid field to be used by VLAN devies on top of LAG.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

All the member VLAN devices in a bridge need to share the same vFID.

To achieve that, expand the vFID struct to include the associated bridge
device (or lack of) and allow one to lookup a vFID based on a bridge
device.

When joining a bridge, lookup the relevant vFID or create one if none
exists. Next, make the VLAN device use the vFID.

Leaving a bridge can either occur because a user removed the VLAN device
from a bridge or because the VLAN device was deleted by the user. In the
latter case the bridge's teardown sequence is invoked after the hardware
vPort is already gone. Therefore, when unlinking the VLAN device from
the real device, check if the associated vPort is bridged and act
accordingly. The bridge's notification will be ignored in this case.

Note that bridging a VLAN interface with an ordinary port netdev is
currently not supported, but not forbidden. This will be addressed in a
follow-up patchset.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When a VLAN interface is configured on top of a physical port we should
associate the VLAN device with the matching vPort. Likewise, when it's
removed, we should revert back to the underlying port netdev.

While not a must, this is consistent with port netdevs and also provides
a more accurate error printing via netdev_err() and friends.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

FDB notifications contain the FID and port (or LAG ID) on which the MAC
was learned. In the case of the 802.1Q bridge one can easily derive the
matching VID - as FID equals VID - and generate the appropriate
notification for the software bridge. With VLAN devices this is no
longer the case, as these are associated with a vFID.

Solve that by converting the FID to a vFID and lookup the matching VLAN
device. From that derive the VID and whether learning (and learning
sync) should occur.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

switchdev ops can now be called for VLAN devices and we need to be
prepared for it. Until now they were only called for the port netdev.

Use the newly propagated orig_dev passed as part of the switchdev
attr/obj and determine whether the original device is a VLAN device. If
so, act accordingly, otherwise continue as usual.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In the Spectrum ASIC - unlike SwitchX-2 - FDB access is done by
specifying FID as parameter and not VID.

Change the relevant variables and parameters names to reflect that.

Note that this was OK up until now, since FID was always equal to VID,
but with the introduction of VLAN interfaces this is no longer the case.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We previously used only one flood table for packets classified to vFIDs.
However, since we are going to add support for bridges between VLAN
interfaces (mapped to vFIDs) we need to add one more flood table.

That way we can separate the flooding domain of unknown unicast traffic
from all the rest and support flood control (as we do with the 802.1Q
bridge).
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The __mlxsw_sp_port_flood_set function is now used to configure flooding
for both FIDs and vFIDs, so change the parameter name to 'idx' instead
of 'fid'. This is also consistent with hardware documentation.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Up until now we used a 1:1 mapping - based on VID - to map a VLAN
interface to a vFID. However, a different scheme is needed in order to
support bridges between VLAN interfaces, as all the member interfaces -
which can have different VIDs - need to share the same vFID.

Solve that by splitting the vFID range in two:
 1. Non-bridged VLAN interfaces
 2. Bridged VLAN interfaces

When a VLAN interface is created, assign it the next available vFID in
the first range, unless one already exists for that VID or number of
vFIDs in the range was exceeded. When interface is removed, free the
vFID, unless other interfaces are mapped to it.

To accomplish the above:
 1. Store the VID to vFID mapping in a new struct (mlxsw_sp_vfid), which
    has a global context and holds a reference count.
 2. Create a vPort (dummy in case of bridge SELF invocation) on top of
    of the physical port and hold a reference to the associated vFID.

	     vfid                    vfid
	+-------------+	        +-------------+
	| vfid        |         | vfid        |
	| vid         +---> ... | vid         |
	| nr_vports   |         | nr_vports   |
	+------+------+         +------+------+
				       |
	       +-----------------------+-------+
	       |			       |
	     vport			     vport
	+-------------+         	+-------------+
	| ...	      |         	| ...	      |
	| *vfid	      +---> ... 	| *vfid	      +---> ...
	| ...	      |         	| ...	      |
	+------+------+         	+------+------+
	       |                               |
	     port			     port
	+-------------+         	+-------------+
	| ...         |         	| ...         |
	| vports_list |         	| vports_list |
	| ...         |         	| ...         |
	+-------------+         	+-------------+
	     swXpY			     swXpZ

Next patches in the series will add the missing infrastructure for the
second range and transfer vPorts between the two ranges according to the
received notifications.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When adding support for bridges between VLAN interfaces, we'll introduce
a new entity called a vPort, which is a represntation of the VLAN
interface in the hardware.

The main difference between a vPort and a physical port is that several
FIDs can be bound to the latter, whereas only one (called a vFID) can be
bound to the first.

Therefore, it makes sense to use the same struct to represent the two,
but to only allocate the 'active_vlans' bitmap in case of a physical
port.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

switchdev drivers need to know the netdev on which the switchdev op was
invoked. For example, the STP state of a VLAN interface configured on top
of a port can change while being member in a bridge. In this case, the
underlying driver should only change the STP state of that particular
VLAN and not of all the VLANs configured on the port.

However, current switchdev infrastructure only passes the port netdev down
to the driver. Solve that by passing the original device down to the
driver as part of the required switchdev object / attribute.

This doesn't entail any change in current switchdev drivers. It simply
enables those supporting stacked devices to know the originating device
and act accordingly.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We need to be able to propagate static FDB entries and certain bridge
port attributes (e.g. learning, flooding) down to the port netdev
driver when bridge port is a VLAN interface.

Achieve that by setting ndo_bridge* and ndo_fdb* in vlan_netdev_ops to
the corresponding switchdev_port* functions. This is consistent with
team and bond devices.
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Jeff Kirsher says:

====================
1GbE Intel Wired LAN Driver Updates 2015-12-14

This series contains updates to e1000e and igb.

Alex Duyck changes e1000_up() to void since it always returned 0, also
by making it void, we can drop some code since we no longer have to worry
about non-zero return values.

Aaron Sierra removes GS40G specific defines and functions since the i210
internal PHY can be accessed with the access functions shared by 82580,
i350 and i354 devices.  Also removes the code to add the PHY address into
the PCDL register address, since there is no real reason to do so.

Joe updates the cable length function reports all four pairs true min, max
and average cable length for i210.  Also updated ethtool to use enum-based
labels instead of hard coded values.

Benjamin Poirier cleans up code that is never reachable since MSI-X
interrupts are not shared in e1000e.  Also removes the ICR read in the
other interrupt handler, since the information is not needed and IMS is
configured such that the only link status change can trigger the other
interrupt handler.  Fixed in MSI-X mode, there is no handler for the LSC
interrupt so there is no point in writing that to ICS now that we always
assume other interrupts are caused by LSC.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since the introduction of 82574 support in e1000e, the driver has worked
on the assumption that msi-x interrupt generation is automatically
disabled after each irq. As it turns out, this is not the case.
Currently, rx interrupts can fire multiple times before and during napi
processing. This can be a problem for users because frames that arrive
in a certain window (after adapter->clean_rx() but before
napi_complete_done() has cleared NAPI_STATE_SCHED) generate an interrupt
which does not lead to napi_schedule(). These frames sit in the rx queue
until another frame arrives (a tcp retransmit for example).

While the EIAC and CTRL_EXT registers are properly configured for irq
automask, the modification of IAM in e1000_configure_msix() is what
prevents automask from working as intended.

This patch removes that erroneous write and fixes interrupt rearming for
tx interrupts. It also clears IAME from CTRL_EXT. This is not strictly
necessary for operation of the driver but it is to avoid disruption from
potential programs that access the registers directly, like `ethregs -c`.
Reported-by: NFrank Steiner <steiner-reg@bio.ifi.lmu.de>
Signed-off-by: NBenjamin Poirier <bpoirier@suse.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

In msi-x mode, there is no handler for the lsc interrupt so there is no
point in writing that to ics now that we always assume Other interrupts
are caused by lsc.
Reviewed-by: NJasna Hodzic <jhodzic@ucdavis.edu>
Signed-off-by: NBenjamin Poirier <bpoirier@suse.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Removes the ICR read in the other interrupt handler, uses EIAC to
autoclear the Other bit from ICR and IMS. This allows us to avoid
interference with Rx and Tx interrupts in the Other interrupt handler.

The information read from ICR is not needed. IMS is configured such that
the only interrupt cause that can trigger the Other interrupt is Link
Status Change.
Signed-off-by: NBenjamin Poirier <bpoirier@suse.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

msi-x interrupts are not shared so there's no need to check if the
interrupt was really from this adapter.
Signed-off-by: NBenjamin Poirier <bpoirier@suse.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

With device tree it is no more possible to reset the PHY at board
level. Furthermore, doing in the driver allow to power down the PHY when
the network interface is no more used.

This reset can't be done at the PHY driver level. The PHY must be able to
answer the to the mii bus scan to let the kernel creating a PHY device.

The patch introduces a new optional property "phy-reset-gpios" inspired
from the one use for the FEC.
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Previously, the ethtool self-test gstrings/data arrays were accessed via
hardcoded indices, which made the code difficult to follow. This patch
replaces the hardcoded values with enum-based labels.
Signed-off-by: NJoe Schultz <jschultz@xes-inc.com>
Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Previously, the PHY-specific code to get the cable length for the
I210 internal and related PHYs was reporting the cable length of a
single pair and reporting it as the min, max, and total cable length.
Update it so that all four pairs are checked so the true min, max,
and average cable lengths are reported.
Signed-off-by: NJoe Schultz <jschultz@xes-inc.com>
Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

There is no reason to add the PHY address into the PCDL register address.
Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This patch fix a typo found within comment of skb_fclone_busy.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next

Johan Hedberg says:

====================
pull request: bluetooth-next 2015-12-11

Here's another set of Bluetooth & 802.15.4 patches for the 4.5 kernel:

 - 6LoWPAN debugfs support
 - New 802.15.4 driver for ADF7242 MAC IEEE802154
 - Initial code for 6LoWPAN Generic Header Compression (GHC) support
 - Refactor Bluetooth LE scan & advertising behind dedicated workqueue
 - Cleanups to Bluetooth H:5 HCI driver
 - Support for Toshiba Broadcom based Bluetooth controllers
 - Use continuous scanning when establishing Bluetooth LE connections

Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If there is 'no suitable DMA available' error, device should be disabled
before returning
Signed-off-by: NSaurabh Sengar <saurabh.truth@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Guillaume Nault says:

====================
Minor PPP devices improvements

Let PPP devices be friendlier to user space by registering their device
type and reporting their interface naming scheme.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Let user space be aware of the naming scheme used by ppp interfaces
(visible in /sys/class/net/<iface>/name_assign_type).
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Let PPP devices be identified as such in /sys/class/net/<iface>/uevent.
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Ursula Braun says:

====================
s390 network patches

here are some s390 related patches for net-next. Most important is
the skb_linearize af_iucv patch from Eugene solving traffic problems
in certain scenarios. The remaining patches are minor improvements.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

0-termination is redundant, since sprintf has done that.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When sending skbs, qeth determines the number of qdio SBAL elements
required. If qeth sends a fragmented skb, the SBAL element number
calculation is wrong, because the fragmented data part is added
twice in qeth_l3_tso_elements(). This patch makes sure fragmented
data is handled in qeth_elements_for_frags() only, while
qeth_l3_tso_elements() starts calculation of qdio SBAL elements just
with the linear data part of the skb.
Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
Reviewed-by: NThomas Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

/sys/class/net/<interface>/operstate for an active qeth network
interface offen shows "unknown", which translates to "state UNKNOWN
in output of "ip link show". It is caused by a missing initialization
of the __LINK_STATE_NOCARRIER bit in the net_device state field.
This patch adds a netif_carrier_off() invocation when creating the
net_device for a qeth device.
Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
Acked-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
Reference-ID: Bugzilla 133209
Signed-off-by: NDavid S. Miller <davem@davemloft.net>