Re: Specific tx rates with ath10k
Not on that specific setup. I'm using OpenWRT (ath9k ath10k) and Ubuntu 14 (ath9k only). There are some equipment that send broadcast traffic as unicast in order to reduce airtime. I don't know which, just remembered about that on some published papers. I would be very usefull to transmit broadcast traffic as real broadcast traffic at HT/VHT speeds in order to reduce air time, which speed is based on last sent unicast frame speed or build a pessimist rate adaptation algoritm with a sort of link with rate adaptation algoritm used for unicast traffic. Quoting Ben Greear gree...@candelatech.com: On 03/13/2015 02:37 AM, Mário Lopes wrote: Hi. You can change to fixed bitrate for all types of traffic for 802.11g/a modes, even on ath10k: for 2.4 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-2.4 54 for 5 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-5 54 Have you actually tried this with an ath10k AP and seen that beacons and broadcast go out at 54Mbps? If so, please let me know what firmware version you are using. Setting fixed speed for HT and VHT modes currently only takes effect on unicast traffic, I would like that this could be applied to other types of traffic in a future ath9k/ath10k driver. I know beacons won't go out at HT speeds, at least not with the logic that I tried in the firmware...but I have not checked to see if my patch allows setting broadcast to HT speeds Thanks, Ben Quoting Ben Greear gree...@candelatech.com: Ath10k firmware gives ability to set specific fixed rate-control rates for beacons/mgt, multicast, broadcast, and regular traffic. The ath10k driver only sets regular traffic currently. I had previously hacked my firmware to just set all rate types when ath10k driver requested to set the rate. But, that is not what my customer needs. So, I am now planning to add some debugfs entries to allow users to set beacon/mgt, multicast and broadcast rates individually (I don't have time or interest right now to try patching things top to bottom to try to get this feature into mac80211 stack or 'iw'). My question is, for when user just runs a command like this: ./local/sbin/iw dev vap1 set bitrates legacy-2.4 6 ht-mcs-2.4 What is the desired behaviour? Set all rates (beacons/mgt, bcast, multicast, regular) to the same fixed speed, or just a certain subset of these traffic types? I can make my firmware do whatever combination is required, and then users can over-ride the values by using debugfs. As a note, ath10k firmware will NOT send beacons at HT speeds, so if you fix an HT rate, then firmware will ignore that for the beacons/mgt ratecontrol type. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This message was sent using IMP, the Internet Messaging Program. -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com This message was sent using IMP, the Internet Messaging Program. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH] ath10k: mac: match wait_for_completion_timeout return type
Return type of wait_for_completion_timeout is unsigned long not int.
An appropriately named unsigned long is added, respectively 'ret'
renamed, and the assignments fixed up.
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---
Patch was only compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m,
CONFIG_ATH10K=m
Patch is against 4.0-rc3 (localversion-next is -next-20150313)
drivers/net/wireless/ath/ath10k/mac.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index e8cc19f..3fa11d8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -99,6 +99,7 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
{
struct ath10k *ar = arvif-ar;
int ret;
+ unsigned long time_left;
lockdep_assert_held(ar-conf_mutex);
@@ -108,8 +109,8 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
if (ret)
return ret;
- ret = wait_for_completion_timeout(ar-install_key_done, 3*HZ);
- if (ret == 0)
+ time_left = wait_for_completion_timeout(ar-install_key_done, 3 * HZ);
+ if (time_left == 0)
return -ETIMEDOUT;
return 0;
@@ -561,16 +562,16 @@ static void ath10k_mac_vif_beacon_cleanup(struct
ath10k_vif *arvif)
static inline int ath10k_vdev_setup_sync(struct ath10k *ar)
{
- int ret;
+ unsigned long time_left;
lockdep_assert_held(ar-conf_mutex);
if (test_bit(ATH10K_FLAG_CRASH_FLUSH, ar-dev_flags))
return -ESHUTDOWN;
- ret = wait_for_completion_timeout(ar-vdev_setup_done,
- ATH10K_VDEV_SETUP_TIMEOUT_HZ);
- if (ret == 0)
+ time_left = wait_for_completion_timeout(ar-vdev_setup_done,
+ ATH10K_VDEV_SETUP_TIMEOUT_HZ);
+ if (time_left == 0)
return -ETIMEDOUT;
return 0;
@@ -2432,6 +2433,7 @@ void ath10k_offchan_tx_work(struct work_struct *work)
const u8 *peer_addr;
int vdev_id;
int ret;
+ unsigned long time_left;
/* FW requirement: We must create a peer before FW will send out
* an offchannel frame. Otherwise the frame will be stuck and
@@ -2477,9 +2479,9 @@ void ath10k_offchan_tx_work(struct work_struct *work)
ath10k_tx_htt(ar, skb);
- ret = wait_for_completion_timeout(ar-offchan_tx_completed,
- 3 * HZ);
- if (ret == 0)
+ time_left =
+ wait_for_completion_timeout(ar-offchan_tx_completed, 3 * HZ);
+ if (time_left == 0)
ath10k_warn(ar, timed out waiting for offchannel skb
%p\n,
skb);
--
1.7.10.4
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH] ath10k: htc: match wait_for_completion_timeout return type
Return type of wait_for_completion_timeout is unsigned long not int.
An appropriately named unsigned long is added and the assignments fixed up.
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---
Patch was only compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m,
CONFIG_ATH10K=m
Patch is against 4.0-rc3 (localversion-next is -next-20150313)
drivers/net/wireless/ath/ath10k/htc.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c
b/drivers/net/wireless/ath/ath10k/htc.c
index 2fd9e18..690a2f5 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -548,6 +548,7 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
{
struct ath10k *ar = htc-ar;
int i, status = 0;
+ unsigned long time_left;
struct ath10k_htc_svc_conn_req conn_req;
struct ath10k_htc_svc_conn_resp conn_resp;
struct ath10k_htc_msg *msg;
@@ -555,9 +556,9 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
u16 credit_count;
u16 credit_size;
- status = wait_for_completion_timeout(htc-ctl_resp,
-ATH10K_HTC_WAIT_TIMEOUT_HZ);
- if (status == 0) {
+ time_left = wait_for_completion_timeout(htc-ctl_resp,
+ ATH10K_HTC_WAIT_TIMEOUT_HZ);
+ if (!time_left) {
/* Workaround: In some cases the PCI HIF doesn't
* receive interrupt for the control response message
* even if the buffer was completed. It is suspected
@@ -569,10 +570,11 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
for (i = 0; i CE_COUNT; i++)
ath10k_hif_send_complete_check(htc-ar, i, 1);
- status = wait_for_completion_timeout(htc-ctl_resp,
-
ATH10K_HTC_WAIT_TIMEOUT_HZ);
+ time_left =
+ wait_for_completion_timeout(htc-ctl_resp,
+ ATH10K_HTC_WAIT_TIMEOUT_HZ);
- if (status == 0)
+ if (!time_left)
status = -ETIMEDOUT;
}
@@ -646,6 +648,7 @@ int ath10k_htc_connect_service(struct ath10k_htc *htc,
struct sk_buff *skb;
unsigned int max_msg_size = 0;
int length, status;
+ unsigned long time_left;
bool disable_credit_flow_ctrl = false;
u16 message_id, service_id, flags = 0;
u8 tx_alloc = 0;
@@ -701,10 +704,10 @@ int ath10k_htc_connect_service(struct ath10k_htc *htc,
}
/* wait for response */
- status = wait_for_completion_timeout(htc-ctl_resp,
-ATH10K_HTC_CONN_SVC_TIMEOUT_HZ);
- if (status == 0) {
- ath10k_err(ar, Service connect timeout: %d\n, status);
+ time_left = wait_for_completion_timeout(htc-ctl_resp,
+ ATH10K_HTC_CONN_SVC_TIMEOUT_HZ);
+ if (!time_left) {
+ ath10k_err(ar, Service connect timeout\n);
return -ETIMEDOUT;
}
--
1.7.10.4
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: add firmware 10.2.4.45 as firmware-4.bin
On Thu, Mar 12, 2015 at 01:35:12PM +0200, Kalle Valo wrote: This is the latest firmware from 10.2.4 firmware branch. Signed-off-by: Kalle Valo kv...@qca.qualcomm.com Pardon my ignorance... It looks like your driver needs more than just firmware-4.bin... How are distros supposed to use this? Symlink it into firmware.bin which it seems the driver looks for? --Kyle --- LICENSE.QualcommAtheros_ath10k| 47 WHENCE|9 + ath10k/QCA988X/hw2.0/firmware-4.bin | Bin 0 - 241892 bytes ath10k/QCA988X/hw2.0/notice_ath10k_firmware-4.txt | 301 + 4 files changed, 357 insertions(+) create mode 100644 LICENSE.QualcommAtheros_ath10k create mode 100644 ath10k/QCA988X/hw2.0/firmware-4.bin create mode 100644 ath10k/QCA988X/hw2.0/notice_ath10k_firmware-4.txt ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 2/3 RFC] ath10k: wmi: match wait_for_completion_timeout return type
On 12 March 2015 at 16:49, Nicholas Mc Guire hof...@osadl.org wrote: Return type of wait_for_completion_timeout is unsigned long not int. An appropriately named unsigned long is added and the assignments fixed up. Rather than returning 0 (timeout) or a more or less random remaining time (completion success) this return 0 or 1 which also resolves the type of the functions being int. Signed-off-by: Nicholas Mc Guire hof...@osadl.org --- Checking the call-sites of ath10k_wmi_wait_for_unified_ready and ath10k_wmi_wait_for_service_ready the positive return value (remaining time in jiffies) is never passed up the call-chain nor used so it is cleaner to treat this like a boolean success/fail only (actually the two functions should probably be of type bool - but that does not seem to be common practice in the ath10k code base) It'd make sense to have these functions return 0 or -ETIMEDOUT. In that case both call sites would need to be adjusted to treat 0 or !x as an error (instead of the current = 0) condition and not set -ETIMEDOUT themselves. Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
On 13 March 2015 at 04:39, jh...@gmx.com wrote: I went through the archives, and the wiki but I still wasn't sure... I have a shiny new Lenovo z70, kernel 4.0-rc1/3. Dmesg reports failures for loading firmware in /lib/firmware/ath10k/QCA6174/hw2.1/... So I found the firmware Git repo, but it seems to be missing hw2.1. I even symlinked 2.1 to 3.0, no dice. You can't use hw3 firmware for hw2 hardware. The problem is there's no publicly available ath10k firmware for hw2 hardware.. I don't dual boot and this is a laptop so I'm looking to get my WiFi working. Any pointers are appreciated. Thanks. You could try building hw2 firmware ath10k binary yourself. You need to fetch athwlan.bin from Windows driver, extract otp image from hw3 firmware ath10k binary and then re-assemble both into hw3 firmware for ath10k. The ath10k binary blob is a tag-length-value format and can be understood by looking at ath10k_core_fetch_firmware_api_n(). Nobody seems to have tried this yet though. Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Specific tx rates with ath10k
Hi. You can change to fixed bitrate for all types of traffic for 802.11g/a modes, even on ath10k: for 2.4 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-2.4 54 for 5 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-5 54 Setting fixed speed for HT and VHT modes currently only takes effect on unicast traffic, I would like that this could be applied to other types of traffic in a future ath9k/ath10k driver. Quoting Ben Greear gree...@candelatech.com: Ath10k firmware gives ability to set specific fixed rate-control rates for beacons/mgt, multicast, broadcast, and regular traffic. The ath10k driver only sets regular traffic currently. I had previously hacked my firmware to just set all rate types when ath10k driver requested to set the rate. But, that is not what my customer needs. So, I am now planning to add some debugfs entries to allow users to set beacon/mgt, multicast and broadcast rates individually (I don't have time or interest right now to try patching things top to bottom to try to get this feature into mac80211 stack or 'iw'). My question is, for when user just runs a command like this: ./local/sbin/iw dev vap1 set bitrates legacy-2.4 6 ht-mcs-2.4 What is the desired behaviour? Set all rates (beacons/mgt, bcast, multicast, regular) to the same fixed speed, or just a certain subset of these traffic types? I can make my firmware do whatever combination is required, and then users can over-ride the values by using debugfs. As a note, ath10k firmware will NOT send beacons at HT speeds, so if you fix an HT rate, then firmware will ignore that for the beacons/mgt ratecontrol type. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This message was sent using IMP, the Internet Messaging Program. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
On 13 March 2015 at 04:39, jh...@gmx.com wrote: I went through the archives, and the wiki but I still wasn't sure... I have a shiny new Lenovo z70, kernel 4.0-rc1/3. Dmesg reports failures for loading firmware in /lib/firmware/ath10k/QCA6174/hw2.1/... So I found the firmware Git repo, but it seems to be missing hw2.1. I even symlinked 2.1 to 3.0, no dice. You can't use hw3 firmware for hw2 hardware. The problem is there's no publicly available ath10k firmware for hw2 hardware.. I don't dual boot and this is a laptop so I'm looking to get my WiFi working. Any pointers are appreciated. Thanks. You could try building hw2 firmware ath10k binary yourself. You need to fetch athwlan.bin from Windows driver, extract otp image from hw3 firmware ath10k binary and then re-assemble both into hw3 firmware for ath10k. The ath10k binary blob is a tag-length-value format and can be understood by looking at ath10k_core_fetch_firmware_api_n(). Nobody seems to have tried this yet though. I installed WINE and attempted to install the driver from lenono on my non-lenovo with working wifi. The install failed (expected) but not before it extracted the actual driver installer images (expected). Parsing through an .inf file, and navigating my way through the sections, I end up at a section specifying eeprom_ar6320_2p1_NFA354xp.bin and qca61x420.bin as the firmware files. I have these files. However I am now diverging from your instructions considerably. Also I don't know why I would want to reassemble into 3.0 when my system is looking for 2.1? I don't know what an 'otp image' is? I think I understand the part about the ath10k format though. Could you update your instructions to suit the new information at hand? Thanks again ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v3 0/3] ath10k: add basic tdls support
Marek Puzyniak marek.puzyn...@tieto.com writes: On 9 March 2015 at 13:45, Marek Puzyniak marek.puzyn...@tieto.com wrote: This patchset introduces tdls funtionality without tdls peer uapsd and tdls channel switching. Tdls is supported by qca6174 hardware what is indicated by firmware through supported services. [...] Marek Puzyniak (2): ath10k: make peer type configurable ath10k: introduce basic tdls functionality Michal Kazior (1): ath10k: unify tx mode and dispatch [...] Kalle, please drop this patchset. I will send new version. Ok, dropped. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Specific tx rates with ath10k
On 03/13/2015 02:37 AM, Mário Lopes wrote: Hi. You can change to fixed bitrate for all types of traffic for 802.11g/a modes, even on ath10k: for 2.4 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-2.4 54 for 5 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-5 54 Have you actually tried this with an ath10k AP and seen that beacons and broadcast go out at 54Mbps? If so, please let me know what firmware version you are using. Setting fixed speed for HT and VHT modes currently only takes effect on unicast traffic, I would like that this could be applied to other types of traffic in a future ath9k/ath10k driver. I know beacons won't go out at HT speeds, at least not with the logic that I tried in the firmware...but I have not checked to see if my patch allows setting broadcast to HT speeds Thanks, Ben Quoting Ben Greear gree...@candelatech.com: Ath10k firmware gives ability to set specific fixed rate-control rates for beacons/mgt, multicast, broadcast, and regular traffic. The ath10k driver only sets regular traffic currently. I had previously hacked my firmware to just set all rate types when ath10k driver requested to set the rate. But, that is not what my customer needs. So, I am now planning to add some debugfs entries to allow users to set beacon/mgt, multicast and broadcast rates individually (I don't have time or interest right now to try patching things top to bottom to try to get this feature into mac80211 stack or 'iw'). My question is, for when user just runs a command like this: ./local/sbin/iw dev vap1 set bitrates legacy-2.4 6 ht-mcs-2.4 What is the desired behaviour? Set all rates (beacons/mgt, bcast, multicast, regular) to the same fixed speed, or just a certain subset of these traffic types? I can make my firmware do whatever combination is required, and then users can over-ride the values by using debugfs. As a note, ath10k firmware will NOT send beacons at HT speeds, so if you fix an HT rate, then firmware will ignore that for the beacons/mgt ratecontrol type. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This message was sent using IMP, the Internet Messaging Program. -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 2/3 RFC] ath10k: wmi: match wait_for_completion_timeout return type
On Fri, 13 Mar 2015, Kalle Valo wrote: Nicholas Mc Guire hof...@osadl.org writes: Return type of wait_for_completion_timeout is unsigned long not int. An appropriately named unsigned long is added and the assignments fixed up. Rather than returning 0 (timeout) or a more or less random remaining time (completion success) this return 0 or 1 which also resolves the type of the functions being int. Signed-off-by: Nicholas Mc Guire hof...@osadl.org Why does patch 2 in this patchset have RFC in the title but patches 1 and 3 not? That just makes me confused, I can't tell what you want me to do with the patches. Normally I just drop all patches (or patchsets) which have RFC, and that's what I'm going to do now. To save everyone's time, when submitting something please state clearly what's your intention. ok - was simply unsure about the proposed change and 1 was a trivial cleanup (which should have been sent out as a seperate patch and not part of a series - my mistake) Will fix this up and repost it. sorry for the screwup - no intent to wast anybodies time. thx! hofrat ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 1/4] ath10k: add WMI support for WOW
Janusz Dziedzic janusz.dzied...@tieto.com writes: Add WMI support for WOW like enable, wakeup events and host wakeup indication. Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com Patch 1 had quite a few conflicts, please check carefully my resolution in the pending branch. Applying: ath10k: add WMI support for WOW Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging drivers/net/wireless/ath/ath10k/wmi.h Auto-merging drivers/net/wireless/ath/ath10k/wmi-tlv.h CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/wmi-tlv.h Auto-merging drivers/net/wireless/ath/ath10k/wmi-tlv.c CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/wmi-tlv.c Auto-merging drivers/net/wireless/ath/ath10k/wmi-ops.h CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/wmi-ops.h Failed to merge in the changes. Patch failed at 0001 ath10k: add WMI support for WOW -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: match wait_for_completion_timeout return type
Nicholas Mc Guire hof...@osadl.org writes: Return type of wait_for_completion_timeout is unsigned long not int. An appropriately named unsigned long is added and the assignments fixed up. Signed-off-by: Nicholas Mc Guire hof...@osadl.org Doesn't apply: Applying: ath10k: match wait_for_completion_timeout return type fatal: sha1 information is lacking or useless (drivers/net/wireless/ath/ath10k/mac.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 ath10k: match wait_for_completion_timeout return type -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: move driver state check before setting throttle
Rajkumar Manoharan rmano...@qti.qualcomm.com writes: Since thermal daemon is unaware of the device state, it might try to adjust the throttle state when the device is powered down. So the driver caches the value and will configure it while powering up the target. The cached value will be programed later once the device is brought up. In such case, returning error status is confusing and misleading the user application. Hence moving the driver state check before sending wmi command to target. Reported-by: Matthias Kaehlcke m...@google.com Signed-off-by: Rajkumar Manoharan rmano...@qti.qualcomm.com What tree do you use as the baseline? Three-way merge doesn't work as sha1 ids are not found: Applying: ath10k: move driver state check before setting throttle fatal: sha1 information is lacking or useless (drivers/net/wireless/ath/ath10k/thermal.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 ath10k: move driver state check before setting throttle -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
