This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This device stores the number of seconds in a 32 bit register.  So
more work is needed on this driver before the year 2038 comes around.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch changes the driver to use the newer API.

Depending on how the hardware represents a time value, this driver may
or may not yet be ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For the 82576, the driver's clock is implemented using a timecounter,
and so with this patch that device is ready for the year 2038.

However, in the case of the i210, the device stores the number of
seconds in a 32 bit register.  Therefore, more work is needed on this
driver before the year 2038 comes around.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The device features a 64 bit nanoseconds register, and so with this
patch the driver is ready for the year 2038.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Acked-by: NSony Chacko <sony.chacko@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.

Compile tested only.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The device uses 64 bit nanoseconds register, and so with this patch the
driver is ready for the year 2038.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch changes the posix clock code to prefer the new methods
whenever they are implemented by the PHC drivers.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch changes the code to use the new method whenever implemented by
the PHC driver.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Converting the PHC drivers over to the new methods is one step along the
way to making them ready for 2038.  Once all the drivers are up to date,
then the old methods will be removed.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A message sent to a node after a successful name table lookup may still
find that the destination socket has disappeared, because distribution
of name table updates is non-atomic. If so, the message will be rejected
back to the sender with error code TIPC_ERR_NO_PORT. If the source
socket of the message has disappeared in the meantime, the message
should be dropped.

However, in the currrent code, the message will instead be subject to an
unwanted tertiary lookup, because the function tipc_msg_lookup_dest()
doesn't check if there is an error code present in the message before
performing the lookup. In the worst case, the message may now find the
old destination again, and be redirected once more, instead of being
dropped directly as it should be.

A second bug in this function is that the "prev_node" field in the message
is not updated after successful lookup, something that may have
unpredictable consequences.

The problems arising from those bugs occur very infrequently.

The third change in this function; the test on msg_reroute_msg_cnt() is
purely cosmetic, reflecting that the returned value never can be negative.

This commit corrects the two bugs described above.
Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Jeff Kirsher says:

====================
Intel Wired LAN Driver Updates 2015-03-27

This series contains updates to i40e and i40evf.

Jesse adds new device IDs to handle the new 20G speed for KR2.

Mitch provides a fix for an issue that shows up as a panic or memory
corruption when the device is brought down while under heavy stress.
This is resolved by delaying the releasing of resources until we
receive acknowledgment from the PF driver that the rings have indeed
been stopped.  Also adds firmware version information to ethtool
reporting to align with ixgbevf behavior.

Akeem increases the polling loop limiter, sine we found that in
certain circumstances the firmware can take longer to be ready after
a reset.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Toshiaki Makita says:

====================
Stacked vlan TSO

On the basis of Netdev 0.1 discussion[1], I made a patch set to enable
TSO for packets with multiple vlans.

Currently, packets with multiple vlans are always segmented by software,
which is caused by that netif_skb_features() drops most feature flags
for multiple tagged packets.

To allow NICs to segment them, we need to get rid of that check from core.
Fortunately, recently introduced ndo_features_check() can be used to
move the check to each driver, and this patch set is based on the idea.

For the initial patch set, I chose 3 drivers, bonding, team, and igb, as
candidates to enable TSO. I tested them and confirmed they works fine
with this change.

Here are samples of performance test results. As I expected, %sys gets
pretty lower than before.

* TEST1: vlan (.1Q) on vlan (.1ad) on igb (I350)

- before

$ netperf -t TCP_STREAM -H 192.168.10.1 -l 60
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    60.02     933.72

Average:        CPU     %user     %nice   %system   %iowait    %steal     %idle
Average:        all      0.13      0.00     11.28      0.01      0.00     88.58

- after

$ netperf -t TCP_STREAM -H 192.168.10.1 -l 60
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    60.01     936.13

Average:        CPU     %user     %nice   %system   %iowait    %steal     %idle
Average:        all      0.24      0.00      4.17      0.01      0.00     95.58

* TEST2: vlan (.1Q) on bridge (.1ad vlan filtering) on team on igb (I350)

- before

$ netperf -t TCP_STREAM -H 192.168.10.1 -l 60
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    60.01     936.28

Average:        CPU     %user     %nice   %system   %iowait    %steal     %idle
Average:        all      0.41      0.00     11.57      0.01      0.00     88.01

- after

$ netperf -t TCP_STREAM -H 192.168.10.1 -l 60
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    60.02     935.72

Average:        CPU     %user     %nice   %system   %iowait    %steal     %idle
Average:        all      0.14      0.00      7.66      0.01      0.00     92.19

In addition to above, I tested these configurations:
- vlan (.1Q) on vlan (1.ad) on bonding on igb (I350)
- vlan (.1Q) on vlan (1.Q) on igb (I350)
- vlan (.1Q) on vlan (1.Q) on team on igb (I350)
And didn't find any problem.

[1] https://netdev01.org/sessions/18
    https://netdev01.org/docs/netdev01_bof_8021ad_makita_150212.pdf
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As datasheets for igb (I210, I350, 82576, etc.) say, maclen can be from
14 to 127, which is enough for reasonable number of vlan tags.
My netperf test showed I350's TSO works pretty fine with multiple vlans.
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Team devices don't need to segment multiple tagged packets since their
slaves can segment them.
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Bonding devices don't need to segment multiple tagged packets since their
slaves can segment them.
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As there are a number of (especially virtual) devices that don't
need the multiple vlan check, introduce passthru_features_check() for
convenience.
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

To allow drivers to handle the features check for multiple tags,
move the check to ndo_features_check().
As no drivers currently handle multiple tagged TSO, introduce
dflt_features_check() and call it if the driver does not have
ndo_features_check().
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Separate the two checks for single vlan and multiple vlans in
netif_skb_features().  This allows us to move the check for multiple
vlans to another function later.
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Stacked vlan devices curretly have few features (GRO, HIGHDMA, LLTX).
Since we have software fallbacks in case the NIC can not handle some
features for multiple vlans, we can add the same features as the lower
vlan devices for stacked vlan devices.

This allows stacked vlan devices to create large (GSO) packets and not to
segment packets. Those packets will be segmented by software on the real
device, or even can be segmented by the NIC once TSO for multiple vlans
becomes enabled by the following patches.

The exception is those related to FCoE, which does not have a software
fallback.
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

existing TC action 'pedit' can munge any bits of the packet.
Generalize it for use in bpf programs attached as cls_bpf and act_bpf via
bpf_skb_store_bytes() helper function.
Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
Reviewed-by: NJiri Pirko <jiri@resnulli.us>
Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Guenter Roeck says:

====================
net: dsa: HW bridging, EEE support

Patch 1 to 7 of this series prepare the drivers using the mv88e6xxx code
for HW bridging support, without adding the code itself. For the most part
this factors out common port initialization code. There is no functional
change except for patch 3, which disables the message port bit for the
CPU port to prevent packet duplication if HW bridging is configured.

Patch 8 adds the infrastructure for hardware bridging support to the
mv88e6xxx code.

Patch 9 wires the MV88E6352 driver to support hardware bridging.

Patches 10 to 12 add support for ndo_fdb functions to the dsa subsystem,
and wire up the MV88E6352 driver to support those functions.

Patches 13 to 16 add EEE support and HW bridging support to the mv88e6171
driver. This set of patches is from Andrew, applied on top of the first
set of patches.

The series applies to net-next as of 3/24/2015.

Thanks a lot to Andrew Lunn for testing and valuable feedback.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Wire up the common code for setting up hardware bridging
and access to the forwarding database.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The mv88e6172 has support for EEE. Check for the product ID and call
the common code if applicable.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Make the code more readable by using defines for the switch IDs.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Get the switch id and save it away in the private mv88x6xxx structure
in a centralised piece of code, rather than each driver doing it itself.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for manipulating switch fdb entries by pointing to the
ndo_fdb functions implemented for mv88e6xxxx.
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

No vlan support at this time.
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Provide callbacks for ndo_fdb_add, ndo_fdb_del, and ndo_fdb_dump.
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Bridge support is similar for all chips supported by the mv88e6xxx code,
so add the code there.
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>