hello LinuxWireless

hi LinuxWireless http://flaskmatningisverige.se/differ.php?garden=1ppdu4fmp9rs69 jeanpierrepoulin -- 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

Re: [PATCH 4/6] ath9k: remove return value from ath9k_hw_init_macaddr

Hi All, On Fri, Jun 24, 2016 at 12:57 AM, Martin Blumenstingl wrote: > ath9k_hw_init_macaddr unconditionally returns 0 in all cases, making the > return value unnecessary. > > Signed-off-by: Martin Blumenstingl Looks right

Re: [PATCH 2/6] ath9k: remove variable which is set but never read

Hi All, On Fri, Jun 24, 2016 at 12:57 AM, Martin Blumenstingl wrote: > No functional changes - this only removes a variable which is set but > never read. > > Signed-off-by: Martin Blumenstingl Looks right to me.

Re: [PATCH] staging: wilc1000: fix spelling mistake: "interupts" -> "interrupts"

Hi All, On Thu, Jun 23, 2016 at 11:14 PM, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in dev_err messages > > Signed-off-by: Colin Ian King Looks right to me. Reviewed-by: Julian

Re: [PATCH] staging: wilc1000: arrays can't be NULL

On 24/06/16 00:54, Julian Calaby wrote: > Hi Luis, > > On Fri, Jun 24, 2016 at 9:50 AM, Luis de Bethencourt > wrote: >> On 24/06/16 00:15, Julian Calaby wrote: >>> Hi Joe, >>> >>> On Fri, Jun 24, 2016 at 5:24 AM, Joe Perches wrote: On Thu,

Re: [PATCH] staging: wilc1000: arrays can't be NULL

Hi Luis, On Fri, Jun 24, 2016 at 9:50 AM, Luis de Bethencourt wrote: > On 24/06/16 00:15, Julian Calaby wrote: >> Hi Joe, >> >> On Fri, Jun 24, 2016 at 5:24 AM, Joe Perches wrote: >>> On Thu, 2016-06-23 at 18:57 +0100, Luis de Bethencourt wrote:

Re: [PATCH] staging: wilc1000: arrays can't be NULL

On 24/06/16 00:15, Julian Calaby wrote: > Hi Joe, > > On Fri, Jun 24, 2016 at 5:24 AM, Joe Perches wrote: >> On Thu, 2016-06-23 at 18:57 +0100, Luis de Bethencourt wrote: >>> hif_drv->usr_scan_req.net.net_info[i] contains found_net_info structs >>> which have the following

Re: [PATCH] staging: wilc1000: arrays can't be NULL

Hi Joe, On Fri, Jun 24, 2016 at 5:24 AM, Joe Perches wrote: > On Thu, 2016-06-23 at 18:57 +0100, Luis de Bethencourt wrote: >> hif_drv->usr_scan_req.net.net_info[i] contains found_net_info structs >> which have the following element: >> u8 bssid[6]; > [] >> I am aware this

Re: [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

On Thu, Jun 23, 2016 at 9:25 PM, Arend Van Spriel wrote: >> +Optional properties: >> +- reg: Address and length of the register set for the device. > > Is 'reg' property handled. I don't see it in patch 2/2. for AHB we would probably have to handle it separately, but

Re: [PATCH] staging: wilc1000: arrays can't be NULL

On 23/06/16 20:24, Joe Perches wrote: > On Thu, 2016-06-23 at 18:57 +0100, Luis de Bethencourt wrote: >> hif_drv->usr_scan_req.net.net_info[i] contains found_net_info structs >> which have the following element: >> u8 bssid[6]; > [] >> I am aware this patch gives a few checkpatch.pl warnings about

Re: pull-request: wireless-drivers-next 2016-06-21

From: Kalle Valo Date: Tue, 21 Jun 2016 13:47:45 +0300 > I hope it's ok to send two pull requests the same day, both for net > and net-next? This is targeted to 4.8 so it is for net-next. Yeah that's fine. > Even though is this the first pull request for 4.8 we actually >

Re: [PATCH v2] mac80211: mesh: Add support for HW RC implementation

> +void sta_get_expected_throughput(struct sta_info *sta, u32 *thr) > +{ > + struct ieee80211_sub_if_data *sdata = sta->sdata; > + struct ieee80211_local *local = sdata->local; > + struct rate_control_ref *ref = NULL; > + > + if (test_sta_flag(sta, WLAN_STA_RATE_CONTROL)) > +

Re: [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

On 23-6-2016 19:45, Martin Blumenstingl wrote: > Add documentation how devicetree can be used to configure ath9k based > devices. > > Signed-off-by: Martin Blumenstingl > --- > changes in v1 -> v2: > - use vendor prefix "qca" instead of "ath" > - extend the

Re: [PATCH] staging: wilc1000: arrays can't be NULL

On Thu, 2016-06-23 at 18:57 +0100, Luis de Bethencourt wrote: > hif_drv->usr_scan_req.net.net_info[i] contains found_net_info structs > which have the following element: > u8 bssid[6]; [] > I am aware this patch gives a few checkpatch.pl warnings about lines being > over 80 characters. Fixing that

Re: pull-request: wireless-drivers 2016-06-21

From: Kalle Valo Date: Tue, 21 Jun 2016 13:27:16 +0300 > here is a pull request for 4.7, really small fixes this time, some of > them fix important regressions. Please let me know if there are any > problems. Applied, thanks. -- To unsubscribe from this list: send the line

[PATCH 0/4] rtl8xxxu: minor fixes

From: Jes Sorensen Hi, This is a couple of minor fixes for the rtl8xxxu driver. Nothing crazy urgent, but nice to get in anyway. Cheers, Jes Jes Sorensen (3): rtl8xxxu: Reduce console noise when removing the kernel module rtl8xxxu: Mark 0x20f4:0x648b as tested

[PATCH 3/4] rtl8xxxu: Mark 0x20f4:0x648b as tested

From: Jes Sorensen Successfully tested by Jocelyn Mayer Reported-by: J. Mayer Signed-off-by: Jes Sorensen --- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 +++-- 1 file changed, 7 insertions(+), 2

[PATCH 1/4] rtl8xxxu: remove unneeded assignments

From: Luis de Bethencourt reg_eac and reg_ecc are only used if candidate is bigger than 0, and in that case new values will be given to them. Removing the unused assignments. Signed-off-by: Luis de Bethencourt Signed-off-by: Jes Sorensen

[PATCH 2/4] rtl8xxxu: Reduce console noise when removing the kernel module

From: Jes Sorensen USB urbs will return with a status != 0 when rmmod'ing the driver. No need to fill the log with messages from rtl8xxxu_int_complete() Signed-off-by: Jes Sorensen --- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 2

[PATCH 4/4] rtl8xxxu: Mark 0x2001:0x3308 as tested

From: Jes Sorensen D-Link DWA-121 is reported as working. Reported-by: Stefano Bravi Signed-off-by: Jes Sorensen --- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 +++-- 1 file changed, 7

Re: [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

On Thu, Jun 23, 2016 at 7:58 PM, Mark Rutland wrote: > On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote: >> Add documentation how devicetree can be used to configure ath9k based >> devices. >> >> Signed-off-by: Martin Blumenstingl

Re: [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote: > Add documentation how devicetree can be used to configure ath9k based > devices. > > Signed-off-by: Martin Blumenstingl > --- > changes in v1 -> v2: > - use vendor prefix "qca" instead of

[PATCH] staging: wilc1000: arrays can't be NULL

hif_drv->usr_scan_req.net.net_info[i] contains found_net_info structs which have the following element: u8 bssid[6]; pstrNetworkInfo, of type network_info, also contains an u8 array named bssid. request->ssids is an array of cfg80211_ssid structs. Making ssid: u8 ssid[IEEE80211_MAX_SSID_LEN];

[PATCH RFC v2 1/2] 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 --- changes in v1 -> v2: - use vendor prefix "qca" instead of "ath" - extend the example so it includes the "compatible" property

[PATCH RFC v2 2/2] ath9k: parse the device configuration from an OF node

This makes it possible to configure ath9k based devices using devicetree. That makes some out-of-tree "convert devicetree to ath9k_platform_data glue"-code obsolete. Signed-off-by: Martin Blumenstingl --- changes in v1 -> v2: - use vendor prefix "qca" instead

[RFC v2] ath9k: 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. This series depends on my previous series: "ath9k:

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

On 06/23/2016 09:40 AM, Mohammed Shafi Shajakhan wrote: From: Mohammed Shafi Shajakhan For chipsets like QCA99X0, IPQ4019 and later we are not getting proper NULL func status (always acked/successs !!) when hostapd does a PROBE_CLIENT via nullfunc frames when the

[PATCH 1/2] ath10k: Replace warning with an error message if HTT op version is unset

From: Mohammed Shafi Shajakhan Print an ath10k error message rather a call trace when HTT op version is not found from firmware META data (IE). This should be sufficient to figure out what went wrong. Signed-off-by: Mohammed Shafi Shajakhan

[PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

From: Mohammed Shafi Shajakhan For chipsets like QCA99X0, IPQ4019 and later we are not getting proper NULL func status (always acked/successs !!) when hostapd does a PROBE_CLIENT via nullfunc frames when the station is powered off abruptly (inactive timer probes client

Re: [PATCH 2/2] Documentation: dt: net: add ath9k wireless device binding

On Thursday, June 23, 2016 05:13:28 PM Martin Blumenstingl wrote: > Add documentation how devicetree can be used to configure ath9k based > devices. > > Signed-off-by: Martin Blumenstingl You need to CC' the devicetree maintainers: Mark Rutland

Re: [PATCH 1/2] ath9k: parse the device configuration from an OF node

On Thursday, June 23, 2016 05:13:27 PM Martin Blumenstingl wrote: > This makes it possible to configure ath9k based devices using > devicetree. That makes some out-of-tree "convert devicetree to > ath9k_platform_data glue"-code obsolete. > > Signed-off-by: Martin Blumenstingl

[PATCH 2/2] 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/ath,ath9k.txt | 40 ++ 1 file changed, 40 insertions(+) create mode 100644

[RFC] ath9k: 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. This series depends on my previous series: "ath9k:

[PATCH 1/6] ath9k: Allow configuration of LED polarity in platform data.

Some devices running OpenWrt need this and it makes sense to add this to ath9k_platform_data as the next patches will add a devicetree (boolean) property for it as well. Suggested-by: Vittorio Gambaletta Signed-off-by: Martin Blumenstingl

ath9k: extend and improve handling of ath9k_platform_data

This series improves handling of ath9k_platform_data inside ath9k. A quick summary of the changes is: - led_active_high can now be configured via ath9k_platform_data: This change is based on a patch originally written by Vittorio Gambaletta which is part of OpenWrt's ath9k patches. - small

[PATCH 5/6] ath9k: move all ath9k_platform_data initialization into one function

No functional changes, this simply makes the code easier to understand because all initialization based on ath9k_platform_data is now within one function. Signed-off-by: Martin Blumenstingl --- drivers/net/wireless/ath/ath9k/init.c | 49

[PATCH 6/6] ath9k: simplify the code-paths when not using the built-in EEPROM

There were two paths in the code for "external" eeprom sources. The code in eeprom.c only handled the cases where the eeprom data was loaded via request_firmware. ahb.c and pci.c on the other hand had some duplicate code which was only used when the eeprom data was passed via ath9k_platform_data.

[PATCH 4/6] ath9k: remove return value from ath9k_hw_init_macaddr

ath9k_hw_init_macaddr unconditionally returns 0 in all cases, making the return value unnecessary. Signed-off-by: Martin Blumenstingl --- drivers/net/wireless/ath/ath9k/hw.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git

[PATCH 3/6] ath9k: ath9k_hw_init_macaddr should not overwrite valid MAC addresses

Currently setting the MAC address via ath9k_platform_data works only due to the order in which init.c sets common->macaddr, which is done after ath9k_hw_init_macaddr was executed. It would be better if the latter was independent of the order in which it's being called. Signed-off-by: Martin

[PATCH 2/6] ath9k: remove variable which is set but never read

No functional changes - this only removes a variable which is set but never read. Signed-off-by: Martin Blumenstingl --- drivers/net/wireless/ath/ath9k/hw.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/hw.c

Re: Driver for rtl8188ee

On 06/23/2016 04:24 AM, jenda wrote: Dear friends My notebook for wifi not working. Is configured with Puppy Linux Precise 5.7.1 and have not driver for rtl8188ee. Pleas help me. Thanks Jan Srajer The driver for the RTL8188EE has been in the kernel since kernel version 3.10, which was

[PATCH v2] mac80211: mesh: Add support for HW RC implementation

Mesh HWMP module will be able to rely on the HW RC algorithm if it exists, for path metric calculations. This allows the metric calculation mechanism to calculate a correct metric, based on PER and last TX rate both via HW RC algorithm if it exists or via parameters collected by the SW.

[PATCH] staging: wilc1000: fix spelling mistake: "interupts" -> "interrupts"

From: Colin Ian King trivial fix to spelling mistake in dev_err messages Signed-off-by: Colin Ian King --- drivers/staging/wilc1000/wilc_sdio.c | 2 +- drivers/staging/wilc1000/wilc_spi.c | 2 +- 2 files changed, 2 insertions(+), 2

[PATCH v2 2/2] staging: wilc1000: fix error values in wilc_debugfs_init()

If there was an error, returning -EINVAL is more appropriate than -1. Signed-off-by: Luis de Bethencourt Reviewed-by: Julian Calaby --- drivers/staging/wilc1000/wilc_debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v2 1/2] staging: wilc1000: fix error handling in wilc_debugfs_init()

The common format to check if a function returned an error pointer is to use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors. Signed-off-by: Luis de Bethencourt Reviewed-by: Julian Calaby ---

Re: Problems with mwifiex_pcie firmware activation

On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote: > On Wed, Jun 15, 2016 at 01:47:53PM +, Amitkumar Karwar wrote: > > Could you please share complete dmesg log for failure and successful cases? > > Dmesg from failure case is in attachment. I loose access to system > where

Re: [PATCH] wlcore: time sync : add support for 64 bit clock

> > Additionally, this looks like it changes the firmware API, so that  > > older firmware images will no longer work? > > It is backwards compatible,  > although it changes a API structure, older firmware are using only > u16 for the field so there is no impact on that. > Oh, ok. I had also

RE: [PATCH] wlcore: time sync : add support for 64 bit clock

On Thu, Jun 23, 2016 at 14:18:00, Johannes Berg wrote: > linux-wireless@vger.kernel.org; net...@vger.kernel.org > Subject: Re: [PATCH] wlcore: time sync : add support for 64 bit clock > > On Thu, 2016-06-23 at 14:12 +0300, Yaniv Machani wrote: > > Changed the configuration to support 64bit

Re: [PATCH] staging: wilc1000: fix error handling in wilc_debugfs_init()

On 23/06/16 02:29, Julian Calaby wrote: > Hi All, > > On Wed, Jun 22, 2016 at 10:39 PM, Luis de Bethencourt > wrote: >> The common format to check if a function returned an error pointer is to >> use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors. >>

Re: [PATCH] wlcore: time sync : add support for 64 bit clock

On Thu, 2016-06-23 at 14:12 +0300, Yaniv Machani wrote: > Changed the configuration to support 64bit instead of 32bit > this in order to offload the driver from handling a wraparound. [...] Since you Cc'ed me, and presumably want me to review it, I'll say that this looks like a terrible idea: >

[PATCH] wlcore: time sync : add support for 64 bit clock

Changed the configuration to support 64bit instead of 32bit this in order to offload the driver from handling a wraparound. Signed-off-by: Yaniv Machani --- drivers/net/wireless/ti/wl18xx/event.c | 26 +- drivers/net/wireless/ti/wl18xx/event.h | 19

Driver for rtl8188ee

Dear friends My notebook for wifi not working. Is configured with Puppy Linux Precise 5.7.1 and have not driver for rtl8188ee. Pleas help me. Thanks Jan Srajer -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v4 0/3] *** staging: wilc1000: Replace semaphores ***

On Thursday, June 23, 2016 11:11:49 AM CEST Binoy Jayan wrote: > > Thank you Arnd for patiently reviewing this patch series multiple times and > apologies to everyone for spamming you inboxes with a patch (v3) that does > not even build. It was due to an uncommited change in my git repo before >

Re: rt2800usb maintainer/expert?

On 23 June 2016 at 08:26, Craig McQueen wrote: > Rafał Miłecki wrote: >> On 23 June 2016 at 07:44, Craig McQueen >> wrote: >> > I'm interested to talk to an expert with the problems I'm seeing, but not >> sure who is the expert these

Re: WARNING: CPU: 1 PID: 103 at drivers/net/wireless/ath/ath9k/hw.c:2778

On Thu, Jun 23, 2016 at 04:47:12AM +, Valo, Kalle wrote: > Mika Westerberg writes: > > > After upgrading from v4.6 to v4.7-rc3 I'm starting to see following > > warnings constantly being printed by ath driver: > > > > [6.761789] ath: phy0: ASPM enabled:

RE: rt2800usb firmware rt2870.bin 0.36 not scanning

I wrote: > I wrote: > > I wrote: > > > Xose Vazquez Perez wrote: > > > > Craig McQueen wrote: > > > > > > > > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based > > > > > (5392 chipset). I'm trying to use it on a BeagleBone Black based > > > > > system with 3.14.x kernel built with

RE: rt2800usb maintainer/expert?

Rafał Miłecki wrote: > On 23 June 2016 at 07:44, Craig McQueen > wrote: > > I'm interested to talk to an expert with the problems I'm seeing, but not > sure who is the expert these days. > > And that has to be done in private, because...? Not at all; it would be

Re: rt2800usb maintainer/expert?

On 23 June 2016 at 07:44, Craig McQueen wrote: > I'm interested to talk to an expert with the problems I'm seeing, but not > sure who is the expert these days. And that has to be done in private, because...? -- Rafał -- To unsubscribe from this list: send the