Found by checkpatch:
drivers/net/wireless/ath/ath6kl/init.c:78: WARNING: line over 80 characters
drivers/net/wireless/ath/ath6kl/init.c:397: WARNING: line over 80 characters
drivers/net/wireless/ath/ath6kl/init.c:407: WARNING: line over 80 characters
drivers/net/wireless/ath/ath6kl/htc.c:189: WARNING: line over 80 characters
drivers/net/wireless/ath/ath6kl/htc.c:704: WARNING: line over 80 characters
drivers/net/wireless/ath/ath6kl/htc.c:2452: WARNING: line over 80 characters
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
All found by checkpatch:
ath6kl/wmi.c:1036: CHECK: Logical continuations should be on the previous line
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Fix the issues which checkpatch found and were easy to fix. Especially
callers of ath6kl_bmi_write() are tricky and that needs to be fixed
separately.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
htc_packet and htc_packet->buf_start are separately allocated
for endpoint 0. This is different for other endpoints where
packets are allocated as skb where htc_packet is skb->head
and they are freed properly. Free htc_packet and htc_packet->buf_start
separatly for endpoint 0.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Tx packets will begin to drop when there are multiple traffic priorities
and the current traffic is not the highest priority and the remaining
cookies drop below a certain number, which is fixed for all AC. It is
possilbe that lower priority AC have more traffic which will consume
more cookies and lock out higher priority AC from having any. Assign
each endpoint (AC) with a different Tx-packet-drop threshold so lower
priority AC is more likely to drop packets and the cookies become more
available to higher priority AC.
Signed-off-by: Chilam Ng <chilamng@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Tx bundling is the more efficient use of SDIO bus and allows more packet
transfers with fewer bus transactions, and is a way to improve overall
throughput. However, Tx bundling has only 4 scatter request resources available.
When there are multiple traffic streams of different priorities, it's possible
that lower priority traffic may hog all the scatter requests and lock out the
higher prioirty traffic from bundling.
Tx bundling is now enabled per AC. When an AC do a scatter request and
the remaining scatter request resources is lower than a configurable
threshold, it will disable Tx bundling for all AC's of lower priorities.
When an AC has Tx bundling disabled and has no Tx bundles sent in a
consecutive and configurable number of packets, Tx bundling will be re-enabled
for that AC.
Signed-off-by: Chilam Ng <chilamng@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Update license header with the copyright to Qualcomm Atheros, Inc.
for the year 2011-2012.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
John Linville had to revert the part of USB support which was already
in ath6kl due to build problems in commit cb00ec382b ("ath6kl: revert
USB support"). Now that I fixed the build problems properly by adding
ath6kl_core.ko kernel module it's possible to add back the
(incomplete) USB support. This patch is a revert of John's patch and
adds back the USB code which as already in ath6kl, only difference
being minor changes in Makefile and adapting usb.c to new core
function names.
Note that USB support in ath6kl is not complete yet. This code only
makes it possible to boot firmware but as HTC layer does not yet
support USB it's not possible to send any WMI commands nor data
packets to the firmware. That will be added soon.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This prevents 'comp_pktq' from being used in an
incorrect manner.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The ath6kl driver is causing build failures when the ath6kl bits are
not built as modules. A better fix is forthcoming in a future release,
but for now lets revert the problematic code.
This reverts the following commits:
fde57764efd70385a26a59d954dda4
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As HTC layer doesn't support USB devices return an error if that happens.
USB support will be added to HTC in the future, this is just a temporary
solution.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The benefit from this is that user space can control hardware's power state
by putting interface up and down. This is handy if firmware gets to some
weird state.
The downside will be that putting interface up takes a bit longer,
I was measuring ~500 ms during interface up.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Move some of the debug logs to boot level because they are more
interesting when debugging boot issues.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It's currently possible to dump full sdio packets, so dumping htc packets
is not strictly needed. So remove it, we can always add it back if
there ever comes a need for that.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It is just a four byte information of the received message
from ath6kl_htc_rxmsg_pending_handler(). Remove unnecessary
array representaion.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It is not necessary to process an htc_packet which is allocated for rx
but failed in sdio rx. Though it does not fix any real issue, it does
not make much sense to process the failed frame.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It is found during the code review. As the leak would happen only
in failure case, the imapct is not easily visible.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Packet is not reclaimed when ath6kl_htc_rx_process_hdr() fails.
Fix this by deferring the packet deletion from comp_pktq till
ath6kl_htc_rx_process_hdr() returns success. This bug is found
in code review, impact is not easily visible as the leak happens
only in failure cases.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It is unnecessary to take the first list entry from queue again for
transmission. Sometimes it may look racy when the head of the list
changes between subsequent retrival, but should not happen in
practical.
Reported-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Current tx scatter gather implementation rolls back the entire
scatter setup in case of a failure in setting up just one packet
into the bundle. Instead of dopping the whole scatter setup,
send the packets available just before the failure one using
scatter gather I/O.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch "ath6kl: Fix buffer alignment for scatter-gather write" does
memmove for a length (scat_req->scat_list[i].len) which is not the
actual length of data that is suppossed to be moved. The right
lengh is packet->act_len + HTC_HDR_LENGTH. Using wrong length
for data move during buffer alignment causes system freeze after
the following WARN_ON and sometimes target assert.
WARNING: at drivers/net/wireless/ath/ath6kl/main.c:771 ath6k_credit_distribute+0x196/0x1a0
[<ffffffffa051cf5f>] ath6kl_htc_rxmsg_pending_handler+0x83f/0xe00 [ath6kl]
[<ffffffff8104a743>] ? __wake_up+0x53/0x70
[<ffffffffa0518b18>] ath6kldev_intr_bh_handler+0x188/0x650 [ath6kl]
[<ffffffffa052d316>] ath6kl_sdio_irq_handler+0x36/0x80 [ath6kl]
[<ffffffff81492b3c>] sdio_irq_thread+0xfc/0x360
[<ffffffff81051c52>] ? default_wake_function+0x12/0x20
[<ffffffff81492a40>] ? sdio_claim_irq+0x220/0x220
[<ffffffff81080c36>] kthread+0x96/0xa0
[<ffffffff815b9fb4>] kernel_thread_helper+0x4/0x10
[<ffffffff81080ba0>] ? kthread_worker_fn+0x190/0x190
[<ffffffff815b9fb0>] ? gs_change+0x13/0x13
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Stephen reported that compilation fails if both ath6kl and ath9k are
compiled in:
drivers/net/wireless/ath/ath6kl/built-in.o: In function `htc_start':
(.opd+0x600): multiple definition of `htc_start'
drivers/net/wireless/ath/ath9k/built-in.o:(.opd+0x3e40): first defined here
drivers/net/wireless/ath/ath6kl/built-in.o: In function `.htc_stop':
(.text+0x7b40): multiple definition of `.htc_stop'
drivers/net/wireless/ath/ath9k/built-in.o:(.text+0x67b34): first defined he=
re
drivers/net/wireless/ath/ath6kl/built-in.o: In function `.htc_start':
(.text+0x7d18): multiple definition of `.htc_start'
drivers/net/wireless/ath/ath9k/built-in.o:(.text+0x67ba0): first defined he=
re
drivers/net/wireless/ath/ath6kl/built-in.o: In function `htc_stop':
(.opd+0x5e8): multiple definition of `htc_stop'
drivers/net/wireless/ath/ath9k/built-in.o:(.opd+0x3e28): first defined here
To fix this add ath6kl prefix to all public functions in htc.c.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Use appropriate hif function directly.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Endpoint id ffrom htc_packet can be used instead.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
