Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.
Su Kang Yin writes: > On 11 May 2017 at 11:55, Kalle Valo wrote: >> Su Kang Yin writes: >> >>> Without this patch QCA9888 is not working. Also I have to update >>> board2.bin from Kalle's git repo. >> >> More details would be good to know, as the behaviour seems to vary quite >> a lot. What platform are you using, x86, some ARM board or what? And >> what kernel exactly? > > Kernel 4.9.25 on X86 Intel Atom > > Panic message is something like that: Thanks, this was very helpful. -- Kalle Valo
Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.
On 11 May 2017 at 11:55, Kalle Valo wrote: > Su Kang Yin writes: > >> Without this patch QCA9888 is not working. Also I have to update >> board2.bin from Kalle's git repo. > > More details would be good to know, as the behaviour seems to vary quite > a lot. What platform are you using, x86, some ARM board or what? And > what kernel exactly? Kernel 4.9.25 on X86 Intel Atom Panic message is something like that: Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core] task: 880036433a00 ti: 88003644 task.ti: 88003644 RIP: 0010:[] [] new_slab+0x39a/0x410 RSP: 0018:880036443b58 EFLAGS: 00010092 RAX: 0006 RBX: 024082c4 RCX: RDX: 0006 RSI: 88021e30dd08 RDI: 88021e30dd08 RBP: 880036443b90 R08: R09: R10: R11: 0372 R12: 88021dc01200 R13: 88021dc00cc0 R14: 88021dc01200 R15: 0001 FS: () GS:88021e30() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f3e65c1c730 CR3: 01e06000 CR4: 001406e0 Stack: 8127a4fc 0a01ff10 024082c4 88021dc01200 88021dc00cc0 88021dc01200 0001 880036443c58 81247ac6 88021e31b360 880036433a00 880036433a00 Call Trace: [] ? __d_lookup+0x9c/0x160 [] ___slab_alloc+0x396/0x4a0 [] ? ath10k_wmi_event_service_ready_work+0x5ad/0x800 [ath10k_core] [] ? alloc_kmem_pages+0x9/0x10 [] ? kmalloc_order+0x13/0x40 [] ? ath10k_wmi_event_service_ready_work+0x5ad/0x800 [ath10k_core] -- Yin
Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.
Su Kang Yin writes: > Without this patch QCA9888 is not working. Also I have to update > board2.bin from Kalle's git repo. More details would be good to know, as the behaviour seems to vary quite a lot. What platform are you using, x86, some ARM board or what? And what kernel exactly? -- Kalle Valo
Re: [PATCH] libertas: Avoid reading past end of buffer
Joe Perches writes: > unrelated trivia: > > lbs_deb_enter is used incorrectly here at > function exit as both enter and leave calls. > > That type of copy/paste defect may be common. > > $ git grep -w lbs_deb_enter | wc -l > 148 > $ git grep -w lbs_deb_leave | wc -l > 71 > > One would expect these numbers to be the same. > > Another option would be to delete all these > calls as ftrace function tracing works well. Yeah, deleting all the enter/exit calls would be better. -- Kalle Valo
Re: [PATCH] libertas: Avoid reading past end of buffer
On Wed, 2017-05-10 at 12:24 -0700, Kees Cook wrote: > Using memcpy() from a string that is shorter than the length copied means > the destination buffer is being filled with arbitrary data from the kernel > rodata segment. another bit of trivia: > diff --git a/drivers/net/wireless/marvell/libertas/mesh.c > b/drivers/net/wireless/marvell/libertas/mesh.c [] > @@ -1170,17 +1170,11 @@ int lbs_mesh_ethtool_get_sset_count(struct net_device > *dev, int sset) [] > + memcpy(s, *mesh_stat_strings, sizeof(mesh_stat_strings)); That * isn't necessary.
Re: [PATCH] libertas: Avoid reading past end of buffer
On Wed, 2017-05-10 at 12:24 -0700, Kees Cook wrote: > Using memcpy() from a string that is shorter than the length copied means [] > diff --git a/drivers/net/wireless/marvell/libertas/mesh.c > b/drivers/net/wireless/marvell/libertas/mesh.c [] > @@ -1170,17 +1170,11 @@ int lbs_mesh_ethtool_get_sset_count(struct net_device > *dev, int sset) > void lbs_mesh_ethtool_get_strings(struct net_device *dev, > uint32_t stringset, uint8_t *s) > { > - int i; > - > lbs_deb_enter(LBS_DEB_ETHTOOL); > > switch (stringset) { > case ETH_SS_STATS: > - for (i = 0; i < MESH_STATS_NUM; i++) { > - memcpy(s + i * ETH_GSTRING_LEN, > - mesh_stat_strings[i], > - ETH_GSTRING_LEN); > - } > + memcpy(s, *mesh_stat_strings, sizeof(mesh_stat_strings)); > break; > } > lbs_deb_enter(LBS_DEB_ETHTOOL); unrelated trivia: lbs_deb_enter is used incorrectly here at function exit as both enter and leave calls. That type of copy/paste defect may be common. $ git grep -w lbs_deb_enter | wc -l 148 $ git grep -w lbs_deb_leave | wc -l 71 One would expect these numbers to be the same. Another option would be to delete all these calls as ftrace function tracing works well.
[PATCH] ath10k: add configurable debugging.
This adds a few configurable debugging options: * driver debugging and tracing is now configurable per device * driver debugging and tracing is now configurable at runtime * the debugging / tracing is not run at all (besides a mask check) unless the specific debugging bitmap field is configured. Signed-off-by: Adrian Chadd --- drivers/net/wireless/ath/ath10k/core.c | 2 + drivers/net/wireless/ath/ath10k/core.h | 2 + drivers/net/wireless/ath/ath10k/debug.c | 101 drivers/net/wireless/ath/ath10k/debug.h | 44 +- 4 files changed, 125 insertions(+), 24 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index eea111d704c5..fcb068cb0248 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -2444,6 +2444,8 @@ struct ath10k *ath10k_core_create(size_t priv_size, struct device *dev, ar->hw_rev = hw_rev; ar->hif.ops = hif_ops; ar->hif.bus = bus; + ar->debug_mask = ath10k_debug_mask; + ar->trace_debug_mask = ath10k_debug_mask; switch (hw_rev) { case ATH10K_HW_QCA988X: diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index 8fc08a5043db..07e392a377d0 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -762,6 +762,8 @@ struct ath10k { struct device *dev; u8 mac_addr[ETH_ALEN]; + u32 debug_mask; + u32 trace_debug_mask; enum ath10k_hw_rev hw_rev; u16 dev_id; u32 chip_id; diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c index 389fcb7a9fd0..017360a26b40 100644 --- a/drivers/net/wireless/ath/ath10k/debug.c +++ b/drivers/net/wireless/ath/ath10k/debug.c @@ -2418,6 +2418,79 @@ int ath10k_debug_create(struct ath10k *ar) return 0; } +#ifdef CONFIG_ATH10K_DEBUGFS +static ssize_t ath10k_write_debug_mask(struct file *file, + const char __user *ubuf, + size_t count, loff_t *ppos) +{ + struct ath10k *ar = file->private_data; + int ret; + u32 val; + +if (kstrtou32_from_user(ubuf, count, 0, &val)) +return -EINVAL; + + ar->debug_mask = val; + ret = count; + + return ret; +} + +static ssize_t ath10k_read_debug_mask(struct file *file, char __user *ubuf, + size_t count, loff_t *ppos) +{ + char buf[32]; + struct ath10k *ar = file->private_data; + int len = 0; + + len = scnprintf(buf, sizeof(buf) - len, "0x%x\n", ar->debug_mask); + return simple_read_from_buffer(ubuf, count, ppos, buf, len); +} + +static const struct file_operations fops_debug_mask = { + .read = ath10k_read_debug_mask, + .write = ath10k_write_debug_mask, + .open = simple_open +}; + +static ssize_t ath10k_write_trace_debug_mask(struct file *file, +const char __user *ubuf, +size_t count, loff_t *ppos) +{ + struct ath10k *ar = file->private_data; + int ret; + u32 val; + +if (kstrtou32_from_user(ubuf, count, 0, &val)) +return -EINVAL; + + ar->trace_debug_mask = val; + ret = count; + + return ret; +} + +static ssize_t ath10k_read_trace_debug_mask(struct file *file, + char __user *ubuf, + size_t count, loff_t *ppos) +{ + char buf[32]; + struct ath10k *ar = file->private_data; + int len = 0; + + len = scnprintf(buf, sizeof(buf) - len, "0x%x\n", + ar->trace_debug_mask); + return simple_read_from_buffer(ubuf, count, ppos, buf, len); +} + +static const struct file_operations fops_trace_debug_mask = { + .read = ath10k_read_trace_debug_mask, + .write = ath10k_write_trace_debug_mask, + .open = simple_open +}; +#endif /* CONFIG_ATH10K_DEBUGFS */ + + void ath10k_debug_destroy(struct ath10k *ar) { vfree(ar->debug.fw_crash_data); @@ -2448,6 +2521,13 @@ int ath10k_debug_register(struct ath10k *ar) init_completion(&ar->debug.tpc_complete); init_completion(&ar->debug.fw_stats_complete); +#ifdef CONFIG_ATH10K_DEBUG + debugfs_create_file("debug", S_IRUSR, ar->debug.debugfs_phy, ar, + &fops_debug_mask); + debugfs_create_file("trace_debug", S_IRUSR, ar->debug.debugfs_phy, ar, + &fops_trace_debug_mask); +#endif + debugfs_create_file("fw_stats", 0400, ar->debug.debugfs_phy, ar, &fops_fw_stats); @@ -2536,7 +2616,7 @@ void ath10k_debug_unregister(struct ath10k *ar) #endif /* CONFIG_ATH10K_DEBUGFS */ #ifdef CONFIG_ATH10K_DEBUG -void ath10k_dbg(struct
pull-request: iwlwifi firmwares update 2017-05-10
Hi Kyle, The last time we pushed new -22 firmwares, we forgot to update the relevant version for 3168 devices. This pull-request contains only this update. Please pull or let me know if there are any issues. Cheers, Luca. The following changes since commit ade8332383e228cbdcfc605b5e5ef3aa51211401: Merge branch 'master' of git://git.marvell.com/mwifiex-firmware (2017-04-22 11:25:59 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2017-05-10 for you to fetch changes up to ca89d62df8fbeb0b8131437dfd5b8098c85f8164: iwlwifi: update -22 firmware for 3168 (2017-05-10 23:43:18 +0300) Update firmware for 3168 * update -22 firmware binaries for iwlwifi device 3168 Emmanuel Grumbach (1): iwlwifi: update -22 firmware for 3168 WHENCE| 2 +- iwlwifi-3168-22.ucode | Bin 1028032 -> 1028092 bytes 2 files changed, 1 insertion(+), 1 deletion(-)
[PATCH] libertas: Avoid reading past end of buffer
Using memcpy() from a string that is shorter than the length copied means the destination buffer is being filled with arbitrary data from the kernel rodata segment. Instead, redefine the stat strings to be ETH_GSTRING_LEN sizes, like other drivers. This lets us use a single memcpy that does not leak rodata contents. Additionally adjust indentation to keep checkpatch.pl happy. This was found with the future CONFIG_FORTIFY_SOURCE feature. Cc: Daniel Micay Signed-off-by: Kees Cook --- v2: use ETH_GSTRING_LEN; joe --- drivers/net/wireless/marvell/libertas/mesh.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/drivers/net/wireless/marvell/libertas/mesh.c b/drivers/net/wireless/marvell/libertas/mesh.c index d0c881dd5846..6076c83ce5ab 100644 --- a/drivers/net/wireless/marvell/libertas/mesh.c +++ b/drivers/net/wireless/marvell/libertas/mesh.c @@ -1108,15 +1108,15 @@ void lbs_mesh_set_txpd(struct lbs_private *priv, * Ethtool related */ -static const char * const mesh_stat_strings[] = { - "drop_duplicate_bcast", - "drop_ttl_zero", - "drop_no_fwd_route", - "drop_no_buffers", - "fwded_unicast_cnt", - "fwded_bcast_cnt", - "drop_blind_table", - "tx_failed_cnt" +static const char mesh_stat_strings[MESH_STATS_NUM][ETH_GSTRING_LEN] = { + "drop_duplicate_bcast", + "drop_ttl_zero", + "drop_no_fwd_route", + "drop_no_buffers", + "fwded_unicast_cnt", + "fwded_bcast_cnt", + "drop_blind_table", + "tx_failed_cnt" }; void lbs_mesh_ethtool_get_stats(struct net_device *dev, @@ -1170,17 +1170,11 @@ int lbs_mesh_ethtool_get_sset_count(struct net_device *dev, int sset) void lbs_mesh_ethtool_get_strings(struct net_device *dev, uint32_t stringset, uint8_t *s) { - int i; - lbs_deb_enter(LBS_DEB_ETHTOOL); switch (stringset) { case ETH_SS_STATS: - for (i = 0; i < MESH_STATS_NUM; i++) { - memcpy(s + i * ETH_GSTRING_LEN, - mesh_stat_strings[i], - ETH_GSTRING_LEN); - } + memcpy(s, *mesh_stat_strings, sizeof(mesh_stat_strings)); break; } lbs_deb_enter(LBS_DEB_ETHTOOL); -- 2.7.4 -- Kees Cook Pixel Security
Re: [PATCH] libertas: Avoid reading past end of buffer
On Tue, May 9, 2017 at 9:33 PM, Joe Perches wrote: > On Tue, 2017-05-09 at 16:23 -0700, Kees Cook wrote: >> Using memcpy() from a string that is shorter than the length copied means >> the destination buffer is being filled with arbitrary data from the kernel >> rodata segment. Instead, use strncpy() which will fill the trailing bytes >> with zeros. Additionally adjust indentation to keep checkpatch.pl happy. >> >> This was found with the future CONFIG_FORTIFY_SOURCE feature. > [] >> diff --git a/drivers/net/wireless/marvell/libertas/mesh.c >> b/drivers/net/wireless/marvell/libertas/mesh.c > [] >> @@ -1177,9 +1177,9 @@ void lbs_mesh_ethtool_get_strings(struct net_device >> *dev, >> switch (stringset) { >> case ETH_SS_STATS: >> for (i = 0; i < MESH_STATS_NUM; i++) { >> - memcpy(s + i * ETH_GSTRING_LEN, >> - mesh_stat_strings[i], >> - ETH_GSTRING_LEN); >> + strncpy(s + i * ETH_GSTRING_LEN, >> + mesh_stat_strings[i], >> + ETH_GSTRING_LEN); >> } > > The better solution is to declare > mesh_stat_strings in in the normal way > > --- > drivers/net/wireless/marvell/libertas/mesh.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/drivers/net/wireless/marvell/libertas/mesh.c > b/drivers/net/wireless/marvell/libertas/mesh.c > index d0c881dd5846..a535e7f48d2d 100644 > --- a/drivers/net/wireless/marvell/libertas/mesh.c > +++ b/drivers/net/wireless/marvell/libertas/mesh.c > @@ -1108,15 +1108,15 @@ void lbs_mesh_set_txpd(struct lbs_private *priv, > * Ethtool related > */ > > -static const char * const mesh_stat_strings[] = { > - "drop_duplicate_bcast", > - "drop_ttl_zero", > - "drop_no_fwd_route", > - "drop_no_buffers", > - "fwded_unicast_cnt", > - "fwded_bcast_cnt", > - "drop_blind_table", > - "tx_failed_cnt" > +static const char mesh_stat_strings[][ETH_GSTRING_LEN] = { > + "drop_duplicate_bcast", > + "drop_ttl_zero", > + "drop_no_fwd_route", > + "drop_no_buffers", > + "fwded_unicast_cnt", > + "fwded_bcast_cnt", > + "drop_blind_table", > + "tx_failed_cnt", > }; > > void lbs_mesh_ethtool_get_stats(struct net_device *dev, Ah yeah! And that simplifies the memcpy too, since it can just do it in one go. New patch on the way... -Kees -- Kees Cook Pixel Security
Re: [PATCH] wcn36xx: Close SMD channel on device removal
On Wed 10 May 00:27 PDT 2017, Arend van Spriel wrote: > On 5/10/2017 1:03 AM, Bjorn Andersson wrote: > > On Mon 08 May 23:17 PDT 2017, Kalle Valo wrote: > > > > > Bjorn Andersson writes: > > > > > > > The SMD channel is not the primary WCNSS channel and must explicitly be > > > > closed as the device is removed, or the channel will already by open on > > > > a subsequent probe call in e.g. the case of reloading the kernel module. > > > > > > > > This issue was introduced because I simplified the underlying SMD > > > > implementation while the SMD adaptions of the driver sat on the mailing > > > > list, but missed to update these patches. The patch does however only > > > > apply back to the transition to rpmsg, hence the limited Fixes. > > > > > > > > Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from > > > > smd to rpmsg") > > > > Reported-by: Eyal Ilsar > > > > Signed-off-by: Bjorn Andersson > > > > > > As this is a regression I'll queue this to 4.12. > > > > > > > Thanks. > > > > > But if this is an older bug (didn't quite understand your description > > > though) should there be a separate patch for stable releases? > > > > > > > AFAICT this never worked, as it seems I did the rework in SMD while we > > tried to figure out the dependency issues we had with moving to SMD. So > > v4.9 through v4.11 has SMD support - with this bug. > > > > How do I proceed, do you want me to write up a fix for stable@? Do I > > send that out as an ordinary patch? > > If the patch applies cleanly on branches linux-4.9.y through linux-4.11.y in > the stable repository you can go for '--- Option 1 ---' as described in > /Documentation/stable_kernel_rules.txt. > It does not, before v4.12 it's a completely different function to call to close the channel. But "Option 3" describes the situation, thanks for the reference. I'll try to find the time to verify the patch on v4.11 and send it to stable@. Regards, Bjorn
Re: [PATCH] ath10k: add configurable debugging.
grr, no. lemme go re-add that and resubmit. thanks! -a On 10 May 2017 at 09:44, Steve deRosier wrote: > Hi Adrian, > > On Wed, May 10, 2017 at 9:25 AM, Adrian Chadd wrote: > >> diff --git a/drivers/net/wireless/ath/ath10k/debug.h >> b/drivers/net/wireless/ath/ath10k/debug.h >> index 257d10985c6e..7bd461927029 100644 >> --- a/drivers/net/wireless/ath/ath10k/debug.h >> +++ b/drivers/net/wireless/ath/ath10k/debug.h >> @@ -200,27 +200,43 @@ void ath10k_sta_update_rx_duration(struct ath10k *ar, >> #endif /* CONFIG_MAC80211_DEBUGFS */ >> >> #ifdef CONFIG_ATH10K_DEBUG >> -__printf(3, 4) void ath10k_dbg(struct ath10k *ar, >> +static inline int >> +_ath10k_do_dbg(struct ath10k *ar, enum ath10k_debug_mask mask) >> +{ >> + if (ar->trace_debug_mask & mask) >> + return (1); >> + if (ar->debug_mask & mask) >> + return (1); >> + return (0); >> +} >> + >> +void _ath10k_dbg(struct ath10k *ar, >>enum ath10k_debug_mask mask, >>const char *fmt, ...); >> -void ath10k_dbg_dump(struct ath10k *ar, >> + >> +void _ath10k_dbg_dump(struct ath10k *ar, >> enum ath10k_debug_mask mask, >> const char *msg, const char *prefix, >> const void *buf, size_t len); >> + >> +#defineath10k_dbg(ar, mask, ...) >>\ >> + do {\ >> + if (_ath10k_do_dbg(ar, mask)) { \ >> + _ath10k_dbg((ar), (mask), __VA_ARGS__); \ >> + }; \ >> + } while (0) >> + > > Looks to me you dropped the "__printf(3, 4)" safety check. Was that > intentional? > > Thanks, > - Steve
Re: [PATCH] ath10k: add configurable debugging.
Hi Adrian, On Wed, May 10, 2017 at 9:25 AM, Adrian Chadd wrote: > diff --git a/drivers/net/wireless/ath/ath10k/debug.h > b/drivers/net/wireless/ath/ath10k/debug.h > index 257d10985c6e..7bd461927029 100644 > --- a/drivers/net/wireless/ath/ath10k/debug.h > +++ b/drivers/net/wireless/ath/ath10k/debug.h > @@ -200,27 +200,43 @@ void ath10k_sta_update_rx_duration(struct ath10k *ar, > #endif /* CONFIG_MAC80211_DEBUGFS */ > > #ifdef CONFIG_ATH10K_DEBUG > -__printf(3, 4) void ath10k_dbg(struct ath10k *ar, > +static inline int > +_ath10k_do_dbg(struct ath10k *ar, enum ath10k_debug_mask mask) > +{ > + if (ar->trace_debug_mask & mask) > + return (1); > + if (ar->debug_mask & mask) > + return (1); > + return (0); > +} > + > +void _ath10k_dbg(struct ath10k *ar, >enum ath10k_debug_mask mask, >const char *fmt, ...); > -void ath10k_dbg_dump(struct ath10k *ar, > + > +void _ath10k_dbg_dump(struct ath10k *ar, > enum ath10k_debug_mask mask, > const char *msg, const char *prefix, > const void *buf, size_t len); > + > +#defineath10k_dbg(ar, mask, ...) > \ > + do {\ > + if (_ath10k_do_dbg(ar, mask)) { \ > + _ath10k_dbg((ar), (mask), __VA_ARGS__); \ > + }; \ > + } while (0) > + Looks to me you dropped the "__printf(3, 4)" safety check. Was that intentional? Thanks, - Steve
[PATCH] ath10k: add configurable debugging.
This adds a few configurable debugging options: * driver debugging and tracing is now configurable per device * driver debugging and tracing is now configurable at runtime * the debugging / tracing is not run at all (besides a mask check) unless the specific debugging bitmap field is configured. Signed-off-by: Adrian Chadd --- drivers/net/wireless/ath/ath10k/core.c | 2 + drivers/net/wireless/ath/ath10k/core.h | 2 + drivers/net/wireless/ath/ath10k/debug.c | 101 drivers/net/wireless/ath/ath10k/debug.h | 44 +- 4 files changed, 125 insertions(+), 24 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index eea111d704c5..fcb068cb0248 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -2444,6 +2444,8 @@ struct ath10k *ath10k_core_create(size_t priv_size, struct device *dev, ar->hw_rev = hw_rev; ar->hif.ops = hif_ops; ar->hif.bus = bus; + ar->debug_mask = ath10k_debug_mask; + ar->trace_debug_mask = ath10k_debug_mask; switch (hw_rev) { case ATH10K_HW_QCA988X: diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index 8fc08a5043db..07e392a377d0 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -762,6 +762,8 @@ struct ath10k { struct device *dev; u8 mac_addr[ETH_ALEN]; + u32 debug_mask; + u32 trace_debug_mask; enum ath10k_hw_rev hw_rev; u16 dev_id; u32 chip_id; diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c index 389fcb7a9fd0..017360a26b40 100644 --- a/drivers/net/wireless/ath/ath10k/debug.c +++ b/drivers/net/wireless/ath/ath10k/debug.c @@ -2418,6 +2418,79 @@ int ath10k_debug_create(struct ath10k *ar) return 0; } +#ifdef CONFIG_ATH10K_DEBUGFS +static ssize_t ath10k_write_debug_mask(struct file *file, + const char __user *ubuf, + size_t count, loff_t *ppos) +{ + struct ath10k *ar = file->private_data; + int ret; + u32 val; + +if (kstrtou32_from_user(ubuf, count, 0, &val)) +return -EINVAL; + + ar->debug_mask = val; + ret = count; + + return ret; +} + +static ssize_t ath10k_read_debug_mask(struct file *file, char __user *ubuf, + size_t count, loff_t *ppos) +{ + char buf[32]; + struct ath10k *ar = file->private_data; + int len = 0; + + len = scnprintf(buf, sizeof(buf) - len, "0x%x\n", ar->debug_mask); + return simple_read_from_buffer(ubuf, count, ppos, buf, len); +} + +static const struct file_operations fops_debug_mask = { + .read = ath10k_read_debug_mask, + .write = ath10k_write_debug_mask, + .open = simple_open +}; + +static ssize_t ath10k_write_trace_debug_mask(struct file *file, +const char __user *ubuf, +size_t count, loff_t *ppos) +{ + struct ath10k *ar = file->private_data; + int ret; + u32 val; + +if (kstrtou32_from_user(ubuf, count, 0, &val)) +return -EINVAL; + + ar->trace_debug_mask = val; + ret = count; + + return ret; +} + +static ssize_t ath10k_read_trace_debug_mask(struct file *file, + char __user *ubuf, + size_t count, loff_t *ppos) +{ + char buf[32]; + struct ath10k *ar = file->private_data; + int len = 0; + + len = scnprintf(buf, sizeof(buf) - len, "0x%x\n", + ar->trace_debug_mask); + return simple_read_from_buffer(ubuf, count, ppos, buf, len); +} + +static const struct file_operations fops_trace_debug_mask = { + .read = ath10k_read_trace_debug_mask, + .write = ath10k_write_trace_debug_mask, + .open = simple_open +}; +#endif /* CONFIG_ATH10K_DEBUGFS */ + + void ath10k_debug_destroy(struct ath10k *ar) { vfree(ar->debug.fw_crash_data); @@ -2448,6 +2521,13 @@ int ath10k_debug_register(struct ath10k *ar) init_completion(&ar->debug.tpc_complete); init_completion(&ar->debug.fw_stats_complete); +#ifdef CONFIG_ATH10K_DEBUG + debugfs_create_file("debug", S_IRUSR, ar->debug.debugfs_phy, ar, + &fops_debug_mask); + debugfs_create_file("trace_debug", S_IRUSR, ar->debug.debugfs_phy, ar, + &fops_trace_debug_mask); +#endif + debugfs_create_file("fw_stats", 0400, ar->debug.debugfs_phy, ar, &fops_fw_stats); @@ -2536,7 +2616,7 @@ void ath10k_debug_unregister(struct ath10k *ar) #endif /* CONFIG_ATH10K_DEBUGFS */ #ifdef CONFIG_ATH10K_DEBUG -void ath10k_dbg(struct
Re: [v2,1/3] ath9k: Support channels in licensed bands
On 05/10/2017 03:30 AM, Tom Psyborg wrote: On 9 May 2017 at 19:50, Adrian Chadd mailto:adr...@freebsd.org>> wrote: (Note note: some of those channels have non-megahertz boundaries, which means ... yeah, hello inter-operability boundaries. Hilarious.) -adrian From what I can tell, it seems like as long as your both points are configured with identical settings, you can use any channel/frequency/bandwidth combination that hardware supports. Possibly even 802.11ac at 2.4 GHz if we got more than 100MHz of bandwidth from 2.4 to 2.5 GHz. The solution i've made myself doesn't include all available channels but can serve as an example: https://forum.openwrt.org/viewtopic.php?pid=353870#p353870 primary/sec HT channel option should also be further extended. Cheers, Tom I've successfully used 802.11ac VHT-40 on 2.4Ghz band with ath10k...it just requires a few small changes in the mac80211 stack to allow it to be configuredjust FYI. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: Cubieboard2 + hostapd + 100 wireless devices
Dnia środa, 10 maja 2017 11:31:17 CEST Stanislaw Gruszka pisze: > On Sun, May 07, 2017 at 02:19:25PM +0200, Marek Floriańczyk wrote: > > > If RT5370 works for you I would stick with it. RTxxx chips with rt2800 > driver are capable to support up to 190 stations with HW encryption and > 11n aggregation (something that you are not interested). Theoretically > more stations can be added and those should fallback to software > encryption and frame aggregation will not be done, but I'm not sure if > anyone test that. > > I'm also not sure if many people test 11b, perhaps 11g would be better > choice. BTW, what kernel version are you using (I'm curious if 11b > still works on latest kernels) ? > > Stanislaw Hi, Thanks for answer. I'm using Linux cubieboard2 4.9.12-sunxi This is Armbian based on Debian Jessie I'm using "b" mode on hostapd because our modules: http://www.electrodragon.com/product/esp-12f-esp8266-wifi-board/ have +20dBm when in "b" mode - that's what docs say. I still have problems when 80 devices are connected, after a few minutes some of them (10-20) deauthenticate with AP. When reporting from hostapd_cli, sta changes from: flags=[AUTH][ASSOC][AUTHORIZED][SHORT_PREAMBLE][WMM] aid=69 capability=0x31 listen_interval=100 supported_rates=8b 96 82 84 0c 18 30 60 6c 12 24 48 timeout_next=NULLFUNC POLL dot11RSNAStatsSTAAddress=5c:cf:7f:ff:eb:ee dot11RSNAStatsVersion=1 dot11RSNAStatsSelectedPairwiseCipher=00-50-f2-2 dot11RSNAStatsTKIPLocalMICFailures=0 dot11RSNAStatsTKIPRemoteMICFailures=0 hostapdWPAPTKState=11 hostapdWPAPTKGroupState=0 rx_packets=18 tx_packets=17 rx_bytes=3295 tx_bytes=3490 inactive_msec=134370 connected_time=832 To: flags=[AUTH] aid=0 capability=0x0 listen_interval=0 supported_rates= timeout_next=NULLFUNC POLL rx_packets=2 tx_packets=2 rx_bytes=48 tx_bytes=143 inactive_msec=1980 When I have only 20some devices it works always, but with more devices something goes wrong I'm running hostapd in debug mode now, and I have found station: 2c:3a:e8:00:33:e0 That deauthenticate with AP, but I don't know why, reason_code=3 "station is leaving (or has left) IBSS or ESS" Any help would be appreciated ;) Best Regards Marek 1494425876.349802: nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlan2 1494425876.349952: nl80211: RX frame da=7c:dd:90:84:79:cc sa=2c:3a:e8:00:33:e0 bssid=7c:dd:90:84:79:cc freq=2437 ssi_signal=-43 fc=0xc0 seq_ctrl=0x450 stype=12 (WLAN_FC_STYPE_DEAUTH) len=26 1494425876.350132: wlan2: Event RX_MGMT (19) received 1494425876.350254: wlan2: mgmt::deauth 1494425876.350382: wlan2: deauthentication: STA=2c:3a:e8:00:33:e0 reason_code=3 1494425876.350518: 1494425876.350526: wlan2: STA 2c:3a:e8:00:33:e0 IEEE 802.11: deauthenticated 1494425876.350683: 1494425876.350691: wlan2: STA 2c:3a:e8:00:33:e0 MLME: MLME-DEAUTHENTICATE.indication(2c:3a:e8:00:33:e0, 3) 1494425876.350845: 1494425876.350853: wlan2: STA 2c:3a:e8:00:33:e0 MLME: MLME-DELETEKEYS.request(2c:3a:e8:00:33:e0) 1494425876.351468: nl80211: sta_remove -> DEL_STATION wlan2 2c:3a:e8:00:33:e0 --> 0 (Success) 1494425876.351681: ap_free_sta: cancel ap_handle_timer for 2c:3a:e8:00:33:e0 1494425876.351978: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan2 1494425876.352135: nl80211: Delete station 2c:3a:e8:00:33:e0 1494425876.352441: nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlan2 1494425876.352599: nl80211: RX frame da=7c:dd:90:84:79:cc sa=2c:3a:e8:00:33:e0 bssid=7c:dd:90:84:79:cc freq=2437 ssi_signal=-41 fc=0xb0 seq_ctrl=0x460 stype=11 (WLAN_FC_STYPE_AUTH) len=30 1494425876.352783: wlan2: Event RX_MGMT (19) received 1494425876.352900: mgmt::auth 1494425876.353251: authentication: STA=2c:3a:e8:00:33:e0 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x460 1494425876.353425: New STA 1494425876.354104: ap_sta_add: register ap_handle_timer timeout for 2c:3a:e8:00:33:e0 (300 seconds - ap_max_inactivity) 1494425876.354721: nl80211: sta_remove -> DEL_STATION wlan2 2c:3a:e8:00:33:e0 --> -2 (No such file or directory) 1494425876.354943: nl80211: Add STA 2c:3a:e8:00:33:e0 1494425876.355185: * supported rates - hexdump(len=0): [NULL] 1494425876.355346: * capability=0x0 1494425876.355458: * aid=1 (UNASSOC_STA workaround) 1494425876.355675: * listen_interval=0 1494425876.355810: * flags set=0x0 mask=0xa0 1494425876.356195: 1494425876.356205: wlan2: STA 2c:3a:e8:00:33:e0 IEEE 802.11: authentication OK (open system) 1494425876.356594: 1494425876.356604: wlan2: STA 2c:3a:e8:00:33:e0 MLME: MLME-AUTHENTICATE.indication(2c:3a:e8:00:33:e0, OPEN_SYSTEM) 1494425876.356958: 1494425876.356966: wlan2: STA 2c:3a:e8:00:33:e0 MLME: MLME-DELETEKEYS.request(2c:3a:e8:00:33:e0) 1494425876.357128: authentication reply: STA=2c:3a:e8:00:33:e0 auth_alg=0 auth_transaction=2 resp=0 (IE len=0) 1494425876.357266: nl80211: send_mlme - da= 2c:3a:e8:00:33:e0 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3 1494425876.357400: nl80211: send_mlme -> send_frame 1
Re: [PATCH] mac80211: Validate michael MIC before attempting packet decode.
On Tue, May 09, 2017 at 02:16:31PM -0400, Michael Skeffington wrote: > In order to allow wpa_supplicant to correctly identify a perceived WPA TKIP > key > recovery attack the michael MIC must be checked before the packet decode is > attempted. A packet with an invalid MIC will always fail a decrypt check > which > previously was being checked first. Therefore the MIC failure bit of > status flags > describing the error would remain unset. Which driver and WLAN hardware are you using? Michael MIC is encrypted, so to be able to check that, the frame will obviously need to be decrypted first. If that WEP decryption fails, this frame needs to be dropped without indicating Michael MIC failure. WEP part here is completely independent of Michael MIC. It is possible that there is a driver that handles these steps in hardware/firmware and if so, that driver may have a bug if you do not see Michael MIC failures reported correctly. Anyway, as Johannes pointed out, this part in mac80211 is in the correct sequence and that cannot be changed since it would completely break TKIP for more or less all software-based cases. -- Jouni MalinenPGP id EFC895FA
Re: [PATCH] mac80211: Validate michael MIC before attempting packet decode.
On Tue, 2017-05-09 at 14:16 -0400, Michael Skeffington wrote: > In order to allow wpa_supplicant to correctly identify a perceived > WPA TKIP key > recovery attack the michael MIC must be checked before the packet > decode is > attempted. A packet with an invalid MIC will always fail a decrypt > check which > previously was being checked first. Therefore the MIC failure bit of > status flags > describing the error would remain unset. This isn't how the Michael MIC works. I have no idea what problem you're trying to solve, but this is not the solution. johannes
Re: Cubieboard2 + hostapd + 100 wireless devices
On Sun, May 07, 2017 at 02:19:25PM +0200, Marek Floriańczyk wrote: > Hello all, > > I need to set up such a configuration: > Cubieboard2 with Debian Jessie, Hostapd 2.6 as an AP, usb wifi dongle + 100 > devices with NodeMCU module: > http://www.electrodragon.com/product/esp-12f-esp8266-wifi-board/ > > I'm using usb wifi dongle based on Ralink RT5370 Wireless Adapter, > after I have switched hostapd network mode to "b" it works quite well (tested > with 70 devices). Only text commands are going to be send from server to > devices, so I don't need high speed, I need reliability. > > Has someone any experience with such a setup ? > Would one recommend different wifi dongle (maybe more powerful), with > different > chipset? If RT5370 works for you I would stick with it. RTxxx chips with rt2800 driver are capable to support up to 190 stations with HW encryption and 11n aggregation (something that you are not interested). Theoretically more stations can be added and those should fallback to software encryption and frame aggregation will not be done, but I'm not sure if anyone test that. I'm also not sure if many people test 11b, perhaps 11g would be better choice. BTW, what kernel version are you using (I'm curious if 11b still works on latest kernels) ? Stanislaw
[PATCH] ath9k: check ah->curchan when updating tx power
When driver fail to reset card ah->curchan value stay NULL. When later driver try to update tx power it oops by using ah->curchan (calltrace is shown below). This problem were reported at various places and for some it was fixed by making ath9k_hw_chip_reset() do not fail. I have this bug report on some oldish RHEL kernel with AR9285, however it's hard to debug where reset fail when kernel OOPS, so I think this patch should be applied. Hopefully ah->curchan is not used unconditionally on other places until is initialized on ath9k_config(). ath: phy0: Chip reset failed ath: phy0: Unable to reset hardware; reset status -22 (freq 2412 MHz) BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] ath9k_hw_set_txpowerlimit+0x25/0x80 [ath9k_hw] Oops: [#1] SMP Call Trace: [] ? ath9k_cmn_update_txpow+0x1a/0x30 [ath9k_common] [] ? ath_complete_reset+0x4e/0x130 [ath9k] [] ? ath9k_start+0x127/0x1e0 [ath9k] [] ? ieee80211_do_open+0x30f/0x910 [mac80211] [] ? dev_open+0x8d/0xf0 Signed-off-by: Stanislaw Gruszka --- drivers/net/wireless/ath/ath9k/common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c index c67d0e0..099f3d4 100644 --- a/drivers/net/wireless/ath/ath9k/common.c +++ b/drivers/net/wireless/ath/ath9k/common.c @@ -369,7 +369,7 @@ void ath9k_cmn_update_txpow(struct ath_hw *ah, u16 cur_txpow, { struct ath_regulatory *reg = ath9k_hw_regulatory(ah); - if (reg->power_limit != new_txpow) + if (ah->curchan && reg->power_limit != new_txpow) ath9k_hw_set_txpowerlimit(ah, new_txpow, false); /* read back in case value is clamped */ -- 1.7.1
Re: [PATCH] wcn36xx: Close SMD channel on device removal
On 5/10/2017 1:03 AM, Bjorn Andersson wrote: On Mon 08 May 23:17 PDT 2017, Kalle Valo wrote: Bjorn Andersson writes: The SMD channel is not the primary WCNSS channel and must explicitly be closed as the device is removed, or the channel will already by open on a subsequent probe call in e.g. the case of reloading the kernel module. This issue was introduced because I simplified the underlying SMD implementation while the SMD adaptions of the driver sat on the mailing list, but missed to update these patches. The patch does however only apply back to the transition to rpmsg, hence the limited Fixes. Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Reported-by: Eyal Ilsar Signed-off-by: Bjorn Andersson As this is a regression I'll queue this to 4.12. Thanks. But if this is an older bug (didn't quite understand your description though) should there be a separate patch for stable releases? AFAICT this never worked, as it seems I did the rework in SMD while we tried to figure out the dependency issues we had with moving to SMD. So v4.9 through v4.11 has SMD support - with this bug. How do I proceed, do you want me to write up a fix for stable@? Do I send that out as an ordinary patch? If the patch applies cleanly on branches linux-4.9.y through linux-4.11.y in the stable repository you can go for '--- Option 1 ---' as described in /Documentation/stable_kernel_rules.txt. Regards, Arend