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: Heiko Schocher <hs@denx.de>
Acked-by: Li Yang <leoli@freescale.com>
Signed-off-by: David 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: Jonathan Lin <jon.lin@vatics.com>
Signed-off-by: Amos Kong <jianjun@zeuux.org>
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David 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=1964
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Jason Andryuk <jandryuk@gmail.com>
Tested-by: Ben Gamari <bgamari@gmail.com>
Signed-off-by: John 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: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John 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: Rami Rosen <ramirose@gmail.com>
Signed-off-by: John 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=30601
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Reported-by: TJ <ubuntu@tjworld.net>
Reported-by: Huaxu Wan <huaxu.wan@linux.intel.com>
Signed-off-by: John 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: Jay Sternberg <jay.e.sternberg@linux.intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John 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: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
pcnet_cs: add cis(firmware) of the Allied Telesis LA-PCM
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David 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: Roland Dreier <rolandd@cisco.com>
Signed-off-by: David 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: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David 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: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David 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: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David 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: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David 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: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David 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 0d489ffb76
("tg3: fix big endian MAC address collection failure").
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Tested-by: Robin Holt <holt@sgi.com>
Tested-by: James Bottomley <james.bottomley@HansenPartnership.com>
Signed-off-by: David 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: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
swap mwl8k_remove and mwl8k_shutdown functions to allow
"rmmod mwl8k; modprobe mwl8k"
Signed-off-by: Joerg Albert <jal2@gmx.de>
Signed-off-by: John 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: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John 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: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Eric W. Biederman <ebiederm@xmission.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
The commit c70f182940 ("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: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David 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: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David 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: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David 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: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David 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: Art van Breemen <ard@telegraafnet.nl>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
EPERM means that disconnect() is runnung. It should be treated like
ENODEV
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: David 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: Erik Waling <erik.waling@konftel.com>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: David 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: Erik Waling <erik.waling@konftel.com>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: David 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: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David 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: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Cc: stable@kernel.org
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the e1000 transmit cleanup inner loop exited early, then
cleaned might not be true. This could cause tx hangs or other
badness. Use count to track the total number of descriptors
cleaned instead of basing a tx queue restart off of a temporary
working state variable.
This code now makes the flow the same for e1000/e1000e/igb/ixgbe
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the e1000e transmit cleanup inner loop exited early, then
cleaned might not be true. This could cause tx hangs or other
badness. Use count to track the total number of descriptors
cleaned instead of basing a tx queue restart off of a temporary
working state variable.
This code now makes the flow the same for e1000/e1000e/igb/ixgbe
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
GCC warns:
drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_sfp_config_module_task':
drivers/net/ixgbe/ixgbe_main.c:3920: warning: suggest parantheses around
operand of '!' or change '&' to '&&' or '!' to '~'
Which I think is right. Bracket to remove ambiguity.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
arm will pad even between u8's, so mark the structs/unions
packed. Fixes a build bug on arm due to BUILD_BUG_ON tests
in the code.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If the value read from HERMES_RID_TXQUEUEEMPTY becomes 0 after exactly
100 readings, we wrongly consider it a timeout. Rewrite the clever
while loop as a for loop that does the right thing and looks simpler.
Reported by Juha Leppanen <juha_motorsportcom@luukku.com>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I forgot that iwl3945 registration is separate from iwlagn.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The assertion of the lock-bit in the hardware register is unreliable,
because there are devices with quirks that will randomly set the bit.
Do the assertion in software, only.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds a new device to ar9170usb.
Reported-by: Mike Kershaw/Dragorn <dragorn@kismetwireless.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Code was clearly wrong, plus callers expect the mode change to happen as
soon as possible, not dropped on the floor until the next time some
other config value changes and a commit happens.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add USB device ID for OQO 01+'s internal wireless LAN
An OQO employee mentions the chip's true identity here:-
ftp://ftp.oqo.com/unsupported/linux/OQOLinux.html
Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Acked-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
