Re: [PATCH v2 01/15] wcn36xx: Clean up wcn36xx_smd_send_beacon
On Sun 03 Apr 15:16 PDT 2016, Bjorn Andersson wrote: > From: Pontus Fuchs > > Needed for coming improvements. No functional changes. > Kalle, Eugene, Have you picked up these patches yet? As I was debugging a firmware crash when trying to start hostap on the DragonBoard410c I found an issue with this patch, would like to know if I should send an incremental patch or resend this one. > Signed-off-by: Pontus Fuchs > Signed-off-by: Bjorn Andersson > --- > drivers/net/wireless/ath/wcn36xx/hal.h | 7 +-- > drivers/net/wireless/ath/wcn36xx/smd.c | 12 +--- > 2 files changed, 10 insertions(+), 9 deletions(-) > > diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h > b/drivers/net/wireless/ath/wcn36xx/hal.h > index b947de0fb2e5..4fd77ccc2287 100644 > --- a/drivers/net/wireless/ath/wcn36xx/hal.h > +++ b/drivers/net/wireless/ath/wcn36xx/hal.h > @@ -51,8 +51,8 @@ > #define WALN_HAL_STA_INVALID_IDX 0xFF > #define WCN36XX_HAL_BSS_INVALID_IDX 0xFF > > -/* Default Beacon template size */ > -#define BEACON_TEMPLATE_SIZE 0x180 > +/* Default Beacon template size. */ > +#define BEACON_TEMPLATE_SIZE 0x17C This affects the wcn36xx_hal_send_probe_resp_req_msg as well, making the firmware on DB410c crash upon receiving the UPDATE_PROBE_RSP_TEMPLATE_REQ. I think we should keep it at 0x180 and subtract sizeof(u32) from the template size in send_beacon_req_msg, because the second length is really part of the buffer. > > /* Param Change Bitmap sent to HAL */ > #define PARAM_BCN_INTERVAL_CHANGED (1 << 0) > @@ -2884,6 +2884,9 @@ struct update_beacon_rsp_msg { > struct wcn36xx_hal_send_beacon_req_msg { > struct wcn36xx_hal_msg_header header; > > + /* length of the template + 6. Only qcom knows why */ > + u32 beacon_length6; > + > /* length of the template. */ > u32 beacon_length; > > diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c > b/drivers/net/wireless/ath/wcn36xx/smd.c > index 74f56a81ad9a..ff3ed2461a69 100644 > --- a/drivers/net/wireless/ath/wcn36xx/smd.c > +++ b/drivers/net/wireless/ath/wcn36xx/smd.c > @@ -1380,19 +1380,17 @@ int wcn36xx_smd_send_beacon(struct wcn36xx *wcn, > struct ieee80211_vif *vif, > mutex_lock(&wcn->hal_mutex); > INIT_HAL_MSG(msg_body, WCN36XX_HAL_SEND_BEACON_REQ); > > - /* TODO need to find out why this is needed? */ > - msg_body.beacon_length = skb_beacon->len + 6; > + msg_body.beacon_length = skb_beacon->len; > + /* TODO need to find out why + 6 is needed */ > + msg_body.beacon_length6 = msg_body.beacon_length + 6; As far as I can tell from the prima code and SMD dumps this should be 4, as in sizeof(u32). This looks like a mishap in the layering of prima. > > - if (BEACON_TEMPLATE_SIZE > msg_body.beacon_length) { > - memcpy(&msg_body.beacon, &skb_beacon->len, sizeof(u32)); > - memcpy(&(msg_body.beacon[4]), skb_beacon->data, > -skb_beacon->len); > - } else { > + if (msg_body.beacon_length > BEACON_TEMPLATE_SIZE) { > wcn36xx_err("Beacon is to big: beacon size=%d\n", > msg_body.beacon_length); > ret = -ENOMEM; > goto out; > } > + memcpy(msg_body.beacon, skb_beacon->data, skb_beacon->len); > memcpy(msg_body.bssid, vif->addr, ETH_ALEN); > > /* TODO need to find out why this is needed? */ PS. I confirmed that the update_beacon_rsp_msg does not come with the prepended length...for some reason. Regards, Bjorn -- 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
Re: pull-request: mac80211-next 2016-04-13
From: Johannes Berg Date: Wed, 13 Apr 2016 21:36:31 +0200 > For a while now I've wanted to remove enum ieee80211_band, and in > order to synchronize more easily with Kalle that's (apart from a > documentation change I already had pending) all in this pull. > > Let me know if there's any problem. Pulled, thanks Johannes. -- 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
Re: pull-request: wireless-drivers 2016-04-13
From: Kalle Valo Date: Wed, 13 Apr 2016 21:23:21 +0300 > few very small fixes for 4.6. All but one are either build fixes or > memory leaks. More info in the signed tag below. > > Please let me know if there are any problems. Pulled, thanks. -- 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
Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm
Thank-you very much for your comments in your reply. Actually the patch did work - I confirmed it was run and the iomap call was successful by adding a pr_info() after the pci_iomap() success branch. The only time I am getting the IRQ 17 nobody cared message is on suspend / resume. A fresh boot always had below the 100k interrupt threshold level. I tried your new patch and the number is even lower < 30,000 over two boots. BUT on suspend resume again 126856. Have you any insights on fixing suspend to disk / resume paths which presumably face the same issue of being passed live hardware on boot up? On 13 April 2016 at 04:32, Lukas Wunner wrote: > Hi Andrew, > > thank you for the extensive testing. > > On Sun, Apr 10, 2016 at 08:09:29PM +1000, Andrew Worsley wrote: >> Further testing Broadcom 4331 reset quirk to prevent IRQ storm patch >> testing reveals that: >> 1. quirk is run on initial boot up and this time appears to have >> vastly reduced the interrupts (only 81 this time): >> cat /proc/interrupts| grep 17 >> 17: 81 0 0 0 0 0 >> 0 0 IO-APIC-fasteoi snd_hda_intel > > Something in the ballpark of 81 interrupt requests is fine. > > The kernel will print the error message about spurious interrupts and > switch to polling at 10 requests. But even 2 is way too much. > This just means that b43 loaded quickly enough to stop the interrupts > before the kernel limit of 10 was reached, but the wireless card > wasn't reset early on as it should have been. > > It looks like the patch didn't work at all on your machine for some > reason. Do you see a message "cannot iomap device, IRQ storm ahead" > in dmesg? Result from two reboots with my 3.16 kernel and your new patch Three full boots (all below 30k interrupts): 17: 23978 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_hda_intel 17: 30088 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_hda_intel 17: 26853 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_hda_intel dmesg output showing quirk running dmesg | grep -C 5 quirk [3.270315] pci :00:1c.0: PCI bridge to [bus 03] [3.270323] pci :00:1c.0: bridge window [mem 0xc1a0-0xc1af] [3.270331] pci :00:1c.0: bridge window [mem 0xc180-0xc18f 64bit pref] [3.270463] pci :04:00.0: [14e4:4331] type 00 class 0x028000 [3.270495] pci :04:00.0: reg 0x10: [mem 0xc190-0xc1903fff 64bit] [3.270574] pci :04:00.0: b43 quirk: resetting controller [3.270711] pci :04:00.0: supports D1 D2 [3.270712] pci :04:00.0: PME# supported from D0 D3hot D3cold [3.270759] pci :04:00.0: System wakeup disabled by ACPI [3.278239] pci :00:1c.1: PCI bridge to [bus 04] [3.278251] pci :00:1c.1: bridge window [mem 0xc190-0xc19f] Output after resume. Note: Some times it looks it can happen on the suspend to disk? But a new one is always present after the resume. 17: 126856 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_hda_intel [ 53.404157] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88045d495540 [ 53.468249] irq 17: nobody cared (try booting with the "irqpoll" option) [ 53.468253] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C O 3.16.7-ckt25-3.16-bcm4331-patch2 #7 [ 53.468254] Hardware name: Apple Inc. MacBookPro10,1/Mac-C3EC7CD22292981F, BIOS MBP101.88Z.00EE.B00.1205101839 05/10/2012 [ 53.468259] 81520370 88045a8a8c00 88045a8a8cc4 [ 53.468262] 810bfe7d 88045a8a8c00 0011 [ 53.468264] 810c022f 0011 [ 53.468265] Call Trace: [ 53.468275][] ? dump_stack+0x5d/0x78 [ 53.468282] [] ? __report_bad_irq+0x2d/0xd0 [ 53.468286] [] ? note_interrupt+0x25f/0x2b0 [ 53.468290] [] ? handle_irq_event_percpu+0x121/0x190 [ 53.468294] [] ? handle_irq_event+0x38/0x50 [ 53.468296] [] ? handle_fasteoi_irq+0x7f/0x150 [ 53.468302] [] ? handle_irq+0x1d/0x30 [ 53.468307] [] ? do_IRQ+0x48/0xe0 [ 53.468311] [] ? common_interrupt+0x6d/0x6d [ 53.468317][] ? cpuidle_enter_state+0x4c/0xc0 [ 53.468320] [] ? cpuidle_enter_state+0x42/0xc0 [ 53.468323] [] ? cpu_startup_entry+0x33a/0x460 [ 53.468326] [] ? start_kernel+0x473/0x47b [ 53.468331] [] ? early_idt_handler_array+0x120/0x120 [ 53.468335] [] ? x86_64_start_kernel+0x14d/0x15c [ 53.468336] handlers: [ 53.468367] [] azx_interrupt [snd_hda_controller] [ 53.468368] Disabling IRQ #17 [ 53.513740] usb 3-1: reset high-speed USB device number 2 using xhci_hcd [ 53.633633] usb 1-1.1: reset high-speed USB device number 3 using ehci-pci [ 53.633646] usb 2-1.8:
Re: General VHT rate-ctrl question
On Wed, Apr 13, 2016 at 10:31 PM, Dave Taht wrote: > > On Wed, Apr 13, 2016 at 6:18 AM, Ben Greear wrote: > > > > > > On 04/13/2016 01:01 AM, Johannes Berg wrote: > >> > >> On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote: > >>> > >>> If a station and it's peer can both do VHT, is there ever a good > >>> reason to even try HT rates? > >>> > >> > >> Not really; perhaps if you could do HT greenfield preamble (which VHT > >> doesn't have) you could get something out of it, beyond that I don't > >> see a reason to try. > >> > >> Unless, for some strange reason, it supports only single stream VHT and > >> dual-stream HT or something really weird? > > > > > > I was wondering if there was ever a reason that, say 450Mbps HT > > would work better than MCS-1 for VHT. Or, maybe a mid-rate HT MCS would > > have more range than VHT, or something like that. I dont think so. basically if you remove 256 QAM out of picture, it just boils down to choosing a modulation scheme which would be same for VHT and HT. (assuming same BW) Only advantage is as Johannes pointed, VHT doesn't have greenfield, so using HT greenfield preamble might be marginally good. Similarly we can use RIFS for HT(not recommended), But again who uses RIFS/greenfield? -- 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
pull-request: mac80211-next 2016-04-13
Hi Dave, For a while now I've wanted to remove enum ieee80211_band, and in order to synchronize more easily with Kalle that's (apart from a documentation change I already had pending) all in this pull. Let me know if there's any problem. Thanks, johannes The following changes since commit bddf59046d804638d998f9015246d4990f1cab09: Merge tag 'wireless-drivers-next-for-davem-2016-04-11' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next (2016-04-11 11:58:12 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-04-13 for you to fetch changes up to 57fbcce37be7c1d2622b56587c10ade00e96afa3: cfg80211: remove enum ieee80211_band (2016-04-12 15:56:15 +0200) To synchronize with Kalle, here's just a big change that affects all drivers - removing the duplicated enum ieee80211_band and replacing it by enum nl80211_band. On top of that, just a small documentation update. Johannes Berg (1): cfg80211: remove enum ieee80211_band Jouni Malinen (1): cfg80211: Improve Connect/Associate command documentation Documentation/DocBook/80211.tmpl | 1 - drivers/net/wireless/admtek/adm8211.c | 4 +- drivers/net/wireless/ath/ar5523/ar5523.c | 4 +- drivers/net/wireless/ath/ath.h | 2 +- drivers/net/wireless/ath/ath10k/core.h | 2 +- drivers/net/wireless/ath/ath10k/htt_rx.c | 8 +- drivers/net/wireless/ath/ath10k/mac.c | 68 drivers/net/wireless/ath/ath10k/wmi.c | 8 +- drivers/net/wireless/ath/ath5k/ani.c | 2 +- drivers/net/wireless/ath/ath5k/ath5k.h | 10 +- drivers/net/wireless/ath/ath5k/attach.c| 8 +- drivers/net/wireless/ath/ath5k/base.c | 32 ++-- drivers/net/wireless/ath/ath5k/debug.c | 6 +- drivers/net/wireless/ath/ath5k/pcu.c | 6 +- drivers/net/wireless/ath/ath5k/phy.c | 30 ++-- drivers/net/wireless/ath/ath5k/qcu.c | 8 +- drivers/net/wireless/ath/ath5k/reset.c | 6 +- drivers/net/wireless/ath/ath6kl/cfg80211.c | 22 +-- drivers/net/wireless/ath/ath6kl/core.h | 2 +- drivers/net/wireless/ath/ath6kl/wmi.c | 22 +-- drivers/net/wireless/ath/ath6kl/wmi.h | 2 +- drivers/net/wireless/ath/ath9k/calib.c | 6 +- drivers/net/wireless/ath/ath9k/channel.c | 8 +- drivers/net/wireless/ath/ath9k/common-init.c | 28 ++-- drivers/net/wireless/ath/ath9k/common.c| 4 +- drivers/net/wireless/ath/ath9k/debug_sta.c | 6 +- drivers/net/wireless/ath/ath9k/dynack.c| 2 +- drivers/net/wireless/ath/ath9k/htc_drv_init.c | 8 +- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 12 +- drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 2 +- drivers/net/wireless/ath/ath9k/init.c | 12 +- drivers/net/wireless/ath/ath9k/main.c | 4 +- drivers/net/wireless/ath/ath9k/xmit.c | 4 +- drivers/net/wireless/ath/carl9170/mac.c| 12 +- drivers/net/wireless/ath/carl9170/main.c | 6 +- drivers/net/wireless/ath/carl9170/phy.c| 18 +-- drivers/net/wireless/ath/carl9170/rx.c | 2 +- drivers/net/wireless/ath/carl9170/tx.c | 8 +- drivers/net/wireless/ath/regd.c| 16 +- drivers/net/wireless/ath/regd.h| 2 +- drivers/net/wireless/ath/wcn36xx/main.c| 12 +- drivers/net/wireless/ath/wcn36xx/smd.c | 4 +- drivers/net/wireless/ath/wcn36xx/txrx.c| 2 +- drivers/net/wireless/ath/wil6210/cfg80211.c| 4 +- drivers/net/wireless/ath/wil6210/netdev.c | 2 +- drivers/net/wireless/ath/wil6210/wmi.c | 2 +- drivers/net/wireless/atmel/at76c50x-usb.c | 6 +- drivers/net/wireless/atmel/atmel.c | 2 +- drivers/net/wireless/broadcom/b43/b43.h| 4 +- drivers/net/wireless/broadcom/b43/main.c | 34 ++-- drivers/net/wireless/broadcom/b43/phy_ac.c | 2 +- drivers/net/wireless/broadcom/b43/phy_common.c | 2 +- drivers/net/wireless/broadcom/b43/phy_ht.c | 16 +- drivers/net/wireless/broadcom/b43/phy_lcn.c| 10 +- drivers/net/wireless/broadcom/b43/phy_lp.c | 30 ++-- drivers/net/wireless/broadcom/b43/phy_n.c | 176 ++--- drivers/net/wireless/broadcom/b43/tables_lpphy.c | 14 +- drivers/net/wireless/broadcom/b43/tables_nphy.c| 16 +- drivers/net/wireless/broadcom/b43/tables_phy_lcn.c | 2 +- drivers/net/wireless/broadcom/b43/xmit.c | 8 +- drivers/n
Google Summer of Code 2016 - We got 11 slots
Hi, now we got our slots and I ask you to accept the best applications quickly. We have 16 applications where someone of us wants to mentor the student, but we have only 11 slots. Org admins can accept applications (mentors perhaps too? I do not know). We have to be quick as if a student applied at more than one organization and one of the other organizations is quicker in accepting him, it goes to there. We can ask the other org whether they would pass the student to us, but they are not obliged to do so. With this mechanism there is also no de-duplication meeting any more this year. So act quickly. If you are an org admin, go onto the page of your desired student's application, confirm the mentors and backup mentors, and accept. Do not worry to be too quick with that, you can unaccept if you change your mind. If you are a mentor and not org admin, contact one or more org admins to ask for accepting students for you. Please tell which students. If you are not a mentor and want to see the applications (and perhaps help us on the decisions, or even help us mentoring), tell me your name and e-mail address so that I can invite you as mentor. Now we have 11 slots for 16 students. As I do all the organization work I have already taken 3 slots for OpenPrinting, so there remain 8 slots for 13 students. Please discuss and tell me, and/or Jan-Simon (CCed) who are the lucky students getting the slots. Yes, we did not get many slots this time, but it seems that there were very many great student applications (passing the first step of a mentor within the org stepping up) for which the orgs requested slots, many more than the slots offered by Google. Till -- 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
pull-request: wireless-drivers 2016-04-13
Hi Dave, few very small fixes for 4.6. All but one are either build fixes or memory leaks. More info in the signed tag below. Please let me know if there are any problems. Kalle The following changes since commit 9a3492194eca6253ae7ba93c7a402cecad7f1c94: Merge branch 'AF_VSOCK-missed-wakeups' (2016-03-22 16:18:42 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2016-04-13 for you to fetch changes up to 15da5d11040c636cddf85bd93fd4abe85f02fc9f: Merge tag 'iwlwifi-for-kalle-2016-03-30' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2016-04-02 17:59:57 +0300) wireless-drivers fixes for 4.6 b43 * fix memory leaks when removing the device bcma * fix building without OF_IRQ rtlwifi * fix gcc-6 indentation warning iwlwifi * lower the debug level of a benign print * fix a memory leak Arnd Bergmann (2): bcma: fix building without OF_IRQ rtlwifi: fix gcc-6 indentation warning Emmanuel Grumbach (1): iwlwifi: pcie: lower the debug level for RSA semaphore access Jia-Ju Bai (1): b43: Fix memory leaks in b43_bus_dev_ssb_init and b43_bus_dev_bcma_init Kalle Valo (1): Merge tag 'iwlwifi-for-kalle-2016-03-30' of https://git.kernel.org/.../iwlwifi/iwlwifi-fixes Matti Gottlieb (1): iwlwifi: mvm: fix memory leak in paging drivers/bcma/main.c| 17 - drivers/net/wireless/broadcom/b43/main.c |6 -- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c |2 ++ drivers/net/wireless/intel/iwlwifi/mvm/ops.c |2 -- drivers/net/wireless/intel/iwlwifi/pcie/trans.c|4 ++-- .../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c|6 +++--- 6 files changed, 15 insertions(+), 22 deletions(-) -- 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
Re: [PATCH v2] qcom: ipq4019: add wifi nodes to ipq4019 SoC device tree
On 04/11/2016 09:18 PM, tamizhchel...@codeaurora.org wrote: > + qcom,msi_addr = <0x0b006040>; > + qcom,msi_base = <0x50>; Are these properties used? I couldn't find any usage in the driver but I may have missed it. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
Re: General VHT rate-ctrl question
On Wed, Apr 13, 2016 at 6:18 AM, Ben Greear wrote: > > > On 04/13/2016 01:01 AM, Johannes Berg wrote: >> >> On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote: >>> >>> If a station and it's peer can both do VHT, is there ever a good >>> reason to even try HT rates? >>> >> >> Not really; perhaps if you could do HT greenfield preamble (which VHT >> doesn't have) you could get something out of it, beyond that I don't >> see a reason to try. >> >> Unless, for some strange reason, it supports only single stream VHT and >> dual-stream HT or something really weird? > > > I was wondering if there was ever a reason that, say 450Mbps HT > would work better than MCS-1 for VHT. Or, maybe a mid-rate HT MCS would > have more range than VHT, or something like that. > > After fighting with the firmware's rate-ctrl all day, I am even more > interested > in trying to make it use mistrel_ht. I just put up Andrew's old paper on minstrel, if that helps any. http://blog.cerowrt.org/post/minstrel/ > > Thanks, > Ben > > -- > Ben Greear > 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 -- 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
Re: [PATCH] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation
Am 13.04.2016 um 11:45 schrieb Kalle Valo: > Kalle Valo writes: > >> Oleksij Rempel writes: >> >>> by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move >>> mask_m & mask_p initialisation. This coused a performance regression >>> on ar9281. >>> >>> Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common >>> code in ar9002_hw_spur_mitigate.") >>> Reported-by: Gustav Frederiksen >>> Tested-by: Gustav Frederiksen >>> Signed-off-by: Oleksij Rempel >> >> If no objections I'm planning to send this to 4.6. > > Should we also CC stable (4.2+)? I can add that before I commit the > patch. > Yes, please. Thank you. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Re: General VHT rate-ctrl question
On 04/13/2016 01:01 AM, Johannes Berg wrote: On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote: If a station and it's peer can both do VHT, is there ever a good reason to even try HT rates? Not really; perhaps if you could do HT greenfield preamble (which VHT doesn't have) you could get something out of it, beyond that I don't see a reason to try. Unless, for some strange reason, it supports only single stream VHT and dual-stream HT or something really weird? I was wondering if there was ever a reason that, say 450Mbps HT would work better than MCS-1 for VHT. Or, maybe a mid-rate HT MCS would have more range than VHT, or something like that. After fighting with the firmware's rate-ctrl all day, I am even more interested in trying to make it use mistrel_ht. Thanks, Ben -- Ben Greear 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
[PATCH v3] brcmfmac: Decrease 8021x_cnt for dropped packets
From: Per Forlin This patch resolves an issue where pend_8021x_cnt was not decreased on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout because the counter indicated pending packets. WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x (warn_slowpath_common) (warn_slowpath_null) (brcmf_netdev_wait_pend8021x [brcmfmac]) (send_key_to_dongle [brcmfmac]) (brcmf_cfg80211_del_key [brcmfmac]) (nl80211_del_key [cfg80211]) (genl_rcv_msg) (netlink_rcv_skb) (genl_rcv) (netlink_unicast) (netlink_sendmsg) (sock_sendmsg) (___sys_sendmsg) (__sys_sendmsg) (SyS_sendmsg) The solution is to pull back the header offset in case of an error in txdata(), which may happen in case of packet overload in brcmf_sdio_bus_txdata. Overloading a WLAN interface is not an unlikely scenario. In case of packet overload the error print "out of bus->txq" is very verbose. To reduce SPAM degrade it to a debug print. Signed-off-by: Per Forlin --- Change log: v2 - Add variable to know whether the counter is increased or not v3 - txfinalize should decrease the counter. Fix skb header offset drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 5 +++-- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c index 67401ca..2c1bc0d 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c @@ -332,8 +332,9 @@ brcmf_proto_bcdc_txdata(struct brcmf_pub *drvr, int ifidx, u8 offset, int res; brcmf_proto_bcdc_hdrpush(drvr, ifidx, offset, pktbuf); res = brcmf_bus_txdata(drvr->bus_if, pktbuf); - if (res < 0) - brcmf_proto_bcdc_hdrpull(drvr, ifidx, offset, pktbuf); + if (res < 0) { + brcmf_proto_bcdc_hdrpull(drvr, false, &ifidx, pktbuf); + } return res; } diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c index a14d9d9d..485e2ad 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -2721,7 +2721,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, struct sk_buff *pkt) *(u16 *)(pkt->cb) = 0; if (!brcmf_sdio_prec_enq(&bus->txq, pkt, prec)) { skb_pull(pkt, bus->tx_hdrlen); - brcmf_err("out of bus->txq !!!\n"); + brcmf_dbg(INFO, "out of bus->txq !!!\n"); ret = -ENOSR; } else { ret = 0; -- 2.1.4 -- 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
[PATCH v2 5/5] ath10k: fix parenthesis alignment
Found by checkpatch: drivers/net/wireless/ath/ath10k/mac.c:6800: Alignment should match open parent Signed-off-by: Kalle Valo --- drivers/net/wireless/ath/ath10k/mac.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 9c848eb09d2e..59ed30cab681 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -6797,7 +6797,7 @@ static u64 ath10k_get_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif) } static void ath10k_set_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif, - u64 tsf) + u64 tsf) { struct ath10k *ar = hw->priv; struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif); -- 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
[PATCH v2 2/5] ath10k: prefer kernel type 'u64' over 'u_int64_t'
Fixes checkpatch warnings: drivers/net/wireless/ath/ath10k/htt.h:1477: Prefer kernel type 'u64' over 'u_int64_t' drivers/net/wireless/ath/ath10k/htt.h:1480: Prefer kernel type 'u64' over 'u_int64_t' Signed-off-by: Kalle Valo --- drivers/net/wireless/ath/ath10k/htt.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h index 60bd9fe4b2d9..ee7c8f8f8073 100644 --- a/drivers/net/wireless/ath/ath10k/htt.h +++ b/drivers/net/wireless/ath/ath10k/htt.h @@ -1475,10 +1475,10 @@ union htt_rx_pn_t { u32 pn24; /* TKIP or CCMP: 48-bit PN */ - u_int64_t pn48; + u64 pn48; /* WAPI: 128-bit PN */ - u_int64_t pn128[2]; + u64 pn128[2]; }; struct htt_cmd { -- 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
[PATCH v2 1/5] ath10k: fix checkpatch warnings related to spaces
Fix checkpatch warnings about use of spaces with operators: spaces preferred around that '*' (ctx:VxV) This has been recently added to checkpatch. Signed-off-by: Kalle Valo --- drivers/net/wireless/ath/ath10k/ce.c|6 +++--- drivers/net/wireless/ath/ath10k/ce.h|2 +- drivers/net/wireless/ath/ath10k/core.h |6 +++--- drivers/net/wireless/ath/ath10k/debug.h |2 +- drivers/net/wireless/ath/ath10k/htc.h |4 ++-- drivers/net/wireless/ath/ath10k/htt.c |2 +- drivers/net/wireless/ath/ath10k/mac.c |8 drivers/net/wireless/ath/ath10k/targaddrs.h |2 +- drivers/net/wireless/ath/ath10k/thermal.h |2 +- drivers/net/wireless/ath/ath10k/txrx.c |2 +- drivers/net/wireless/ath/ath10k/wmi-tlv.h |4 ++-- drivers/net/wireless/ath/ath10k/wmi.c |2 +- drivers/net/wireless/ath/ath10k/wmi.h | 18 +- 13 files changed, 30 insertions(+), 30 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c index 7212802eb327..9fb8d7472d18 100644 --- a/drivers/net/wireless/ath/ath10k/ce.c +++ b/drivers/net/wireless/ath/ath10k/ce.c @@ -1050,11 +1050,11 @@ int ath10k_ce_alloc_pipe(struct ath10k *ar, int ce_id, * * For the lack of a better place do the check here. */ - BUILD_BUG_ON(2*TARGET_NUM_MSDU_DESC > + BUILD_BUG_ON(2 * TARGET_NUM_MSDU_DESC > (CE_HTT_H2T_MSG_SRC_NENTRIES - 1)); - BUILD_BUG_ON(2*TARGET_10X_NUM_MSDU_DESC > + BUILD_BUG_ON(2 * TARGET_10X_NUM_MSDU_DESC > (CE_HTT_H2T_MSG_SRC_NENTRIES - 1)); - BUILD_BUG_ON(2*TARGET_TLV_NUM_MSDU_DESC > + BUILD_BUG_ON(2 * TARGET_TLV_NUM_MSDU_DESC > (CE_HTT_H2T_MSG_SRC_NENTRIES - 1)); ce_state->ar = ar; diff --git a/drivers/net/wireless/ath/ath10k/ce.h b/drivers/net/wireless/ath/ath10k/ce.h index 25cafcfd6b12..dfc098606bee 100644 --- a/drivers/net/wireless/ath/ath10k/ce.h +++ b/drivers/net/wireless/ath/ath10k/ce.h @@ -408,7 +408,7 @@ static inline u32 ath10k_ce_base_address(struct ath10k *ar, unsigned int ce_id) /* Ring arithmetic (modulus number of entries in ring, which is a pwr of 2). */ #define CE_RING_DELTA(nentries_mask, fromidx, toidx) \ - (((int)(toidx)-(int)(fromidx)) & (nentries_mask)) + (((int)(toidx) - (int)(fromidx)) & (nentries_mask)) #define CE_RING_IDX_INCR(nentries_mask, idx) (((idx) + 1) & (nentries_mask)) #define CE_RING_IDX_ADD(nentries_mask, idx, num) \ diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index 362bbed8f0e9..ccc3d639b077 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -44,8 +44,8 @@ #define ATH10K_SCAN_ID 0 #define WMI_READY_TIMEOUT (5 * HZ) -#define ATH10K_FLUSH_TIMEOUT_HZ (5*HZ) -#define ATH10K_CONNECTION_LOSS_HZ (3*HZ) +#define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ) +#define ATH10K_CONNECTION_LOSS_HZ (3 * HZ) #define ATH10K_NUM_CHANS 39 /* Antenna noise floor */ @@ -334,7 +334,7 @@ struct ath10k_sta { #endif }; -#define ATH10K_VDEV_SETUP_TIMEOUT_HZ (5*HZ) +#define ATH10K_VDEV_SETUP_TIMEOUT_HZ (5 * HZ) enum ath10k_beacon_state { ATH10K_BEACON_SCHEDULED = 0, diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h index 6206edd7c49f..75c89e3625ef 100644 --- a/drivers/net/wireless/ath/ath10k/debug.h +++ b/drivers/net/wireless/ath/ath10k/debug.h @@ -57,7 +57,7 @@ enum ath10k_dbg_aggr_mode { }; /* FIXME: How to calculate the buffer size sanely? */ -#define ATH10K_FW_STATS_BUF_SIZE (1024*1024) +#define ATH10K_FW_STATS_BUF_SIZE (1024 * 1024) extern unsigned int ath10k_debug_mask; diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h index e70aa38e6e05..cc827185d3e9 100644 --- a/drivers/net/wireless/ath/ath10k/htc.h +++ b/drivers/net/wireless/ath/ath10k/htc.h @@ -297,10 +297,10 @@ struct ath10k_htc_svc_conn_resp { #define ATH10K_NUM_CONTROL_TX_BUFFERS 2 #define ATH10K_HTC_MAX_LEN 4096 #define ATH10K_HTC_MAX_CTRL_MSG_LEN 256 -#define ATH10K_HTC_WAIT_TIMEOUT_HZ (1*HZ) +#define ATH10K_HTC_WAIT_TIMEOUT_HZ (1 * HZ) #define ATH10K_HTC_CONTROL_BUFFER_SIZE (ATH10K_HTC_MAX_CTRL_MSG_LEN + \ sizeof(struct ath10k_htc_hdr)) -#define ATH10K_HTC_CONN_SVC_TIMEOUT_HZ (1*HZ) +#define ATH10K_HTC_CONN_SVC_TIMEOUT_HZ (1 * HZ) struct ath10k_htc_ep { struct ath10k_htc *htc; diff --git a/drivers/net/wireless/ath/ath10k/htt.c b/drivers/net/wireless/ath/ath10k/htt.c index 17a3008d9ab1..ee79512b1fcc 100644 --- a/drivers/net/wireless/ath/ath10k/htt.c +++ b/drivers/net/wireless/ath/ath10k/htt.c @@ -208,7 +208,7 @@ int ath10k_htt_init(struct ath10k *ar) return 0; } -#define HTT_TARGET_VERSION_TIMEOUT_HZ (3*HZ) +#define HTT_TARGET_VERSION_TIMEOUT_HZ (3 * HZ) static int ath10k_htt_verify_version(s
[PATCH v2 3/5] ath10k: prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()
Fixes checkpatch warnings: drivers/net/wireless/ath/ath10k/mac.c:452: Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp() drivers/net/wireless/ath/ath10k/mac.c:455: Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp() drivers/net/wireless/ath/ath10k/txrx.c:133: Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp() Signed-off-by: Kalle Valo --- drivers/net/wireless/ath/ath10k/mac.c |4 ++-- drivers/net/wireless/ath/ath10k/txrx.c |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 045bfc7e0279..9c848eb09d2e 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -449,10 +449,10 @@ static int ath10k_mac_vif_update_wep_key(struct ath10k_vif *arvif, lockdep_assert_held(&ar->conf_mutex); list_for_each_entry(peer, &ar->peers, list) { - if (!memcmp(peer->addr, arvif->vif->addr, ETH_ALEN)) + if (ether_addr_equal(peer->addr, arvif->vif->addr)) continue; - if (!memcmp(peer->addr, arvif->bssid, ETH_ALEN)) + if (ether_addr_equal(peer->addr, arvif->bssid)) continue; if (peer->keys[key->keyidx] == key) diff --git a/drivers/net/wireless/ath/ath10k/txrx.c b/drivers/net/wireless/ath/ath10k/txrx.c index c503ff601a54..8c7086989a71 100644 --- a/drivers/net/wireless/ath/ath10k/txrx.c +++ b/drivers/net/wireless/ath/ath10k/txrx.c @@ -130,7 +130,7 @@ struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int vdev_id, list_for_each_entry(peer, &ar->peers, list) { if (peer->vdev_id != vdev_id) continue; - if (memcmp(peer->addr, addr, ETH_ALEN)) + if (!ether_addr_equal(peer->addr, addr)) continue; return peer; -- 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
[PATCH v2 4/5] ath10k: prefer ether_addr_copy() over memcpy()
Fixes checkpatch warning: drivers/net/wireless/ath/ath10k/wmi.c:5800: Prefer ether_addr_copy() over memcpy() if the Ethernet addresses are __aligned(2) Signed-off-by: Kalle Valo --- drivers/net/wireless/ath/ath10k/wmi.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index e92ac26865ff..adb31e188ebd 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -5827,9 +5827,8 @@ ath10k_wmi_put_start_scan_tlvs(struct wmi_start_scan_tlvs *tlvs, bssids->num_bssid = __cpu_to_le32(arg->n_bssids); for (i = 0; i < arg->n_bssids; i++) - memcpy(&bssids->bssid_list[i], - arg->bssids[i].bssid, - ETH_ALEN); + ether_addr_copy(bssids->bssid_list[i].addr, + arg->bssids[i].bssid); ptr += sizeof(*bssids); ptr += sizeof(struct wmi_mac_addr) * arg->n_bssids; -- 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
[PATCH v2 0/5] ath10k: fix recent checkpatch warnings
I updated checkpatch and noticed that there are few new warnings. v2: * fix tests in patch 3 * add patch 5 to fix a new warning in mac.c --- Kalle Valo (5): ath10k: fix checkpatch warnings related to spaces ath10k: prefer kernel type 'u64' over 'u_int64_t' ath10k: prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp() ath10k: prefer ether_addr_copy() over memcpy() ath10k: fix parenthesis alignment drivers/net/wireless/ath/ath10k/ce.c|6 +++--- drivers/net/wireless/ath/ath10k/ce.h|2 +- drivers/net/wireless/ath/ath10k/core.h |6 +++--- drivers/net/wireless/ath/ath10k/debug.h |2 +- drivers/net/wireless/ath/ath10k/htc.h |4 ++-- drivers/net/wireless/ath/ath10k/htt.c |2 +- drivers/net/wireless/ath/ath10k/htt.h |4 ++-- drivers/net/wireless/ath/ath10k/mac.c | 14 +++--- drivers/net/wireless/ath/ath10k/targaddrs.h |2 +- drivers/net/wireless/ath/ath10k/thermal.h |2 +- drivers/net/wireless/ath/ath10k/txrx.c |4 ++-- drivers/net/wireless/ath/ath10k/wmi-tlv.h |4 ++-- drivers/net/wireless/ath/ath10k/wmi.c |7 +++ drivers/net/wireless/ath/ath10k/wmi.h | 18 +- 14 files changed, 38 insertions(+), 39 deletions(-) -- 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
Re: [PATCH v3] prism54: isl_38xx: Replace 'struct timeval'
On 13-4-2016 10:38, Johannes Berg wrote: > >> The patch was build-tested / debugged by removing the >> "if VERBOSE > SHOW_ERROR_MESSAGES" guards. > > Stands to reason that we should just remove the (more or less) dead > code, since I don't think anyone really ever touches this driver any > more or will ever again ... It does bring back memories from my Intersil/Globespan/Conexant day(s), but not sentimental enough to touch the prism54 driver. Gr. AvS > johannes > -- > 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 > -- 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
Re: [PATCH] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation
Kalle Valo writes: > Oleksij Rempel writes: > >> by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move >> mask_m & mask_p initialisation. This coused a performance regression >> on ar9281. >> >> Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common >> code in ar9002_hw_spur_mitigate.") >> Reported-by: Gustav Frederiksen >> Tested-by: Gustav Frederiksen >> Signed-off-by: Oleksij Rempel > > If no objections I'm planning to send this to 4.6. Should we also CC stable (4.2+)? I can add that before I commit the patch. -- Kalle Valo -- 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
Re: [PATCH] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation
Oleksij Rempel writes: > by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move > mask_m & mask_p initialisation. This coused a performance regression > on ar9281. > > Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common > code in ar9002_hw_spur_mitigate.") > Reported-by: Gustav Frederiksen > Tested-by: Gustav Frederiksen > Signed-off-by: Oleksij Rempel If no objections I'm planning to send this to 4.6. -- Kalle Valo -- 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
Re: [PATCH v2] ath10k: remove MSI range support
Rajkumar Manoharan writes: > MSI-X is never well-tested, might contain bugs and generally isn't > really all that useful to maintain. Also ath10k is mainly used with > shared/singly-MSI interrupt systems. Hence removing MSI range support. > This change will be useful for further cleanup in copy engine lock > and to add NAPI support. > > Signed-off-by: Rajkumar Manoharan Applied, thanks. -- Kalle Valo-- 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
Re: [PATCH 0/3] ath10k: add a support of set_tsf on vdev interface
Peter Oh writes: > 10.2.4 and 10.4 firmware has introduced new function to > set TSF via vdev parameter. > set_tsf function can be used to shift TBTT that will help > avoid its clockdrift which happens when beacons are collided. > > Peter Oh (3): > ath10k: add a support of set_tsf on vdev interface > ath10k: update 10.4 WMI vdev parameters > ath10k: enable set_tsf vdev command to WMI 10.4 Series applied, thanks. -- Kalle Valo-- 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
Re: [PATCH v3] prism54: isl_38xx: Replace 'struct timeval'
> The patch was build-tested / debugged by removing the > "if VERBOSE > SHOW_ERROR_MESSAGES" guards. Stands to reason that we should just remove the (more or less) dead code, since I don't think anyone really ever touches this driver any more or will ever again ... johannes -- 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
[PATCH v3] prism54: isl_38xx: Replace 'struct timeval'
'struct timeval' uses a 32-bit seconds field which will overflow in year 2038 and beyond. This patch is part of a larger effort to remove all instances of 'struct timeval' from the kernel and replace them with 64-bit timekeeping variables. The patch also fixes the debug printf specifier to avoid the seconds value being truncated. The patch was build-tested / debugged by removing the "if VERBOSE > SHOW_ERROR_MESSAGES" guards. Signed-off-by: Tina Ruchandani Suggested-by: Arnd Bergmann -- Changes in v3: Fix commit message Changes in v2: Changed printf specifier as suggested by Arnd Bergmann to avoid truncation. --- drivers/net/wireless/intersil/prism54/isl_38xx.c | 35 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/drivers/net/wireless/intersil/prism54/isl_38xx.c b/drivers/net/wireless/intersil/prism54/isl_38xx.c index 333c1a2..6700387 100644 --- a/drivers/net/wireless/intersil/prism54/isl_38xx.c +++ b/drivers/net/wireless/intersil/prism54/isl_38xx.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -113,7 +114,7 @@ isl38xx_trigger_device(int asleep, void __iomem *device_base) #if VERBOSE > SHOW_ERROR_MESSAGES u32 counter = 0; - struct timeval current_time; + struct timespec64 current_ts64; DEBUG(SHOW_FUNCTION_CALLS, "isl38xx trigger device\n"); #endif @@ -121,22 +122,22 @@ isl38xx_trigger_device(int asleep, void __iomem *device_base) if (asleep) { /* device is in powersave, trigger the device for wakeup */ #if VERBOSE > SHOW_ERROR_MESSAGES - do_gettimeofday(¤t_time); - DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", - current_time.tv_sec, (long)current_time.tv_usec); + ktime_get_real_ts64(¤t_ts64); + DEBUG(SHOW_TRACING, "%lld.%09ld Device wakeup triggered\n", + (s64)current_ts64.tv_sec, current_ts64.tv_nsec); - DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", - current_time.tv_sec, (long)current_time.tv_usec, + DEBUG(SHOW_TRACING, "%lld.%09ld Device register read %08x\n", + (s64)current_ts64.tv_sec, current_ts64.tv_nsec, readl(device_base + ISL38XX_CTRL_STAT_REG)); #endif reg = readl(device_base + ISL38XX_INT_IDENT_REG); if (reg == 0xabadface) { #if VERBOSE > SHOW_ERROR_MESSAGES - do_gettimeofday(¤t_time); + ktime_get_real_ts64(¤t_ts64); DEBUG(SHOW_TRACING, - "%08li.%08li Device register abadface\n", - current_time.tv_sec, (long)current_time.tv_usec); + "%lld.%09ld Device register abadface\n", + (s64)current_ts64.tv_sec, current_ts64.tv_nsec); #endif /* read the Device Status Register until Sleepmode bit is set */ while (reg = readl(device_base + ISL38XX_CTRL_STAT_REG), @@ -149,13 +150,13 @@ isl38xx_trigger_device(int asleep, void __iomem *device_base) #if VERBOSE > SHOW_ERROR_MESSAGES DEBUG(SHOW_TRACING, - "%08li.%08li Device register read %08x\n", - current_time.tv_sec, (long)current_time.tv_usec, + "%lld.%09ld Device register read %08x\n", + (s64)current_ts64.tv_sec, current_ts64.tv_nsec, readl(device_base + ISL38XX_CTRL_STAT_REG)); - do_gettimeofday(¤t_time); + ktime_get_real_ts64(¤t_ts64); DEBUG(SHOW_TRACING, - "%08li.%08li Device asleep counter %i\n", - current_time.tv_sec, (long)current_time.tv_usec, + "%lld.%09ld Device asleep counter %i\n", + (s64)current_ts64.tv_sec, current_ts64.tv_nsec, counter); #endif } @@ -168,9 +169,9 @@ isl38xx_trigger_device(int asleep, void __iomem *device_base) /* perform another read on the Device Status Register */ reg = readl(device_base + ISL38XX_CTRL_STAT_REG); - do_gettimeofday(¤t_time); - DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", - current_time.tv_sec, (long)current_time.tv_usec, reg); + ktime_get_real_ts64(¤t_ts64); + DEBUG(SHOW_TRACING, "%lld.%00ld Device register read %08x\n", + (s64)current_ts64.tv_sec, current_ts64.tv_nsec, reg); #endif } else { /* device is (still) awake */ -- 2.8.0.rc3.226.g39d4020 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the b
Re: General VHT rate-ctrl question
On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote: > If a station and it's peer can both do VHT, is there ever a good > reason to even try HT rates? > Not really; perhaps if you could do HT greenfield preamble (which VHT doesn't have) you could get something out of it, beyond that I don't see a reason to try. Unless, for some strange reason, it supports only single stream VHT and dual-stream HT or something really weird? johannes -- 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