Prior to commit fbd929f2dc
bonding: support QinQ for bond arp interval
the arp monitoring code allowed for proper detection of devices
stacked on top of vlans. Since the above commit, the
code can still detect a device stacked on top of single
vlan, but not a device stacked on top of Q-in-Q configuration.
The search will only set the inner vlan tag if the route
device is the vlan device. However, this is not always the
case, as it is possible to extend the stacked configuration.
With this patch it is possible to provision devices on
top Q-in-Q vlan configuration that should be used as
a source of ARP monitoring information.
For example:
ip link add link bond0 vlan10 type vlan proto 802.1q id 10
ip link add link vlan10 vlan100 type vlan proto 802.1q id 100
ip link add link vlan100 type macvlan
Note: This patch limites the number of stacked VLANs to 2,
just like before. The original, however had another issue
in that if we had more then 2 levels of VLANs, we would end
up generating incorrectly tagged traffic. This is no longer
possible.
Fixes: fbd929f2dc (bonding: support QinQ for bond arp interval)
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@redhat.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Ding Tianhong <dingtianhong@huawei.com>
CC: Patric McHardy <kaber@trash.net>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the NAPI budget was not all used, xenvif_poll() would call
napi_complete() /after/ enabling the interrupt. This resulted in a
race between the napi_complete() and the napi_schedule() in the
interrupt handler. The use of local_irq_save/restore() avoided by
race iff the handler is running on the same CPU but not if it was
running on a different CPU.
Fix this properly by calling napi_complete() before reenabling
interrupts (in the xenvif_napi_schedule_or_enable_irq() call).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John W. Linville says:
====================
pull request: wireless 2014-05-15
Please pull this batch of fixes for the 3.15 stream...
For the mac80211 bits, Johannes says:
"One fix is to get better VHT performance and the other fixes tracing
garbage or other potential issues with the interface name tracing."
And...
"This has a fix from Emmanuel for a problem I failed to fix - when
association is in progress then it needs to be cancelled while
suspending (I had fixed the same for authentication). Also included a
fix from myself for a userspace API problem that hit the iw tool and a
fix to the remain-on-channel framework."
For the iwlwifi bits, Emmanuel says:
"Alex fixes the scan by disabling the fragmented scan. David prevents
scan offload while associated, the firmware seems not to like it. I
fix a stupid bug I made in BT Coex, and fix a bad #ifdef clause in rate
scaling. Along with that there is a fix for a NULL pointer exception
that can happen if we load the driver and our ISR gets called because
the interrupt line is shared. The fix has been tested by the reporter."
And...
"We have here a fix from David Spinadel that makes a previous fix more
complete, and an off-by-one issue fixed by Eliad in the same area.
I fix the monitor that broke on the way."
Beyond that...
Daniel Kim's one-liner fixes a brcmfmac regression caused by a typo
in an earlier commit..
Rajkumar Manoharan fixes an ath9k oops reported by David Herrmann.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
With commit be9dad1f9f ("net: phy: suspend phydev when going
to HALTED"), an unused PHY device will be put in a low-power mode
using BMCR_PDOWN. Some Ethernet drivers might be calling phy_start()
and phy_stop() from ndo_open and ndo_close() respectively, while
calling phy_connect() and phy_disconnect() from probe and remove.
In such a case, the PHY will be powered down during the phy_stop()
call, but will fail to be powered up in phy_start().
This patch fixes this scenario.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds UPDATE_QP SRIOV wrapper support.
The mechanism is a general one, but currently only source MAC
index changes are allowed for VFs.
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I've missed to add a NULL entry to the bond_intmax_tbl when I introduced
it with the conversion of arp_interval so add it now.
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Fixes: 7bdb04ed0d ("bonding: convert arp_interval to use the new option API")
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Acked-by: Veaceslav Falico <vfalico@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The original series for reintroducing grant mapping for netback had a patch [1]
to handle receiving of packets from an another VIF. Grant copy on the receiving
side needs the grant ref of the page to set up the op.
The original patch assumed (wrongly) that the frags array haven't changed. In
the case reported by Sander, the sending guest sent a packet where the linear
buffer and the first frag were under PKT_PROT_LEN (=128) bytes.
xenvif_tx_submit() then pulled up the linear area to 128 bytes, and ditched the
first frag. The receiving side had an off-by-one problem when gathered the grant
refs.
This patch fixes that by checking whether the actual frag's page pointer is the
same as the page in the original frag list. It can handle any kind of changes on
the original frags array, like:
- removing granted frags from the array at any point
- adding local pages to the frags list anywhere
- reordering the frags
It's optimized to the most common case, when there is 1:1 relation between the
frags and the list, plus works optimal when frags are removed from the end or
the beginning.
[1]: 3e2234: xen-netback: Handle foreign mapped pages on the guest RX path
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: Guenter Roeck <linux@roeck-us.net>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David 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: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David 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: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
During remain on channel request, ANI worker thread is not stopped
before doing hw reset. This is causing kernel crash in
hw_per_calibration. This change ensures that ANI is stopped before
doing chip reset and it will be rescheduled later when the chip is
configured back to home channel and having valid bss.
Reported-by: David Herrmann <dh.herrmann@gmail.com>
Tested-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Kalesh AP <kalesh.purayil@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In my recent fix (76a691d0a: 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: Neil 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: David S. Miller <davem@davemloft.net>
Prevent sched scan while not idle (including during association or in AP
mode) instead of while associated only.
This fixes my previous commit which was incomplete:
commit bd5e4744a6
Author: David Spinadel <david.spinadel@intel.com>
Date: Thu Apr 24 13:15:29 2014 +0300
iwlwifi: mvm: do no sched scan while associated
Currently the FW doesn't support sched scan while associated,
Prevent it.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
tail should be equal to the last valid index, so
decrease it by one.
This error causes in "a gap" in some cases (as well as
some possible out-of-bound write), finally resulting in
ucode assertion.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
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: 1899c111a5 ("sfc: Fix IRQ cleanup in case of a probe failure")
Reported-by: Zenghui Shi <zshi@redhat.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Acked-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David 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: Peter Christensen <pch@ordbogen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix iovar 'bw_cap' set command failure introduced by
commit ff3b0fba6f25555ef59c55d138a467d0f81d82d7
Author: Arend van Spriel <arend@broadcom.com>
Date: Sat Mar 15 12:00:57 2014 +0100
brcmfmac: fallback to mimo_bw_cap for older firmwares
This resulted in disabling 20MHz operation in the firmware.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Signed-off-by: Daniel Kim <dekim@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Meelis Roos <mroos@linux.ee>
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: David 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: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: David 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: Johan Hovold <jhovold@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit f8d56d8f89 ("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: Johan Hovold <jhovold@gmail.com>
Signed-off-by: David 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: Johan Hovold <jhovold@gmail.com>
Signed-off-by: David 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: a82c7ce5bc ("net: cdc_ncm: map MBIM IPS SessionID to VLAN ID")
Cc: Greg Suarez <gsuarez@smithmicro.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David 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: Dariusz Marcinkiewicz <reksio@newterm.pl>
Signed-off-by: David 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: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David 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: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In case RFKILL is in KILL position, the NIC will issue an
interrupt straight away. This interrupt won't be sent
because it is masked in the hardware.
But if our interrupt service routine is called for another
reason (SHARED_IRQ), then we'll look at the interrupt cause
and service it. This can cause bad things if we are not
ready yet.
Explicitly clean the interrupt cause register to make sure
we won't service anything before we are ready to.
Cc: <stable@vger.kernel.org> [3.14]
Reported-and-tested-by: Alexander Monakov <amonakov@gmail.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
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: Neil Horman <nhorman@tuxdriver.com>
CC: Guo-Fu Tseng <cooldavid@cooldavid.org>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently the FW doesn't support sched scan while associated,
Prevent it.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
My bad - I forgot to update this when sending the patch
upstream.
Fixes: 87d5e4155c ("iwlwifi: mvm: rs: reinit rs if no tx for a long time")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The commit below introduced a bug in the validity bits in
init. Due to that, all the Coex mechanism stopped sending
kills to the BT side. Fix that.
Fixes: b9fae2d54c ("iwlwifi: mvm: BT Coex add support for Co-running block")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
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: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: David 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: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: David 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: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: David 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: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Just as commit "net: macb: DMA-unmap full rx-buffer"
(48330e08fa), 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: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates
This series contains updates to e1000e only.
David provides four fixes for e1000e, first is a workaround for a hardware
erratum on 82579 devices which experienced packet loss in gigabit and 100
speeds when interconnect between the PHY and MAC is exiting K1 power saving
state. Second expands the scope of a workaround to include i217 and i218
parts as well to address over aggressive transmit behavior when connecting
at 10Mbs half-duplex. Next is to resolve a reported link flap issue on
82579 parts which was root caused as an interoperability problem between
82579 and at least some Broadcom PHYs in the Energy Efficient Ethernet wake
mechanism. Lastly, restricts the workaround of putting the PHY into MDIO
slow mode to access the PHY id to relevant parts since this issue has been
fixed on the newer hardware.
====================
Signed-off-by: David 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: Dave Ertman <davidx.m.ertman@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff 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: Dave Ertman <davidx.m.ertman@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
In commit 772d05c51c "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: Dave Ertman <davidx.m.ertman@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff 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: Dave Ertman <davidx.m.ertman@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff 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: b912b2f ('net/mlx4_core: Warn if device doesn't have enough PCI bandwidth')
Signed-off-by: Eyal Perry <eyalpe@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
