Commit dff173de ("bnx2x: Fix statistics locking scheme") changed the
bnx2x locking around statistics state into using a mutex - but the lock
is being accessed via a timer which is forbidden.

[If compiled with CONFIG_DEBUG_MUTEXES, logs show a warning about
accessing the mutex in interrupt context]

This moves the implementation into using a semaphore [with size '1']
instead.
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>

When Rx packet data must be dropped, all the buffers
associated with that Rx packet must be freed. Extend
and rename efx_free_rx_buffer() to efx_free_rx_buffers()
and loop through all the fragments.
By doing so this patch fixes a possible memory leak.
Signed-off-by: NShradha Shah <sshah@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Bug in the driver initialization causes soft-lockup if firmware
initialization timeout is reached. Polling function bfa_ioc_poll_fwinit()
incorrectly calls bfa_nw_iocpf_timeout() when the timeout is reached.
The problem is that bfa_nw_iocpf_timeout() calls again
bfa_ioc_poll_fwinit()... etc. The bfa_ioc_poll_fwinit() should directly
send timeout event for iocpf and the same should be done if firmware
download into HW fails.

Cc: Rasesh Mody <rasesh.mody@qlogic.com>
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Driver starts iocpf timer prior bnad_ioceth_enable() call and this is
unreasonable. This piece of code probably originates from Brocade/Qlogic
out-of-box driver during initial import into upstream. This driver uses
only one timer and queue to implement multiple timers and this timer is
started at this place. The upstream driver uses multiple timers instead
of this.

Cc: Rasesh Mody <rasesh.mody@qlogic.com>
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Firmware required by bna is stored in appropriate files as sequence
of LE32 integers. After loading by request_firmware() they need to be
byte-swapped on big-endian arches. Without this conversion the NIC
is unusable on big-endian machines.

Cc: Rasesh Mody <rasesh.mody@qlogic.com>
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

da91309e (cpumask: Utility function to set n'th cpu...) created a
genuinely weird function.  I never saw it before, it went through DaveM.
(He only does this to make us other maintainers feel better about our own
mistakes.)

cpumask_set_cpu_local_first's purpose is say "I need to spread things
across N online cpus, choose the ones on this numa node first"; you call
it in a loop.

It can fail.  One of the two callers ignores this, the other aborts and
fails the device open.

It can fail in two ways: allocating the off-stack cpumask, or through a
convoluted codepath which AFAICT can only occur if cpu_online_mask
changes.  Which shouldn't happen, because if cpu_online_mask can change
while you call this, it could return a now-offline cpu anyway.

It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
drawn to my attention by Geert, who said this causes a warning on Sparc.
It sets a single bit in a cpumask instead of returning a cpu number,
because that's what the callers want.

It could be made more efficient by passing the previous cpu rather than
an index, but that would be more invasive to the callers.

Fixes: da91309e
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (then rebased)
Tested-by: NAmir Vadai <amirv@mellanox.com>
Acked-by: NAmir Vadai <amirv@mellanox.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>

The test in mlx4_load_one() to remove MLX4_FLAG_MSI_X expects mlx4_NOP() to
fail with -EBUSY. It is also necessary to avoid the reset since the device
is not fully reinitialized before calling mlx4_start_hca() a second time.

Note that this will also affect mlx4_test_interrupts(), the only other user
of MLX4_CMD_NOP.

Fixes: f5aef5aa ("net/mlx4_core: Activate reset flow upon fatal command cases")
Signed-off-by: NBenjamin Poirier <bpoirier@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If read() syscall requests unexpected number of bytes from "dimm" binary
attribute file, return EINVAL instead of EPERM.

At the same time pin down sysfs file size to the fixed
sizeof(struct netxen_dimm_cfg), which allows to exploit some missing
sanity checks from kernfs (file boundary checks vs offset etc.)
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

stmmac DebugFS entries are currently global to the driver. As a result,
having more than one stmmac device in the system creates the following
error:
* ERROR stmmaceth, debugfs create directory failed
* stmmac_hw_setup: failed debugFS registration

This also results in being able to access the debugfs information for
the first registered device only.

This patch changes the debugfs structure to have one sub-directory per
net-device. Files under "/sys/kernel/debug/stmmaceth" will now show-up
under /sys/kernel/debug/stmmaceth/ethN/.
Signed-off-by: NMathieu Olivari <mathieu@codeaurora.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix in send of emac regs dump to ethtool which
causing in wrong data interpretation on ethtool
layer for MII and EMAC.
Signed-off-by: NIvan Mikhaylov <ivan@ru.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According to the Zynq TRM, gigabit half duplex is not supported.  Add a
new cap and compatible string so Zynq can avoid advertising that mode.
Signed-off-by: NNathan Sullivan <nathan.sullivan@ni.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Once we get a neighbour through looking up arp cache or creating a
new one in rocker_port_ipv4_resolve(), the neighbour's refcount is
already taken. But as we don't put the refcount again after it's
used, this makes the neighbour entry leaked.
Suggested-by: NEric Dumazet <edumazet@google.com>
Acked-by: NJiri Pirko <jiri@resnulli.us>
Acked-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NYing Xue <ying.xue@windriver.com>
Acked-by: NJiri Pirko <jiri@resnulli.us>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Describe the handler for RXUBR better with a new comment.
Signed-off-by: NNathan Sullivan <nathan.sullivan@ni.com>
Reviewied-by: NJosh Cartwright <joshc@ni.com>
Reviewied-by: NBen Shelton <ben.shelton@ni.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

With a cross-compiler based on gcc-4.9, I see warnings like the following:

  drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_SW2HW_CQ_wrapper':
  drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3048:10: error: 'cq' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    cq->mtt = mtt;

I think the warning is spurious because we only use cq when
cq_res_start_move_to() returns zero, and it always initializes *cq in that
case.  The srq case is similar.  But maybe gcc isn't smart enough to figure
that out.

Initialize cq and srq explicitly to avoid the warnings.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit e2c65448 moved pm_qos_req to e1000_adapter. Add the header file
that defines the struct.
Signed-off-by: NDavid Ahern <dsahern@gmail.com>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

DMA allocates skb->len instead of headlen
which is used for DMA.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Registering the netdev before setting the priv data is unsafe.
So fix this possible race by setting the priv data first.
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Cc: <stable@vger.kernel.org> # v3.18+
Fixes: 291ab06e (net: qualcomm: new Ethernet over SPI driver for QCA7000)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 12a8541d "bnx2x: Delay during kdump load" added a 5 seconds
delay to bnx2x's probe function in the kdump case to let the firmware
realize the old driver is gone.

The problem with the delay is that it is per-device, so if you have
several bnx2x NICs in NPAR mode, the delays can accumulate to minutes.

Fix it by adjusting the delay so that we do not wait more than
necessary, i.e. no more delaying after 5 seconds of kernel boot time.
Signed-off-by: NMichal Schmidt <mschmidt@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch should have been part of the previous patch having the
same summary. See  http://marc.info/?l=linux-kernel&m=143039470103795&w=2
Unfortunately, I didn't check to see where else this lock was used before
submitting that patch. This should take care of it for netxen_nic, as I
did a thorough search this time.

To recap from the original patch; although testing this driver with
DEBUG_LOCKDEP and DEBUG_SPINLOCK enabled did not produce any traces,
it would be more prudent in the case of tx_clean_lock to use _bh
versions of spin_[un]lock, since this lock is manipulated in both
the process and softirq contexts.

This patch was tested for functionality and regressions with netperf
and DEBUG_LOCKDEP and DEBUG_SPINLOCK enabled.
Signed-off-by: NTony Camuso <tcamuso@redhat.com>
Acked-By: NNeil Horman <nhorman@tuxdriver.com>
Acked-By: NManish Chopra <manish.chopra@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The xgene_enet driver is only useful on X-Gene SoC.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Iyappan Subramanian <isubramanian@apm.com>
Cc: Keyur Chudgar <kchudgar@apm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The amd-xgbe driver currently only works with the Seattle SoC, which
is ARM64 architecture, so there is no point in building this driver on
other architectures except for build testing purpose. The dependency
list can be updated later if the driver ever supports other
architectures.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The same hardware issue the at91 must work around applies to at least the
Zynq ethernet, and possibly more devices.  The driver also needs to handle
the RXUBR interrupt since it turns it on with MACB_RX_INT_FLAGS anyway.
Signed-off-by: NNathan Sullivan <nathan.sullivan@ni.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

adapter->tx_ring is set to NULL where rx_ring should be.

Fixes: 5536d210 ("igb: Combine q_vector and ring allocation into a single function")
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When changing the number of rings by ethtool -L, q_vectors are reused,
which causes oops because of uninitialized pointers.

- When an rx is reused as a tx, q_vector->rx.ring is not set to NULL, which
  misleads igb_poll() to determine that it has an rx ring although it
  actually points to the tx ring.
- When a tx is reused as an rx, q_vector->rx.ring->skb
  (q_vector->ring[0].skb) has a value that was used as tx_stats before.

Fix these problems by zeroing it out on reuseing it.

Fixes: 02ef6e1d ("igb: Fix queue allocation method to accommodate changing during runtime")
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

The Firmware uses dynamic EQs allocation based on number of VFs and
max EQs that can be allocated. As a result, VF can have EQ numbers
that are larger than 256.

According to the firmware spec, the max value is limited to be 1024
(10 bits), adapt the relevant code accordingly. This bug was impossible
to hit prior to commit 7ae0e400 ("net/mlx4_core: Flexible (asymmetric)
allocation of EQs and MSI-X vectors for PF/VFs") which actually enables
large number of EQs for VFs.
Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This caused the en_stats_adder helper to accumulate a field which is
not related to the counter, fix that.

Fixes: a3333b35 ('net/mlx4_en: Moderate ethtool callback to show [..]')
Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Submit 909d9faa ("bnx2x: Prevent inner-reload while VFs exist")
contained a bug - MTU change was not prevented by it; Instead, it
`randomally' prevented bnx2x_resume() from running [harmless yet wrong].

This moves the check to its correct spot.
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 8d7d9cca.

Now that the necessary infrastructure is really all there
in the tree, we can put this change back in.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When smsc911x uses GPIO as the interrupt controller, and if both are
loaded as modules, we get following error:

"smsc911x: Could not allocate irq resource"

This issue is because of smsc911x using platform_get_resource to get
device tree based irq resource.

commit "9ec36caf (of/irq: do irq resolution in platform_get_irq)" and
commit "7085a7 (drivers: platform: parse IRQ flags from resources)" add
support in platform_get_irq to resolve irq and irq_flags respectively
for both modern device tree and legacy static platform data platforms.

Modify smsc911x driver to use platform_get_irq to pick up irq resource
correctly and use irq_get_trigger_type to get the IRQ trigger flags.
Signed-off-by: NKamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

With netpoll making use of the transmit function it is possible for the
ndo_start_xmit function to be called with irqs disabled.  As such we need
to use dev_kfree_skb_any in the Tx cleanup path for frames that are
dropped.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The function r8169_csum_workaround is called in the ndo_start_xmit path of
the r8169 driver.  As such it should not be using dev_kfree_skb as it is
not irq safe, so instead we should be using dev_kfree_skb_any for freeing
in the dropped path, and dev_consume_skb_any for any frames that were
transmitted.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The netpoll path will call napi->poll with a budget of 0 in order to clean
the Tx rings only.  This change updates the fm10k driver so that it will
correctly support that instead of cleaning 1 Rx frame if a budget of 0 is
received.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This file is built off of a tristate Kconfig option and also contains
modular function calls so it should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.

Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: netdev@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

RGMII-ID uses an internal delay within the transmitter or receiver. This
feature is phy specific. The rest of the communication is normal RGMII.

So the fec driver has to check for all RGMII modes, not only
'PHY_INTERFACE_MODE_RGMII'.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When system is out of memory, refilling of RX buffers fails while
the driver continue to pass the received packets to the kernel stack.
At some point, when all RX buffers deplete, driver may fall into a
sleep, and not recover when memory for new RX buffers is once again
availible. This is because hardware does not have valid descriptors,
so no interrupt will be generated for the driver to return to work
in napi context. Fix it by schedule the napi poll function from
stats_task delayed workqueue, as long as the allocations fail.
Signed-off-by: NIdo Shamay <idos@mellanox.com>
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While testing this driver with DEBUG_LOCKDEP and DEBUG_SPINLOCK
enabled did not produce any traces, it would be more prudent in the
case of tx_clean_lock to use spin_[un]lock_bh, since this lock is
manipulated in both the process and softirq contexts.

This patch was tested for functionality and regressions with netperf
and DEBUG_LOCKDEP and DEBUG_SPINLOCK enabled.
Signed-off-by: NTony Camuso <tcamuso@redhat.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Addresses the following kernel logs seen during boot:

Kernel unaligned access at TPC[100ee150] mlx4_QUERY_HCA+0x80/0x248 [mlx4_core]
Kernel unaligned access at TPC[100f071c] mlx4_QUERY_ADAPTER+0x100/0x12c [mlx4_core]
Kernel unaligned access at TPC[100f071c] mlx4_QUERY_ADAPTER+0x100/0x12c [mlx4_core]
Kernel unaligned access at TPC[100f071c] mlx4_QUERY_ADAPTER+0x100/0x12c [mlx4_core]
Kernel unaligned access at TPC[100f071c] mlx4_QUERY_ADAPTER+0x100/0x12c [mlx4_core]
Signed-off-by: NDavid Ahern <david.ahern@oracle.com>
Acked-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NBenjamin Poirier <bpoirier@suse.de>
Fixes: 9e311e77 ("net/mlx4_en: Use affinity hint")
Acked-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 6559a7e8 ("cxgb4: Cleanup macros so they follow the same
style and look consistent") introduced a regression where reading MC1
memory in adapters where MC0 isn't present or MC0 size is not equal to MC1
size caused the adapter to crash due to incorrect computation of memoffset.
Fix is to read the size of MC0 instead of MC1 for offset calculation
Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In a kdump environment interfaces might be re-loaded without a proper
unload sequence in the previous running kernel.
bnx2x management FW and driver maintains a `pulse' that notifies the FW
that the driver is still up and running.

Driver load on the kdump kernel should be performed only after the pulse
has been out-of-sync long enough for the management FW to identify that
the driver has crashed, on which point it will perform some necessary
cleanup of the HW.

In today's distros kdump loading is quite fast, sometimes too fast for our
FW to get out-of-sync. This patch delays the bnx2x's probe during kdump
to allow a proper re-load on the kdump kernel.
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>