Re: [Outreachy kernel] [PATCH v4 1/3] staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer

On Fri, 24 Feb 2017, Tahia Khan wrote: > Rename struct tstrRSSI to rssi_history_buffer for clarity > and to remove camel casing. > > Signed-off-by: Tahia Khan Acked-by: Julia Lawall > --- > drivers/staging/wilc1000/coreconfigurator.h | 4 ++-- >

[PATCH v3] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

Sourced from the current legislation at https://www.legislation.gov.au/Details/F2016C00432 The current rules exceed legal limits between 5250-5330MHz, and permit illegal operation in 5600-5650MHz (disallowed regardless of DFS). Frequency ranges and EIRP limits for all ranges have been updated to

[no subject]

hi Linux http://blog.iconversity.com/product.php?action=24kyew6ae2vhk5 Mark Coste

[PATCH v4] ath10k: search SMBIOS for OEM board file extension

Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified, among others, by device and sybsystem ids. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different

[PATCH v4 3/3] staging: wilc1000: Rename network_info member str_rssi to rssi_history

Change name of str_rssi to rssi_history within the network_info struct for clarity. Signed-off-by: Tahia Khan Acked-by: Julia Lawall --- drivers/staging/wilc1000/coreconfigurator.h | 2 +- drivers/staging/wilc1000/wilc_wfi_cfgoperations.c |

[PATCH v4 2/3] staging: wilc1000: Rename tstrRSSI members and change type of u8Full to bool

Remove Hungarian notation and camel casing from all tstrRSSI members' names. Additionally, change type of u8Full to bool since it only takes values 1 or 0. Signed-off-by: Tahia Khan Acked-by: Julia Lawall ---

[PATCH v4 1/3] staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer

Rename struct tstrRSSI to rssi_history_buffer for clarity and to remove camel casing. Signed-off-by: Tahia Khan --- drivers/staging/wilc1000/coreconfigurator.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v4 0/3] staging: wilc1000: multiple coding style changes to struct tstrRSSI

Multiple coding style changes to struct tstrRSSI. Initially reported by checkpath.pl: Avoid CamelCase: Avoid CamelCase: Avoid CamelCase: Changes since v3: Reformatting commit messages, as requested by Julia Lawall Tahia Khan (3): staging: wilc1000: Rename

Re: [PATCH] NFC: remove TI nfcwilink driver

Hi Rob, >>> It appears that TI WiLink devices including NFC (WL185x/WL189x) never >>> shipped. The only information I found were announcements in Feb >>> 2012 about the parts. There's been no activity on this driver besided >>> common changes since initially added in Jan 2012. There's also no in

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

Am 24.02.2017 um 20:37 schrieb Johannes Berg: > So let's see. The error *isn't* generated by mac80211 or iwlwifi, but > it's still returned through wiphy_suspend(). That function just calls > mac80211 though, and never generates any error conditions by itself. As > a consequence, this must be

Re: [PATCH] NFC: remove TI nfcwilink driver

On Wed, Jan 25, 2017 at 11:54 PM, Marcel Holtmann wrote: > Hi Rob, > >> It appears that TI WiLink devices including NFC (WL185x/WL189x) never >> shipped. The only information I found were announcements in Feb >> 2012 about the parts. There's been no activity on this driver

[PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

From: Jesse Jones Changes since v1: Only flush tx queue if interface is mesh mode. This prevents kernel panics due to uninitialized spin_lock. When more than one station hears a broadcast request, it is possible that multiple devices will reply at the same time,

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

On Fri, 2017-02-24 at 19:51 +0100, Oliver Freyermuth wrote: > > Thanks for your reply and the suggestion! I have put the two lines > directly after the last #include > in both files, i.e. both drivers/net/wireless/intel/iwlwifi/mvm/mvm.h > and net/mac80211/ieee80211_i.h .  > Sadly, none of them

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

Am 24.02.2017 um 13:11 schrieb Johannes Berg: >> However, when trying to suspend to RAM ( echo mem > /sys/power/state >> ), I get: >> [46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211] >> returns -16 >> [46656.403769] PM: Device phy0 failed to suspend async: error -16 >> > >

[PATCH RFC] brcmfmac: shutdown interfaces on PSM's watchdog fire

From: Rafał Miłecki When PSM's watchdog fires hardware / firmware is not operational. It seems there isn't a way to restart firmware & reapply all settings so instead shut all interfaces down. This is at least some signal for the user things went wrong and allows reacting to

[PATCH] brcmfmac: always print error when PSM's watchdog fires

From: Rafał Miłecki So far we were attaching BRCMF_E_PSM_WATCHDOG event listener in brcmf_debug_attach which gets compiled only with CONFIG_BRCMDBG. This event means something went wrong and firmware / hardware usually can't be expected to work (reliably). Such a problem is

Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.

On 02/23/2017 10:36 PM, Johannes Berg wrote: + msg_head = genlmsg_put(skb, 0, 0, _genl_family, 0, + HWSIM_CMD_NOTIFY); I think you should use a more specific command name. My idea was that other attributes could be added over time without having to add

什么情况下用人单位需支付两倍的经济补偿

422:25:31 新《劳动合同法》、《社会保险法》、《工伤保险条例》实操 应对策略与有效调岗调薪、裁员解雇及违纪问题员工处理技巧 2017年3月3--4日---上海（A单元） 2017年3月10--11日-深圳（A单元） 2017年3月17--18日-北京（A单元） 2017年3月24--25日-广州（A单元） 2017年3月31-4月1日上海（B单元） 2017年4月14--15日-深圳（B单元） 2017年4月21--22日-北京（B单元） 2017年4月28--29日-广州（B单元） 2

Re: [PATCH 160/306] mac80211-hwsim: add rate-limited debugging for rx-netlink

On 02/23/2017 10:39 PM, Johannes Berg wrote: + !info->attrs[HWSIM_ATTR_SIGNAL]) { + if (net_ratelimit()) + printk(KERN_DEBUG " hwsim rx-nl: Missing required attribute\n"); I'm not convinced net_ratelimit() is a good idea, that's a global rate

Re: [PATCH 161/306] mac80211-hwsim: Improve logging.

On 02/23/2017 10:42 PM, Johannes Berg wrote: + static unsigned int cnt = 0; + /* This is fairly common, and usually not a bug. So, print errors + rarely. */ + if (((cnt++ & 0x3FF) == 0x3FF) && net_ratelimit()) +

Re: [PATCH v2] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

On Fri, Feb 24, 2017 at 01:20:24PM +1030, Ryan Mounce wrote: > On 24 February 2017 at 02:05, Seth Forshee wrote: > > On Fri, Feb 24, 2017 at 12:22:53AM +1030, Ryan Mounce wrote: > >> Sourced from the current legislation at > >>

Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.

On 02/24/2017 12:45 AM, Andrew Zaborowski wrote: On 24 February 2017 at 01:28, wrote: Modify the receive-from-user-space logic to do length and 'is-down' checks before trying to allocate an skb. And, if we are going to ignore the pkt due to radio idle, then do not

Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset

On 2017-02-24 14:21, Arend Van Spriel wrote: On 24-2-2017 13:27, Rafał Miłecki wrote: From: Rafał Miłecki 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In brcmfmac there is support for 43602a1 and from what I know supporting 43602a0 would require loading

Re: [PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once

On 2017-02-24 14:31, Arend Van Spriel wrote: On 24-2-2017 14:10, Rafał Miłecki wrote: From: Rafał Miłecki It avoids some unnecessary work. Most likely there wasn't much sense in doing this before bus reset anyway, as reset is supposed to put chip into default state. In

[PATCH] mwifiex: fix kernel crash after shutdown command timeout

We observed a SHUTDOWN command timeout during reboot stress test due to a corner case firmware bug. It leads to use-after-free on adapter structure pointer and crash. We already have a cancel_work_sync() call in teardown thread. This issue is fixed by having this call just before

Re: [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table

On 24-2-2017 13:27, Rafał Miłecki wrote: > From: Rafał Miłecki > > Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or > 4366c0. Cutting name at the letter isn't a good idea as sometimes we may > have e.g. a0 and a1. As explained in 1/2, the revision may

Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset

On 24-2-2017 13:27, Rafał Miłecki wrote: > From: Rafał Miłecki > > 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In > brcmfmac there is support for 43602a1 and from what I know supporting > 43602a0 would require loading a different firmware. This is not

[PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once

From: Rafał Miłecki It avoids some unnecessary work. Most likely there wasn't much sense in doing this before bus reset anyway, as reset is supposed to put chip into default state. In PCIe code (only bus implementing reset) we e.g. use watchdog to perform a chip "reboot".

Re: Regression with Intel 3160 AP: client not reconnecting

W dniu 24.02.2017 o 13:13, Johannes Berg pisze: > Hi Jarek, Hello Johannes, >> What might be the cause? Is there anything I can do to help debug or >> fix this? > > Thanks for the detailed bug report and analysis! I can't analyse this > in depth right now, can you please file a bug on

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

> I have been trying to get basic WoWLAN to work with the following > configuration: > - Intel Corporation Wireless 7260 (rev 73) with in-tree iwlwifi > driver So I just tried on 4.9 with a 6205 NIC and it works there. The difference must be somewhere in mvm/d3.c then, I guess. I got a lot of

[PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table

From: Rafał Miłecki Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or 4366c0. Cutting name at the letter isn't a good idea as sometimes we may have e.g. a0 and a1. This is just a cosmetic change, a trivial cleanup. It obviously doesn't change fw filenames as

[PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset

From: Rafał Miłecki 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In brcmfmac there is support for 43602a1 and from what I know supporting 43602a0 would require loading a different firmware. Signed-off-by: Rafał Miłecki ---

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

Hi Arend, On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote: > On 24-2-2017 10:43, Jörg Krause wrote: > > Hi Arend, > > > > On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote: > > > > > > On 23-2-2017 21:21, Jörg Krause wrote: > > > > Hi, > > > > > > > > I am using Linux Kernel

Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq

Hi Kalle, On 02/24/2017 07:01 PM, Kalle Valo wrote: Jeffy Chen writes: Currrently we are disabling this wake irq after receiving it. If this happens before we finish suspend and the pm event check is disabled, the system will continue suspending, and this irq would

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

On 24-2-2017 11:26, Jörg Krause wrote: > Hi Arend, > > On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote: >> On 24-2-2017 10:43, Jörg Krause wrote: >>> Hi Arend, >>> >>> On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote: On 23-2-2017 21:21, Jörg Krause wrote: > Hi,

Re: Regression with Intel 3160 AP: client not reconnecting

Hi Jarek, [snip] > What might be the cause? Is there anything I can do to help debug or > fix this? Thanks for the detailed bug report and analysis! I can't analyse this in depth right now, can you please file a bug on bugzilla.kernel.org? Thanks, johannes

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

Hi Arend, On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote: > > On 23-2-2017 21:21, Jörg Krause wrote: > > Hi, > > > > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running > > 'wpa_cli wps_pin any', the following messages are printed: > > > > """ > > > wps_pin any   

Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq

Jeffy Chen writes: > Currrently we are disabling this wake irq after receiving it. If this > happens before we finish suspend and the pm event check is disabled, > the system will continue suspending, and this irq would not work again. > > We may need to abort system

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

Hi Arend, On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote: > > On 23-2-2017 21:21, Jörg Krause wrote: > > Hi, > > > > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running > > 'wpa_cli wps_pin any', the following messages are printed: > > > > """ > > > wps_pin any   

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

On 24-2-2017 10:43, Jörg Krause wrote: > Hi Arend, > > On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote: >> >> On 23-2-2017 21:21, Jörg Krause wrote: >>> Hi, >>> >>> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running >>> 'wpa_cli wps_pin any', the following messages are

Re: Request for brcmfmac4366c-pcie.bin

On 23-2-2017 21:53, Rafał Miłecki wrote: > Hi guys, > > On 12 September 2016 at 07:22, Rafał Miłecki wrote: >> Few months ago Hante added support for 4366c0 to the brcmfmac. There >> are already few devices with this chipset on the market. We even have >> some related bug

Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.

On 24 February 2017 at 01:28, wrote: > Modify the receive-from-user-space logic to do length > and 'is-down' checks before trying to allocate an skb. > > And, if we are going to ignore the pkt due to radio idle, > then do not return an error code to user-space.

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

On 23-2-2017 21:21, Jörg Krause wrote: > Hi, > > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running > 'wpa_cli wps_pin any', the following messages are printed: > > """ >> wps_pin any > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error : -30 > [

Re: [RFC v2 2/2] cfg80211: support 4-way handshake offloading for 802.1X

On 21-2-2017 13:37, Johannes Berg wrote: > From: Avraham Stern > > Add API for setting the PMK to the driver. For FT support, allow > setting also the PMK-R0 Name. > > This can be used by drivers that support 4-Way handshake offload > while IEEE802.1X authentication