Commit 1daa4303b4 ("net/mlx4_core: Deprecate error message at
ConnectX-2 cards startup to debug") did the deprecation only for port 1
of the card. Need to deprecate for port 2 as well.
Fixes: 1daa4303b4 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
mvneta_adjust_link() is a callback for of_phy_connect() and should
not be called directly. The result of calling it directly is as below:
Signed-off-by: David S. Miller <davem@davemloft.net>
xen-netfront limits transmitted skbs to be at most 44 segments in size. However,
GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
bytes each. This slight reduction in the size of packets means a slight loss in
efficiency.
Since c/s 9ecd1a75d, xen-netfront sets gso_max_size to
XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER,
where XEN_NETIF_MAX_TX_SIZE is 65535 bytes.
The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s
6c09fa09d) in determining when to split an skb into two is
sk->sk_gso_max_size - 1 - MAX_TCP_HEADER.
So the maximum permitted size of an skb is calculated to be
(XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER.
Intuitively, this looks like the wrong formula -- we don't need two TCP headers.
Instead, there is no need to deviate from the default gso_max_size of 65536 as
this already accommodates the size of the header.
Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments
of 1448 bytes each), as observed via tcpdump. This patch makes netfront send
skbs of up to 65160 bytes (45 segments of 1448 bytes each).
Similarly, the maximum allowable mtu does not need to subtract MAX_TCP_HEADER as
it relates to the size of the whole packet, including the header.
Fixes: 9ecd1a75d9 ("xen-netfront: reduce gso_max_size to account for max TCP header")
Signed-off-by: Jonathan Davies <jonathan.davies@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* fix a memory leak, we leaked memory each time the module
was loaded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJVHB3DAAoJEG4XJFUm622bLYkH+gMnmUgVD/MQLqhActOwGg/f
YM+gAmHyHW3arwLStkx8MfYrXf2a+Q3A/+Mj61s9fMKdxtH143JwL3Gu/y76S9vH
7bbhoiajwCg83IhrN+lIOpAHjHo/bxodXmjojnZFHTQ0MBT6ftXmLUZ7HBDwaL6A
ct79Yh/k2lhaL8Vk242dIXWjoVmG9HtazVnK7jYB4fX+dIuqZ/53Z4acqTLeKUez
UMRs/R0MYMtjHXhpnNHegiZ/umf4FfhrtVZ4yW2C3PqPR7wor/XkegnbwEXH3TNq
zGACPN5YdFjDPacPslBsMT9FkOQPOwvz9Djzn7GEW6fv7AvGTC0lIXQ2E2I2phQ=
=E1Gh
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-for-davem-2015-04-01' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
iwlwifi:
* fix a memory leak, we leaked memory each time the module
was loaded.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add new Common Code routines to retrieve Firmware Device Log
parameters from PCIE_FW_PF[7]. The firmware initializes its Device Log very
early on and stores the parameters for its location/size in that register.
Using the parameters from the register allows us to access the Firmware
Device Log even when the firmware crashes very early on or we're not
attached to the firmware
Based on original work by Casey Leedom <leedom@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Adds new macro and few macro changes for fw version 1.13.32.0 also
changes version string in driver to match 1.13.32.0
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When IOMM-vtd is active, once main kernel crashes unfinished DMAE transactions
will be blocked, putting the HW in an error state which will cause further
transactions to timeout.
Current employed logic uses wrong macros, causing the first function to be the
only function that cleanups that error state during its probe/load.
This patch allows all the functions to successfully re-load in kdump kernel.
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>
When running in a kdump kernel, it's very likely that due to sync. loss with
management firmware the first PCI function to probe and reach the previous
unload flow would decide it can reset the chip and continue onward. While doing
so, it will only close its own Rx port.
On a 4-port device where 2nd port on engine is a 1g-port, the 2nd port would
allow ingress traffic after the chip is reset [assuming it was active on the
first kernel]. This would later cause a HW attention.
This changes driver flow to close both ports' 1g capabilities during the
previous driver unload flow prior to the chip reset.
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>
This device is sold as 'Lenovo Tinkpad USB 3.0 Ethernet 4X90E51405'.
Chipset is RTL8153 and works with r8152.
Signed-off-by: Christian Hesse <mail@eworm.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Before commit 3900f29021 ("bonding: slight
optimizztion for bond_slave_override()") the override logic was to send packets
with non-zero queue_id through the slave with corresponding queue_id, under two
conditions only - if the slave can transmit and it's up.
The above mentioned commit changed this logic by introducing an additional
condition - whether the bond is active (indirectly, using the slave_can_tx and
later - bond_is_active_slave), that prevents the user from implementing more
complex policies according to the Documentation/networking/bonding.txt.
Signed-off-by: Anton Nayshtut <anton@swortex.com>
Signed-off-by: Alexey Bogoslavsky <alexey@swortex.com>
Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When an ipvlan interface is down, its addresses are not on the hash list.
Fix checks for existence of addresses not to depend on the hash list, walk
through all interface addresses instead.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Adding and removing to the 'ipvlans' list is already done using _rcu list
operations.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When ipvlan interface with IP addresses attached is brought down and then
deleted, the assigned addresses are deleted twice from the address hash
list, first on the interface down and second on the link deletion.
Similarly, when an address is added while the interface is down, it is added
second time once the interface is brought up.
When the interface is down, the addresses should be kept off the hash list
for performance reasons. Ensure this is true, which also fixes the double add
problem. To fix the double free, check whether the address is hashed before
removing it.
Reported-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
was loaded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVGOp+AAoJEC0Llv5uNjIBtnUQALBt98Uf5dWzzb1Kzw0EMB6k
FMR5sY85BZz9EwvTIm5ZE0ZyLjZF2p8qvxw1mc2OWmaS5HIGOCKWXRRn9LqYmD4P
kUcYotBpbxvTQI7rNa7ENjo2yXwEC7MPWRJcgjQdUD0NxdIc00SPe/Y5upyOreDn
NmToXwl3f4SAoe4e7/QtjbG3tj2hlsFmkfDjW0bdlJBfcl+ug69aHEFOlEv/LYfS
WLlWdBcFWBUjnn90AFtw9vm1zoqPCw9ogKp8RPjuTdKcOEdt9t5jTQk4BJ5v4Zoz
KE1E1LB97cc7RUxeSBzlC023Getd2nypVQJdFw18PD23vJVvHVQxqqWS8GTVmKZ5
ybnuSJLLUlZ7s2QjI6vY6y42OTP4q4g/q6dpm1Hcl+WUl7mKdDFmnOnzSnhV6E1O
yqj3inetRwYXHRCc4hCLXQz1CH5c4/qwJfXvonHHz3Xp/L214u1KVoRyPXlYQo05
KdjjdAOIdMxApT2Qv+lOGd8U9KtPT8SJcbkM17rwoabD9mXYg5/3g1Db3e0uk3wj
zmFpAbSSsUb0YNGSNbWk1Ya6kvuenXQdgQSphtK+zvlJ6A3FAnwAxlYOFaKvXQ/i
0wrSsRbEDySIAcwwnxR2tCc4P0O4pl1OCJ2SmqBIxmiUJ6nzNtUptOd2H8FyCAF1
ocv0i4LEKEPuRizSc0+Y
=wIgU
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-for-kalle-2015-03-30' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
* fix a memory leak: we leaked memory each time the module
was loaded.
The FEC modules used on i.MX28 and newer have a register to tune the MDIO
output hold time that should be at least 10 ns. Up to now this value was not
explicitly set and so resulted in less hold time if the fec clock was
faster than 100 MHz.
This was noticed on an i.MX28 machine that uses an input clock of ~150
Mhz which resulted in unreliable communication with a Marvell switch.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes sparse warnings introduced in commit e85c9a7abf ("cxgb4/cxgb4vf: Add
code to calculate T5 BAR2 Offsets for SGE Queue Registers") and
df64e4d38c ("cxgb4/cxgb4vf: Use new interfaces to calculate BAR2 SGE Queue
Register addresses") and few old ones
sparse warnings:
>> drivers/net/ethernet/chelsio/cxgb4vf/sge.c:1006:48: sparse: cast removes
>> address space of expression
>> drivers/net/ethernet/chelsio/cxgb4vf/sge.c:1006:48: sparse: incorrect type in
>> initializer (different address space)
>> drivers/net/ethernet/chelsio/cxgb4vf/sge.c:1020:40: sparse: incorrect type in
>> argument 1 (different base types)
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Disable interrupts and quiesce rx before unregistering net device to avoid crash
while unloading driver when traffic is flowing through.
Based on original work by Shameem Khalid <shameem@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
QIDs (egress/ingress) from firmware in FW_*_CMD.alloc command
can be anywhere in the range from EQ(IQFLINT)_START to EQ(IQFLINT)_END.
For eg, in the first load eqid can be from 100 to 300.
In the next load it can be from 301 to 500 (assume eq_start is 100 and eq_end is
1000).
The driver was assuming them to always start from EQ(IQFLINT)_START till
MAX_EGRQ(INGQ). This was causing stack overflow and subsequent crash.
Fixed it by dynamically allocating memory (of qsize (x_END - x_START + 1)) for
these structures.
Based on original work by Santosh Rastapur <santosh@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
cdc_ncm disagrees with usbnet about how much framing overhead should
be counted in the tx_bytes statistics, and tries 'fix' this by
decrementing tx_bytes on the transmit path. But statistics must never
be decremented except due to roll-over; this will thoroughly confuse
user-space. Also, tx_bytes is only incremented by usbnet in the
completion path.
Fix this by requiring drivers that set FLAG_MULTI_FRAME to set a
tx_bytes delta along with the tx_packets count.
Fixes: beeecd42c3 ("net: cdc_ncm/cdc_mbim: adding NCM protocol statistics")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Currently the usbnet core does not update the tx_packets statistic for
drivers with FLAG_MULTI_PACKET and there is no hook in the TX
completion path where they could do this.
cdc_ncm and dependent drivers are bumping tx_packets stat on the
transmit path while asix and sr9800 aren't updating it at all.
Add a packet count in struct skb_data so these drivers can fill it
in, initialise it to 1 for other drivers, and add the packet count
to the tx_packets statistic on completion.
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Tested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes below warning by dynamically allocating memory
All warnings:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c: In function
'cctrl_tbl_show':
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c:689:1: warning: the
>> frame
>> size of 1028 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ucc_geth was indicating link up after a port is administratively enabled even
when nothing is plugged in. This causes user-space tools to see a spurious link
up the first time after boot.
Signed-off-by: Cliff Clark <cliff_clark@selinc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We occasionally see in procedure mlx4_GEN_EQE that the driver tries
to grab an uninitialized mutex.
This can occur in only one of two ways:
1. We are trying to generate an async event on an uninitialized slave.
2. We are trying to generate an async event on an illegal slave number
( < 0 or > persist->num_vfs) or an inactive slave.
To deal with #1: move the mutex initialization from specific slave init
sequence in procedure mlx_master_do_cmd to mlx4_multi_func_init() (so that
the mutex is always initialized for all slaves).
To deal with #2: check in procedure mlx4_GEN_EQE that the slave number
provided is in the proper range and that the slave is active.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Netdevice registration should be performed a the end of the driver
initialization flow. If we don't do that, after calling register_netdevice,
device callbacks may be issued by higher layers of the stack before
final configuration of the device is done.
For example (VXLAN configuration race), mlx4_SET_PORT_VXLAN was issued
after the register_netdev command. System network scripts may configure
the interface (UP) right after the registration, which also attach
unicast VXLAN steering rule, before mlx4_SET_PORT_VXLAN was called,
causing the firmware to fail the rule attachment.
Fixes: 837052d0cc ("net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling")
Signed-off-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* avoid panic with lots of IBSS stations
* Fix dvm's behavior after suspend resume
* Allow to keep connection after CSA failure
* Remove a noisy by harmless WARN_ON
* New device IDs
rtlwifi:
* fix IOMMU mapping leak in AP mode
brcmfmac:
* disable MBSS feature for BCM43362 to get AP mode working again
ath9k:
* disable Transmit Power Control (TPC) again due to regressions
* fix beaconing issue with AP+STA setup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJVEQL4AAoJEG4XJFUm622boBwH/R61GyJvh2OieOfv35fv84N0
h4abht9N4gfogwJcF9AT0rPddo+ueYhD1pSYOS6pyM1d2OjhJq73vEVetCUKpX46
TpFw2hZOOZKj97flYyi7dPXQxGcUYLAzfqZ5Dn45czGuwMk/v3v+Ni3lzHUfmKvm
jrjHWKm2+WiJGRO7xJEmUAZoXTLEZdQtxLC3oViIeldhjsS5XQfx6K7mlp6L/7lC
zvHBSkLFEjjn6fMa17r9GgCsN7HkHuK8/tbXfbDyVw37bWte/6ZJv+1IUn6HPUKJ
mCRl5Sbs/+Rg0sqWaf1ygjGCghx9I7U4R9EvaZxpSnn+KjeeL4ibds2Lq+DoAaM=
=fEF3
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-for-davem-2015-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
iwlwifi:
* avoid panic with lots of IBSS stations
* Fix dvm's behavior after suspend resume
* Allow to keep connection after CSA failure
* Remove a noisy by harmless WARN_ON
* New device IDs
rtlwifi:
* fix IOMMU mapping leak in AP mode
brcmfmac:
* disable MBSS feature for BCM43362 to get AP mode working again
ath9k:
* disable Transmit Power Control (TPC) again due to regressions
* fix beaconing issue with AP+STA setup
Signed-off-by: David S. Miller <davem@davemloft.net>
Master change notifications may occur other than when joining or
leaving a bridge, for example when being added to or removed from
a bond or Open vSwitch.
Previously in those cases rocker_port_bridge_leave() was called
which results in a null-pointer dereference as rocker_port->bridge_dev
is NULL because there is no bridge device.
This patch makes provision for doing nothing in such cases.
Fixes: 6c70794500 ("rocker: implement L2 bridge offloading")
Acked-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In this routine, kzalloc allocates a memory block. This allocation is
freed in the error paths, but not in the normal exit, thus the allocation
is leaked.
The kmemleak facility was used to find the leak.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Intel Linux Wireless <ilw@linux.intel.com>
Statistics' state-machine in bnx2x driver must be synced with various driver
flows, but its current locking scheme manages to be wasteful [using 2 locks +
additional local variable] and prone to race-conditions at the same time,
as the state-machine and 'action' are being accessed under different locks.
In addition, current 'safe exec' isn't in fact safe, since the only guarantee
it gives is that DMA transactions are over, but ramrods might still be running.
This patch cleans up said logic, leaving us with a single lock for the entire
flow and removing the possible races.
Changes from v2:
- Switched into mutex locking from semaphore locking.
- Release locks on error flows.
Changes from v1:
Failure to acquire lock fails flow instead of printing a warning and
allowing access to the critical section.
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>
Return EPROBE_DEFER if Regulator returns EPROBE_DEFER
If the Flexcan driver is built into kernel and a regulator is used to
enable the CAN transceiver, the Flexcan driver may not use the regulator.
When initializing the Flexcan device with a regulator defined in the device
tree, but not initialized, the regulator subsystem returns EPROBE_DEFER, hence
the Flexcan init fails.
The solution for this is to return EPROBE_DEFER if regulator is not initialized
and wait until the regulator is initialized.
Signed-off-by: Andreas Werner <kernel@andy89.org>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Making sure that the bus-off state gets passed to can_change_state().
Signed-off-by: Andri Yngvason <andri.yngvason@marel.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The PCAN USB (pro) FD adapters with firmware versions > 2.x support the
switching between ISO (default) and non-ISO conform bitstreams on the CAN bus.
The setting for the 2.x firmware adapters can be modified with the 'ip' tool
from the iproute2 package (option: fd-non-iso [on|off]).
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The PUCAN_CMD_RX_FRAME_(ENABLE|DISABLE) command has extended its purpose
and was therefore renamed to PUCAN_CMD_SET_(EN|DIS)_OPTION.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
smatch detected the following issue:
drivers/net/can/usb/gs_usb.c:904 gs_usb_probe() error:
potential null dereference 'dev'. (kzalloc returns null)
Add a check for null return from kzalloc and return -ENOMEM
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
USB endpoint's wMaxPacketSize field is an le16 entity. Use
appropriate le16_to_cpu macros to maintain endian independence.
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Current driver code arbitrarily assumes a max outstanding tx
value of 16 parallel transmissions. Meanwhile, the device
firmware provides its actual maximum inside its reply to the
CMD_GET_SOFTWARE_INFO message.
Under heavy tx traffic, if the interleaved transmissions count
increases above the limit reported by firmware, the firmware
breaks up badly, reports a massive list of internal errors, and
the candump traces hardly matches the actual frames sent and
received.
On the other hand, in certain models, the firmware can support
up to 48 tx URBs instead of just 16, increasing the driver
throughput by two-fold and reducing the possibility of -ENOBUFs.
Thus dynamically set the driver's max tx URBs value according
to firmware replies.
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Transmission of an AP beacon does not call the TX interrupt service routine,
which usually does the cleanup. Instead, cleanup is handled in a tasklet
completion routine. Unfortunately, this routine has a serious bug in that it does
not release the DMA mapping before it frees the skb, thus one IOMMU mapping is
leaked for each beacon. The test system failed with no free IOMMU mapping slots
approximately one hour after hostapd was used to start an AP.
This issue was reported and tested at https://github.com/lwfinger/rtlwifi_new/issues/30.
Reported-and-tested-by: Kevin Mullican <kevin@mullican.com>
Cc: Kevin Mullican <kevin@mullican.com>
Signed-off-by: Shao Fu <shaofu@realtek.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [3.18+]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When the device is powered up, some (older) firmware versions fail to work
properly if we send commands before the boot is complete (everything is OK
when the device is hot-plugged). The firmware indicates its ready status by
putting the link up.
Newer firmwares delay the first command so they don't suffer from this problem.
They also report the link being always up.
Wait for firmware to become ready (link up) before sending any commands and/or
data.
This also allows lowering CMD_TIMEOUT value to a reasonable time.
Tested with 4.1.0.9 (old) and 4.1.0.30 (new) firmware versions.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The BCM43362 firmware falsely reports it is capable of providing
MBSS. As a result AP mode no longer works for this device. Therefor
disable MBSS in the driver for this chipset.
Cc: stable@vger.kernel.org # 3.19.y
Reported-by: Jorg Krause <jkrause@posteo.de>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When an EEH error occurs, the device/slot is disconnected. This condition
is more reliably detected (i.e., returns all ones) with an MMIO read rather
than a config read -- especially on power platforms.
Hence, this patch fixes EEH error detection by replacing config reads with
MMIO reads for reading the error registers. The error registers in
Skyhawk-R/BE2/BE3 are accessible both via the config space and the
PCICFG (BAR0) memory space.
Reported-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Suresh Reddy <Suresh.Reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Issuing this cmd for more than 8 EQs does not have the intended effect
even on BEx and Skyhawk-R.
This patch fixes this by issuing this cmd for upto 8 EQs at a time.
Signed-off-by: Suresh Reddy <Suresh.Reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, a PF does not restrict its VF interface from enabling vlan
promiscuous mode. This breaks vlan isolation when a vlan
(transparent tagging) is configured on a VF.
This patch fixes this problem by disabling the vlan promisc capability
for VFs.
Reported-by: Yoann Juet <veilletechno-irts@univ-nantes.fr>
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On a MIPS Malta board, tons of fifo underflow errors have been observed
when using u-boot as bootloader instead of YAMON. The reason for that
is that YAMON used to set the pcnet device to SRAM mode but u-boot does
not. As a result, the default Tx threshold (64 bytes) is now too small to
keep the fifo relatively used and it can result to Tx fifo underflow errors.
As a result of which, it's best to setup the SRAM on supported controllers
so we can always use the NOUFLO bit.
Cc: <netdev@vger.kernel.org>
Cc: <stable@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Cc: Don Fry <pcnet32@frontier.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The firmware frequently manages to trigger this, and there's
no known driver workaround, so stop warning.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When the driver callback returns that it's out of space for new
stations, the mac80211 IBSS code still keeps the station so it
doesn't try to add it over and over again.
Since the rate scaling algorithm is separate in mac80211, it also
invokes the rate scaling algorithm for such stations. It doesn't
know that our rate scaling algorithm is tightly integrated with
the MVM code and relies on those data structures, and it cannot
as the abstraction doesn't allow for it.
This leads to crashes when the rate scaling algorithm tries to
use uninitialized data, notably the mvmsta->vif pointer.
Protect against this in the rate scaling algorithm. We cannot get
good rates with such peers anyway since the firmware cannot do
anything with them.
This should fix https://bugzilla.kernel.org/show_bug.cgi?id=93461
CC: <stable@vger.kernel.org>
Reported-by: Richard Taylor <rjt-kernel@thegrindstone.me.uk>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The assumption before this patch was that we don't need to
run again the INIT firmware after the system booted. The
INIT firmware runs calibrations which impact the physical
layer's behavior.
Users reported that it may be helpful to run these
calibrations again every time the interface is brought up.
The penatly is minimal, since the calibrations run fast.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=94341
CC: <stable@vger.kernel.org>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This reverts commit 11ad714b98 because
it breaks cx82310_eth.
The custom USB_DEVICE_CLASS macro matches
bDeviceClass, bDeviceSubClass and bDeviceProtocol
but the common USB_DEVICE_AND_INTERFACE_INFO matches
bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol instead, which are
not specified.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Port statistics bitmap will now be initialized at port init. Even before
starting the port, statistics are visible to the user and must be properly masked.
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jack Morgenstein