Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"
Sorry to pick up this thread again, it looks this issue still existed in the newer 4.3 kernel. (The EAP frames can not be received by wireless interface due to the bridge interface, http://marc.info/?l=linux-wireless&m=136743495526905&w=2) Wonder is anyone know some update for this issue? Currently the only workaround is make the 4-address AP and STA associated in security mode firstly and then create the bridge, the renew key configuration also need be disable at the hostapd side to avoid renew the key at bridge status. Thanks Yanbo > On Wed, May 1, 2013 at 5:53 PM, Felix Fietkau wrote: > > > > On 2013-05-02 12:49 AM, Stephen Hemminger wrote: > > > On Wed, 01 May 2013 23:06:16 +0200 > > > Felix Fietkau wrote: > > > > > >> On 2013-05-01 10:21 PM, Stephen Hemminger wrote: > > >> > What about using AF_PACKET bound to underlying wireless device and the > > >> > packet type. You can even use BPF to filter. > > >> As far as I know, AF_PACKET only works when not binding it to the packet > > >> type (otherwise it get stolen by the rx handler). > > > > > > You can do AF_PACKET and it gets handle before rx_handler. > > If I don't bind it to a protocol, it ends up in ptype_all, if I do, it > > ends up in &ptype_base. ptype_all is processed before the rx_handler, > > ptype_base is processed after the rx handler. > > Hooking into ptype_all wastes tons of CPU cycles, hooking into > > ptype_base does not solve the problem. > > > > - Felix > > -- > > 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: iw set txpower error
On Thu, Dec 3, 2015 at 11:57 AM, Emmanuel Grumbach wrote: > On Thu, Dec 3, 2015 at 8:10 PM, Kobi Cohen-Arazi > wrote: >> Hi all, >> >> I’m trying to change txpower with iw. Using AR9580 HW + ath9k driver >> with Kernel 4.1.6. >> >> The call fails in mac80211 with the following error: "Failed >> check-sdata-in-driver check, flags: 0x0". >> stack: >> - start stack > > Try that one: > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/jberg/mac80211/+/5ad11b50fda1306b5317124f97f0a7a4c022b022 Works perfect. thanks! Kobi -- 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: Can we increase IEEE80211_MAX_QUEUES
On 12/03/2015 12:21 PM, Johannes Berg wrote: On Thu, 2015-12-03 at 12:16 -0800, Ben Greear wrote: ath10k wants to use vdev-id as a queue-id, and I want to support up to 64 vdevs. In the 4.2 kernel, this is causing splats when using lots of vdevs because then queue is out of range. Can we just increase IEEE80211_MAX_QUEUES to 64? I think not, that would likely cause a lot of data structures to grow too much. We'd have to do more dynamic things in that case, I suppose. Does the original premise even make sense though? A single queue for each vdev seems a bit strange. Comments in ath10k claim that the approach makes per-vif tx locking much easier and that is why that code was added 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
[RFC] mac80211: Support 65 tx-queues.
From: Ben Greear
ath10k wants to use one tx-queue per vdev, and I want to support
up to 64 vdevs. One additional q is needed for off-channel work.
So, re-work mac80211 to allow 65 tx queues. This should have small
run-time effect, but it will cause a fair bit more RAM usage in
certain structs.
Signed-off-by: Ben Greear
---
include/net/mac80211.h | 8 +++--
net/mac80211/driver-ops.h | 13 ++--
net/mac80211/ieee80211_i.h | 9 --
net/mac80211/tx.c | 9 --
net/mac80211/util.c| 77 +-
5 files changed, 83 insertions(+), 33 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 970372d..01e31bb 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -123,13 +123,15 @@ struct device;
* enum ieee80211_max_queues - maximum number of queues
*
* @IEEE80211_MAX_QUEUES: Maximum number of regular device queues.
- * @IEEE80211_MAX_QUEUE_MAP: bitmap with maximum queues set
*/
enum ieee80211_max_queues {
- IEEE80211_MAX_QUEUES = 16,
- IEEE80211_MAX_QUEUE_MAP = BIT(IEEE80211_MAX_QUEUES) - 1,
+ IEEE80211_MAX_QUEUES = 65,
};
+/* bitmap with maximum queues set */
+#define IEEE80211_MAX_QUEUE_MAP_CNT 3
+extern unsigned long IEEE80211_MAX_QUEUE_MAP[IEEE80211_MAX_QUEUE_MAP_CNT];
+
#define IEEE80211_INVAL_HW_QUEUE 0xff
/**
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 46342c1..da976e3 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -789,7 +789,7 @@ static inline void drv_rfkill_poll(struct ieee80211_local
*local)
static inline void drv_flush(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
-u32 queues, bool drop)
+unsigned long *queues, bool drop)
{
struct ieee80211_vif *vif = sdata ? &sdata->vif : NULL;
@@ -798,9 +798,16 @@ static inline void drv_flush(struct ieee80211_local *local,
if (sdata && !check_sdata_in_driver(sdata))
return;
- trace_drv_flush(local, queues, drop);
+ trace_drv_flush(local, queues[0], drop);
+ /* NOTE: Only ath10k might want more queues than fits in 32-bits,
+* and currently it pays no attention to the queues argument. So,
+* just passing first value here is safe. If other drivers ever
+* do need to see the array, then can create a flushA member
+* and use it if it exists, falling back to old flush() for
+* other drivers.
+*/
if (local->ops->flush)
- local->ops->flush(&local->hw, vif, queues, drop);
+ local->ops->flush(&local->hw, vif, queues[0], drop);
trace_drv_return_void(local);
}
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 132ee14..fb8fd85 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1910,9 +1910,12 @@ void ieee80211_sta_tx_notify(struct
ieee80211_sub_if_data *sdata,
struct ieee80211_hdr *hdr, bool ack, u16 tx_time);
void ieee80211_wake_queues_by_reason(struct ieee80211_hw *hw,
-unsigned long queues,
+unsigned long *queues,
enum queue_stop_reason reason,
bool refcounted);
+void ieee80211_get_vif_queues(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ unsigned long *queues);
void ieee80211_stop_vif_queues(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
enum queue_stop_reason reason);
@@ -1920,7 +1923,7 @@ void ieee80211_wake_vif_queues(struct ieee80211_local
*local,
struct ieee80211_sub_if_data *sdata,
enum queue_stop_reason reason);
void ieee80211_stop_queues_by_reason(struct ieee80211_hw *hw,
-unsigned long queues,
+unsigned long *queues,
enum queue_stop_reason reason,
bool refcounted);
void ieee80211_wake_queue_by_reason(struct ieee80211_hw *hw, int queue,
@@ -1938,7 +1941,7 @@ void ieee80211_flush_queues(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata, bool drop);
void __ieee80211_flush_queues(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
- unsigned int queues, bool drop);
+ unsigned long *queues, bool drop);
static inline bool ieee80211_can_run_worker(struct ieee80211_local *local)
{
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 39d
Re: [PATCH 08/11] brcmfmac: Make 5G join preference configurable.
On 12/02/2015 07:00 PM, Paul Stewart wrote: From my perspective it is useful to have the driver express whether or not it supports this parameter. It may not change how the system operates, but it will be useful in testing to determine whether it is expected that a (given version of a) driver is expected to act with respect to this property so we can flag issues with the implementation. Thanks, Paul and others. Will come up with a RFC for this incorporating all feedback received. Regards, Arend On Wed, Dec 2, 2015 at 8:38 AM, Dan Williams wrote: On Wed, 2015-12-02 at 14:32 +0100, Arend van Spriel wrote: On 12/01/2015 12:08 PM, Jouni Malinen wrote: On Tue, Dec 01, 2015 at 11:48:32AM +0200, Kalle Valo wrote: Arend van Spriel writes: It solves a problem for us, but admittedly it is not something that is very usable by user-space apps. So I guess what you are suggesting here is to come up with a nl80211 api for this. On the mailing list (or hostap list) the topic pops up from time to time so there are people who would like to have such a knob to play with. Still would like to keep the module parameter although its use may change when nl80211 api is added. I don't know what is the best approach, that's why I would like to hear opinions from others. Personally I don't like the idea of adding 802.11 level configuration options to module parameters, but on the other hand I don't have any strong opinions about this. I would like to see this as a new attribute to NL80211_CMD_CONNECT to provide parameters for offloaded (driver and/or firmware) BSS selection and roaming. If there is a driver that uses roaming offload with NL80211_CMD_ASSOCIATE, the same attribute could be used there (but I'm not sure how exact such offloading would work in practice since I'd expect both authentication and (re)association to be offloaded). Sounds reasonable. Just would like to explore the use-case a bit more. Looking at tools like NetworkManager and android network list, the user is always presented with just SSID listed once. For NetworkManager While NM has band locking properties, there is currently no "prefer 5ghz" since as Jouni said, the supplicant should probably just prefer 5ghz right now. In any case, the best path from an NM perspective would be a supplicant per-network property that would then be sent for CONNECT-capable drivers, or which the supplicant would manually handle for softmac drivers through its existing AP selection code. Dan details can be configured for a connection and the bss selection parameters could be one of those. What level of detail would be needed there. Not saying we can not have more detail in the nl80211 API. I guess we have two different designs, one where the roaming logic is in firmware and other where wpasupplicant is responsible for this. (And I assume that brcfmac belongs to the former group.) Ideally it would be nice that we would have a same configuration knob for both but I don't know if that's really feasible. Both of these would work as long as wpa_supplicant has means for providing such configuration to the driver in a generic manner. That NL80211_CMD_CONNECT extension with a new optional attribute would be such a generic design. So does the driver need to advertise support for bss selection parameters or can it simply ignore the parameters. Assuming the latter for now. Regards, Arend -- 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 -- 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 2015-12-02
From: Johannes Berg Date: Wed, 02 Dec 2015 22:42:10 +0100 > >> Please add them and send a new pull request, I'll just skip over your >> existing one. > > Ok, here we go, below a new pull request. 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: Can we increase IEEE80211_MAX_QUEUES
On 12/03/2015 12:21 PM, Johannes Berg wrote: On Thu, 2015-12-03 at 12:16 -0800, Ben Greear wrote: ath10k wants to use vdev-id as a queue-id, and I want to support up to 64 vdevs. In the 4.2 kernel, this is causing splats when using lots of vdevs because then queue is out of range. Can we just increase IEEE80211_MAX_QUEUES to 64? I think not, that would likely cause a lot of data structures to grow too much. We'd have to do more dynamic things in that case, I suppose. Does the original premise even make sense though? A single queue for each vdev seems a bit strange. I think it is all fakery in the driver, but I'm not sure how easy it would be to fix. I'm not certain why I'm suddenly seeing this, but I just started using 4.2 kernel again and maybe that is the difference. I also tweaked firmware recently... I'll make a stab at allowing 64 queues, and also try to figure out why I started seeing the problem. 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
Re: Can we increase IEEE80211_MAX_QUEUES
On Thu, 2015-12-03 at 21:21 +0100, Johannes Berg wrote: > > Does the original premise even make sense though? A single queue for > each vdev seems a bit strange. > Btw, it might make more sense to use Felix's txq scheduling thing for this, where you get a txq for each station. You can still combine them back any way you want in the driver. 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: Can we increase IEEE80211_MAX_QUEUES
On Thu, 2015-12-03 at 12:16 -0800, Ben Greear wrote: > ath10k wants to use vdev-id as a queue-id, and I want to support up > to > 64 vdevs. In the 4.2 kernel, this is causing splats when using lots > of > vdevs because then queue is out of range. > > Can we just increase IEEE80211_MAX_QUEUES to 64? > I think not, that would likely cause a lot of data structures to grow too much. We'd have to do more dynamic things in that case, I suppose. Does the original premise even make sense though? A single queue for each vdev seems a bit strange. 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
Can we increase IEEE80211_MAX_QUEUES
ath10k wants to use vdev-id as a queue-id, and I want to support up to 64 vdevs. In the 4.2 kernel, this is causing splats when using lots of vdevs because then queue is out of range. Can we just increase IEEE80211_MAX_QUEUES to 64? 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
Re: iw set txpower error
On Thu, Dec 3, 2015 at 8:10 PM, Kobi Cohen-Arazi
wrote:
> Hi all,
>
> I’m trying to change txpower with iw. Using AR9580 HW + ath9k driver
> with Kernel 4.1.6.
>
> The call fails in mac80211 with the following error: "Failed
> check-sdata-in-driver check, flags: 0x0".
> stack:
> - start stack
Try that one:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/jberg/mac80211/+/5ad11b50fda1306b5317124f97f0a7a4c022b022
>
> [44387.506210] WARNING: CPU: 2 PID: 19731 at
> net/mac80211/driver-ops.h:12
> ieee80211_bss_info_change_notify+0x1d2/0x1e0 [mac80211]()
> [44387.506211] wlp2s0: Failed check-sdata-in-driver check, flags: 0x0
> [44387.506212] Modules linked in: ath9k(OE) ath9k_common(OE)
> ath9k_hw(OE) ath(OE) mac80211 cfg80211 rfkill nfsv3 rpcsec_gss_krb5
> nfsv4 dns_resolver nfs fscache xt_CHECKSUM iptable_mangle xt_conntrack
> ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4
> nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype tun br_netfilter nf_nat
> nf_conntrack bridge stp llc dm_thin_pool dm_persistent_data
> dm_bio_prison libcrc32c loop arc4 intel_rapl iosf_mbi
> x86_pkg_temp_thermal coretemp kvm_intel kvm snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_codec_generic crct10dif_pclmul
> snd_soc_rt5640 snd_hda_intel crc32_pclmul snd_soc_rl6231
> snd_hda_controller crc32c_intel snd_soc_core snd_hda_codec
> ghash_clmulni_intel snd_hda_core snd_compress snd_pcm_dmaengine
> snd_hwdep snd_seq iTCO_wdt iTCO_vendor_support snd_seq_device
> [44387.506241] ir_lirc_codec lirc_dev ir_xmp_decoder
> ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder
> ir_jvc_decoder ir_nec_decoder ir_rc6_decoder ir_rc5_decoder rc_rc6_mce
> snd_pcm nuvoton_cir tpm_tis dw_dmac i2c_hid regmap_i2c tpm rc_core
> dw_dmac_core snd_timer i2c_designware_platform i2c_i801
> i2c_designware_core snd_soc_sst_acpi snd lpc_ich soundcore shpchp
> mfd_core nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 i2c_algo_bit
> drm_kms_helper e1000e drm ptp pps_core sdhci_acpi sdhci mmc_core video
> [last unloaded: rfkill]
> [44387.506264] CPU: 2 PID: 19731 Comm: iwconfig Tainted: GW
> OE 4.1.6-100.fc21.x86_64 #1
> WYLPT10H.86A.0035.2015.0126.1814 01/26/2015
> [44387.506267] a8ea5b62 8800942cbb58
> 817940d5
> [44387.506269] 8800942cbbb0 8800942cbb98
> 810a163a
> [44387.506270] 8800942cbc20 8800d49b2840 0001
> 8801c92c86a0
> [44387.506272] Call Trace:
> [44387.506278] [] dump_stack+0x45/0x57
> [44387.506281] [] warn_slowpath_common+0x8a/0xc0
> [44387.506283] [] warn_slowpath_fmt+0x55/0x70
> [44387.506286] [] ? iw_handler_get_private+0x70/0x70
> [44387.506293] []
> ieee80211_bss_info_change_notify+0x1d2/0x1e0 [mac80211]
> [44387.506300] []
> ieee80211_recalc_txpower+0x35/0x40 [mac80211]
> [44387.506309] [] ieee80211_set_tx_power+0x4c/0x1b0
> [mac80211]
> [44387.506320] []
> cfg80211_wext_siwtxpower+0x9f/0x1c0 [cfg80211]
> [44387.506334] [] ioctl_standard_call+0x52/0xe0
> [44387.506336] [] ? iw_handler_get_private+0x70/0x70
> [44387.506340] [] ? ioctl_standard_iw_point+0x390/0x390
> [44387.506342] [] wireless_process_ioctl+0x17e/0x1d0
> [44387.506345] [] wext_handle_ioctl+0x78/0xe0
> [44387.506348] [] dev_ioctl+0x2c3/0x5d0
> [44387.506353] [] ? handle_mm_fault+0x117f/0x17f0
> [44387.506356] [] ? sk_prot_alloc+0xdc/0x180
> [44387.506359] [] sock_ioctl+0x132/0x2c0
> [44387.506362] [] ? __d_instantiate+0x9e/0x100
> [44387.506365] [] do_vfs_ioctl+0x2f8/0x500
> [44387.506369] [] ? __do_page_fault+0x1c1/0x450
> [44387.506372] [] SyS_ioctl+0x81/0xa0
> [44387.506375] [] ? do_page_fault+0x2f/0x80
> [44387.506378] [] system_call_fastpath+0x12/0x71
> [44387.506380] ---[ end trace de552a3121eef335 ]---
> --- end stack
> ---
>
> The call in driver-ops.h:check_sdata_in_driver() fails:
>
> static inline bool check_sdata_in_driver(struct ieee80211_sub_if_data *sdata)
> {
> return !WARN(!(sdata->flags & IEEE80211_SDATA_IN_DRIVER),
> "%s: Failed
> check-sdata-in-driver check, flags: 0x%x\n",
> sdata->dev ? sdata->dev->name :
> sdata->name, sdata->flags);
> }
>
> AFAIU, this should not happen.
> ath9k_add_interface is being called before trying to set txpower. I verified
> it.
> When ath9k_add_interface returns, driver-ops.h:drv_add_interface()
> should set SDATA_IN_DRIVER flag.
>
> Any idea why the sdata->flags would still show up with 0x0 in the
> above function ?
>
> Thank you,
> Kobi
> --
> 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-wirele
Re: [PATCH v4 2/3] mac80211: Prevent build failure with CONFIG_UBSAN=y
2015-12-03 20:05 GMT+03:00 Johannes Berg : > On Thu, 2015-12-03 at 18:50 +0300, Andrey Ryabinin wrote: >> With upcoming CONFIG_UBSAN the following BUILD_BUG_ON in >> net/mac80211/debugfs.c starts to trigger: >> BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (void >> *)0x1); >> >> It seems, that compiler instrumentation causes some code >> deoptimizations. >> Because of that GCC is not being able to resolve condition in >> BUILD_BUG_ON() >> at compile time. >> >> We could make size of hw_flag_names array unspecified and replace the >> condition in BUILD_BUG_ON() with following: >> ARRAY_SIZE(hw_flag_names) != NUM_IEEE80211_HW_FLAGS >> >> That will have the same effect as before (adding new flag without >> updating >> array will trigger build failure) except it doesn't fail with >> CONFIG_UBSAN. >> As a bonus this patch slightly decreases size of hw_flag_names array. >> > Seems fine, would you want to take it through some other tree together > with UBSAN, or do you expect that to still take long enough to allow > this to trickle through our trees? > I expect that Andrew will take it with UBSAN for 4.5 -- 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
iw set txpower error
Hi all,
I’m trying to change txpower with iw. Using AR9580 HW + ath9k driver
with Kernel 4.1.6.
The call fails in mac80211 with the following error: "Failed
check-sdata-in-driver check, flags: 0x0".
stack:
- start stack
[44387.506210] WARNING: CPU: 2 PID: 19731 at
net/mac80211/driver-ops.h:12
ieee80211_bss_info_change_notify+0x1d2/0x1e0 [mac80211]()
[44387.506211] wlp2s0: Failed check-sdata-in-driver check, flags: 0x0
[44387.506212] Modules linked in: ath9k(OE) ath9k_common(OE)
ath9k_hw(OE) ath(OE) mac80211 cfg80211 rfkill nfsv3 rpcsec_gss_krb5
nfsv4 dns_resolver nfs fscache xt_CHECKSUM iptable_mangle xt_conntrack
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype tun br_netfilter nf_nat
nf_conntrack bridge stp llc dm_thin_pool dm_persistent_data
dm_bio_prison libcrc32c loop arc4 intel_rapl iosf_mbi
x86_pkg_temp_thermal coretemp kvm_intel kvm snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic crct10dif_pclmul
snd_soc_rt5640 snd_hda_intel crc32_pclmul snd_soc_rl6231
snd_hda_controller crc32c_intel snd_soc_core snd_hda_codec
ghash_clmulni_intel snd_hda_core snd_compress snd_pcm_dmaengine
snd_hwdep snd_seq iTCO_wdt iTCO_vendor_support snd_seq_device
[44387.506241] ir_lirc_codec lirc_dev ir_xmp_decoder
ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder
ir_jvc_decoder ir_nec_decoder ir_rc6_decoder ir_rc5_decoder rc_rc6_mce
snd_pcm nuvoton_cir tpm_tis dw_dmac i2c_hid regmap_i2c tpm rc_core
dw_dmac_core snd_timer i2c_designware_platform i2c_i801
i2c_designware_core snd_soc_sst_acpi snd lpc_ich soundcore shpchp
mfd_core nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 i2c_algo_bit
drm_kms_helper e1000e drm ptp pps_core sdhci_acpi sdhci mmc_core video
[last unloaded: rfkill]
[44387.506264] CPU: 2 PID: 19731 Comm: iwconfig Tainted: GW
OE 4.1.6-100.fc21.x86_64 #1
WYLPT10H.86A.0035.2015.0126.1814 01/26/2015
[44387.506267] a8ea5b62 8800942cbb58
817940d5
[44387.506269] 8800942cbbb0 8800942cbb98
810a163a
[44387.506270] 8800942cbc20 8800d49b2840 0001
8801c92c86a0
[44387.506272] Call Trace:
[44387.506278] [] dump_stack+0x45/0x57
[44387.506281] [] warn_slowpath_common+0x8a/0xc0
[44387.506283] [] warn_slowpath_fmt+0x55/0x70
[44387.506286] [] ? iw_handler_get_private+0x70/0x70
[44387.506293] []
ieee80211_bss_info_change_notify+0x1d2/0x1e0 [mac80211]
[44387.506300] []
ieee80211_recalc_txpower+0x35/0x40 [mac80211]
[44387.506309] [] ieee80211_set_tx_power+0x4c/0x1b0
[mac80211]
[44387.506320] []
cfg80211_wext_siwtxpower+0x9f/0x1c0 [cfg80211]
[44387.506334] [] ioctl_standard_call+0x52/0xe0
[44387.506336] [] ? iw_handler_get_private+0x70/0x70
[44387.506340] [] ? ioctl_standard_iw_point+0x390/0x390
[44387.506342] [] wireless_process_ioctl+0x17e/0x1d0
[44387.506345] [] wext_handle_ioctl+0x78/0xe0
[44387.506348] [] dev_ioctl+0x2c3/0x5d0
[44387.506353] [] ? handle_mm_fault+0x117f/0x17f0
[44387.506356] [] ? sk_prot_alloc+0xdc/0x180
[44387.506359] [] sock_ioctl+0x132/0x2c0
[44387.506362] [] ? __d_instantiate+0x9e/0x100
[44387.506365] [] do_vfs_ioctl+0x2f8/0x500
[44387.506369] [] ? __do_page_fault+0x1c1/0x450
[44387.506372] [] SyS_ioctl+0x81/0xa0
[44387.506375] [] ? do_page_fault+0x2f/0x80
[44387.506378] [] system_call_fastpath+0x12/0x71
[44387.506380] ---[ end trace de552a3121eef335 ]---
--- end stack
---
The call in driver-ops.h:check_sdata_in_driver() fails:
static inline bool check_sdata_in_driver(struct ieee80211_sub_if_data *sdata)
{
return !WARN(!(sdata->flags & IEEE80211_SDATA_IN_DRIVER),
"%s: Failed
check-sdata-in-driver check, flags: 0x%x\n",
sdata->dev ? sdata->dev->name :
sdata->name, sdata->flags);
}
AFAIU, this should not happen.
ath9k_add_interface is being called before trying to set txpower. I verified it.
When ath9k_add_interface returns, driver-ops.h:drv_add_interface()
should set SDATA_IN_DRIVER flag.
Any idea why the sdata->flags would still show up with 0x0 in the
above function ?
Thank you,
Kobi
--
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] ath10k: allow Mesh Point to install peer security key
Mesh Point requires peer security key install when running in secured mode since it's a type of peer links, otherwise peer link will be removed due to key install failure. MFP feature set is required to run Mesh in secured mode and QCA988X firmware, 10.2.4.70.14-2 and above, is the only one supporting secured Mesh at this moment. Signed-off-by: Peter Oh --- drivers/net/wireless/ath/ath10k/mac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index bcb364d..b4bdeb0 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -250,7 +250,8 @@ static int ath10k_install_peer_wep_keys(struct ath10k_vif *arvif, lockdep_assert_held(&ar->conf_mutex); if (WARN_ON(arvif->vif->type != NL80211_IFTYPE_AP && - arvif->vif->type != NL80211_IFTYPE_ADHOC)) + arvif->vif->type != NL80211_IFTYPE_ADHOC && + arvif->vif->type != NL80211_IFTYPE_MESH_POINT)) return -EINVAL; spin_lock_bh(&ar->data_lock); -- 1.9.1 -- 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: wireless-testing regression: Could not configure driver mode
Sorry for the merge damage. I was (and still am) trying to deal with
some merge conflicts when pulling the mac80211 tree, FWIW...
On Thu, Dec 03, 2015 at 08:54:16AM +0200, Kalle Valo wrote:
> Hi John,
>
> with latest wireless-testing[1] I noticed that I cannot start AP mode
> anymore with ath10k:
>
> nl80211: Subscribe to mgmt frames with AP handle 0x9e5b410
> nl80211: Register frame type=0xb0 nl_handle=0x9e5b410 match=
> nl80211: Register frame command failed (type=176): ret=-95 (Operation not
> supported)
> nl80211: Register frame match - hexdump(len=0): [NULL]
> nl80211: Could not configure driver mode
>
> With help of Johannes we find out that there are odd changes in
> wireless-testing[2]. Reverting the change in cfg.c fixed my regression,
> but I don't know really know what has happened.
>
> Kalle
>
> [1] To be exact I was using ath.git master branch but that's just
> wireless-testing plus latest ath patches so should affect here.
>
> [2] $ git diff master-2015-11-27..master-2015-11-30 -- net/mac80211
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 2d1c4c35186d..b3a708366a5a 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -3384,8 +3384,6 @@ const struct cfg80211_ops mac80211_config_ops = {
> .set_bitrate_mask = ieee80211_set_bitrate_mask,
> .remain_on_channel = ieee80211_remain_on_channel,
> .cancel_remain_on_channel = ieee80211_cancel_remain_on_channel,
> - .mgmt_tx = ieee80211_mgmt_tx,
> - .mgmt_tx_cancel_wait = ieee80211_mgmt_tx_cancel_wait,
> .set_cqm_rssi_config = ieee80211_set_cqm_rssi_config,
> .mgmt_frame_register = ieee80211_mgmt_frame_register,
> .set_antenna = ieee80211_set_antenna,
> diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
> index ce8e1a6c7281..cfd3356e26fd 100644
> --- a/net/mac80211/offchannel.c
> +++ b/net/mac80211/offchannel.c
> @@ -916,6 +916,13 @@ int ieee80211_mgmt_tx(struct wiphy *wiphy, struct
> wireless_dev *wdev,
> kfree_skb(skb);
> goto out_unlock;
> }
> + } else {
> + /* Assign a dummy non-zero cookie, it's not sent to
> +* userspace in this case but we rely on its value
> +* internally in the need_offchan case to distinguish
> +* mgmt-tx from remain-on-channel.
> +*/
> + *cookie = 0x;
> }
>
> if (!need_offchan) {
>
>
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
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 v4 2/3] mac80211: Prevent build failure with CONFIG_UBSAN=y
On Thu, 2015-12-03 at 18:50 +0300, Andrey Ryabinin wrote: > With upcoming CONFIG_UBSAN the following BUILD_BUG_ON in > net/mac80211/debugfs.c starts to trigger: > BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (void > *)0x1); > > It seems, that compiler instrumentation causes some code > deoptimizations. > Because of that GCC is not being able to resolve condition in > BUILD_BUG_ON() > at compile time. > > We could make size of hw_flag_names array unspecified and replace the > condition in BUILD_BUG_ON() with following: > ARRAY_SIZE(hw_flag_names) != NUM_IEEE80211_HW_FLAGS > > That will have the same effect as before (adding new flag without > updating > array will trigger build failure) except it doesn't fail with > CONFIG_UBSAN. > As a bonus this patch slightly decreases size of hw_flag_names array. > Seems fine, would you want to take it through some other tree together with UBSAN, or do you expect that to still take long enough to allow this to trickle through our trees? 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] staging: wilc1000: replace 'ptr > 0' check by 'ptr' check.
This silences a sparse warning about incompatible comparisons, while making the intent of the check a bit clearer. Signed-off-by: Mario J. Rugiero --- drivers/staging/wilc1000/host_interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index d5b7725..0c87f6c 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -2270,7 +2270,7 @@ static void Handle_AddBeacon(struct host_if_drv *hif_drv, *pu8CurrByte++ = ((pstrSetBeaconParam->tail_len >> 16) & 0xFF); *pu8CurrByte++ = ((pstrSetBeaconParam->tail_len >> 24) & 0xFF); - if (pstrSetBeaconParam->tail > 0) + if (pstrSetBeaconParam->tail) memcpy(pu8CurrByte, pstrSetBeaconParam->tail, pstrSetBeaconParam->tail_len); pu8CurrByte += pstrSetBeaconParam->tail_len; -- 2.6.3 -- 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 v4 2/3] mac80211: Prevent build failure with CONFIG_UBSAN=y
With upcoming CONFIG_UBSAN the following BUILD_BUG_ON in
net/mac80211/debugfs.c starts to trigger:
BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (void *)0x1);
It seems, that compiler instrumentation causes some code deoptimizations.
Because of that GCC is not being able to resolve condition in BUILD_BUG_ON()
at compile time.
We could make size of hw_flag_names array unspecified and replace the
condition in BUILD_BUG_ON() with following:
ARRAY_SIZE(hw_flag_names) != NUM_IEEE80211_HW_FLAGS
That will have the same effect as before (adding new flag without updating
array will trigger build failure) except it doesn't fail with CONFIG_UBSAN.
As a bonus this patch slightly decreases size of hw_flag_names array.
Signed-off-by: Andrey Ryabinin
Cc: Johannes Berg
Cc: "David S. Miller"
---
net/mac80211/debugfs.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index abbdff0..3e24d0d 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -91,7 +91,7 @@ static const struct file_operations reset_ops = {
};
#endif
-static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 1] = {
+static const char *hw_flag_names[] = {
#define FLAG(F)[IEEE80211_HW_##F] = #F
FLAG(HAS_RATE_CONTROL),
FLAG(RX_INCLUDES_FCS),
@@ -126,9 +126,6 @@ static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS +
1] = {
FLAG(SUPPORTS_AMSDU_IN_AMPDU),
FLAG(BEACON_TX_STATUS),
FLAG(NEEDS_UNIQUE_STA_ADDR),
-
- /* keep last for the build bug below */
- (void *)0x1
#undef FLAG
};
@@ -148,7 +145,7 @@ static ssize_t hwflags_read(struct file *file, char __user
*user_buf,
/* fail compilation if somebody adds or removes
* a flag without updating the name array above
*/
- BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (void *)0x1);
+ BUILD_BUG_ON(ARRAY_SIZE(hw_flag_names) != NUM_IEEE80211_HW_FLAGS);
for (i = 0; i < NUM_IEEE80211_HW_FLAGS; i++) {
if (test_bit(i, local->hw.flags))
--
2.4.10
--
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 24/41] iwlwifi: mvm: move fw-dbg code to separate file
Emmanuel Grumbach writes: >> Indeed... Thanks for catching this... >> Will re-spin... > > I pushed -f the tree with the same tag. Should be fine now. Thanks again. I would prefer that you create a new tag in cases like this. Just to make sure that I don't accidentally pull the old tag. -- 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: pull request: iwlwifi-next 2015-12-01
"Grumbach, Emmanuel" writes: > This is a pull request for -next. It is based on your tree after the > reorganisation. Details in the tag. Let me know if you have issues. > > Please pull. Thanks. > > > The following changes since commit 6d808eba602b00f77f26191f45328774ff057cc0: > > mac80211_hwsim: move Kconfig entry for sorting alphabetically (2015-11-18 > 15:23:36 +0200) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git > tags/iwlwifi-next-for-kalle-2015-12-01 Pulled, 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 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
On Thu, Dec 03, 2015 at 12:18:34PM -0300, Mario J. Rugiero wrote: > Would be v3, or remains v2 because of the lack of further changes > afterwards? Bump the version number. regards, dan carpenter -- 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 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
Would be v3, or remains v2 because of the lack of further changes afterwards? Regards, Mario. El 03/12/15 a las 12:17, Dan Carpenter escribió: On Thu, Dec 03, 2015 at 12:13:59PM -0300, Mario J. Rugiero wrote: Thank you. Then the patch itself should see no changes as of now, am I right? Should I submit a new one anyway to fix the subject line? Yes, please. regards, dan carpenter -- 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 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
On Thu, Dec 03, 2015 at 12:13:59PM -0300, Mario J. Rugiero wrote: > Thank you. Then the patch itself should see no changes as of now, am > I right? > Should I submit a new one anyway to fix the subject line? Yes, please. regards, dan carpenter -- 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 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
Thank you. Then the patch itself should see no changes as of now, am I right? Should I submit a new one anyway to fix the subject line? Regards, Mario. -- 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: wlan0: set_features() failed (-1); wanted 0x0000000000004008, left 0x0000000000004808
Johannes Berg writes: > On Thu, 2015-12-03 at 09:03 +0100, Janusz Dziedzic wrote: >> >> Missing: >> net: fix feature changes on devices without ndo_set_features ? >> > > According to the *code* that's there, but maybe Kalle hasn't recompiled > it to the latest tree quite right? Actually I was too hasty when reading the logs and missed that I haven't seen these warnings since November 30th or so. I guess during after the patch above trickled down to wireless-testing and fixed the issue. So everything is good, sorry for the noise. -- 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
[PATCH V5] wlcore/wl18xx: fw logger over sdio
From: Shahar Patury
enable the FW Logger to work over the SDIO interface instead of only
over UART.
in new design we will use fw internal memory instead of packet ram
that was used in older (and wl12xx) design.
this change will reduce the impact on tp and stability.
adding new event to notify fw logger is ready to be read.
adding dynamic configuration to debugfs.
Signed-off-by: Shahar Patury
---
V5: Resubmitted again due to cpu interface changes
drivers/net/wireless/ti/wl18xx/event.c |2 +
drivers/net/wireless/ti/wl18xx/event.h |1 +
drivers/net/wireless/ti/wl18xx/main.c|9 ++-
drivers/net/wireless/ti/wlcore/cmd.h |1 -
drivers/net/wireless/ti/wlcore/debugfs.c | 60 +++
drivers/net/wireless/ti/wlcore/event.c | 82 +
drivers/net/wireless/ti/wlcore/event.h |9 +++
drivers/net/wireless/ti/wlcore/io.c | 11 ++--
drivers/net/wireless/ti/wlcore/io.h |4 +-
drivers/net/wireless/ti/wlcore/main.c| 96 +++--
drivers/net/wireless/ti/wlcore/rx.c |1 -
drivers/net/wireless/ti/wlcore/sysfs.c | 26
drivers/net/wireless/ti/wlcore/wlcore.h |3 -
13 files changed, 177 insertions(+), 128 deletions(-)
diff --git a/drivers/net/wireless/ti/wl18xx/event.c
b/drivers/net/wireless/ti/wl18xx/event.c
index 09c7e09..719907a 100644
--- a/drivers/net/wireless/ti/wl18xx/event.c
+++ b/drivers/net/wireless/ti/wl18xx/event.c
@@ -205,6 +205,8 @@ int wl18xx_process_mailbox_events(struct wl1271 *wl)
mbox->sc_ssid,
mbox->sc_pwd_len,
mbox->sc_pwd);
+ if (vector & FW_LOGGER_INDICATION)
+ wlcore_event_fw_logger(wl);
return 0;
}
diff --git a/drivers/net/wireless/ti/wl18xx/event.h
b/drivers/net/wireless/ti/wl18xx/event.h
index f3d4f13..070de12 100644
--- a/drivers/net/wireless/ti/wl18xx/event.h
+++ b/drivers/net/wireless/ti/wl18xx/event.h
@@ -41,6 +41,7 @@ enum {
SMART_CONFIG_SYNC_EVENT_ID = BIT(22),
SMART_CONFIG_DECODE_EVENT_ID = BIT(23),
TIME_SYNC_EVENT_ID = BIT(24),
+ FW_LOGGER_INDICATION= BIT(25),
};
enum wl18xx_radar_types {
diff --git a/drivers/net/wireless/ti/wl18xx/main.c
b/drivers/net/wireless/ti/wl18xx/main.c
index 50cce42..60eda4d 100644
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -461,7 +461,7 @@ static struct wlcore_conf wl18xx_conf = {
},
.fwlog = {
.mode = WL12XX_FWLOG_CONTINUOUS,
- .mem_blocks = 2,
+ .mem_blocks = 0,
.severity = 0,
.timestamp= WL12XX_FWLOG_TIMESTAMP_DISABLED,
.output = WL12XX_FWLOG_OUTPUT_DBG_PINS,
@@ -584,7 +584,7 @@ static const struct wlcore_partition_set
wl18xx_ptable[PART_TABLE_LEN] = {
.mem = { .start = 0x00A0, .size = 0x00012000 },
.reg = { .start = 0x00807000, .size = 0x5000 },
.mem2 = { .start = 0x0080, .size = 0xB000 },
- .mem3 = { .start = 0x, .size = 0x },
+ .mem3 = { .start = 0x00401594, .size = 0x1020 },
},
[PART_DOWN] = {
.mem = { .start = 0x, .size = 0x00014000 },
@@ -602,7 +602,7 @@ static const struct wlcore_partition_set
wl18xx_ptable[PART_TABLE_LEN] = {
.mem = { .start = 0x0080, .size = 0x50FC },
.reg = { .start = 0x00B00404, .size = 0x1000 },
.mem2 = { .start = 0x00C0, .size = 0x0400 },
- .mem3 = { .start = 0x, .size = 0x },
+ .mem3 = { .start = 0x00401594, .size = 0x1020 },
},
[PART_PHY_INIT] = {
.mem = { .start = WL18XX_PHY_INIT_MEM_ADDR,
@@ -1029,7 +1029,8 @@ static int wl18xx_boot(struct wl1271 *wl)
DFS_CHANNELS_CONFIG_COMPLETE_EVENT |
SMART_CONFIG_SYNC_EVENT_ID |
SMART_CONFIG_DECODE_EVENT_ID |
- TIME_SYNC_EVENT_ID;
+ TIME_SYNC_EVENT_ID |
+ FW_LOGGER_INDICATION;
wl->ap_event_mask = MAX_TX_FAILURE_EVENT_ID;
diff --git a/drivers/net/wireless/ti/wlcore/cmd.h
b/drivers/net/wireless/ti/wlcore/cmd.h
index 8dc46c0..e28e2f2 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.h
+++ b/drivers/net/wireless/ti/wlcore/cmd.h
@@ -626,7 +626,6 @@ struct wl12xx_cmd_remove_peer {
*/
enum wl12xx_fwlogger_log_mode {
WL12XX_FWLOG_CONTINUOUS,
- WL12XX_FWLOG_ON_DEMAND
};
/* Include/exclude timestamps from the log messages */
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c
RE: [PATCH v2] mac80211_hwsim: check ATTR_FREQ for wmediumd (netlink) packets
> if (rx_status.freq != data2->channel->center_freq &&
> (!data2->tmp_chan ||
> rx_status.freq != data2->tmp_chan->center_freq)) {
Perfect, thank you!
Adam
N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: iw ignores channel switch
On Thu, 2015-12-03 at 12:01 +0100, Reiner Karlsberg wrote: > > Interface wlan0 > ifindex 21 #steadily > increasing, not re-used ? Correct. You'll eventually roll over after 2^32-1 ... this has nothing to do with wifi btw - look at ethernet devices :) [snip irrelevant use of the station interface] > root@OpenWrt:/tmp# iw dev wmon0 set channel 1 Is 'wmon0' still up at that point? It should work then, not sure why it wouldn't, but it's certainly not an iw problem but more likely a kernel problem. Since openwrt also has a fair number of patches I'd ask you to please retest on a regular kernel first, or report the bug to them. 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: [PATCH v2] mac80211_hwsim: check ATTR_FREQ for wmediumd (netlink) packets
On Wed, 2015-12-02 at 19:30 +, Adam R. Welle wrote:
> > Applied. I added locking and made a change to accept both the off-
> > channel and non-offchannel since the internal datapath also does
> > that
> > and we don't stop other operation for off-channel.
>
> Does your change only throw away packets when tmp_chan is set? I was
> under the impression that most of the time tmp_chan would be null.
>
Yeah, umm, that expression was wrong. Thanks.
It should be
if (rx_status.freq != data2->channel->center_freq &&
(!data2->tmp_chan ||
rx_status.freq != data2->tmp_chan->center_freq)) {
I'll fix it.
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: wlan0: set_features() failed (-1); wanted 0x0000000000004008, left 0x0000000000004808
On Thu, 2015-12-03 at 09:03 +0100, Janusz Dziedzic wrote: > > Missing: > net: fix feature changes on devices without ndo_set_features ? > According to the *code* that's there, but maybe Kalle hasn't recompiled it to the latest tree quite right? 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 V4] wlcore/wl18xx: fw logger over sdio
From: Shahar Patury
enable the FW Logger to work over the SDIO interface instead of only
over UART.
in new design we will use fw internal memory instead of packet ram
that was used in older (and wl12xx) design.
this change will reduce the impact on tp and stability.
adding new event to notify fw logger is ready to be read.
adding dynamic configuration to debugfs.
Signed-off-by: Shahar Patury
---
V4: Resubmitted again due to compiler dependencies fixes
drivers/net/wireless/ti/wl18xx/event.c |2 +
drivers/net/wireless/ti/wl18xx/event.h |1 +
drivers/net/wireless/ti/wl18xx/main.c|9 ++-
drivers/net/wireless/ti/wlcore/cmd.h |1 -
drivers/net/wireless/ti/wlcore/debugfs.c | 60 +++
drivers/net/wireless/ti/wlcore/event.c | 80 +
drivers/net/wireless/ti/wlcore/event.h |9 +++
drivers/net/wireless/ti/wlcore/io.c | 11 ++--
drivers/net/wireless/ti/wlcore/io.h |4 +-
drivers/net/wireless/ti/wlcore/main.c| 96 +++--
drivers/net/wireless/ti/wlcore/rx.c |1 -
drivers/net/wireless/ti/wlcore/sysfs.c | 26
drivers/net/wireless/ti/wlcore/wlcore.h |3 -
13 files changed, 175 insertions(+), 128 deletions(-)
diff --git a/drivers/net/wireless/ti/wl18xx/event.c
b/drivers/net/wireless/ti/wl18xx/event.c
index 09c7e09..719907a 100644
--- a/drivers/net/wireless/ti/wl18xx/event.c
+++ b/drivers/net/wireless/ti/wl18xx/event.c
@@ -205,6 +205,8 @@ int wl18xx_process_mailbox_events(struct wl1271 *wl)
mbox->sc_ssid,
mbox->sc_pwd_len,
mbox->sc_pwd);
+ if (vector & FW_LOGGER_INDICATION)
+ wlcore_event_fw_logger(wl);
return 0;
}
diff --git a/drivers/net/wireless/ti/wl18xx/event.h
b/drivers/net/wireless/ti/wl18xx/event.h
index f3d4f13..070de12 100644
--- a/drivers/net/wireless/ti/wl18xx/event.h
+++ b/drivers/net/wireless/ti/wl18xx/event.h
@@ -41,6 +41,7 @@ enum {
SMART_CONFIG_SYNC_EVENT_ID = BIT(22),
SMART_CONFIG_DECODE_EVENT_ID = BIT(23),
TIME_SYNC_EVENT_ID = BIT(24),
+ FW_LOGGER_INDICATION= BIT(25),
};
enum wl18xx_radar_types {
diff --git a/drivers/net/wireless/ti/wl18xx/main.c
b/drivers/net/wireless/ti/wl18xx/main.c
index 50cce42..60eda4d 100644
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -461,7 +461,7 @@ static struct wlcore_conf wl18xx_conf = {
},
.fwlog = {
.mode = WL12XX_FWLOG_CONTINUOUS,
- .mem_blocks = 2,
+ .mem_blocks = 0,
.severity = 0,
.timestamp= WL12XX_FWLOG_TIMESTAMP_DISABLED,
.output = WL12XX_FWLOG_OUTPUT_DBG_PINS,
@@ -584,7 +584,7 @@ static const struct wlcore_partition_set
wl18xx_ptable[PART_TABLE_LEN] = {
.mem = { .start = 0x00A0, .size = 0x00012000 },
.reg = { .start = 0x00807000, .size = 0x5000 },
.mem2 = { .start = 0x0080, .size = 0xB000 },
- .mem3 = { .start = 0x, .size = 0x },
+ .mem3 = { .start = 0x00401594, .size = 0x1020 },
},
[PART_DOWN] = {
.mem = { .start = 0x, .size = 0x00014000 },
@@ -602,7 +602,7 @@ static const struct wlcore_partition_set
wl18xx_ptable[PART_TABLE_LEN] = {
.mem = { .start = 0x0080, .size = 0x50FC },
.reg = { .start = 0x00B00404, .size = 0x1000 },
.mem2 = { .start = 0x00C0, .size = 0x0400 },
- .mem3 = { .start = 0x, .size = 0x },
+ .mem3 = { .start = 0x00401594, .size = 0x1020 },
},
[PART_PHY_INIT] = {
.mem = { .start = WL18XX_PHY_INIT_MEM_ADDR,
@@ -1029,7 +1029,8 @@ static int wl18xx_boot(struct wl1271 *wl)
DFS_CHANNELS_CONFIG_COMPLETE_EVENT |
SMART_CONFIG_SYNC_EVENT_ID |
SMART_CONFIG_DECODE_EVENT_ID |
- TIME_SYNC_EVENT_ID;
+ TIME_SYNC_EVENT_ID |
+ FW_LOGGER_INDICATION;
wl->ap_event_mask = MAX_TX_FAILURE_EVENT_ID;
diff --git a/drivers/net/wireless/ti/wlcore/cmd.h
b/drivers/net/wireless/ti/wlcore/cmd.h
index 8dc46c0..e28e2f2 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.h
+++ b/drivers/net/wireless/ti/wlcore/cmd.h
@@ -626,7 +626,6 @@ struct wl12xx_cmd_remove_peer {
*/
enum wl12xx_fwlogger_log_mode {
WL12XX_FWLOG_CONTINUOUS,
- WL12XX_FWLOG_ON_DEMAND
};
/* Include/exclude timestamps from the log messages */
diff --git a/drivers/net/wireless/ti/wlcore/debu
Re: [PATCH 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
On 2015년 12월 03일 00:12, Mario J. Rugiero wrote: OK. Since the maintainers are CC'd, I guess I should wait for a clarification about this? Hi Mario, The purpose of that is to check if tail is null or not. if it is not null, there is tail to send, so copy to buff. regards, glen lee. El 02/12/15 a las 10:29, Dan Carpenter escribió: Put v2 in the subject. Also the subsystem prefix is: [PATCH v3] staging: wilc1000: ... On Mon, Nov 30, 2015 at 09:09:04PM -0300, Mario J. Rugiero wrote: This patch replaces an "if (ptr > 0)" comparison that seems to be a confusing way to check for null by a simpler "if (ptr)" check. Signed-off-by: Mario J. Rugiero --- v2: Remove the != NULL because checkpatch complains. drivers/staging/wilc1000/host_interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index d5b7725..0c87f6c 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -2270,7 +2270,7 @@ static void Handle_AddBeacon(struct host_if_drv *hif_drv, *pu8CurrByte++ = ((pstrSetBeaconParam->tail_len >> 16) & 0xFF); *pu8CurrByte++ = ((pstrSetBeaconParam->tail_len >> 24) & 0xFF); -if (pstrSetBeaconParam->tail > 0) +if (pstrSetBeaconParam->tail) Probably the intention was to check if "pstrSetBeaconParam->tail_len > 0" but I'm not sure. The wilc1000 maintainers are very responsive though so maybe they will know for sure. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel -- 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: wlan0: set_features() failed (-1); wanted 0x0000000000004008, left 0x0000000000004808
On Thu, 2015-12-03 at 09:07 +0200, Kalle Valo wrote: > I'm using ath.git master branch which is latest wireless-testing plus > latest ath patches. Any ideas what's causing these? mac80211 or > something else? This is usually caused by a driver (in this case mac80211) implementing ndo_set_features, but I never accepted that patch as far as I remember, it's pending in patchwork. I don't see that in your tree either, so that's very puzzling. Clearly it's trying to turn off NETIF_F_GSO, as it should since the drivers both don't advertise NETIF_F_SG right now. The code you're looking at is in __netdev_update_features(), but I can't explain how it would get into this message if ndo_set_features is NULL. Perhaps you should recompile the kernel from scratch. 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: wlan0: set_features() failed (-1); wanted 0x0000000000004008, left 0x0000000000004808
On 3 December 2015 at 08:07, Kalle Valo wrote: > Hi, > > For few weeks (I think) I have seen these kind of messages: > > ath10k_pci :02:00.0 wlan0: set_features() failed (-1); wanted > 0x4008, left 0x4808 > > iwlwifi :03:00.0 wlan0: set_features() failed (-1); wanted > 0x4000, left 0x4800 > > I'm using ath.git master branch which is latest wireless-testing plus > latest ath patches. Any ideas what's causing these? mac80211 or > something else? > Missing: net: fix feature changes on devices without ndo_set_features ? BR Janusz > -- > 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 -- 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
