After the call to phy_init_hw failed in phy_attach_direct, phy_detach is called
to detach the phy device from its network device. If the attached driver is a
generic phy driver, this also detaches the driver. Subsequently phy_resume
is called, which assumes without checking that a driver is attached to the
device. This will result in a crash such as

Unable to handle kernel paging request for data at address 0xffffffffffffff90
Faulting instruction address: 0xc0000000003a0e18
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c0000000003a0e18] .phy_attach_direct+0x68/0x17c
LR [c0000000003a0e6c] .phy_attach_direct+0xbc/0x17c
Call Trace:
[c0000003fc0475d0] [c0000000003a0e6c] .phy_attach_direct+0xbc/0x17c (unreliable)
[c0000003fc047670] [c0000000003a0ff8] .phy_connect_direct+0x28/0x98
[c0000003fc047700] [c0000000003f0074] .of_phy_connect+0x4c/0xa4

Only call phy_resume if phy_init_hw was successful.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch disables multicast hash filtering if present in the hardware
and uses promiscuous mode instead until the problem with multicast
filtering has been debugged, integrated and tested.
Signed-off-by: NVince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the many sparse errors and warnings contained in the
initial submission of the Altera Triple Speed Ethernet driver, and a
few minor cppcheck warnings. Changes are tested on ARM and NIOS2
example designs, and compile tested against multiple architectures.
Typical issues addressed were as follows:

altera_tse_ethtool.c:136:19: warning: incorrect type in argument
    1 (different address spaces)
altera_tse_ethtool.c:136:19:    expected void const volatile
    [noderef] <asn:2>*addr
altera_tse_ethtool.c:136:19:    got unsigned int *<noident>
...
altera_sgdma.c:129:31: warning: cast removes address space of
    expression
Signed-off-by: NVince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On some BE3 FW versions, after a HW reset, interrupts will remain disabled
for each function. So, explicitly enable the interrupts in the eeh_resume
handler, else after an eeh recovery interrupts wouldn't work.
Signed-off-by: NKalesh AP <kalesh.purayil@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In my recent fix (76a691d0: fix dma unmap warning), Ben Hutchings noted that my
loop count was incorrect.  Where j started at startidx, it should have started
at zero, and gone on for count entries, not to endidx.  Additionally, a DMA
resource exhaustion should drop the frame and (for now), return
NETDEV_TX_OK, not NETEV_TX_BUSY.  This patch fixes both of those issues:
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: Ben Hutchings <ben@decadent.org.uk>
CC: "David S. Miller" <davem@davemloft.net>
CC: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the sfc driver is in legacy interrupt mode (either explicitly by
using interrupt_mode module param or by falling back to it) it will
hit a warning at kernel/irq/manage.c because it will try to free an irq
which wasn't allocated by it in the first place because the MSI(X) irqs are
zero and it'll try to free them unconditionally. So fix it by checking if
we're in legacy mode and freeing the appropriate irqs.

CC: Zenghui Shi <zshi@redhat.com>
CC: Ben Hutchings <ben@decadent.org.uk>
CC: <linux-net-drivers@solarflare.com>
CC: Shradha Shah <sshah@solarflare.com>
CC: David S. Miller <davem@davemloft.net>

Fixes: 1899c111 ("sfc: Fix IRQ cleanup in case of a probe failure")
Reported-by: NZenghui Shi <zshi@redhat.com>
Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
Acked-by: NShradha Shah <sshah@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Clearing the IFF_ALLMULTI flag on a down interface could cause an allmulti
overflow on the underlying interface.

Attempting the set IFF_ALLMULTI on the underlying interface would cause an
error and the log message:

"allmulti touches root, set allmulti failed."
Signed-off-by: NPeter Christensen <pch@ordbogen.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In the cas_lock_tx function we acquire multiple locks in a loop and
need to use nested lock annotation to prevent lockdep warnings.
Reported-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NEmil Goode <emilgoode@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 91ebb928b "bnx2x: Add support for Multi-Function UNDI" contains a bug
which prevent the emptying of the device's Rx buffers before reset.
As a result, on new boards it is likely HW will reach some fatal assertion
once its interfaces load after UNDI was previously loaded.
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NAriel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add missing of_node_put to avoid kref leak.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix null-pointer dereference at probe when the mdio platform device is
missing (e.g. when it has been disabled in DT).

Cc: stable <stable@vger.kernel.org>	# v3.8
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit f8d56d8f ("net:
 eth: cpsw: Correctly attach to GPIO bitbang MDIO driver").

Fix potential null-pointer dereference at probe if the mdio-gpio device
has not been successfully probed yet.

The offending commit is plain wrong for a number of reasons. First of
all it accesses internal driver data of an unrelated device. Neither
does it check that the data is non-null (which it is in case the device
has not been probed yet).

Furthermore, the decision on whether to treat any driver data according
to the mdio-gpio driver's internals is made based on the node name. But
the name is not compared against "mdio" which is the normal name for the
node, but rather against "gpio" which the node does not have to be named
(and shouldn't be according to the binding documentation). [ If this
hack is to be kept out-of-tree it should at least be matching against
the compatible property. ]

Cc: Stefan Roese <sr@denx.de>
Cc: stable <stable@vger.kernel.org>	# v3.14
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use a sane default bus id (rather than -ENODEV) and print a warning when
the bus alias id is missing.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver maps 802.1q VLANs to MBIM sessions. The mapping is based on
a bogus assumption that all tagged frames will use the acceleration API
because we enable NETIF_F_HW_VLAN_CTAG_TX. This fails for e.g. frames
tagged in userspace using packet sockets. Such frames will erroneously
be considered as untagged and silently dropped based on not being IP.

Fix by falling back to looking into the ethernet header for a tag if no
accelerated tag was found.

Fixes: a82c7ce5 ("net: cdc_ncm: map MBIM IPS SessionID to VLAN ID")
Cc: Greg Suarez <gsuarez@smithmicro.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver adds support for EtherCAT master module located on CCAT
FPGA found on Beckhoff CX series industrial PCs. The driver exposes
EtherCAT master as an ethernet interface.

EtherCAT is a fieldbus protocol defined on top of ethernet and Beckhoff
CX5020 PCs come with built-in EtherCAT master module located on a FPGA,
which in turn is connected to a PCI bus.
Signed-off-by: NDariusz Marcinkiewicz <reksio@newterm.pl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Do not set netdev->real_num_tx_queues directly,
let netif_set_real_num_tx_queues() take care of it.
Do not overwrite netdev->num_tx_queues everytime when driver
changes its Tx ring size through ethtool -L and also notify
stack to update number of Rx queues.
Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

o In case of non-multi TX queue mode driver does not initialize "crb_intr_mask" pointer
  and driver was accessing that un-initialized pointer while dumping TX queue.
  So dump "crb_intr_mask" only when it is initilaized.
Signed-off-by: NManish Chopra <manish.chopra@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The jme driver forgot to check the return status from pci_map_page in its tx
path, causing a dma api warning on unmap.  Easy fix, just do the check and
augment the tx path to tell the stack that the driver is busy so we re-queue the
frame.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: Guo-Fu Tseng <cooldavid@cooldavid.org>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixes this warning introduced by commit 5b8f15f7
("net: cdc_mbim: handle IPv6 Neigbor Solicitations"):

===============================
[ INFO: suspicious RCU usage. ]
3.15.0-rc3 #213 Tainted: G        W  O
-------------------------------
net/8021q/vlan_core.c:69 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 1
no locks held by ksoftirqd/0/3.

stack backtrace:
CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G        W  O  3.15.0-rc3 #213
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
 0000000000000001 ffff880232533bf0 ffffffff813a5ee6 0000000000000006
 ffff880232530090 ffff880232533c20 ffffffff81076b94 0000000000000081
 0000000000000000 ffff8802085ac000 ffff88007fc8ea00 ffff880232533c50
Call Trace:
 [<ffffffff813a5ee6>] dump_stack+0x4e/0x68
 [<ffffffff81076b94>] lockdep_rcu_suspicious+0xfa/0x103
 [<ffffffff813978a6>] __vlan_find_dev_deep+0x54/0x94
 [<ffffffffa04a1938>] cdc_mbim_rx_fixup+0x379/0x66a [cdc_mbim]
 [<ffffffff813ab76f>] ? _raw_spin_unlock_irqrestore+0x3a/0x49
 [<ffffffff81079671>] ? trace_hardirqs_on_caller+0x192/0x1a1
 [<ffffffffa059bd10>] usbnet_bh+0x59/0x287 [usbnet]
 [<ffffffff8104067d>] tasklet_action+0xbb/0xcd
 [<ffffffff81040057>] __do_softirq+0x14c/0x30d
 [<ffffffff81040237>] run_ksoftirqd+0x1f/0x50
 [<ffffffff8105f13e>] smpboot_thread_fn+0x172/0x18e
 [<ffffffff8105efcc>] ? SyS_setgroups+0xdf/0xdf
 [<ffffffff810594b0>] kthread+0xb5/0xbd
 [<ffffffff813a84b1>] ? __wait_for_common+0x13b/0x170
 [<ffffffff810593fb>] ? __kthread_parkme+0x5c/0x5c
 [<ffffffff813b147c>] ret_from_fork+0x7c/0xb0
 [<ffffffff810593fb>] ? __kthread_parkme+0x5c/0x5c

Fixes: 5b8f15f7 ("net: cdc_mbim: handle IPv6 Neigbor Solicitations")
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Under "heavy" RX load, the driver cannot handle the descriptors fast
enough. In detail, when a descriptor is consumed, its used flag is
cleared and once the RX budget is consumed all descriptors with a
cleared used flag are prepared to receive more data. Under load though,
the HW may constantly receive more data and use those descriptors with a
cleared used flag before they are actually prepared for next usage.

The head and tail pointers into the RX-ring should always be valid and
we can omit clearing and checking of the used flag.
Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Coverage data suggests that the unlikely case of receiving data while
the receive handler is running may not be that unlikely.
Coverage data after running iperf for a while:
    91320:  891:	work_done = bp->macbgem_ops.mog_rx(bp, budget);
    91320:  892:	if (work_done < budget) {
     2362:  893:		napi_complete(napi);
        -:  894:
        -:  895:		/* Packets received while interrupts were disabled */
     4724:  896:		status = macb_readl(bp, RSR);
     2362:  897:		if (unlikely(status)) {
      762:  898:			if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
      762:  899:				macb_writel(bp, ISR, MACB_BIT(RCOMP));
        -:  900:			napi_reschedule(napi);
        -:  901:		} else {
     1600:  902:			macb_writel(bp, IER, MACB_RX_INT_FLAGS);
        -:  903:		}
        -:  904:	}
Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When data is received during the driver processing received data the
NAPI is re-scheduled. In that case the RX interrupt should not be
re-enabled.
Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A few interrupt flags were not cleared in the ISR, resulting in a sytem
trapped in the ISR in cases one of those interrupts occurred. Clear all
flags to avoid such situations.
Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Just as commit "net: macb: DMA-unmap full rx-buffer"
(48330e08), pass the size that
was used for mapping the memory also to the unmap routine to
avoid warnings from the DMA_API.
Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It has been determined that the workaround of putting the PHY into MDIO
slow mode to access the PHY id is not necessary with Lynx Point and newer
parts.  The issue that necessitated the workaround has been fixed on the
newer hardware.

We will maintains, as a last ditch attempt, the conversion to MDIO Slow
Mode in the failure branch when attempting to access the PHY id so as to
cover all contingencies.
Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Several customers have reported a link flap issue on 82579. The symptoms
are random and intermittent link losses when 82579 is connected to specific
link partners. Issue has been root caused as interoperability problem
between 82579 and at least some Broadcom PHYs in the Energy Efficient
Ethernet wake mechanism.

To fix the issue, we are disabling the Phase Locked Loop shutdown in 100M
Low Power Idle.  This solution will cause an increase of power in 100M EEE
link. It will cost additional 28mW in this specific mode.

Cc: Lukasz Adamczuk <lukasz.adamczuk@intel.com>
Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

In commit 772d05c5 "e1000e: slow performance
between two 82579 connected via 10Mbit hub", a workaround was put into place
to address the overaggressive transmit behavior of 82579 parts when connecting
at 10Mbs half-duplex.

This same behavior is seen on i217 and i218 parts as well.  This patch expands
the original workaround to encompass these parts.
Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This is a workaround for a HW erratum on 82579 devices.
Erratum is #23 in Intel 6 Series Chipset and Intel C200 Series Chipset
specification Update June 2013.

Problem: 82579 parts experience packet loss in Gig and 100 speeds
when interconnect between PHY and MAC is exiting K1 power saving state.
This was previously believed to only affect 1Gig speed, but has been observed
at 100Mbs also.

Workaround: Disable K1 for 82579 devices at Gig and 100 speeds.
Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Carrying out PCI speed/width checks through pcie_get_minimum_link()
on VFs yield wrong results, so remove them.

Fixes: b912b2f8 ('net/mlx4_core: Warn if device doesn't have enough PCI bandwidth')
Signed-off-by: NEyal Perry <eyalpe@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When running in SRIOV mode, VM that is assigned with a non-provisioned
Ethernet VFs get themselves a random mac when the Eth driver starts. In
this case, if the IB driver startup code that deals with RoCE runs first,
it will use a zero mac as the source mac for the Para-Virtual CM MADs
which is buggy. To handle that, we change the order of loading.
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The code that deals with computing the slave id based on a given GID
gave wrong results when the number of single port VFs wasn't the
same for port 1 vs. port 2 and the relevant VF is single ported on
port 2. As a result, incoming CM MADs were dispatched to the wrong VF.
Fixed that and added documentation to clarify the computation steps.

Fixes: 449fc488 ('net/mlx4: Adapt code for N-Port VF')
Signed-off-by: NMatan Barak <matanb@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When using single ported VFs and the VF is using port 2, we need
to adjust the port accordingly (change it from 1 to 2).

Fixes: 449fc488 ('net/mlx4: Adapt code for N-Port VF')
Signed-off-by: NMatan Barak <matanb@mellanox.com>
Signed-off-by: NJack Morgenstein <jackm@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 4d619f62 ("net: cdc_ncm: no point in filling up the NTBs
if we send ZLPs") changed the padding logic for devices with the ZLP
flag set.  This meant that frames of any size will be sent without
additional padding, except for the single byte added if the size is
a multiple of the USB packet size. But if the unpadded size is
identical to the maximum frame size, and the maximum size is a
multiplum of the USB packet size, then this one-byte padding will
overflow the buffer.

Prevent padding if already at maximum frame size, letting usbnet
transmit a ZLP instead in this case.

Fixes: 4d619f62 ("net: cdc_ncm: no point in filling up the NTBs if we send ZLPs")
Reported by: Yu-an Shih <yshih@nvidia.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If NO_DMA=y:

drivers/built-in.o: In function `altera_tse_probe':
altera_tse_main.c:(.text+0x25ec2e): undefined reference to `dma_set_mask'
altera_tse_main.c:(.text+0x25ec78): undefined reference to `dma_supported'
altera_tse_main.c:(.text+0x25ecb6): undefined reference to `dma_supported'
drivers/built-in.o: In function `sgdma_async_read':
altera_sgdma.c:(.text+0x25f620): undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `sgdma_uninitialize':
(.text+0x25f678): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `sgdma_uninitialize':
(.text+0x25f696): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `sgdma_initialize':
(.text+0x25f6f0): undefined reference to `dma_map_single'
drivers/built-in.o: In function `sgdma_initialize':
(.text+0x25f702): undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `sgdma_tx_buffer':
(.text+0x25f92a): undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `sgdma_rx_status':
(.text+0x25fa24): undefined reference to `dma_sync_single_for_cpu'
make[3]: *** [vmlinux] Error 1
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NVince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The following commit:

commit 9ec36caf
Author: Rob Herring <robh@kernel.org>
Date:   Wed Apr 23 17:57:41 2014 -0500

    of/irq: do irq resolution in platform_get_irq

changed platform_get_irq() which now returns EINVAL and EPROBE_DEFER,
in addition to ENXIO. If there's no interrupt for mvmdio, platform_get_irq()
returns EINVAL, but we currently check only for ENXIO.

Fix this by looking for a positive integer, which is the proper way of
validating a virtual interrupt number.

While at it, add a proper handling for the deferral probe case.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

phy_state_machine should check whether auto-negotiatin is completed
before changing phydev->state from PHY_NOLINK to PHY_RUNNING. If
auto-negotiation is not completed phydev->state should be set to
PHY_AN.
Signed-off-by: NBalakumaran Kannan <kumaran.4353@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Do checksum offload only if the client of the driver wants checksum to be
offloaded.

In V1 version of this patch, I  addressed comments from
Stephen Hemminger <stephen@networkplumber.org> and
Eric Dumazet <eric.dumazet@gmail.com>.

In this version of the patch I have addressed comments from
David Miller.

This patch fixes a bug that is exposed in gateway scenarios.
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For phy devices that don't issue interrupts upon link
state changes, phylib polls the link state resulting in
repeated calls to adjust_link(), even if the link state
didn't change.  As a result, some mac registers are
repeatedly read and written with the same values, which
is not ok.

To fix this, adjust_link() has been refactored to check
first whether the link state has changed and to take action
only if needed, updating mac registers and local state
variables.  The 'new_state' local flag, set if one of the
link params changed (link, speed or duplex), has been
rendered useless and removed by this refactoring.
Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 12a2856b.
The commit above doesn't appear to be necessary any more as the
checksums appear to be correctly computed/validated.

Additionally the above commit breaks kvm configurations where
one VM is using a device that support checksum offload (virtio) and
the other VM does not.
In this case, packets leaving virtio device will have CHECKSUM_PARTIAL
set.  The packets is forwarded to a macvtap that has offload features
turned off.  Since we use CHECKSUM_UNNECESSARY, the host does does not
update the checksum and thus a bad checksum is passed up to
the guest.

CC: Daniel Lezcano <daniel.lezcano@free.fr>
CC: Patrick McHardy <kaber@trash.net>
CC: Andrian Nord <nightnord@gmail.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Michael S. Tsirkin <mst@redhat.com>
CC: Jason Wang <jasowang@redhat.com>
Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The following is a problematic configuration:

 VM1: virtio-net device connected to macvtap0@eth0
 VM2: e1000 device connect to macvtap1@eth0

The problem is is that virtio-net supports checksum offloading
and thus sends the packets to the host with CHECKSUM_PARTIAL set.
On the other hand, e1000 does not support any acceleration.

For small TCP packets (and this includes the 3-way handshake),
e1000 ends up receiving packets that only have a partial checksum
set.  This causes TCP to fail checksum validation and to drop
packets.  As a result tcp connections can not be established.

Commit 3e4f8b78
	macvtap: Perform GSO on forwarding path.
fixes this issue for large packets wthat will end up undergoing GSO.
This commit adds a check for the non-GSO case and attempts to
compute the checksum for partially checksummed packets in the
non-GSO case.

CC: Daniel Lezcano <daniel.lezcano@free.fr>
CC: Patrick McHardy <kaber@trash.net>
CC: Andrian Nord <nightnord@gmail.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Michael S. Tsirkin <mst@redhat.com>
CC: Jason Wang <jasowang@redhat.com>
Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>