The P1010 device tree restricts the number of
supported interrupt groups to 1, although the eth
controller can support 2 interrupt groups and the
driver assumes the Multi-Group mode ("fsl,etsec2" model).

So, in this case the assumption that the Multi-Group
mode (MQ_MG_MODE) devices always support 2 interrupt
groups is false.  To fix this, a check for the actual
number of interrupt groups enabled in the board's
device tree has been added in gfar_probe for the
"fsl,etsec2" devices.

Without this fix, P1010 based boards claim support for
2 Tx queues to the net stack but only one is actually
allocated, leading to NULL access in xmit.  This issue
was introduced by enabling Single-Queue polling for
the P1010 devices.
(71ff9e3d gianfar: Use Single-Queue polling for
"fsl,etsec2")

Fixes: 71ff9e3dSigned-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ipv4_ifdown_dst does nothing after IPv4 route caches removal,
so we can remove it.
Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When changing one 16bit value by another in IP header, we can adjust
the IP checksum by doing a simple operation described in RFC 1624, as
reminded by David.

csum_partial() is a complex function on x86_64, not really suited for
small number of checksummed bytes.

I spotted csum_partial() being in the top 20 most consuming functions
(more than 1 %) in a GRO workload, which was rather unexpected.

The caller was inet_gro_complete() doing a csum_replace2() when
building the new IP header for the GRO packet.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Antonio Quartulli says:

====================
Included changes:
- use ether_addr_copy instead of memcpy when possible
- implement new multicast packet optimisation
- improve several kerneldoc sections
- minor code cleanups

here you have our patchset for net-next/linux-3.15.  They are 16
patches but most of them are just small cleanups and kerneldoc
improvements.

The only big change is the one from patch 8 to 13 by Linus Lüssing
that introduces a new multicast packets optimisation. This new
component aims to reduce the air overhead by sending multicast packets
as bat-unicast when only one destination exists or by dropping them
directly at the source if the multicast group is totally empty.

In patch 11 Linus introduces an atomic_t variable, that like others
that we already have is only object of write and read, thus making the
atomic characteristic totally useless.  Unfortunately this is part of
our sysfs framework, that helps the developer to introduce new knobs
by using few macros only. For this reason we decided to keep Linus'
new knob for now, but I'd like to let you know that we are in the
process of re-working such framework in order to convert all the
current (useless) atomic_t to boolean in one go.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

Add missing documentation for BATADV_DAT_ADDR_MAX and
convert an existing documentation to kerneldoc
Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>

Convert the current documentation for the TT flags in proper
kerneldoc and improve it by adding an explanation for each
of the flags.
Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>

With this patch a node sends IPv4 multicast packets to nodes which
have a BATADV_MCAST_WANT_ALL_IPV4 flag set and IPv6 multicast packets
to nodes which have a BATADV_MCAST_WANT_ALL_IPV6 flag set, too.

Why is this needed? There are scenarios involving bridges where
multicast report snooping and multicast TT announcements are not
sufficient, which would lead to packet loss for some nodes otherwise:

MLDv1 and IGMPv1/IGMPv2 have a suppression mechanism
for multicast listener reports. When we have an MLDv1/IGMPv1/IGMPv2
querier behind a bridge then our snooping bridge is potentially not
going to see any reports even though listeners exist because according
to RFC4541 such reports are only forwarded to multicast routers:

-----------------------------------------------------------
            ---------------
{Querier}---|Snoop. Switch|----{Listener}
            ---------------
                       \           ^
                      -------
                      | br0 |  <  ???
                      -------
                          \
                     _-~---~_
                 _-~/        ~-_
                ~   batman-adv  \-----{Sender}
                \~_   cloud    ~/
                   -~~__-__-~_/

I)  MLDv1 Query:  {Querier}  -> flooded
II) MLDv1 Report: {Listener} -> {Querier}

-> br0 cannot detect the {Listener}
=> Packets from {Sender} need to be forwarded to all
   detected listeners and MLDv1/IGMPv1/IGMPv2 queriers.

-----------------------------------------------------------

Note that we do not need to explicitly forward to MLDv2/IGMPv3 queriers,
because these protocols have no report suppression: A bridge has no
trouble detecting MLDv2/IGMPv3 listeners.

Even though we do not support bridges yet we need to provide the
according infrastructure already to not break compatibility later.
Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

With this patch a node may additionally perform the dropping or
unicasting behaviour for a link-local IPv4 and link-local-all-nodes
IPv6 multicast packet, too.

The extra counter and BATADV_MCAST_WANT_ALL_UNSNOOPABLES flag is needed
because with a future bridge snooping support integration a node with a
bridge on top of its soft interface is not able to reliably detect its
multicast listeners for IPv4 link-local and the IPv6
link-local-all-nodes addresses anymore (see RFC4541, section 2.1.2.2
and section 3).

Even though this new flag does make "no difference" now, it'll ensure
a seamless integration of multicast bridge support without needing to
break compatibility later.

Also note, that even with multicast bridge support it won't be possible
to optimize 224.0.0.x and ff02::1 towards nodes with bridges, they will
always receive these ranges.
Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

With this patch a multicast packet is not always simply flooded anymore,
the behaviour for the following cases is changed to reduce
unnecessary overhead:

If all nodes within the horizon of a certain node have signalized
multicast listener announcement capability then an IPv6 multicast packet
with a destination of IPv6 link-local scope (excluding ff02::1) coming
from the upstream of this node...

* ...is dropped if there is no according multicast listener in the
  translation table,
* ...is forwarded via unicast if there is a single node with interested
  multicast listeners
* ...and otherwise still gets flooded.
Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

If the soft interface of a node is not part of a bridge then a node
announces a new multicast TVLV: The existence of this TVLV
signalizes that this node is announcing all of its multicast listeners
via the translation table infrastructure.
Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

The new bitfield allows us to keep track whether capability subsets of
an originator have gone through their initialization phase yet.

The translation table is the only user right now, but a new one will be
added soon.
Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

With this patch a node which has no bridge interface on top of its soft
interface announces its local multicast listeners via the translation
table.
Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

Some helper functions used along the TX path have now a new
"dst_hint" argument but the kerneldoc was missing.
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>

Reported-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

Reported-by: NAntonio Quartulli <antonio@meshcoding.com>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

On some architectures ether_addr_copy() is slightly faster
than memcpy() therefore use the former when possible.
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>

Our .ndo_start_xmit handler (batadv_interface_tx()) can rely on having
the skb mac header pointer set correctly since the following commit
present in kernels >= 3.9:

"net: reset mac header in dev_start_xmit()" (6d1ccff6)

Therefore this commit removes the according, now redundant,
skb_reset_mac_header() call in batadv_bla_tx().
Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

Our .ndo_start_xmit handler (batadv_interface_tx()) can rely on having
the skb mac header pointer set correctly since the following commit
present in kernels >= 3.9:

"net: reset mac header in dev_start_xmit()" (6d1ccff6)

Therefore we can safely use eth_hdr() and vlan_eth_hdr() instead of
skb->data now, which spares us some ugly type casts.

At the same time set the mac_header in batadv_dat_snoop_incoming_arp_request()
before sending the skb along the TX path.
Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

net/batman-adv/network-coding.c:1535:1-7: Replace memcpy with struct assignment

Generated by: coccinelle/misc/memcpy-assign.cocci
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NMartin Hundebøll <martin@hundeboll.net>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>

Richard Cochran says:

====================
ptp: dynamic pin control

This patch series introduces a way of changing the auxiliary PTP
Hardware Clock functions (periodic output signals and time stamping
external signals) at run time. In the past on the netdev list, we have
discussed other ways to handle this, such as module parameters and
ethtool. This series implements a new PHC ioctl because that is the
most natural way. Users already activate the auxiliary functions via
the ioctls. The sysfs interface has also been expanded so that the pin
configuration can be programmed using shell scripts.

The first patch adds the new ioctls. The PHC subsystem does most of
the work of maintaining the function-to-pin mapping. Drivers will only
need to allocate and initialize a pin configuration table and also
provide a new method that validates a particular assignment.

Patches 5 and 6 just clean up a couple of issues in the phyter driver,
and the remaining patches actually hook the phyter's pins into the new
system.

* ChangeLog
** V3
   - simplify locking in the set pin logic
** V2
   - fix bug in sysfs code on init error path
   - rename ptp_setpin() to ptp_set_pinfunc()
   - rename .setpin() to .verify() in the driver interface
   - simplify ptp_find_pin() logic
   - use correct test when checking whether the pin with the
     calibration function is being reprogrammed
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch changes the driver use the new pin configuration method when
programming the periodic output signal.
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 new pin configuration method when
programming the external time stamp input signals.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adapts the dp83640 driver to allow reconfiguration of which
auxiliary function goes on which pin. The functions may be reassigned
freely with the one exception of the calibration function.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The phyter driver incorrectly feeds the value of the period into what
is in fact a pulse width register, resulting in the actual period
being twice the dialed value. This patch fixes the issue and renames a
variable to make the code at bit more clear.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch cleans up the input checking code on the external time stamp
function by using an unsigned rather than a signed channel index.

Also, this patch corrects the author's email address. When this macro
was last changed, the top level domain part of the email address was
left behind.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch updates the many PTP Hardware Clock drivers with the
newly introduced field that advertises the number of programmable
pins. Some of these devices do have programmable pins, but the
implementation will have to wait for follow on patches.
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 patch adds the sysfs hooks needed in order to get and set the
programmable pin settings.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds a option to the test program that lists the
programmable pins on a PTP Hardware Clock device, assuming there
are any such pins. A second option lets the user reprogram the
auxiliary function of a single pin.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds a pair of new ioctls to the PTP Hardware Clock device
interface. Using the ioctls, user space programs can query each pin to
find out its current function and also reprogram a different function
if desired.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Florian Fainelli says:

====================
net: bcmgenet: misc fixes

This patch series contains some misc. fixes for the bcmgenet driver.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Instead of always invoking netdev_get_tx_queue() in bcmgenet_xmit() and
bcmgenet_tx_reclaim(), just get the corresponding netdev_queue pointer
once and for all and manipulate it throughout bcmgenet_xmit() and
bcmgenet_tx_reclaim().
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

netdev_pick_tx already takes care of making sure that a given
skb->queue_mapping value will remain within the number of advertised
hardware queue number, there is no need to re-do this again in the
driver.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The BCMGENET driver was not TX timestamping the SKBs it queued for
transmission, do this in bcmgenet_xmit() right before kicking the
Transmit DMA engine.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The spinlock cookie in bcmgenet_priv is never used, get rid of it.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Laurent Pinchart says:

====================
sh_eth: Fix the race between open and MDIO bus registration

This patch series fixes the race condition that exists in the sh_eth driver
between network device open and MDIO bus registration. The actual fix is in
patch 4/5, with previous patches preparing the driver and patch 5/5 cleaning
up an unrelated issue.

I've based the idea on Sergei's attempt to fix the problem and can successfully
boot the Koelsch board over NFS with this series. I might have missed other
issues though, hence the RFC status.

The patches are based on top of the latest net-next master branch.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

"goto" is well accepted for error paths in the kernel but should not be
used unnecessarily. Return the correct value directly instead of using a
goto when possible.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Network API functions that rely on the MDIO bus can be called as soon as
the driver calls register_netdev(). Register the MDIO bus before the
network device to avoid race conditions.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The network device passed to the sh_mdio_init and sh_mdio_release
functions is only used to access the sh_eth_private instance. Pass it
directly to those functions.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The MDIO bus parent is set to the network device. Beside not reflecting
the hardware topology, this prevents registering the MDIO bus before
initializing the network device. Fix it by setting the MDIO bus parent
to the platform device.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>