summaryrefslogtreecommitdiff
path: root/drivers/net/wimax/i2400m/tx.c
AgeCommit message (Collapse)AuthorFilesLines
2011-03-31Fix common misspellingsLucas De Marchi1-2/+2
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2010-05-12wimax/i2400m: reserve additional space in the TX queue's buffer while ↵Prasanna S. Panchamukhi1-1/+10
allocating space for a new message header 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>
2010-05-12wimax/i2400m: fix system freeze caused by an infinite loop [v1]Prasanna S. Panchamukhi1-5/+60
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>
2010-05-12wimax/i2400m: modify i2400m_tx_fifo_push() to check for head room space in ↵Prasanna S. Panchamukhi1-2/+14
the TX FIFO [v1] 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>
2010-05-12wimax/i2400m: fix BUILD_BUG_ON() to use the maximum message size constant [v1]Prasanna S. Panchamukhi1-15/+5
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>
2010-05-12wimax/i2400m: limit the message size upto 16KiB [v1]Prasanna S. Panchamukhi1-1/+12
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>
2010-05-12wimax/i2400m: increase the maximum number of payloads per message to 60 [v1]Prasanna S. Panchamukhi1-1/+7
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>
2010-05-12wimax/i2400m: Reset the TX FIFO indices when allocating the TX FIFO in ↵Cindy H Kao1-8/+21
tx_setup() 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>
2010-05-12wimax/i2400m: fix insufficient size of Tx buffer for 12 payload of 1400 MTU.Prasanna S. Panchamukhi1-1/+18
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>
2010-05-12wimax/i2400m: fix incorrect return -ESHUTDOWN when there is no Tx buffer ↵Prasanna S.Panchamukhi1-2/+4
available 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>
2010-04-12Merge branch 'master' of ↵David S. Miller1-0/+1
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/stmmac/stmmac_main.c drivers/net/wireless/wl12xx/wl1271_cmd.c drivers/net/wireless/wl12xx/wl1271_main.c drivers/net/wireless/wl12xx/wl1271_spi.c net/core/ethtool.c net/mac80211/scan.c
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo1-0/+1
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-25net/various: remove trailing space in messagesFrans Pop1-1/+1
Signed-off-by: Frans Pop <elendil@planet.nl> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-10-19wimax/i2400m: fix oops in TX when tearing down the deviceInaky Perez-Gonzalez1-1/+17
All the entry points into the TX module should check if the device has been torn down. Otherwise, when the device resets or shuts down, there are windows when a call to i2400m_tx*() will oops the system. For that, make i2400m_tx_release() set i2400m->tx_buf to NULL under the tx_lock. Then, any entry point [i2400m_tx(), _tx_msg_sent(), _tx_msg_get()] will check for i2400m->tx_buf to be NULL and exit gracefully. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax: misplaced parenthesisRoel Kluin1-1/+1
Fix misplaced parenthesis Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11wimax/i2400m: fix oops when the TX FIFO fills up due to a missing checkInaky Perez-Gonzalez1-0/+2
When the TX FIFO filled up and i2400m_tx_new() failed to allocate a new TX message header, a missing check for said condition was causing a kernel oops when trying to dereference a NULL i2400m->tx_msg pointer. Found and diagnosed by Cindy H. Kao. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11wimax/i2400m: fix panic due to missed corner cases on tail_room calculationInaky Perez-Gonzalez1-2/+56
i2400m_tx_skip_tail() needs to handle the special case of being called when the tail room that is left over in the FIFO is zero. This happens when a TX message header was opened at the very end of the FIFO (without payloads). The i2400m_tx_close() code already marked said TX message (header) to be skipped and this function should be doing nothing. It is called anyway because it is part of a common "corner case" path handling which takes care of more cases than only this one. The tail room computation was also improved to take care of the case when tx_in is at the end of the buffer boundary; tail_room has to be modded (%) to the buffer size. To do that in a single well-documented place, __i2400m_tx_tail_room() is introduced and used. Treat i2400m->tx_in == 0 as a corner case and handle it accordingly. Found and diagnosed by Cindy H. Kao. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11wimax/i2400m: fix panic/warnings caused by missed check on empty TX messageInaky Perez-Gonzalez1-1/+9
In some situations, when a new TX message header is started, there might be no space for data payloads. In this case the message is left with zero payloads and the i2400m_tx_close() function has just to mark it as "to skip". If it tries to go ahead it will overwrite things because there is no space to add padding as defined by the bus-specific layer. This can cause buffer overruns and in some stress cases, panics. Found and diagnosed by Cindy H. Kao. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11wimax/i2400m: rename misleading I2400M_PL_PAD to I2400M_PL_ALIGNInaky Perez-Gonzalez1-2/+2
The constant is being use as an alignment factor, not as a padding factor; made reading/reviewing the code quite confusing. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11wimax/i2400m: don't call netif_start_queue() in _tx_msg_sent()Inaky Perez-Gonzalez1-1/+0
Reported and fixed by Cindy H Kao. When the device is stopped __i2400m_dev_stop() stops the network queue. However, when this is done in the middle of heavy network operation, when the bus-specific subdriver is still wrapping up and it reports a sent TX transaction with _tx_msg_sent() right after the device was stopped, the queue was being started again, which was causing a stream of oopsen and finally a panic. In any case, said call has no place there. It's a left over from an early implementation that was discarded later on. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-01-07i2400m: RX and TX data/control pathsInaky Perez-Gonzalez1-0/+817
Handling of TX/RX data to/from the i2400m device (IP packets, control and diagnostics). On RX, this parses the received read transaction from the device, breaks it in chunks and passes it to the corresponding subsystems (network and control). Transmission to the device is done through a software FIFO, as data/control frames can be coalesced (while the device is reading the previous tx transaction, others accumulate). A FIFO is used because at the end it is resource-cheaper that scatter/gather over USB. As well, most traffic is going to be download (vs upload). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>