RE: [PATCH v2] brcmfmac: shut down AP and set IBSS mode only on primary interface

From: Rafał Miłecki [mailto:zaj...@gmail.com] > On 11 August 2016 at 07:44, Wright Feng wrote: > > When stopping hostap on virtual interface, driver will set INFRA and > > AP mode that may affect the functionality on primary interface. For > > example, if we create and

Re: [PATCH] Staging: rtl8723au: rtw_xmit: Fixed operators spacing style issues

On Tue, Aug 02, 2016 at 08:05:30PM +0200, Shiva Kerdel wrote: > Fixed spaces around operators to fix their coding style issues. > > Signed-off-by: Shiva Kerdel > --- > drivers/staging/rtl8723au/core/rtw_xmit.c | 24 > 1 file changed, 12 insertions(+), 12

[PATCH 1/5] ath9k: Add a #define for the EEPROM "eepmisc" endianness bit

This replaces a magic number with a named #define. Additionally it removes two "eeprom format" specific #defines for the "big endianness" bit which are the same on all eeprom formats. --- drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 3 ++- drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 1 -

[PATCH 4/5] ath9k: Make the EEPROM swapping check use the eepmisc register

There are two ways of swapping the EEPROM data in the ath9k driver: 1) swab16 based on the first two EEPROM "magic" bytes (same for all EEPROM formats) 2) field and EEPROM format specific swab16/swab32 (different for eeprom_def, eeprom_4k and eeprom_9287) The result of the first check was

[PATCH 5/5] ath9k: Make EEPROM endianness swapping configurable via devicetree

The endianness swapping is disabled by default since many devices have EEPROMs with incorrect endianness magic bytes (at the beginning). Devices where the EEPROM is known to indicate the correct endianness can enable the new flag to enable swapping when required. This behavior is consistent with

[PATCH 3/5] ath9k: Add an eeprom_ops callback for retrieving the eepmisc value

This allows deciding if we have to swap the EEPROM data (so it matches the system's native endianness) even if no byte-swapping (swab16, based on the first two bytes in the EEPROM) is needed. --- drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 8 +++- drivers/net/wireless/ath/ath9k/eeprom.h

[PATCH 2/5] ath9k: Set the "big endian" bit of the AR9003 EEPROM templates

We will default to the system's native endianness for the eepmisc value. This may be overwritten by the actual calibration data. If it is not overwritten we interpret the template data in it's native endianness, meaning that no swapping is required. ---

[PATCH 0/5] ath9k: EEPROM swapping improvements

There are two types of swapping the EEPROM data in the ath9k driver. Before this series one type of swapping could not be used without the other. The first type of swapping looks at the "magic bytes" at the start of the EEPROM data and performs swab16 on the EEPROM contents if needed. The second

[PATCH v5 2/3] ath9k: add a helper to get the string representation of ath_bus_type

This can be used when the ath_bus_type has to be presented in a log message or firmware filename. Signed-off-by: Martin Blumenstingl --- drivers/net/wireless/ath/ath.h | 6 ++ drivers/net/wireless/ath/main.c | 7 +++ 2 files changed, 13 insertions(+)

[PATCH v5 3/3] ath9k: parse the device configuration from an OF node

This allows configuring ath9k based PCI devices using devicetree. There is some out-of-tree code to "convert devicetree to ath9k_platform_data" (for example in OpenWrt and LEDE) which becomes obsolete with this patch. Signed-off-by: Martin Blumenstingl ---

[PATCH v5 0/3] add devicetree support to ath9k

This series adds support for configuring ath9k based devices via devicetree. This was tested on PCI(e) based devices. This should work for AHB based devices as well as soon as the ath79 platform is ready to populate the ath9k wmac via devicetree. Changes since v4: - dropped

[PATCH v5 1/3] Documentation: dt: net: add ath9k wireless device binding

Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl --- .../devicetree/bindings/net/wireless/qca,ath9k.txt | 47 ++ 1 file changed, 47 insertions(+) create mode 100644

[PATCH 2/3 v2] wlcore: Pass win_size taken from ieee80211_sta to FW

When starting a new BA session, we must pass the win_size to the FW. To do this we take max_rx_aggregation_subframes (BA RX win size) which is stored in ieee80211_sta structure (e.g per link and not per HW) We will use the value stored per link when passing the win_size to firmware through the

[PATCH 3/3 v2] wlcore: Add RX_BA_WIN_SIZE_CHANGE_EVENT event

This event is used by the Firmware to limit the RX BA win size for a specific link. The event handler updates the new size in the mac's sta->sta struct. BA sessions opened for that link will use the new restricted win_size. This limitation remains until a new update is received or until the link

[PATCH 1/3 v2] mac80211: RX BA support for sta max_rx_aggregation_subframes

The ability to change the max_rx_aggregation frames is useful in cases of IOP. There exist some devices (latest mobile phones and some AP's) that tend to not respect a BA sessions maximum size (in Kbps). These devices won't respect the AMPDU size that was negotiated during associasion (even

RE: [PATCH] wlcore: mesh: add zone time sync support

Kalle/Thomas, Thanks for your feedback. This time sync support is different from the one that mac80211 maintains with mesh peers. This time sync is mostly used by upper layers for several applications (like audio). In this case we allow the user to configure for each zone who will be the

GOOD NEWS.

Dear Sir/Ma By this email I am checking the possibility of going into confidentiality partnership with you to facilitate and provide guidance for investment of funds from overseas. I run oil and gas businesses in Gabon and Angola, and currently have access to high-net-worth individuals who are