The handling of tx descriptors for beacons can be simplified by updating
write_tx_desc implementations of each driver to write directly to the
queue entry descriptor instead of to a provided memory area.
This is also a preparation for further clean ups where descriptors are
properly reserved in the skb instead of fiddling with the skb data
pointer.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Where possible, write the tx descriptor words from start to end, to
follow a logical ordering of words.
Where this is not possible (in rt2400pci, rt2500pci and rt61pci) add
a comment as to why word 0 needs to be written last.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The buffer address descriptor word is not part of the TXINFO structure
needed for beacons. The current writing of that word for beacons is
therefore an out-of-bounds write.
Fix this by only writing the buffer address descriptor word for TX
queues.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The skb frame descriptor is called everywhere skbdesc, except in one
place in rt2x00debug_dump_frame. Change that occurence to have
consistent naming.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* add support for the Qwest/Actiontec 802AIN Wireless N USB Network Adapter.
lsusb identifies the device as: "ID 1668:1200 Actiontec Electronics, Inc. [hex]"
usb_modeswitch package and appropriate rules are required to switch
the device from "ID 0ace:20ff ZyDas"
Changes-licensed-under: GPL
Signed-off-by: Steve Tanner <steve.tanner@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Drop cast on the result of kmalloc and similar functions.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
type T;
@@
- (T *)
(\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...))
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove the double swapping of the descriptor data structure, instead
keep it little-endian (native format of the eeprom data), and byteswap
on access.
This allows sparse to verify endian access to the eeprom struct.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The ready message from the target could be processed
before the host HW init has completed. In this case,
htc_process_target_rdy() would assume the target has timed
out, when it hasn't. Fix this by checking if the target
has sent the ready message properly.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The HTC state has to be setup before initializing
the target because the ready message could possibly
come before the control endpoints in HTC have been
identified.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The URBs have to be allocated before uploading
the firmware to the target. This is needed to process
the target ready message properly.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Updates the i2400m driver to default to firmware versions v1.5 for the
Intel Wireless WiMAX Connection 5150 and 5350 devices.
Firmware available in linux-firmware.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
This patch moves the module parameters to the file where they
can be avoided to be global and allow them to be static.
The module param : idle_mode_disabled and power_save_disabled
are moved from driver.c to control.c. Also these module parameters
are declared to be static as they are not required to be global anymore.
The module param : rx_reorder_disabled is moved from driver.c file to
rx.c file. Also this parameter is declated as static as it is not
required to be global anymore.
Signed-off-by: Prasanna S Panchamukhi<prasannax.s.panchamukhi@intel.com>
wimax_msg_alloc() returns an ERR_PTR and not null. I changed it to test
for ERR_PTR instead of null. I also added a check in front of the
kfree() because kfree() can handle null but not ERR_PTR.
Signed-off-by: Dan Carpenter <error27@gmail.com>
This patch specifies the TX queue's buffer room required by the
USB bus driver while allocating header space for a new message.
Please refer the documentation in the code.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
This patch specifies the TX queue's minimum buffer room required to
accommodate one smallest SDIO payload.
Please refer the documentation in the code.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
Increase the possibilities of including at least one payload by reserving
some additional space in the TX queue while allocating TX queue's space
for new message header. Please refer the documentation in the code for details.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
According to Intel Wimax i3200, i5x50 and i6x60 device specification documents,
the host driver must not reset the device if the normalized sequence numbers
are greater than 1023 for type 2 and type 3 RX messages.
This patch removes the code that incorrectly used to reset the device.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
This patch fixes the race condition when one thread tries to destroy
the memory allocated for rx_roq, while another thread still happen
to access rx_roq.
Such a race condition occurs when i2400m-sdio kernel module gets
unloaded, destroying the memory allocated for rx_roq while rx_roq
is accessed by i2400m_rx_edata(), as explained below:
$thread1 $thread2
$ void i2400m_rx_edata() $
$Access rx_roq[] $
$roq = &i2400m->rx_roq[ro_cin] $
$ i2400m_roq_[reset/queue/update_ws] $
$ $ void i2400m_rx_release();
$ $kfree(rx->roq);
$ $rx->roq = NULL;
$Oops! rx_roq is NULL
This patch fixes the race condition using refcount approach.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
This patch increases the tx_queue_len to 20 so as to
minimize the jitter in the throughput.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
This patch fixes an infinite loop caused by i2400m_tx_fifo_push() due
to a corner case where there is no tail space in the TX FIFO.
Please refer the documentation in the code for details.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
This fixes i2400m_tx_fifo_push(); the check for having enough
space in the TX FIFO's tail was obscure and broken in certain
corner cases. The new check works in all cases and is way
clearer. Please refer the documentation in the code for details.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
The older method of computing the maximum PDU size relied
on a method that doesn't work when we prop the maximum
number of payloads up to the physical limit, and thus we kill
the whole computation and just verify that the constants are
congruent.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
According to Intel Wimax i3200, i5x50 and i6x50 specification
documents, the maximum size of each TX message can be upto 16KiB.
This patch modifies the i2400m_tx() routine to check that the
message size does not exceed the 16KiB limit.
Please refer the documentation in the code for details.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
According to Intel Wimax i3200, i5x50 and i6x50 device specification
documents, the maximum number of payloads per message can be up to 60.
Increasing the number of payloads to 60 per message helps to
accommodate smaller payloads in a single transaction. This patch
increases the maximum number of payloads from 12 to 60 per message.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
This patch makes sure whenever tx_setup() is invoked during driver
initialization or device reset where TX FIFO is released and re-allocated,
the indices tx_in, tx_out, tx_msg_size, tx_sequence, tx_msg are properly
initialized.
When a device reset happens and the TX FIFO is released/re-allocated,
a new block of memory may be allocated for the TX FIFO, therefore tx_msg
should be cleared so that no any TX threads (tx_worker, tx) would access
to the out-of-date addresses.
Also, the TX threads use tx_in and tx_out to decide where to put the new
host-to-device messages and from where to copy them to the device HW FIFO,
these indices have to be cleared so after the TX FIFO is re-allocated during
the reset, the indices both refer to the head of the FIFO, ie. a new start.
The same rational applies to tx_msg_size and tx_sequence.
To protect the indices from being accessed by multiple threads simultaneously,
the lock tx_lock has to be obtained before the initializations and released
afterwards.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
When bus_setup fails in i2400m_post_reset(), it falls to the error path handler
"error_bus_setup:" which includes unlock the mutext. However, we didn't ever
try to the obtain the lock when running bus_setup.
The patch is to fix the misplaced error path handler "error_bus_setup:".
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
This patch adds an error recovery mechanism on TX path.
The intention is to bring back the device to some known state
whenever TX sees -110 (-ETIMEOUT) on copying the data to the HW FIFO.
The TX failure could mean a device bus stuck or function stuck, so
the current error recovery implementation is to trigger a bus reset
and expect this can bring back the device.
Since the TX work is done in a thread context, there may be a queue of TX works
already that all hit the -ETIMEOUT error condition because the device has
somewhat stuck already. We don't want any consecutive bus resets simply because
multiple TX works in the queue all hit the same device erratum, the flag
"error_recovery" is introduced to denote if we are ready for taking any
error recovery. See @error_recovery doc in i2400m.h.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
The problem is only seen on SDIO interface since on USB, a bus reset would
really re-probe the driver, but on SDIO interface, a bus reset will not
re-enumerate the SDIO bus, so no driver re-probe is happening. Therefore,
on SDIO interface, the reset event should be still detected and handled by
dev_reset_handle().
Problem description:
Whenever a reboot barker is received during operational mode (i2400m->boot_mode == 0),
dev_reset_handle() is invoked to handle that function reset event.
dev_reset_handle() then sets the flag i2400m->boot_mode to 1 indicating the device is
back to bootmode before proceeding to dev_stop() and dev_start().
If dev_start() returns failure, a bus reset is triggered by dev_reset_handle().
The flag i2400m->boot_mode then remains 1 when the second reboot barker arrives.
However the interrupt service routine i2400ms_rx() instead of invoking dev_reset_handle()
to handle that reset event, it filters out that boot event to bootmode because it sees
the flag i2400m->boot_mode equal to 1.
The fix:
Maintain the flag i2400m->boot_mode within dev_reset_handle() and set the flag
i2400m->boot_mode to 1 when entering dev_reset_handle(). It remains 1
until the dev_reset_handle() issues a bus reset. ie: the bus reset is
taking place just like it happens for the first time during operational mode.
To denote the actual device state and the state we expect, a flag i2400m->alive
is introduced in addition to the existing flag i2400m->updown.
It's maintained with the same way for i2400m->updown but instead of reflecting
the actual state like i2400m->updown does, i2400m->alive maintains the state
we expect. i2400m->alive is set 1 just like whenever i2400m->updown is set 1.
Yet i2400m->alive remains 1 since we expect the device to be up all the time
until the driver is removed. See the doc for @alive in i2400m.h.
An enumeration I2400M_BUS_RESET_RETRIES is added to define the maximum number of
bus resets that a device reboot can retry.
A counter i2400m->bus_reset_retries is added to track how many bus resets
have been retried in one device reboot. If I2400M_BUS_RESET_RETRIES bus resets
were retried in this boot, we give up any further retrying so the device would enter
low power state. The counter i2400m->bus_reset_retries is incremented whenever
dev_reset_handle() is issuing a bus reset and is cleared to 0 when dev_start() is
successfully done, ie: a successful reboot.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
This fix is to correct order of the handlers in the error path
of dev_start(). When i2400m_firmware_check fails, all the works done
before it should be released or cleared.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
The race condition happens when the TX queue is accessed by
the TX work while the same TX queue is being destroyed because
a bus reset is triggered either by debugfs entry or simply
by failing waking up the device from WiMAX IDLE mode.
This fix is to prevent the TX queue from being accessed by
multiple threads
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
This patch increases the Tx buffer size so as to accommodate 12 payloads
of 1408 (1400 MTU 16 bytes aligned). Currently Tx buffer is 32 KiB which
is insufficient to accommodate 12 payloads of 1408 size.
This patch
- increases I2400M_TX_BUF_SIZE from 32KiB to 64KiB
- Adds a BUILD_BUG_ON if the calculated buffer size based
on the given MTU exceeds the I2400M_TX_BUF_SIZE.
Below is how we calculate the size of the Tx buffer.
Payload + 4 bytes prefix for each payload (1400 MTU 16 bytes boundary aligned)
= (1408 + sizeof(struct i2400m_pl_data_hdr)) * I2400M_TX_PLD_MAX
Adding 16 byte message header = + sizeof(struct i2400m_msg_hdr)
Aligning to 256 byte boundary
Total Tx buffer = (((((1408 + sizeof(struct i2400m_pl_data_hdr))
* I2400M_TX_PLD_MAX )+ sizeof(struct i2400m_msg_hdr))
/ 256) + 1) * 256 * 2
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
This patch moves I2400M_MAX_MTU enum defined in netdev.c to i2400m.h.
Follow up changes will make use of this value in other location,
thus requiring it to be moved to a global header file i2400m.h.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
i2400m_tx() routine was returning -ESHUTDOWN even when there was no Tx buffer
available. This patch fixes the i2400m_tx() to return -ESHUTDOWN only when
the device is down(i2400m->tx_buf is NULL) and also to return -ENOSPC
when there is no Tx buffer. Error seen in the kernel log.
kernel: i2400m_sdio mmc0:0001:1: can't send message 0x5606: -108
kernel: i2400m_sdio mmc0:0001:1: Failed to issue 'Enter power save'command: -108
Signed-off-by: Prasanna S.Panchamukhi <prasannax.s.panchamukhi@intel.com>
These changes include:
* For PAPRD, the TXRF3.capdiv5G, TXRF3.rdiv5G and TXRF3.rdiv2G
are set to 0x0, the TXRF6.capdiv2G is set to 0x2 for all
three chains.
* The d2cas5G/d3cas5G/d4cas5G was updated to 4/4/4 in lowest_ob_db
Tx gain table.
* To improve DPPM, three parameters were updated (Released from Madhan):
1. RANGE_OSDAC is set to 0x1 for 2G, 0x0 for 5G
2. offsetC1 is set to 0xc
3. inv_clk320_adc is set to 0x1
* To reduce PHY error(from spur), cycpwr_thr1 and cycpwr_thr1_ext
are increased to 0x8 at 2G.
* The 2G Rx gain tables are updated with mixer gain setting 3,1,0.
The new checksums yield:
initvals -f ar9003
0x00000000c2bfa7d5 ar9300_2p0_radio_postamble
0x00000000ada2b114 ar9300Modes_lowest_ob_db_tx_gain_table_2p0
0x00000000e0bc2c84 ar9300Modes_fast_clock_2p0
0x00000000056eaf74 ar9300_2p0_radio_core
0x0000000000000000 ar9300Common_rx_gain_table_merlin_2p0
0x0000000078658fb5 ar9300_2p0_mac_postamble
0x0000000023235333 ar9300_2p0_soc_postamble
0x0000000054d41904 ar9200_merlin_2p0_radio_core
0x00000000748572cf ar9300_2p0_baseband_postamble
0x000000009aa5a0a4 ar9300_2p0_baseband_core
0x000000003df9a326 ar9300Modes_high_power_tx_gain_table_2p0
0x000000001cfba124 ar9300Modes_high_ob_db_tx_gain_table_2p0
0x0000000011302700 ar9300Common_rx_gain_table_2p0
0x00000000e3eab114 ar9300Modes_low_ob_db_tx_gain_table_2p0
0x00000000c9d66d40 ar9300_2p0_mac_core
0x000000001e1d0800 ar9300Common_wo_xlna_rx_gain_table_2p0
0x00000000a0c54980 ar9300_2p0_soc_preamble
0x00000000292e2544 ar9300PciePhy_pll_on_clkreq_disable_L1_2p0
0x000000002d3e2544 ar9300PciePhy_clkreq_enable_L1_2p0
0x00000000293e2544 ar9300PciePhy_clkreq_disable_L1_2p0
Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jumbo frames are not supported, and if they are seen it is likely
a bogus frame so just silently discard them instead of warning on
them all time. Also, instead of dropping them immediately though
move the check *after* we check for all sort of frame errors. This
should enable us to discard these frames if the hardware picks
other bogus items first. Lets see if we still get those jumbo
counters increasing still with this.
Jumbo frames would happen if we tell hardware we can support
a small 802.11 chunks of DMA'd frame, hardware would split RX'd
frames into parts and we'd have to reconstruct them in software.
This is done with USB due to the bulk size but with ath5k we
already provide a good limit to hardware and this should not be
happening.
This is reported quite often and if it fills the logs then this
needs to be addressed and to avoid spurious reports.
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The goto and the break are equivelent. I removed the goto in memory of
Edsger Dijkstra who famously hated gotos and who would have been eighty
years old next Tuesday.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The "(wl == NULL)" test doesn't work here because "wl" is always
non-null. The intent of the code is to return if the interface
was not supported by the driver.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
net: Fix FDDI and TR config checks in ipv4 arp and LLC.
IPv4: unresolved multicast route cleanup
mac80211: remove association work when processing deauth request
ar9170: wait for asynchronous firmware loading
ipv4: udp: fix short packet and bad checksum logging
phy: Fix initialization in micrel driver.
sctp: Fix a race between ICMP protocol unreachable and connect()
veth: Dont kfree_skb() after dev_forward_skb()
IPv6: fix IPV6_RECVERR handling of locally-generated errors
net/gianfar: drop recycled skbs on MTU change
iwlwifi: work around passive scan issue
