Commit ac45f602ee ("net: infrastructure
for hardware time stamping") added two skb initialization actions to
__alloc_skb(), which need to be added to skb_recycle_check() as well.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add barrier() to bnx2_get_hw_{tx|rx}_cons() to fix this issue:
http://bugzilla.kernel.org/show_bug.cgi?id=12698
This issue was reported by multiple i386 users. Without barrier(),
the compiled code looks like the following where %eax contains the
address of the tx_cons or rx_cons in the DMA status block. The
status block contents can change between the cmpb and the movzwl
instruction. The driver would crash if the value was not 0xff during
the cmpb instruction, but changed to 0xff during the movzwl
instruction.
6828: 80 38 ff cmpb $0xff,(%eax)
682b: 0f b7 10 movzwl (%eax),%edx
With the added barrier(), the compiled code now looks correct:
683d: 0f b7 10 movzwl (%eax),%edx
6840: 0f b6 c2 movzbl %dl,%eax
6843: 3d ff 00 00 00 cmp $0xff,%eax
Thanks to Pascal de Bruijn <pmjdebruijn@pcode.nl> for reporting the
problem and Holger Noefer <hnoefer@pironet-ndh.com> for patiently
testing test patches for us.
Also updated version to 2.0.1.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When no limit is given, the bfifo uses a default of tx_queue_len * mtu.
Packets handled by qdiscs include the link layer header, so this should
be taken into account, similar to what other qdiscs do.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
The setup_rctl call was making a call into the ring structure after it had
been freed. This was causing a panic on shutdown. This call wasn't
necessary since it is possible to get the needed index from
adapter->vfs_allocated_count.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Traditionally Intel based NIC drivers request I/O port even though it
doesn't need that really.
Intel PCIE 10Gb driver (ixgbe) also requests I/O port but it doesn't
need it either.
This is a little inconvenient situation because sometimes we have to
handle those cards on the slots where any I/O space is not attached.
So we made pach which makes ixgbe driver legacy I/O port free.
Signed-off-by: Masayuki Gouji <gouji.masayuki@jp.fujitsu.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
According to the "PCI Error Recovery" document, if after a recovery,
the bus is disabled, the error_detected function should return
PCI_ERS_RESULT_DISCONNECT. Actually ixgbe error_detected function is
always returning PCI_ERS_RESULT_NEED_RESET, even if the bus is in failure.
This patch just check if the bus is disabled and then returns
PCI_ERS_RESULT_DISCONNET.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There were still some references to napi_add/del_all left after the dynamic
vector allocation patch. This patch removes those references since the
ixgbe_napi_add/del_all calls are no longer needed as the napi struct is
added when the vector is created, and deleted when the vector is freed.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
currently ixgbe_receive_skb is passing the vector index to
skb_record_rx_queue instead of the queue index. This patch changes that so
that the ring index is passed instead.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently the q_vectors are being allocated statically inside of the
adapter struct. This increases the overall size of the adapter struct when
we can easily allocate the vectors dynamically. This patch changes that
behavior so that the q_vectors are allocated dynamically and the napi
structures are automatically allocated inside of the q_vectors as needed.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current quirk doesn't include all 82576 device IDs. This update
resolves that.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
An issue was found in which rx checksum could not be enabled without
resetting the interface. The issue was the hardware enable was not being
done via ethtool. To resolve this issue and prevent conflicts with VF
configuration we will leave the feature always enabled in hardware, and
then in software we will choose to ignore the results via a sw flag.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch cleans up a number of unused or unneeded feature flags. As a
result of these changes the user should now be able to enable or disable rx
checksumming via ethtool.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is not a good idea to blindly unmask the RX and TX_END interrupts
for all eight queues on all mv643xx_eth hardware, since some variations
of the hardware have less than eight transmit/receive queues, and the
RX/TX_END interrupts for the queues they don't have can be in use by
other interrupt sources.
Signed-off-by: Saeed Bishara <saeed@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On the platforms that mv643xx_eth is used on, the manual skb->data
alignment logic in mv643xx_eth can be simplified, as the only case we
need to handle is where NET_SKB_PAD is not a multiple of the cache
line size. If this is the case, the extra padding we need can be
computed at compile time, while if NET_SKB_PAD _is_ a multiple of
the cache line size, the code can be optimised out entirely.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Move the definitions for the SDMA and port serial configuration
register values to where all the other register definitions live,
and expand the shifts to 32 bit constants.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
o Pause traffic during mac addr change.
o Enable setting mac address for NX3031.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
o use standard linked list api for mac addr list management
in NX3031.
o release mac addresses in firmware in dev close().
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix the distance check between tx ring producer and consumer that
could lead to tx ring wrap around.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a new wimax_dev is created, it's state has to be __WIMAX_ST_NULL
until wimax_dev_add() is succesfully called. This allows calls into
the stack that happen before said time to be rejected.
Until now, the state was being set (by mistake) to UNINITIALIZED,
which was allowing calls such as wimax_report_rfkill_hw() to go
through even when a call to wimax_dev_add() had failed; that was
causing an oops when touching uninitialized data.
This situation is normal when the device starts reporting state before
the whole initialization has been completed. It just has to be dealt
with.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When sending a message to user space using wimax_msg(), if nla_put()
fails, correctly interpret the return code from wimax_msg_alloc() as
an err ptr and return the error code instead of crashing (as it is
assuming than non-NULL means the pointer is ok).
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
IEEE 802.11w/D8.0 changed the length of the SA Query transaction
identifier from 16 to 2 octets.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR_SREV_9285_1[12]_OR_LATER macros already contains the
AR_SREV_9285 check.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On x86 this allows us to do the following small savings:
shave off 23 % off of the module's data, and
shave off 6 % off of the module's text.
We save 456 bytes, for those counting.
$ size ath9k.ko
text data bss dec hex filename
250794 3628 1600 256022 3e816 ath9k.ko
$ size ath9k-old.ko
text data bss dec hex filename
239114 15308 1600 256022 3e816 ath9k-old.ko
$ du -b ath9k.ko
4034244 ath9k.ko
$ du -b ath9k-old.ko
4033788 ath9k-old.ko
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently queues are stopped when their length reaches their length limit,
but are restarted only when the size of freed range of packet buffer is
not less than the size of the largest possible packet.
This causes permanent queue stop on radio visibility loss in the middle
of ping series: there is plenty of room in the packet buffer, but it is
never freed more than 3 (size of 'best effort' queue) * 288 (ping packet
plus headers) bytes at once.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We are currently processing block ack reordering as a separate task
before all other RX handlers. In theory, this is wrong since this step
should be done only after duplicate removal (see Figure 6-1 in IEEE
802.11n). However, moving this needs some work and the current
situation is not too bad. Add a comment here so that this small detail
does not get forgotten and who knows, maybe someone has some extra
time to take a look at cleaning this up.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch allows skbs to be released from the RX reorder buffer in
case they have been there for an unexpectedly long time without us
having received the missing frames before them. Previously, these
frames were only released when the reorder window moved and that could
take very long time unless new frames were received constantly (e.g.,
TCP connections could be killed more or less indefinitely).
This situation should not happen very frequently, but it looks like
there are some scenarious that trigger it for some reason. As such,
this should be considered mostly a workaround to speed up recovery
from unexpected siutation that could result in connections hanging for
long periods of time.
The changes here will only check for timeout situation when adding new
RX frames to the reorder buffer. It does not handle all possible
cases, but seems to help for most cases that could result from common
network usage (e.g., TCP retrying at least couple of times). For more
completely coverage, a timer could be used to periodically check
whether there are any frames remaining in the reorder buffer if no new
frames are received.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No need to duplicate the same code in two places (and that would be
three after the followup patch).
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00_check_rev() was too specific for rt2500usb and rt73usb,
by adding the mask argument (instead of hardcoding it into
the function itself) we can use the function in rt2800usb as
well.
v2: Fix revision mask for rt2800usb
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net/mac80211/mlme.c:2079:28: warning: symbol 'ssid_len' shadows an earlier one
net/mac80211/mlme.c:2022:12: originally declared here
ssid_len is already being declared and checked above so there is
no need for it again.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix this build error when CONFIG_PM is not set:
drivers/net/wireless/ath/ar9170/usb.c: In function 'ar9170_usb_probe':
drivers/net/wireless/ath/ar9170/usb.c:692:
error: 'struct usb_device' has no member named 'reset_resume'
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It's not very helpful to see, in iwconfig, the current frequency
the card is tuned to if that frequency is currently somewhere
across the board because we're scanning. Since we keep track of
the frequency the user wants, display that instead.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fixes sparse complaint:
CHECK net/wireless/nl80211.c
net/wireless/nl80211.c:3694:6:
warning: symbol 'nl80211_send_mlme_timeout'
was not declared. Should it be static?
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
/drivers/net/wireless/p54/p54usb.c: In function 'p54u_probe':
/drivers/net/wireless/p54/p54usb.c:923: error: 'struct usb_device' has no member named 'reset_resume'
In the struct usb_device the reset_resume attribute is only available
when CONFIG_PM is defined.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.
Cc: John W. Linville <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fixes warnings:
drivers/net/wireless/wl12xx/main.c:87: warning: int format, different
type arg (arg 2)
drivers/net/wireless/wl12xx/main.c: In function `wl12xx_fetch_nvs':
drivers/net/wireless/wl12xx/main.c:125: warning: int format, different
type arg (arg 2)
drivers/net/wireless/wl12xx/wl1251.c: In function 'wl1251_upload_firmware':
drivers/net/wireless/wl12xx/wl1251.c:94: warning: int format, different
type arg (arg 2)
drivers/net/wireless/wl12xx/wl1251.c:141: warning: int format, different
type arg (arg 2)
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch replaces test_and_set_bit by set_bit since the bit is not
tested anyway
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch change the "is_fat" checking in rate scale to use
iwl_is_fat_tx_allowed() to match the sta and RX_ON command setting.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Tested-by: Conrad Kostecki <ConiKost@gmx.de>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some issues in PS prevent us from supporting it reliably.
When 4965 goes to sleep it stores some data in host DRAM, reads it back
when device wakes up. In 4965 there is a problem that the data is not
correct when ucode starts using it upon wakeup.
For all iwlagn devices there is a problem where command is sent when PS is
enabled. At the moment there is a locking problem with priv->lock not being
held and thus not requesting nic access correctly.
We disable PS until these issues have been resolved.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Mohamed Abbas <mohamed.abbas@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Patch seperates rx_used and rx_free into two
different atomic contexts. We can now avoid using GFP_ATOMIC
for skb allocation and use GFP_KERNEL.
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add LED support on the IBM ThinkPad 11a/b/g Wireless LAN Mini Express
Adapter (AR5BXB6), found on the IBM/Lenovo Thinkpad X60/T60/Z60 series.
Signed-off-by: Paride Legovini <legovini@spiro.fisica.unipd.it>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update ath5k to use the ctl settings for tx power based on current
regulatory domain.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Add spur filter support for RF5413 and later chips
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Add code to support the various antenna scenarios supported by hw
* For now hardcode the default scenario (single or dual omnis with
tx/rx diversity working and tx antenna handled by session -hw keeps
track on which antenna it got ack from each ap/station and maps each
ap/station to one of the antennas-).
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After some debuging we were hitting the following bugs so far...
* Due to huge channel list hostapd couldn't get infos from the driver
and couldn't set the channel. If we manualy set the channel after
hostapd starts (by setting channel to 0 -auto), beacons are sent
but they wont show up on scan because they are malformed (they have
channel = 0 because hostapd doesn't update the channel info -this is
probably a hostapd bug so i'm CCing Jouni) and they get dropped. Bob
fixed this by only allowing standard channels to be registered so
now hostapd works as expected.
* Docs (and HAL source) say that we must write 0 on timer0 when
operating on AP mode to start TSF increment but this seems to
mess with DBA in many cases and beacon queue never gets started.
We fixed that on the previous patch.
We have some more things to deal with...
* For some reason (hw bug or something else) after restarting hostapd
a few times, beacon inteval seems to change from 100ms to a sec
(we get one beacon per sec).
* We need to set sleep timers on STA mode and enable power saving +
support PCF.
...but i think it's time we enable AP support "officialy" so that
we can get more feedback from users. I ran ath5k with the mentioned
patches + hostapd 0.6.8 and AP mode worked fine (it had some less
throughput on my tests than IBSS but it worked).
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Write next beacon timer even on AP mode since without this we get
no beacons + ath9k does it too. Docs say that we must write 0 on
this register on AP mode to start TSF increment, we do both to be
on the safe side.
* Fix num_tx_pending function, we never read the register :P that's
why we got all those "beacon queue 7 didn't stop messages".
* Put full prioriy on beacon queue, lock all queues with lower
priority using the arblock and also bypass any arblock by seting
the arblock ignore flag.
* For the CAB queue (do we need this thing ?, it seems crap) since
it's supposed to fire up after each beacon (we don't use it on driver
part, ath9k/MadWiFi does), don't make it DBA gated but instead make
it fire after each beacon by using the beacon sent gated flag.
* Increase bmiss threshold to 10, that's what we used on MadWiFi for
a long time. Also when we have pending frames on the beacon queue (we
got a beacon that didn't make it on the air) it's more likely that
the beacon queue never started, probably due to faulty DBA setting,
so change that "beacon queue didn't stop" message.
Tested this with AP mode and IBSS mode and seems to work fine ;-)
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Put remaining EEPROM information on ee struct and remove is_hb63
function.
Now we also have rfkill stuff available.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
