Size of be_nic_res_desc structure is incorrect. Fix it.
Signed-off-by: NAjit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Tx on SH-R can lockup if the packet size is less than 32 bytes.
Pad such packets to a safer 36-byte size.
Patch uses the Lancer-R workaround - which checks for packet <= 32-bytes
Signed-off-by: NAjit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

coccicheck shows:

drivers/net/ethernet/intel/i40e/i40e_adminq.c:704:2-8: Replace memcpy
with struct assignment
drivers/net/ethernet/intel/i40e/i40e_adminq.c:763:1-7: Replace memcpy
with struct assignment
drivers/net/ethernet/intel/i40e/i40e_adminq.c:810:2-8: Replace memcpy
with struct assignment
drivers/net/ethernet/intel/i40e/i40e_common.c:510:2-8: Replace memcpy
with struct assignment

Fix each of them with a *a = *b;
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

As mentioned by Joe Perches, clean up return values in some functions
making sure to have consistent return types, not mixing types.

A couple of Joe's comments suggested returning void, but since
the functions in question are ndo defined, the return values are fixed.
So make a comment in the header that notes this is a function called by
net_device_ops.

v2: fix post increment bug in return

CC: Joe Perches <joe@perches.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When calling admin queue functions the driver should use aq_ret
variable to help make clear that the return value is not a regular
return variable.

This allows for clean up of the return types that were previously
converted to int.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

As mentioned by Joe Perches clean up a loop flow.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
CC: Joe Perches <joe@perches.com>
Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

As mentioned by Joe Perches, we should be using
foo = alloc(...)
if (!foo)
	return -ENOMEM;

return 0;
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
CC: Joe Perches <joe@perches.com>
Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Add back 82580 loopback tests to ethtool.
Signed-off-by: NTodd Fujinaka <todd.fujinaka@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Outgoing packets sent by via-rhine have their VLAN PCP field off by one
(when hardware acceleration is enabled). The TX descriptor expects only VID
and PCP (without a CFI/DEI bit).

Peter Boström noticed and reported the bug.
Signed-off-by: NRoger Luethi <rl@hellgate.ch>
Cc: Peter Boström <peter.bostrom@netrounds.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Also changed a log message to indicate that memory was not allocated
instead of memory not available!
Signed-off-by: NMalahal Naineni <malahal@us.ibm.com>
Acked-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In my patch c194992c ("skge: fix
broken driver") I didn't fix the skge bug correctly. The value of the
new mapping (not old) was passed to pci_unmap_single.

If we enable CONFIG_DMA_API_DEBUG, it results in this warning:
WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:986 check_sync+0x4c4/0x580()
skge 0000:02:07.0: DMA-API: device driver tries to sync DMA memory it has
not allocated [device address=0x000000023a0096c0] [size=1536 bytes]

This patch makes the skge driver pass the correct value to
pci_unmap_single and fixes the warning. It copies the old descriptor to
on-stack variable "ee" and unmaps it if mapping of the new descriptor
succeeded.

This patch should be backported to 3.11-stable.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Reported-by: NFrancois Romieu <romieu@fr.zoreil.com>
Tested-by: NMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit b9871bcf "bnx2x: VF RSS support - PF side" has deprecated one of
the previous existing messages. If an old VF driver were to send this message
to the PF then the PF will not reply and leave the mailbox in an unsteady
state (and cause a timeout on the VF side).

Wait until firmware ack is written before unlocking channel
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

During flows which mask block attentions (e.g., register dump) all parities
are masked. However, unlike other blocks the MCP's attention is not masked
inside the block but rather the indication to the driver. If another attention
(e.g., link change) will occour while there's an MCP parity, the driver will
ignore the fact that the parity is masked and erroneously report a parity.

This patch forces the driver to read the MCP masking while checking for
parities.
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

During error flows while loading cnic the return value was incorrectly replaced
by that of bnx2x_set_real_num_queues(); If that function was to finish
successfully then the cnic would have mistakenly thought the load ended
successfully, causing issues (& panics) later on.
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

bnx2x_iov_static_resc() should be called after IGU was read for information on
the number of available VFs, so that resources will be correctly set.
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Due to incorrect usage of PF macros when reading information relating to
interrupts, some PFs were erroneously unable to support VFs.
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When system CPU is stressed it's possible that the driver will not be able
to pulse the FW every second, which will cause the log to be filled with
error messages.

Increasing the threshold to 5 seconds seems to be enough to eliminate the
issue.
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On 848xx PHY (10G-baseT), half-duplex was always advertised regardless of the
actual configuration. Change the 848xx duplex settings to advertise half-duplex
only if configured.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix Warpcore mode setting when active DAC (Direct Attached Cable) is detected.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

when 1G-optic module was plugged in, internal loopback test failed because the
driver used to check the optic module (with no need), and for 1G optic module,
the link speed was forced down to 1G, while the XMAC (10G MAC) was enabled.
This patch avoid accessing optic module in case internal loopback was selected,
and update the link speed in case 1G optic module was detected during init
stage.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Relocate bnx2x_disable_kr2 function, and use it to disable KR2 in case it is not
configured in order to clear it's configuration, otherwise the link may come up
at 20G instead of the requested 10G-KR. In addition, restart AN after
disabling KR2 as part of the KR2 work-around.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Previously, in case of KR link down, the driver would reset the PHY and restart
auto negotiation only when old Warpcore microcode was used (below D108).
This patch comes to generalize this by keep trying to restart KR link,
regardless of Warpcore microcode, since it was found that it solves another link
issue which source is a link-partner. As part of this change, the signal
detect is no longer a condition to apply the work-around to cover this new case.
Like before, as long as the link is down, AN will be restarted every 2 seconds.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The SFC9120 MC firmware often takes longer than 20ms to reboot and
update the warm boot count in BIU_MC_SFT_STATUS_REG.  A timeout of
250ms is very generous for an MC reboot.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>

Scheduling a reset following an MC reboot event before waiting for
reboot to complete results in a race that can lead to a state where
must_realloc_vis is false in efx_ef10_fini_dmaq() but the VIs have
been destroyed during the MC reboot.

To avoid MC errors when trying to remove VIs that do not exist, wait
for the MC reboot to complete before scheduling the reset.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>

The patch 136d8f37 broke the skge driver.
Note this part of the patch:
+               if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) {
+                       dev_kfree_skb(nskb);
+                       goto resubmit;
+               }
+
                pci_unmap_single(skge->hw->pdev,
                                 dma_unmap_addr(e, mapaddr),
                                 dma_unmap_len(e, maplen),
                                 PCI_DMA_FROMDEVICE);
                skb = e->skb;
                prefetch(skb->data);
-               skge_rx_setup(skge, e, nskb, skge->rx_buf_size);

The function skge_rx_setup modifies e->skb to point to the new skb. Thus,
after this change, the new buffer, not the old, is returned to the
networking stack.

This bug is present in kernels 3.11, 3.11.1 and 3.12-rc1. The patch should
be queued for 3.11-stable.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Reported-by: NMikulas Patocka <mpatocka@redhat.com>
Reported-by: NVasiliy Glazov <vascom2@gmail.com>
Tested-by: NMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit 104a43ed
    cnic: Use CHIP_NUM macros from bnx2x.h

changed the code to use the bnx2x macro NO_FCOE() to determine if FCoE
is supported or not.  There is another place in cnic that is still using
the old method to determine if FCoE is supported or not.  The 2 methods
may not yield the same result after the network interface is brought down
and up.  This will cause the crash as cnic_bnx2x_service_kcq() will access
the uninitialized cp->kcq2.

The fix is to consistently use the same macro CNIC_SUPPORTS_FCOE() which
uses the bnx2x NO_FCOE() macro.  As a follow-up, we can clean up the code
to remove the old method as it is no longer needed.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit b9871bcf
    bnx2x: VF RSS support - PF side

changed the configuration of the doorbell HW and it broke iSCSI and FCoE.
We fix this by making compatible changes to the doorbell address in bnx2i
and bnx2fc.  For the userspace driver, we need to pass a modified CID
so that the existing userspace driver will calculate the correct doorbell
address and continue to work.
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NEddie Wai <eddie.wai@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is important patch for new devices that support unaligned
addressing. That devices suffer from the backward-compatibility bug in
DMA engine. In theory we should be able to use old mechanism, but in
practice DMA address seems to be randomly copied into status register
when hardware reaches end of a ring. This breaks reading slot number
from status register and we can't use DMA anymore.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Without this patch it is impossible to read et_swtype, because the 1
byte space is needed for the terminating null byte. The max expected
value is 0xF, so now it should be possible to read decimal form ("15")
and hex form ("0xF").
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some devices (BCM4749, BCM5357, BCM53572) have internal switch that
requires initialization. We already have code for this, but because
of the typo in code it was never working. This resulted in network not
working for some routers and possibility of soft-bricking them.

Use correct bit for switch initialization and fix typo in the define.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use separate table for alias entries in the ehea module, otherwise the
probe() function will operate on the separate ports instead of the
lhea-"root" entry of the device-tree

Addresses https://bugzilla.novell.com/show_bug.cgi?id=435215

[ Thadeu notes that: "... this issue might happen with the generation of
  initrd, when the scripts check for /sys/class/net/eth0/device/modalias,
  which links to the port device at
  /sys/devices/ibmebus/23c00400.lhea/port0/" ]
Signed-off-by: NJeff Mahoney <jeffm@suse.com>
Signed-off-by: NOlaf Hering <ohering@suse.com>
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Acked-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When driver registration fails, we need to clean up the resources allocated
before. cxgb4 missed to destroy the workqueue allocated at the very beginning.

This patch destroies the workqueue when registration fails.
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

o At the time of firmware hang "adapter->need_fw_reset" variable gets
  set but after re-initialization of firmware OR at the time of VF
  re-initialization that variable was not getting cleared which
  was leading to failure in VF reset recovery.Fix it by clearing
  this variable before re-initializing VF
Signed-off-by: NManish Chopra <manish.chopra@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/toshiba/ps3_gelic_net.c

It's a NOOP since 2.6.35 and I will remove it one day ;)
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch proposes to remove the IRQF_DISABLED flag from
code in drivers/net/ethernet/smsc/

It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/pasemi/pasemi_mac.c

It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch proposes to remove the IRQF_DISABLED flag from
code in drivers/net/ethernet/natsemi/

It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/micrel/ks8851_mll.c

It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/lantiq_etop.c

It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>