The current code writes the PME enabled bit in PCI config space which is
wrong.  This was needed for pre-release hardware, and was not removed from
the driver.  Also, we need to clear the WUS (wake up status) after we
resume.  Otherwise we can't wake for the same event again since it's still
asserted in the hardware.  Plus, the multicast lists were being written
improperly, causing multicast WoL to fail.
Signed-off-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Stephen Hemminger <shemminger@vyatta.com>

The veth driver will oops if sysfs hooks are open while module is removed.

The net device destructor can not point to code in a module; basically
there are only two possible safe values: NULL - no destructor, or
free_netdev - free on last use
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the tx_timeout() to properly handle the clean up of the
tx ring. It also sets the tx put pointer back to the correct position to
be in sync with HW.
Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If we failed to allocate new fragments for receive buffer,
the packet should be dropped and packets should be reused.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In case of mlx4_en_activate_cq() failure, the cleanup
code would go to rx_err and try to disable unactivated rings.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If using the UCC on a MPC8360 in RMII mode, don;t set
UCC_GETH_UPSMR_RPM bit in the upsmr register.
Signed-off-by: NHeiko Schocher <hs@denx.de>
Acked-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While ifconfig eth0 up kernel calls open() of 8139 driver(8139too.c).
In rtl8139_hw_start() of rtl8139_open(), 8139 driver enable RX before
setting up the DMA buffer address. In this interval where RX was
enabled and DMA buffer address is not yet set up, any incoming
broadcast packet would be send to a strange physical address:
0x003e8800 which is the default value of DMA buffer address.
Unfortunately, this address is used by Linux kernel. So kernel panics.
This patch fix it by setting up DMA buffer address before RX enabled
and everything is fine even under broadcast packets attack.
Signed-off-by: NJonathan Lin <jon.lin@vatics.com>
Signed-off-by: NAmos Kong <jianjun@zeuux.org>
Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A few issues wrt DMA were uncovered when using the driver with swiotlb.
- driver should not use memory after it has been mapped
- iwl3945's RX queue management cannot use all of iwlagn because
  the size of the RX buffer is different. Revert back to using
  iwl3945 specific routines that map/unmap memory.
- no need to "dma_syn_single_range_for_cpu" followed by pci_unmap_single,
  we can just call pci_unmap_single initially
- only map the memory area that will be used by device. this is especially
  relevant to the mapping of iwl_cmd. we should not map the entire
  structure because the meta data at the beginning of structure contains
  the address to be used later for unmapping. If the address to be used for
  unmapping is stored in mapped data it creates a problem.
- ensure that _if_ memory needs to be modified after it is mapped that we
  call _sync_single_for_cpu first, and then release it back to device with
  _sync_single_for_device
- we mapped the wrong length of data for host commands, with mapped length
  differing with length provided to device, fix that.

Thanks to Jason Andryuk <jandryuk@gmail.com> for significant bisecting
help to find these issues.

This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1964Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Tested-by: NJason Andryuk <jandryuk@gmail.com>
Tested-by: NBen Gamari <bgamari@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When debugging TX issues it is helpful to know the seq nr of the
frame being transmitted. The seq nr is printed as part of ucode's
log informing us which frame is being processed. Having this information
printed in driver log makes it easy to match activities between driver
and firmware.

Also make possible to print TX flags directly. These are already printed
as part of entire TX command, but having it printed directly in cpu format
makes it easier to look at.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes a build warning in mwl8.c.
(Marvell TOPDOG wireless driver)

The warning it fixes is: "large integer implicitly truncated to unsigned type."

The rx_ctrl member of the mwl8k_rx_desc struct is 8 bit (__u8 ), whereas trying
to assign it a 32 bit value (which is returned from  cpu_to_le32())
causes the compiler to issue
a truncation warning.
Signed-off-by: NRami Rosen <ramirose@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Users reported lockup with work still trying to run
after module has been unloaded.

http://thread.gmane.org/gmane.linux.kernel.wireless.general/30594/focus=30601Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Reported-by: NTJ <ubuntu@tjworld.net>
Reported-by: NHuaxu Wan <huaxu.wan@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix the bug where some revisions of 6000 series hardware cannot
be used. Later versions of 6000 series have the EEPROM replaced by
OTP. For these devices to be used we need to expand valid EEPROM mask.
Signed-off-by: NJay Sternberg <jay.e.sternberg@linux.intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

sparse says:

drivers/net/wireless/atmel.c:1501:3: warning: Initializer entry defined twice
drivers/net/wireless/atmel.c:1505:3:   also defined here

and it's correct; atmel has its own ndo_change_mtu and
shouldn't use eth_change_mtu.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

pcnet_cs: add cis(firmware) of the Allied Telesis LA-PCM
Signed-off-by: NKen Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If creating a workqueue fails, don't jump to the error path where that
same workqueue is destroyed, since destroy_workqueue() can't handle a
NULL pointer.

This was spotted by the Coverity checker (CID 2617).
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The per ring counters are implemented in SW. Now moving to have the total
counters as the sum of all rings. This way the numbers will always be consistent
and we no longer depend on HW buffer size limitations for those counters
that can be insufficient in some cases.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The former usage was to set the NETIF_F_HW_CSUM flag which is not used
in get_tx_csum. It caused Ethtool to show tx checksum as "on" even
though it was turned off in previous operation.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The low level driver always assumes this handler exists.
The lack of it could cause kernel panic
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The query whether the port is up or not should be done at
the execution of the restart task and not when it is queued.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In case of failure of either srq creation or page allocation,
the cleanup code handled the failed ring as well, and tried
to destroy resources that where not allocated.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The recent NVRAM patches sanitized how the driver deals with NVRAM
data, but they failed to bring the SEEPROM interfaces inline with
the new strategy.  This patch brings the SEEPROM interfaces up to date.
This patch also reverts commit 0d489ffb
("tg3: fix big endian MAC address collection failure").
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Tested-by: NRobin Holt <holt@sgi.com>
Tested-by: NJames Bottomley <james.bottomley@HansenPartnership.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes a hang on resume when the filesystem is not
available and request_firmware blocks.

However, the device does not accept the firmware on resume.
and it will exit with:

> firmware part 1 upload failed (-71).
> device is in a bad state. please reconnect it!
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

swap mwl8k_remove and mwl8k_shutdown functions to allow
"rmmod mwl8k; modprobe mwl8k"
Signed-off-by: NJoerg Albert <jal2@gmx.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch deactivates powersave in station mode.

It does not work correctly yet, so the code does more harm than good.
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"not" is not printed without a space after %pM
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After suspend & resume the rt2x00 devices won't wakeup
anymore due to a broken register information setup.
The most important problem is the release of the EEPROM
buffer which is completely cleared and never read again
after the suspend.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As the sk_sleep wait queue actually lives in tfile, which may be
detached from the tun device, bad things will happen when we use
sk_sleep after detaching.

Since the tun device is the persistent data structure here (when
requested by the user), it makes much more sense to have the wait
queue live there.  There is no reason to have it in tfile at all
since the only time we can wait is if we have a tun attached.
In fact we already have a wait queue in tun_struct, so we might
as well use it.
Reported-by: NEric W. Biederman <ebiederm@xmission.com>
Tested-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Tested-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The commit c70f1829 ("tun: Fix
races between tun_net_close and free_netdev") fixed a race where
an asynchronous deletion of a tun device can hose a poll(2) on
a tun fd attached to that device.

However, this came at the cost of moving the tun wait queue into
the tun file data structure.  The problem with this is that it
imposes restrictions on when and where the tun device can access
the wait queue since the tun file may change at any time due to
detaching and reattaching.

In particular, now that we need to use the wait queue on the
receive path it becomes difficult to properly synchronise this
with the detachment of the tun device.

This patch solves the original race in a different way.  Since
the race is only because the underlying memory gets freed, we
can prevent it simply by ensuring that we don't do that until
all tun descriptors ever attached to the device (even if they
have since be detached because they may still be sitting in poll)
have been closed.

This is done by using reference counting the attached tun file
descriptors.  The refcount in tun->sk has been reappropriated
for this purpose since it was already being used for that, albeit
from the opposite angle.

Note that we no longer zero tfile->tun since tun_get will return
NULL anyway after the refcount on tfile hits zero.  Instead it
represents whether this device has ever been attached to a device.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

EEH attempts to recover up 6 times.
The last attempt leaves all the ports and adapter down.hen
The driver is then unloaded, bringing the adapter down again
unconditionally. The unload will hang.
Check if the adapter is already down before trying to bring it down again.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Release vectors when a MSI-X allocation fails.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The fatal error task can be scheduled while processing an offload packet
in NAPI context when the connection handle is bogus. this can race
with the ports being brought down and the cxgb3 workqueue being flushed.
Stop napi processing before flushing the work queue.

The ULP drivers (iSCSI, iWARP) might also schedule a task on keventd_wk
while releasing a connection handle (cxgb3_offload.c::cxgb3_queue_tid_release()).
The driver however does not flush any work on keventd_wq while being unloaded.
This patch also fixes this.

Also call cancel_delayed_work_sync in place of the the deprecated
cancel_rearming_delayed_workqueue.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use the existing periodic task to handle link faults.
The link fault interrupt handler is also called in work queue context,
which is wrong and might cause potential deadlocks.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Check whether the underlying device provides a set of ethtool ops before
checking for individual handlers to avoid NULL pointer dereferences.
Reported-by: NArt van Breemen <ard@telegraafnet.nl>
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

EPERM means that disconnect() is runnung. It should be treated like
ENODEV
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Suppose that we receive lots of frames, start processing them, but
exhaust our budget so that we return before we had a chance to look
at all of them.

Then, when the network layer calls us again, we will only continue
processing the buffers if the REC bit was set in the mean time, which it
might not be if there was a brief pause in the flow of packets. If this
happens, we'll simply display a warning and call netif_rx_complete()
with potentially lots of unprocessed packets in the RX ring...

Fix this by scanning the ring no matter what flags are set in the
interrupt status register.
Signed-off-by: NErik Waling <erik.waling@konftel.com>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When transfering large amounts of data we sometimes experienced that the
Retry Limit Exceeded (RLE) bit got set in TSR during transmission
attempts. When this happened the driver would stall in a state that
prevented any more data from being sent.
Signed-off-by: NErik Waling <erik.waling@konftel.com>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The thresholds for the DCB priority flow control are incorrect for 82599.
This fixes the thresholds to be correct.
Signed-off-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The traffic classes in hardware are not symmetrical for Rx and Tx.  Rx
is every 16 descriptor queues, Tx is not.  It runs 32-32-16-16-8-8-8 when
running with 8 traffic classes, and runs 64-32-16 when running with 4
traffic classes.  This patch fixes the mapping.
Signed-off-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Cc: stable@kernel.org
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>