hello LinuxWireless

[jeanpierrepoulin]

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  http://vger.kernel.org/majordomo-info.html

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

[Julian Calaby]

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 to me.

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 2/6] ath9k: remove variable which is set but never read

[Julian Calaby]

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.

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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] staging: wilc1000: fix spelling mistake: "interupts" -> "interrupts"

[Julian Calaby]

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 Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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] staging: wilc1000: arrays can't be NULL

[Luis de Bethencourt]

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, 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 would be a completely different issue, and
> a lengthy one since the file has loads of them.
>
> Hopefully somebody else picks that up. Maybe I should send a hit to the
> kernelnewbies mailing list :)

 Or not.

 really_long_identifiers™ makes using 80 columns silly.

 The hungarian could probably be converted though.
>>>
>>> The main developers of this driver are slowly working through the
>>> driver's style issues, which is part of the reason why it's in
>>> staging.
>>>
>>> Thanks,
>>>
>>
>> I understand Julian,
>>
>> All the maintainers listed in the MAINTAINERS file are in CC. I will wait for
>> them to OK the suggestion of sending a patch fixing the Hungarian Notation.
> 
> I was letting you know that this work is going to happen, not
> dissuading you from doing it.
> 
>> Didn't mean to step on your toes. I just wanted to help.
> 
> No toes were stepped on. As I said, this was not a "don't do that"
> message, this was an "it's going to happen eventually" message.
> 
>> Code in staging is cared for by a lot of people :)
> 
> Indeed it is.
> 
> Thanks,
> 

Gotcha.

I will send the Hungarian Notation change tomorrow. Since it is some small help.

I will let the memcpy/memcp to ether_addr_* change for the maintainers. I 
believe
it will happen soon.

Thanks for your input.

Luis
--
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] staging: wilc1000: arrays can't be NULL

[Julian Calaby]

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:
 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 would be a completely different issue, and
 a lengthy one since the file has loads of them.

 Hopefully somebody else picks that up. Maybe I should send a hit to the
 kernelnewbies mailing list :)
>>>
>>> Or not.
>>>
>>> really_long_identifiers™ makes using 80 columns silly.
>>>
>>> The hungarian could probably be converted though.
>>
>> The main developers of this driver are slowly working through the
>> driver's style issues, which is part of the reason why it's in
>> staging.
>>
>> Thanks,
>>
>
> I understand Julian,
>
> All the maintainers listed in the MAINTAINERS file are in CC. I will wait for
> them to OK the suggestion of sending a patch fixing the Hungarian Notation.

I was letting you know that this work is going to happen, not
dissuading you from doing it.

> Didn't mean to step on your toes. I just wanted to help.

No toes were stepped on. As I said, this was not a "don't do that"
message, this was an "it's going to happen eventually" message.

> Code in staging is cared for by a lot of people :)

Indeed it is.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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] staging: wilc1000: arrays can't be NULL

[Luis de Bethencourt]

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 element:
>>> u8 bssid[6];
>> []
>>> I am aware this patch gives a few checkpatch.pl warnings about lines being
>>> over 80 characters. Fixing that would be a completely different issue, and
>>> a lengthy one since the file has loads of them.
>>>
>>> Hopefully somebody else picks that up. Maybe I should send a hit to the
>>> kernelnewbies mailing list :)
>>
>> Or not.
>>
>> really_long_identifiers™ makes using 80 columns silly.
>>
>> The hungarian could probably be converted though.
> 
> The main developers of this driver are slowly working through the
> driver's style issues, which is part of the reason why it's in
> staging.
> 
> Thanks,
> 

I understand Julian,

All the maintainers listed in the MAINTAINERS file are in CC. I will wait for
them to OK the suggestion of sending a patch fixing the Hungarian Notation.

Didn't mean to step on your toes. I just wanted to help.

Code in staging is cared for by a lot of people :)

Luis
--
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] staging: wilc1000: arrays can't be NULL

[Julian Calaby]

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 patch gives a few checkpatch.pl warnings about lines being
>> over 80 characters. Fixing that would be a completely different issue, and
>> a lengthy one since the file has loads of them.
>>
>> Hopefully somebody else picks that up. Maybe I should send a hit to the
>> kernelnewbies mailing list :)
>
> Or not.
>
> really_long_identifiers™ makes using 80 columns silly.
>
> The hungarian could probably be converted though.

The main developers of this driver are slowly working through the
driver's style issues, which is part of the reason why it's in
staging.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

[Martin Blumenstingl]

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 AHB
support is not scope of my patch. For PCI(e) this is parsed
automatically by of_pci_find_child_device when the PCI controller is
found and the child nodes are enumerated. See [0]

>> +- qca,eeprom-name: The name of the file which contains the EEPROM data 
>> (which
>> + will be loaded via request_firmware)
>> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and
>> + swapping of the EEPROM data if required
>> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM
>> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM
>
> These not really. Storing filename information in device tree seems
> wrong as it does not describe hardware configuration. The other three
> also seem more like driver module parameters. I think what you are
> trying here with the last two properties is to use the same eeprom file
> for different types of hardware, ie. for dual-band, 2g-only, and 5g-only
> devices. From device tree perspective I would use those types, eg.:
>
> qca,2g-capable: Device can operate in 2.4GHz band.
> qca,5g-capable: Device can operate in 5GHz band.
please let me explain this a bit more detailed (and clean up the
confusion which I may have created):
ath9k itself does not need a firmware to run.
But it needs to know some details of the actual RF hardware (let's
call it calibration/EEPROM data) to which the ath9k chip is wired
(which frequencies/bands are enabled, how many RX/TX antennas are
there, max TX power, if there's a LNA, and so on).
This calibration/EEPROM data is unique for each "ath9k + RF hardware"
combination and usually stored inside an EEPROM connected directly to
the ath9k chip. However, many embedded devices do not have a physical
EEPROM connected to ath9k. For these devices we have to obtain the
calibration/EEPROM data from "somewhere" (which is usually stored
somewhere on SPI/NOR/NAND flash, but can sometimes even be stored
inside an UBI volume).

"qca,eeprom-name" tries to solve the problem that ath9k needs
calibration/EEPROM data even if there is no physical EEPROM attached
to the wifi chip.
One important thing here is that we need to be able to load two
different calibration/EEPROM data files in case one system uses two
ath9k chips (there might for example be a dedicated 2.4G and dedicated
5G chip).
If this should not be part of devicetree then we could do it like
ath10k does and generate the filename for request_firmware based on
the dev_name() - see [1].
I would then replace "qca,eeprom-name" with a boolean
"qca,use-external-eeprom" to signal ath9k that this chip does not have
a (physical) EEPROM attached (ath9k would then start the
request_firmware mechanism).

qca,check-eeprom-endianness is unfortunately required because some
vendors use the little endian magic while the data is actually big
endian.
Endianness swapping needs to be done inside ath9k because it's a quite
complex operation (due to the fact that there are some 16bit and 32bit
fields which have to be swapped differently).
So one would set qca,check-eeprom-endianness if the device vendor
chose the wrong endianness magic, while the data inside the
calibration/EEPROM data is correct.
Enabling it unconditionally would result in the calibration/EEPROM
data being endianness-swapped.

qca,disable-2ghz/qca,disable-5ghz exist due to a similar issue as we
find with the eeprom endianness magic:
Normally the information which bands are enabled for this specific
"ath9k + RF hardware" combination is stored inside the
calibration/EEPROM data.
Unfortunately some vendors left for example the 5GHz band enabled in
the calibration/EEPROM data while the RF hardware only supports
2.4GHz.
Using the 5GHz band on such devices will lead to issues, so it should
be possible to disable those "incorrectly allowed" frequencies/bands.

> The other patch also looks for a MAC address for the device. I suppose
> that should be documented as well.
good catch, thanks!

>> +In this example, the node is defined as child node of the PCI controller.
>> +
>> +pci {
>> + pcie@0 {
>> + reg = <0 0 0 0 0>;
>> + #interrupt-cells = <1>;
>> + #size-cells = <2>;
>> + #address-cells = <3>;
>> + device_type = "pci";
>> +
>> + ath9k@0,0 {
>> + compatible = "qca,ath9k";
>> + reg = <0 0 0 0 0>;
>> + device_type = "pci";
>
> Is this just a copy-paste or should device_type be specified?
indeed, as far as I understand it should only be defined on the bridge
- thus it should be removed from the ath9k node.
again, thanks for noting this!

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

[Luis de Bethencourt]

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 lines being
>> over 80 characters. Fixing that would be a completely different issue, and
>> a lengthy one since the file has loads of them.
>>
>> Hopefully somebody else picks that up. Maybe I should send a hit to the
>> kernelnewbies mailing list :)
> 
> Or not.
> 
> really_long_identifiers™ makes using 80 columns silly.

I agree. Not a priority, at all.

> 
> The hungarian could probably be converted though.
> 

I could look into this tomorrow.

I noticed, for example these 3 in the same function:
struct wid strWIDList[8];
u32 u32WidsCount = 0, dummyval = 0;
u8 *pu8CurrByte = NULL;

Not pretty and cleaning those should take little time.

> A log of the memcpy and memcpy uses could probably be
> converted to ether_addr_ too.
> 

Switching memcpy for ether_addr_copy and memcmp for ether_addr_equal.

I could send a patch for this as well, but I would need to have somebody
test it for me. Or maybe get this hardware for myself and do it properly.

Do you approve of my original patch?

Thanks for the review :)
Luis


--
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: wireless-drivers-next 2016-06-21

[David Miller]

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
> remove more code than add, thanks to Guenter Roeck's on removing
> unused "phy_a" support from b43. Otherwise there's not really
> anything standing out, adding new chipset support to brcmfmac and
> ath10k, lots of fixes and the usual.

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: [PATCH v2] mac80211: mesh: Add support for HW RC implementation

[Johannes Berg]

> +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))
> + ref = local->rate_ctrl;
> +
> + /* check if the driver has a SW RC implementation */
> + if (ref && ref->ops->get_expected_throughput)
> + *thr = ref->ops->get_expected_throughput(sta-
> >rate_ctrl_priv);
> + else
> + *thr = drv_get_expected_throughput(local, 
> >sta);
> +}

I don't really see a reason for the function to take a u32 *thr, rather
than return u32? Would be clearer, IMHO, to just return the value.

Then in the user, it seems that you shouldn't use "rate" as the
variable that gets this result?

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 RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

[Arend Van Spriel]

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 example so it includes the "compatible" property
> 
>  .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 
> ++
>  1 file changed, 41 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> new file mode 100644
> index 000..bb78f68
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,41 @@
> +* Qualcomm Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: Should be "qca,ath9k"
> +
> +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.

> +- qca,gpio-mask: The GPIO mask
> +- qca,gpio-val: The GPIO value
> +- qca,led-pin: The GPIO number to which the LED is connected
> +- qca,led-active-high: The LED is active when the GPIO is HIGH
> +- qca,clk-25mhz: Defines that at 25MHz clock is used

For the above I can somehow see them as variables for different hardware
platforms.

> +- qca,eeprom-name: The name of the file which contains the EEPROM data (which
> + will be loaded via request_firmware)
> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and
> + swapping of the EEPROM data if required
> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM
> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM

These not really. Storing filename information in device tree seems
wrong as it does not describe hardware configuration. The other three
also seem more like driver module parameters. I think what you are
trying here with the last two properties is to use the same eeprom file
for different types of hardware, ie. for dual-band, 2g-only, and 5g-only
devices. From device tree perspective I would use those types, eg.:

qca,2g-capable: Device can operate in 2.4GHz band.
qca,5g-capable: Device can operate in 5GHz band.

The other patch also looks for a MAC address for the device. I suppose
that should be documented as well.

> +In this example, the node is defined as child node of the PCI controller.
> +
> +pci {
> + pcie@0 {
> + reg = <0 0 0 0 0>;
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> +
> + ath9k@0,0 {
> + compatible = "qca,ath9k";
> + reg = <0 0 0 0 0>;
> + device_type = "pci";

Is this just a copy-paste or should device_type be specified?

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

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

[Joe Perches]

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 would be a completely different issue, and
> a lengthy one since the file has loads of them.
> 
> Hopefully somebody else picks that up. Maybe I should send a hit to the
> kernelnewbies mailing list :)

Or not.

really_long_identifiers™ makes using 80 columns silly.

The hungarian could probably be converted though.

A log of the memcpy and memcpy uses could probably be
converted to ether_addr_ too.

--
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: wireless-drivers 2016-06-21

[David Miller]

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 "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 0/4] rtl8xxxu: minor fixes

[Jes . Sorensen]

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
  rtl8xxxu: Mark 0x2001:0x3308 as tested

Luis de Bethencourt (1):
  rtl8xxxu: remove unneeded assignments

 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c   |  2 --
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c| 20 +++-
 2 files changed, 15 insertions(+), 7 deletions(-)

-- 
2.7.4

--
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 3/4] rtl8xxxu: Mark 0x20f4:0x648b as tested

[Jes . Sorensen]

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 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index cfa5528..90d21c3 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5852,6 +5852,10 @@ static int rtl8xxxu_probe(struct usb_interface 
*interface,
if (id->idProduct == 0x1004)
untested = 0;
break;
+   case 0x20f4:
+   if (id->idProduct == 0x648b)
+   untested = 0;
+   break;
default:
break;
}
@@ -6021,6 +6025,9 @@ static struct usb_device_id dev_table[] = {
 /* Tested by Andrea Merello */
 {USB_DEVICE_AND_INTERFACE_INFO(0x050d, 0x1004, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
+/* Tested by Jocelyn Mayer */
+{USB_DEVICE_AND_INTERFACE_INFO(0x20f4, 0x648b, 0xff, 0xff, 0xff),
+   .driver_info = (unsigned long)_fops},
 /* Currently untested 8188 series devices */
 {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x8191, 0xff, 0xff, 
0xff),
.driver_info = (unsigned long)_fops},
@@ -6080,8 +6087,6 @@ static struct usb_device_id dev_table[] = {
.driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(0x2019, 0xed17, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
-{USB_DEVICE_AND_INTERFACE_INFO(0x20f4, 0x648b, 0xff, 0xff, 0xff),
-   .driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(0x4855, 0x0090, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(0x4856, 0x0091, 0xff, 0xff, 0xff),
-- 
2.7.4

--
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 1/4] rtl8xxxu: remove unneeded assignments

[Jes . Sorensen]

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 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index 5b825fa..9a1994f 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1244,11 +1244,9 @@ static void rtl8192eu_phy_iq_calibrate(struct 
rtl8xxxu_priv *priv)
reg_e94 = result[i][0];
reg_e9c = result[i][1];
reg_ea4 = result[i][2];
-   reg_eac = result[i][3];
reg_eb4 = result[i][4];
reg_ebc = result[i][5];
reg_ec4 = result[i][6];
-   reg_ecc = result[i][7];
}
 
if (candidate >= 0) {
-- 
2.7.4

--
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 2/4] rtl8xxxu: Reduce console noise when removing the kernel module

[Jes . Sorensen]

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 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 9f6dbb4..cfa5528 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5267,7 +5267,7 @@ static void rtl8xxxu_int_complete(struct urb *urb)
if (ret)
usb_unanchor_urb(urb);
} else {
-   dev_info(dev, "%s: Error %i\n", __func__, urb->status);
+   dev_dbg(dev, "%s: Error %i\n", __func__, urb->status);
}
 }
 
-- 
2.7.4

--
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 4/4] rtl8xxxu: Mark 0x2001:0x3308 as tested

[Jes . Sorensen]

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 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 90d21c3..dfe61e4 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5856,6 +5856,10 @@ static int rtl8xxxu_probe(struct usb_interface 
*interface,
if (id->idProduct == 0x648b)
untested = 0;
break;
+   case 0x2001:
+   if (id->idProduct == 0x3308)
+   untested = 0;
+   break;
default:
break;
}
@@ -6028,6 +6032,9 @@ static struct usb_device_id dev_table[] = {
 /* Tested by Jocelyn Mayer */
 {USB_DEVICE_AND_INTERFACE_INFO(0x20f4, 0x648b, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
+/* Tested by Stefano Bravi */
+{USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3308, 0xff, 0xff, 0xff),
+   .driver_info = (unsigned long)_fops},
 /* Currently untested 8188 series devices */
 {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x8191, 0xff, 0xff, 
0xff),
.driver_info = (unsigned long)_fops},
@@ -6075,8 +6082,6 @@ static struct usb_device_id dev_table[] = {
.driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(0x13d3, 0x3357, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
-{USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3308, 0xff, 0xff, 0xff),
-   .driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x330b, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(0x2019, 0x4902, 0xff, 0xff, 0xff),
-- 
2.7.4

--
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 RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

[Martin Blumenstingl]

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 
>> ---
>> changes in v1 -> v2:
>> - use vendor prefix "qca" instead of "ath"
>> - extend the example so it includes the "compatible" property
>>
>>  .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 
>> ++
>>  1 file changed, 41 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt 
>> b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
>> new file mode 100644
>> index 000..bb78f68
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
>> @@ -0,0 +1,41 @@
>> +* Qualcomm Atheros ath9k wireless devices
>> +
>> +This node provides properties for configuring the ath9k wireless device. The
>> +node is expected to be specified as a child node of the PCI controller to
>> +which the wireless chip is connected.
>> +
>> +Required properties:
>> +- compatible: Should be "qca,ath9k"
>> +
>> +Optional properties:
>> +- reg: Address and length of the register set for the device.
>> +- qca,gpio-mask: The GPIO mask
>> +- qca,gpio-val: The GPIO value
>> +- qca,led-pin: The GPIO number to which the LED is connected
>> +- qca,led-active-high: The LED is active when the GPIO is HIGH
>> +- qca,clk-25mhz: Defines that at 25MHz clock is used
>
> I must assume these apply to internal GPIOs, LEDs and clocks, so I'm
> somewhat surprised any description is necessary.
>
> How variable are these in practice?
led-pin and led-active-high are definitely used on various OpenWrt devices.
However, I am afraid that I have to pass this question to the ath9k
developers for the other properties (gpio-mask, gpio-val and
clk-25mhz).
If you want we can skip gpio-mask, gpio-val and clk-25mhz for now, but
keep led-pin and led-active-high.

>> +- qca,eeprom-name: The name of the file which contains the EEPROM data 
>> (which
>> + will be loaded via request_firmware)
>
> The binding shouldn't know anything about the host filesystem,
> request_firmware, etc. So the description is a best a little off.
>
> What happens when a new FW comes out? I shouldn't have to update my DT
> to cater for that.
This is not exactly a "firmware" but rather device-specific
calibration data (RF settings, MAC address, etc). Usually there is an
eeprom connected directly to the wifi chip, but on embedded devices
this is usually skipped and instead the calibration data is shipped
somewhere on the main flash (directly on SPI-/NOR-/NAND flash,
sometimes even inside an UBI volume).

> Please find a better way to identify relevant FW. What exactly affects
> which FW can be used, or would ideally be used? Are different FWs
> required for the same HW in some contexts?
>
> Can we not figure out the relevant FW names in the driver based on some
> identification mechanism (e.g. a more thoroughly defined set of
> compatible strings)?
The only way of auto-detecting a "correct" name would be via
dev_name() (with some prefix this could give something like
ath9k-pci-:00:0e.0.bin).

>> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and
>> + swapping of the EEPROM data if required
>
> CAn we not simply always do this?
I've asked myself this question as well, but unfortunately some
manufacturers ship the EEPROM data with incorrect endianness magic.
Thus I decided to stay consistent with ath9k_platform_data which also
has a boolean (which defaults to false).

>> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM
>> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM
>
> When/why would these be necessary?
sometimes a manufacturer (accidentally) leaves both bands enabled in
the EEPROM data,while the RF hardware is only suitable for one of both
bands. The same settings exist in ath9k_platform_data, serving exactly
the same purpose


Regards,
Martin
--
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 RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

[Mark Rutland]

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 "ath"
> - extend the example so it includes the "compatible" property
> 
>  .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 
> ++
>  1 file changed, 41 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> new file mode 100644
> index 000..bb78f68
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,41 @@
> +* Qualcomm Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: Should be "qca,ath9k"
> +
> +Optional properties:
> +- reg: Address and length of the register set for the device.
> +- qca,gpio-mask: The GPIO mask
> +- qca,gpio-val: The GPIO value
> +- qca,led-pin: The GPIO number to which the LED is connected
> +- qca,led-active-high: The LED is active when the GPIO is HIGH
> +- qca,clk-25mhz: Defines that at 25MHz clock is used

I must assume these apply to internal GPIOs, LEDs and clocks, so I'm
somewhat surprised any description is necessary.

How variable are these in practice?

> +- qca,eeprom-name: The name of the file which contains the EEPROM data (which
> + will be loaded via request_firmware)

The binding shouldn't know anything about the host filesystem,
request_firmware, etc. So the description is a best a little off.

What happens when a new FW comes out? I shouldn't have to update my DT
to cater for that.

Please find a better way to identify relevant FW. What exactly affects
which FW can be used, or would ideally be used? Are different FWs
required for the same HW in some contexts?

Can we not figure out the relevant FW names in the driver based on some
identification mechanism (e.g. a more thoroughly defined set of
compatible strings)?

> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and
> + swapping of the EEPROM data if required

CAn we not simply always do this?

> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM
> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM

When/why would these be necessary?

Thanks,
Mark.
--
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] staging: wilc1000: arrays can't be NULL

[Luis de Bethencourt]

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];

In these 3 cases the arrays are being checked against NULL, which can't
happen. Removing the checks since they will always be true.

Found with smatch:
drivers/staging/wilc1000/host_interface.c:1234 Handle_RcvdNtwrkInfo() warn: 
this array is probably non-NULL. 'hif_drv->usr_scan_req.net_info[i].bssid'
drivers/staging/wilc1000/host_interface.c:1235 Handle_RcvdNtwrkInfo() warn: 
this array is probably non-NULL. 'pstrNetworkInfo->bssid'
drivers/staging/wilc1000/host_interface.c:1253 Handle_RcvdNtwrkInfo() warn: 
this array is probably non-NULL. 
'hif_drv->usr_scan_req.net_info[hif_drv->usr_scan_req.rcvd_ch_cnt].bssid'
drivers/staging/wilc1000/host_interface.c:1254 Handle_RcvdNtwrkInfo() warn: 
this array is probably non-NULL. 'pstrNetworkInfo->bssid'

Signed-off-by: Luis de Bethencourt 
---
Hi,

I am aware this patch gives a few checkpatch.pl warnings about lines being
over 80 characters. Fixing that would be a completely different issue, and
a lengthy one since the file has loads of them.

Hopefully somebody else picks that up. Maybe I should send a hit to the
kernelnewbies mailing list :)

Thanks,
Luis


 drivers/staging/wilc1000/host_interface.c | 38 ++-
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c |  3 +-
 2 files changed, 17 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 9535842..7d5745a 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1231,17 +1231,14 @@ static s32 Handle_RcvdNtwrkInfo(struct wilc_vif *vif,
}
 
for (i = 0; i < hif_drv->usr_scan_req.rcvd_ch_cnt; i++) {
-   if ((hif_drv->usr_scan_req.net_info[i].bssid) &&
-   (pstrNetworkInfo->bssid)) {
-   if 
(memcmp(hif_drv->usr_scan_req.net_info[i].bssid,
-  pstrNetworkInfo->bssid, 6) == 0) {
-   if (pstrNetworkInfo->rssi <= 
hif_drv->usr_scan_req.net_info[i].rssi) {
-   goto done;
-   } else {
-   
hif_drv->usr_scan_req.net_info[i].rssi = pstrNetworkInfo->rssi;
-   bNewNtwrkFound = false;
-   break;
-   }
+   if (memcmp(hif_drv->usr_scan_req.net_info[i].bssid,
+  pstrNetworkInfo->bssid, 6) == 0) {
+   if (pstrNetworkInfo->rssi <= 
hif_drv->usr_scan_req.net_info[i].rssi) {
+   goto done;
+   } else {
+   hif_drv->usr_scan_req.net_info[i].rssi 
= pstrNetworkInfo->rssi;
+   bNewNtwrkFound = false;
+   break;
}
}
}
@@ -1250,20 +1247,17 @@ static s32 Handle_RcvdNtwrkInfo(struct wilc_vif *vif,
if (hif_drv->usr_scan_req.rcvd_ch_cnt < 
MAX_NUM_SCANNED_NETWORKS) {

hif_drv->usr_scan_req.net_info[hif_drv->usr_scan_req.rcvd_ch_cnt].rssi = 
pstrNetworkInfo->rssi;
 
-   if 
(hif_drv->usr_scan_req.net_info[hif_drv->usr_scan_req.rcvd_ch_cnt].bssid &&
-   pstrNetworkInfo->bssid) {
-   
memcpy(hif_drv->usr_scan_req.net_info[hif_drv->usr_scan_req.rcvd_ch_cnt].bssid,
-  pstrNetworkInfo->bssid, 6);
+   
memcpy(hif_drv->usr_scan_req.net_info[hif_drv->usr_scan_req.rcvd_ch_cnt].bssid,
+  pstrNetworkInfo->bssid, 6);
 
-   hif_drv->usr_scan_req.rcvd_ch_cnt++;
+   hif_drv->usr_scan_req.rcvd_ch_cnt++;
 
-   pstrNetworkInfo->new_network = true;
-   pJoinParams = 
host_int_ParseJoinBssParam(pstrNetworkInfo);
+   pstrNetworkInfo->new_network = true;
+   pJoinParams = 
host_int_ParseJoinBssParam(pstrNetworkInfo);
 
-   
hif_drv->usr_scan_req.scan_result(SCAN_EVENT_NETWORK_FOUND, pstrNetworkInfo,
- 

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

[Martin Blumenstingl]

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

 .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt 
b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
new file mode 100644
index 000..bb78f68
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
@@ -0,0 +1,41 @@
+* Qualcomm Atheros ath9k wireless devices
+
+This node provides properties for configuring the ath9k wireless device. The
+node is expected to be specified as a child node of the PCI controller to
+which the wireless chip is connected.
+
+Required properties:
+- compatible: Should be "qca,ath9k"
+
+Optional properties:
+- reg: Address and length of the register set for the device.
+- qca,gpio-mask: The GPIO mask
+- qca,gpio-val: The GPIO value
+- qca,led-pin: The GPIO number to which the LED is connected
+- qca,led-active-high: The LED is active when the GPIO is HIGH
+- qca,clk-25mhz: Defines that at 25MHz clock is used
+- qca,eeprom-name: The name of the file which contains the EEPROM data (which
+   will be loaded via request_firmware)
+- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and
+   swapping of the EEPROM data if required
+- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM
+- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM
+
+In this example, the node is defined as child node of the PCI controller.
+
+pci {
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+
+   ath9k@0,0 {
+   compatible = "qca,ath9k";
+   reg = <0 0 0 0 0>;
+   device_type = "pci";
+   qca,disable-5ghz;
+   };
+   };
+};
-- 
2.9.0

--
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 RFC v2 2/2] ath9k: parse the device configuration from an OF node

[Martin Blumenstingl]

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 of "ath"
- use of_device_is_available instead of simply checking if "np" is NULL
- removed code which read some properties twice

 drivers/net/wireless/ath/ath9k/init.c | 61 +++
 1 file changed, 61 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index a0f4a52..2b5e3db 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -555,6 +557,61 @@ static int ath9k_init_platform(struct ath_softc *sc)
return 0;
 }
 
+static int ath9k_of_init(struct ath_softc *sc)
+{
+   struct device_node *np = sc->dev->of_node;
+   struct ath_hw *ah = sc->sc_ah;
+   struct ath_common *common = ath9k_hw_common(ah);
+   const char *mac, *eeprom_name;
+   int led_pin, ret;
+   u32 gpio_data;
+
+   if (!of_device_is_available(np))
+   return 0;
+
+   ath_dbg(common, CONFIG, "parsing configuration from OF node\n");
+
+   if (!of_property_read_u32(np, "qca,led-pin", _pin))
+   ah->led_pin = led_pin;
+
+   if (!of_property_read_u32(np, "qca,gpio-mask", _data))
+   ah->gpio_mask = gpio_data;
+
+   if (!of_property_read_u32(np, "qca,gpio-val", _data))
+   ah->gpio_val = gpio_data;
+
+   if (of_property_read_bool(np, "qca,clk-25mhz"))
+   ah->is_clk_25mhz = true;
+
+   if (of_property_read_bool(np, "qca,led-active-high"))
+   ah->config.led_active_high = true;
+
+   if (of_property_read_bool(np, "qca,disable-2ghz"))
+   ah->disable_2ghz = true;
+
+   if (of_property_read_bool(np, "qca,disable-5ghz"))
+   ah->disable_5ghz = true;
+
+   if (of_property_read_bool(np, "qca,check-eeprom-endianness"))
+   ah->ah_flags &= ~AH_NO_EEP_SWAP;
+   else
+   ah->ah_flags |= AH_NO_EEP_SWAP;
+
+   if (!of_property_read_string(np, "qca,eeprom-name", _name)) {
+   ret = ath9k_eeprom_request(sc, eeprom_name);
+   if (ret)
+   return ret;
+   }
+
+   mac = of_get_mac_address(np);
+   if (mac)
+   ether_addr_copy(common->macaddr, mac);
+
+   ah->ah_flags &= ~AH_USE_EEPROM;
+
+   return 0;
+}
+
 static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
const struct ath_bus_ops *bus_ops)
 {
@@ -611,6 +668,10 @@ static int ath9k_init_softc(u16 devid, struct ath_softc 
*sc,
if (ret)
return ret;
 
+   ret = ath9k_of_init(sc);
+   if (ret)
+   return ret;
+
if (ath9k_led_active_high != -1)
ah->config.led_active_high = ath9k_led_active_high == 1;
 
-- 
2.9.0

--
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 v2] ath9k: add devicetree support to ath9k

[Martin Blumenstingl]

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: extend and improve handling of ath9k_platform_data"

changes in v1 -> v2:
This addresses all issues found by Christian Lamparter (thanks!), the
detailed changes are documented in each patch.


--
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 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Ben Greear]

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 station is powered off
abruptly (inactive timer probes client via null func after the inactive
time reaches beyond the threshold). Fix this by disabling the workaround
(getting the ACK status of NULL func frames by sending via HTT mgmt-tx
  path) introduced by the change ("ath10k: fix beacon loss handling ")
for QCA99X0 and later chipsets. The normal tx path provides the proper
ACK status for NULL data frames. As of now disable this workaround for
chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
completely get rid of this workaround for all the chipsets


Did you see my fix for the tx-status that Kalle posted about recently?
That fixed my problem with 9980, but I normally test status with tx over
the htt mgt path instead of wmi path, so possibly that makes a difference.

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

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

[Mohammed Shafi Shajakhan]

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 
---
 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index dfb3db0..689d6ce 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1675,7 +1675,7 @@ static int ath10k_core_init_firmware_features(struct 
ath10k *ar)
case ATH10K_FW_WMI_OP_VERSION_10_4:
case ATH10K_FW_WMI_OP_VERSION_UNSET:
case ATH10K_FW_WMI_OP_VERSION_MAX:
-   WARN_ON(1);
+   ath10k_err(ar, "htt op version not found from fw meta 
data");
return -EINVAL;
}
}
-- 
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

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

[Mohammed Shafi Shajakhan]

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 via null func after the inactive
time reaches beyond the threshold). Fix this by disabling the workaround
(getting the ACK status of NULL func frames by sending via HTT mgmt-tx
 path) introduced by the change ("ath10k: fix beacon loss handling ")
for QCA99X0 and later chipsets. The normal tx path provides the proper
ACK status for NULL data frames. As of now disable this workaround for
chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
completely get rid of this workaround for all the chipsets

Signed-off-by: Tamizh chelvam 
Signed-off-by: Mohammed Shafi Shajakhan 
---
 drivers/net/wireless/ath/ath10k/core.c | 3 +++
 drivers/net/wireless/ath/ath10k/core.h | 6 ++
 drivers/net/wireless/ath/ath10k/mac.c  | 1 +
 3 files changed, 10 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 689d6ce..9978e4a 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+   .disable_null_func_workaround = true,
},
},
{
@@ -204,6 +205,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+   .disable_null_func_workaround = true,
},
},
{
@@ -262,6 +264,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
+   .disable_null_func_workaround = true,
},
},
 };
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9..e8c728c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -750,6 +750,12 @@ struct ath10k {
const char *board;
size_t board_size;
size_t board_ext_size;
+   /* Workaround of sending NULL data frames via
+* HTT mgmt TX and getting the proper ACK status does
+* not works for chipsets QCA99X0 and later, while
+* Tx data path reports the ACK status properly.
+*/
+   bool disable_null_func_workaround;
} fw;
} hw_params;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a16..f1e9672 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3236,6 +3236,7 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
 * mode though because AP don't sleep.
 */
if (ar->htt.target_version_major < 3 &&
+   !ar->hw_params.fw.disable_null_func_workaround &&
(ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
  ar->running_fw->fw_file.fw_features))
-- 
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: [PATCH 2/2] Documentation: dt: net: add ath9k wireless device binding

[Christian Lamparter]

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 
Rob Herring 
devicet...@vger.kernel.org

for all patches which touch Documentation/devicetree/... .

Also, I know (from experience) that they would prefer it, if you put
the device tree binding patch at the top of the series (i.e. make it:
[PATCH 1/2] dt-bindings...). ;-)

> ---
>  .../devicetree/bindings/net/wireless/ath,ath9k.txt | 40 
> ++
>  1 file changed, 40 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/ath,ath9k.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/ath,ath9k.txt 
> b/Documentation/devicetree/bindings/net/wireless/ath,ath9k.txt
> new file mode 100644
> index 000..d6f5471
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ath,ath9k.txt
> @@ -0,0 +1,40 @@
> +* Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: Should be "ath,ath9k"
Documentation/devicetree/bindings/vendor-prefixes.txt has an entry for
Qualcomm Atheros, Inc. => qca. I would use that instead, given that this
is a new binding, so there's '"no"' legacy code to worry about.

> +
> +Optional properties:
> +- reg: Address and length of the register set for the device.
> +- ath,gpio-mask: The GPIO mask
> +- ath,gpio-val: The GPIO value
> +- ath,led-pin: The GPIO number to which the LED is connected
> +- ath,led-active-high: The LED is active when the GPIO is HIGH
> +- ath,clk-25mhz: Defines that at 25MHz clock is used
> +- ath,eeprom-name: The name of the file which contains the EEPROM data (which
> + will be loaded via request_firmware)
> +- ath,check-eeprom-endianness: Allow checking the EEPROM endianness and
> + swapping of the EEPROM data if required
> +- ath,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM
> +- ath,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM
> +
> +In this example, the node is defined as child node of the PCI controller.
> +
> +pci {
> + pcie@0 {
> + reg = <0 0 0 0 0>;
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> +
> + ath9k@0,0 {
compatible = "qca,ath9k"; ?

> + reg = <0 0 0 0 0>;
> + device_type = "pci";
> + ath,disable-5ghz;
> + };
> + };
> +};
> 

--
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/2] ath9k: parse the device configuration from an OF node

[Christian Lamparter]

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 
> ---
>  drivers/net/wireless/ath/ath9k/init.c | 70 
> +++
>  1 file changed, 70 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/init.c 
> b/drivers/net/wireless/ath/ath9k/init.c
> index a0f4a52..0f76137 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -20,6 +20,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
> @@ -555,6 +557,70 @@ static int ath9k_init_platform(struct ath_softc *sc)
>   return 0;
>  }
>  
> +static int ath9k_of_init(struct ath_softc *sc)
> +{
> + struct device_node *np = sc->dev->of_node;
> + struct ath_hw *ah = sc->sc_ah;
> + struct ath_common *common = ath9k_hw_common(ah);
> + const char *mac, *eeprom_name;
> + int led_pin, ret;
> + u32 gpio_data;
> +
> + if (!np)
> + return 0;

Can you please add a of_device_is_available check here too? So
we can skip it with the status property?

> +
> + ath_dbg(common, CONFIG, "parsing configuration from OF node\n");
> +
> + if (!of_property_read_u32(np, "ath,led-pin", _pin))
> + ah->led_pin = led_pin;
> +
> + if (!of_property_read_u32(np, "ath,gpio-mask", _data))
> + ah->gpio_mask = gpio_data;
> +
> + if (!of_property_read_u32(np, "ath,gpio-val", _data))
> + ah->gpio_val = gpio_data;
> +
> + if (of_property_read_bool(np, "ath,clk-25mhz"))
> + ah->is_clk_25mhz = true;
> +
> + if (!of_property_read_u32(np, "ath,gpio-mask", _data))
> + ah->gpio_mask = gpio_data;
^^
Duplicated? (see 11 lines above)

> +
> + if (!of_property_read_u32(np, "ath,gpio-val", _data))
> + ah->gpio_val = gpio_data;
^^
Duplicated?

> +
> + if (of_property_read_bool(np, "ath,clk-25mhz"))
> + ah->is_clk_25mhz = true;
^^
Duplicated?

> +
> + if (of_property_read_bool(np, "ath,led-active-high"))
> + ah->config.led_active_high = true;
> +
> + if (of_property_read_bool(np, "ath,disable-2ghz"))
> + ah->disable_2ghz = true;
> +
> + if (of_property_read_bool(np, "ath,disable-5ghz"))
> + ah->disable_5ghz = true;
> +
> + if (of_property_read_bool(np, "ath,check-eeprom-endianness"))
> + ah->ah_flags &= ~AH_NO_EEP_SWAP;
> + else
> + ah->ah_flags |= AH_NO_EEP_SWAP;
> +
> + if (!of_property_read_string(np, "ath,eeprom-name", _name)) {
> + ret = ath9k_eeprom_request(sc, eeprom_name);
> + if (ret)
> + return ret;
> + }
> +
> + mac = of_get_mac_address(np);
> + if (mac)
> + ether_addr_copy(common->macaddr, mac);
> +
> + ah->ah_flags &= ~AH_USE_EEPROM;
> +
> + return 0;
> +}
> +
>  static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
>   const struct ath_bus_ops *bus_ops)
>  {
> @@ -611,6 +677,10 @@ static int ath9k_init_softc(u16 devid, struct ath_softc 
> *sc,
>   if (ret)
>   return ret;
>  
> + ret = ath9k_of_init(sc);
> + if (ret)
> + return ret;
> +
>   if (ath9k_led_active_high != -1)
>   ah->config.led_active_high = ath9k_led_active_high == 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

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

[Martin Blumenstingl]

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 Documentation/devicetree/bindings/net/wireless/ath,ath9k.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ath,ath9k.txt 
b/Documentation/devicetree/bindings/net/wireless/ath,ath9k.txt
new file mode 100644
index 000..d6f5471
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ath,ath9k.txt
@@ -0,0 +1,40 @@
+* Atheros ath9k wireless devices
+
+This node provides properties for configuring the ath9k wireless device. The
+node is expected to be specified as a child node of the PCI controller to
+which the wireless chip is connected.
+
+Required properties:
+- compatible: Should be "ath,ath9k"
+
+Optional properties:
+- reg: Address and length of the register set for the device.
+- ath,gpio-mask: The GPIO mask
+- ath,gpio-val: The GPIO value
+- ath,led-pin: The GPIO number to which the LED is connected
+- ath,led-active-high: The LED is active when the GPIO is HIGH
+- ath,clk-25mhz: Defines that at 25MHz clock is used
+- ath,eeprom-name: The name of the file which contains the EEPROM data (which
+   will be loaded via request_firmware)
+- ath,check-eeprom-endianness: Allow checking the EEPROM endianness and
+   swapping of the EEPROM data if required
+- ath,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM
+- ath,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM
+
+In this example, the node is defined as child node of the PCI controller.
+
+pci {
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+
+   ath9k@0,0 {
+   reg = <0 0 0 0 0>;
+   device_type = "pci";
+   ath,disable-5ghz;
+   };
+   };
+};
-- 
2.9.0

--
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] ath9k: add devicetree support to ath9k

[Martin Blumenstingl]

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: extend and improve handling of ath9k_platform_data"

--
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 1/6] ath9k: Allow configuration of LED polarity in platform data.

[Martin Blumenstingl]

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 
---
 drivers/net/wireless/ath/ath9k/init.c | 3 +++
 include/linux/ath9k_platform.h| 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index 2ee8624..384929d 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -527,6 +527,9 @@ static int ath9k_init_soc_platform(struct ath_softc *sc)
return ret;
}
 
+   if (pdata->led_active_high)
+   ah->config.led_active_high = true;
+
if (pdata->tx_gain_buffalo)
ah->config.tx_gain_buffalo = true;
 
diff --git a/include/linux/ath9k_platform.h b/include/linux/ath9k_platform.h
index e66153d..76860a4 100644
--- a/include/linux/ath9k_platform.h
+++ b/include/linux/ath9k_platform.h
@@ -40,6 +40,7 @@ struct ath9k_platform_data {
bool tx_gain_buffalo;
bool disable_2ghz;
bool disable_5ghz;
+   bool led_active_high;
 
int (*get_mac_revision)(void);
int (*external_reset)(void);
-- 
2.9.0

--
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

ath9k: extend and improve handling of ath9k_platform_data

[Martin Blumenstingl]

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 code cleanups which include removal of unused variables,
  return values duplicate code (no functional changes)
- ath9k_hw_init_macaddr will not change common->macaddr anymore
  to make it independent of whether it's called before or after
  ath9k_platform_data initialization in init.c
- initialization based on ath9k_platform_data in init.c is now
  easier to understand (no functional changes)

Patch 6 from this series supersedes the following patch by Eduardo
Abinader: "ath9k: return false when reading wrong eeprom offset" [0]


[0] https://patchwork.kernel.org/patch/9181371/


--
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 5/6] ath9k: move all ath9k_platform_data initialization into one function

[Martin Blumenstingl]

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 ++-
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index 384929d..a0f4a52 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -512,15 +512,31 @@ static void ath9k_eeprom_release(struct ath_softc *sc)
release_firmware(sc->sc_ah->eeprom_blob);
 }
 
-static int ath9k_init_soc_platform(struct ath_softc *sc)
+static int ath9k_init_platform(struct ath_softc *sc)
 {
struct ath9k_platform_data *pdata = sc->dev->platform_data;
struct ath_hw *ah = sc->sc_ah;
-   int ret = 0;
+   struct ath_common *common = ath9k_hw_common(ah);
+   int ret;
 
if (!pdata)
return 0;
 
+   if (!pdata->use_eeprom) {
+   ah->ah_flags &= ~AH_USE_EEPROM;
+   ah->gpio_mask = pdata->gpio_mask;
+   ah->gpio_val = pdata->gpio_val;
+   ah->led_pin = pdata->led_pin;
+   ah->is_clk_25mhz = pdata->is_clk_25mhz;
+   ah->get_mac_revision = pdata->get_mac_revision;
+   ah->external_reset = pdata->external_reset;
+   ah->disable_2ghz = pdata->disable_2ghz;
+   ah->disable_5ghz = pdata->disable_5ghz;
+
+   if (!pdata->endian_check)
+   ah->ah_flags |= AH_NO_EEP_SWAP;
+   }
+
if (pdata->eeprom_name) {
ret = ath9k_eeprom_request(sc, pdata->eeprom_name);
if (ret)
@@ -533,13 +549,15 @@ static int ath9k_init_soc_platform(struct ath_softc *sc)
if (pdata->tx_gain_buffalo)
ah->config.tx_gain_buffalo = true;
 
-   return ret;
+   if (pdata->macaddr)
+   ether_addr_copy(common->macaddr, pdata->macaddr);
+
+   return 0;
 }
 
 static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
const struct ath_bus_ops *bus_ops)
 {
-   struct ath9k_platform_data *pdata = sc->dev->platform_data;
struct ath_hw *ah = NULL;
struct ath9k_hw_capabilities *pCap;
struct ath_common *common;
@@ -553,6 +571,8 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
ah->dev = sc->dev;
ah->hw = sc->hw;
ah->hw_version.devid = devid;
+   ah->ah_flags |= AH_USE_EEPROM;
+   ah->led_pin = -1;
ah->reg_ops.read = ath9k_ioread32;
ah->reg_ops.multi_read = ath9k_multi_ioread32;
ah->reg_ops.write = ath9k_iowrite32;
@@ -572,22 +592,6 @@ static int ath9k_init_softc(u16 devid, struct ath_softc 
*sc,
if (!ath9k_is_chanctx_enabled())
sc->cur_chan->hw_queue_base = 0;
 
-   if (!pdata || pdata->use_eeprom) {
-   ah->ah_flags |= AH_USE_EEPROM;
-   sc->sc_ah->led_pin = -1;
-   } else {
-   sc->sc_ah->gpio_mask = pdata->gpio_mask;
-   sc->sc_ah->gpio_val = pdata->gpio_val;
-   sc->sc_ah->led_pin = pdata->led_pin;
-   ah->is_clk_25mhz = pdata->is_clk_25mhz;
-   ah->get_mac_revision = pdata->get_mac_revision;
-   ah->external_reset = pdata->external_reset;
-   ah->disable_2ghz = pdata->disable_2ghz;
-   ah->disable_5ghz = pdata->disable_5ghz;
-   if (!pdata->endian_check)
-   ah->ah_flags |= AH_NO_EEP_SWAP;
-   }
-
common->ops = >reg_ops;
common->bus_ops = bus_ops;
common->ps_ops = _ps_ops;
@@ -603,7 +607,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
 */
ath9k_init_pcoem_platform(sc);
 
-   ret = ath9k_init_soc_platform(sc);
+   ret = ath9k_init_platform(sc);
if (ret)
return ret;
 
@@ -649,9 +653,6 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
if (ret)
goto err_hw;
 
-   if (pdata && pdata->macaddr)
-   memcpy(common->macaddr, pdata->macaddr, ETH_ALEN);
-
ret = ath9k_init_queues(sc);
if (ret)
goto err_queues;
-- 
2.9.0

--
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 6/6] ath9k: simplify the code-paths when not using the built-in EEPROM

[Martin Blumenstingl]

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.
With this change all eeprom data handling is now unified in eeprom.c.

Signed-off-by: Martin Blumenstingl 
---
This supersedes the following patch by Eduardo Abinader
:
"ath9k: return false when reading wrong eeprom offset"
https://patchwork.kernel.org/patch/9181371/

 drivers/net/wireless/ath/ath9k/ahb.c| 18 +++
 drivers/net/wireless/ath/ath9k/eeprom.c | 19 +--
 drivers/net/wireless/ath/ath9k/pci.c| 41 +++--
 3 files changed, 28 insertions(+), 50 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ahb.c 
b/drivers/net/wireless/ath/ath9k/ahb.c
index bd4a1a6..bea6186 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -18,7 +18,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include "ath9k.h"
 
@@ -58,20 +57,9 @@ static void ath_ahb_read_cachesize(struct ath_common 
*common, int *csz)
 
 static bool ath_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
 {
-   struct ath_softc *sc = (struct ath_softc *)common->priv;
-   struct platform_device *pdev = to_platform_device(sc->dev);
-   struct ath9k_platform_data *pdata;
-
-   pdata = dev_get_platdata(>dev);
-   if (off >= (ARRAY_SIZE(pdata->eeprom_data))) {
-   ath_err(common,
-   "%s: flash read failed, offset %08x is out of range\n",
-   __func__, off);
-   return false;
-   }
-
-   *data = pdata->eeprom_data[off];
-   return true;
+   ath_err(common, "%s: eeprom data has to be provided externally\n",
+   __func__);
+   return false;
 }
 
 static struct ath_bus_ops ath_ahb_bus_ops  = {
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c 
b/drivers/net/wireless/ath/ath9k/eeprom.c
index a794157..ba1c8ba 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -15,6 +15,7 @@
  */
 
 #include "hw.h"
+#include 
 
 void ath9k_hw_analog_shift_regwrite(struct ath_hw *ah, u32 reg, u32 val)
 {
@@ -108,26 +109,30 @@ void ath9k_hw_usb_gen_fill_eeprom(struct ath_hw *ah, u16 
*eep_data,
}
 }
 
-static bool ath9k_hw_nvram_read_blob(struct ath_hw *ah, u32 off,
+static bool ath9k_hw_nvram_read_blob(u16 *blob, size_t blob_size, u32 offset,
 u16 *data)
 {
-   u16 *blob_data;
-
-   if (off * sizeof(u16) > ah->eeprom_blob->size)
+   if (offset * sizeof(u16) > blob_size)
return false;
 
-   blob_data = (u16 *)ah->eeprom_blob->data;
-   *data =  blob_data[off];
+   *data =  blob[offset];
return true;
 }
 
 bool ath9k_hw_nvram_read(struct ath_hw *ah, u32 off, u16 *data)
 {
struct ath_common *common = ath9k_hw_common(ah);
+   struct ath9k_platform_data *pdata = ah->dev->platform_data;
bool ret;
 
if (ah->eeprom_blob)
-   ret = ath9k_hw_nvram_read_blob(ah, off, data);
+   ret = ath9k_hw_nvram_read_blob((u16 *) ah->eeprom_blob->data,
+  ah->eeprom_blob->size, off,
+  data);
+   else if (pdata && !pdata->use_eeprom && pdata->eeprom_data)
+   ret = ath9k_hw_nvram_read_blob(pdata->eeprom_data,
+  ARRAY_SIZE(pdata->eeprom_data),
+  off, data);
else
ret = common->bus_ops->eeprom_read(common, off, data);
 
diff --git a/drivers/net/wireless/ath/ath9k/pci.c 
b/drivers/net/wireless/ath/ath9k/pci.c
index 7cdaf40..0dd454a 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include "ath9k.h"
 
@@ -786,35 +785,21 @@ static void ath_pci_read_cachesize(struct ath_common 
*common, int *csz)
 
 static bool ath_pci_eeprom_read(struct ath_common *common, u32 off, u16 *data)
 {
-   struct ath_softc *sc = (struct ath_softc *) common->priv;
-   struct ath9k_platform_data *pdata = sc->dev->platform_data;
-
-   if (pdata && !pdata->use_eeprom) {
-   if (off >= (ARRAY_SIZE(pdata->eeprom_data))) {
-   ath_err(common,
-   "%s: eeprom read failed, offset %08x is out of 
range\n",
-   __func__, off);
-   }
-
-   *data = pdata->eeprom_data[off];
-   } else {
-   struct ath_hw *ah = (struct ath_hw *) common->ah;
-
-   common->ops->read(ah, 

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

[Martin Blumenstingl]

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 a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 4dd3aca..fa59117 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -471,7 +471,7 @@ static void ath9k_hw_init_defaults(struct ath_hw *ah)
ah->tx_trig_level = (AR_FTRIG_512B >> AR_FTRIG_S);
 }
 
-static int ath9k_hw_init_macaddr(struct ath_hw *ah)
+static void ath9k_hw_init_macaddr(struct ath_hw *ah)
 {
struct ath_common *common = ath9k_hw_common(ah);
int i;
@@ -480,7 +480,7 @@ static int ath9k_hw_init_macaddr(struct ath_hw *ah)
 
/* MAC address may already be loaded via ath9k_platform_data */
if (is_valid_ether_addr(common->macaddr))
-   return 0;
+   return;
 
for (i = 0; i < 3; i++) {
eeval = ah->eep_ops->get_eeprom(ah, EEP_MAC[i]);
@@ -489,7 +489,7 @@ static int ath9k_hw_init_macaddr(struct ath_hw *ah)
}
 
if (is_valid_ether_addr(common->macaddr))
-   return 0;
+   return;
 
ath_err(common, "eeprom contains invalid mac address: %pM\n",
common->macaddr);
@@ -498,7 +498,7 @@ static int ath9k_hw_init_macaddr(struct ath_hw *ah)
ath_err(common, "random mac address will be used: %pM\n",
common->macaddr);
 
-   return 0;
+   return;
 }
 
 static int ath9k_hw_post_init(struct ath_hw *ah)
@@ -637,12 +637,7 @@ static int __ath9k_hw_init(struct ath_hw *ah)
if (r)
return r;
 
-   r = ath9k_hw_init_macaddr(ah);
-   if (r) {
-   ath_err(common, "Failed to initialize MAC address\n");
-   return r;
-   }
-
+   ath9k_hw_init_macaddr(ah);
ath9k_hw_init_hang_checks(ah);
 
common->state = ATH_HW_INITIALIZED;
-- 
2.9.0

--
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 3/6] ath9k: ath9k_hw_init_macaddr should not overwrite valid MAC addresses

[Martin Blumenstingl]

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 Blumenstingl 
---
 drivers/net/wireless/ath/ath9k/hw.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 4f98ca0..4dd3aca 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -478,21 +478,25 @@ static int ath9k_hw_init_macaddr(struct ath_hw *ah)
u16 eeval;
static const u32 EEP_MAC[] = { EEP_MAC_LSW, EEP_MAC_MID, EEP_MAC_MSW };
 
+   /* MAC address may already be loaded via ath9k_platform_data */
+   if (is_valid_ether_addr(common->macaddr))
+   return 0;
+
for (i = 0; i < 3; i++) {
eeval = ah->eep_ops->get_eeprom(ah, EEP_MAC[i]);
common->macaddr[2 * i] = eeval >> 8;
common->macaddr[2 * i + 1] = eeval & 0xff;
}
-   if (!is_valid_ether_addr(common->macaddr)) {
-   ath_err(common,
-   "eeprom contains invalid mac address: %pM\n",
-   common->macaddr);
 
-   random_ether_addr(common->macaddr);
-   ath_err(common,
-   "random mac address will be used: %pM\n",
-   common->macaddr);
-   }
+   if (is_valid_ether_addr(common->macaddr))
+   return 0;
+
+   ath_err(common, "eeprom contains invalid mac address: %pM\n",
+   common->macaddr);
+
+   random_ether_addr(common->macaddr);
+   ath_err(common, "random mac address will be used: %pM\n",
+   common->macaddr);
 
return 0;
 }
-- 
2.9.0

--
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 2/6] ath9k: remove variable which is set but never read

[Martin Blumenstingl]

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 
b/drivers/net/wireless/ath/ath9k/hw.c
index 8b2895f..4f98ca0 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -474,15 +474,12 @@ static void ath9k_hw_init_defaults(struct ath_hw *ah)
 static int ath9k_hw_init_macaddr(struct ath_hw *ah)
 {
struct ath_common *common = ath9k_hw_common(ah);
-   u32 sum;
int i;
u16 eeval;
static const u32 EEP_MAC[] = { EEP_MAC_LSW, EEP_MAC_MID, EEP_MAC_MSW };
 
-   sum = 0;
for (i = 0; i < 3; i++) {
eeval = ah->eep_ops->get_eeprom(ah, EEP_MAC[i]);
-   sum += eeval;
common->macaddr[2 * i] = eeval >> 8;
common->macaddr[2 * i + 1] = eeval & 0xff;
}
-- 
2.9.0

--
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: Driver for rtl8188ee

[Larry Finger]

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 released approximately 2.5 years ago. If yours is older than that, you 
could use the external driver from http://github.com/lwfinger/rtlwifi_new.git. 
The problem with using that driver is that I'm not sure that a minimal 
distribution like Puppy will have all the tools needed to build external 
modules. That question will need to be asked on a Puppy forum.


Larry


--
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 v2] mac80211: mesh: Add support for HW RC implementation

[Maxim Altshul]

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.

Signed-off-by: Maxim Altshul 
---
Changed previous implementation according to Johannes's
comment. Combined the RC test and throughput assignment
to a sta_get_expected_throughput function.
Using the function both from airtime_link_metric and
from sta_set_sinfo. 

 net/mac80211/mesh_hwmp.c | 22 ++
 net/mac80211/sta_info.c  | 22 +-
 net/mac80211/sta_info.h  |  2 ++
 3 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index c6be0b4..39f9541 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -322,19 +322,25 @@ static u32 airtime_link_metric_get(struct ieee80211_local 
*local,
int device_constant = 1 << ARITH_SHIFT;
int test_frame_len = TEST_FRAME_LEN << ARITH_SHIFT;
int s_unit = 1 << ARITH_SHIFT;
-   int rate, err;
+   int rate = 0, err = 0;
u32 tx_time, estimated_retx;
u64 result;
 
-   if (sta->mesh->fail_avg >= 100)
-   return MAX_METRIC;
+   /* try to get rate based on HW/SW RC algorithm */
+   sta_get_expected_throughput(sta, );
 
-   sta_set_rate_info_tx(sta, >tx_stats.last_rate, );
-   rate = cfg80211_calculate_bitrate();
-   if (WARN_ON(!rate))
-   return MAX_METRIC;
+   /* if we did not get a rate */
+   if (!rate) {
+   if (sta->mesh->fail_avg >= 100)
+   return MAX_METRIC;
 
-   err = (sta->mesh->fail_avg << ARITH_SHIFT) / 100;
+   sta_set_rate_info_tx(sta, >tx_stats.last_rate, );
+   rate = cfg80211_calculate_bitrate();
+   if (WARN_ON(!rate))
+   return MAX_METRIC;
+
+   err = (sta->mesh->fail_avg << ARITH_SHIFT) / 100;
+   }
 
/* bitrate is in units of 100 Kbps, while we need rate in units of
 * 1Mbps. This will be corrected on tx_time computation.
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 63ea6cb..9580946 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2069,14 +2069,26 @@ void sta_set_sinfo(struct sta_info *sta, struct 
station_info *sinfo)
if (test_sta_flag(sta, WLAN_STA_TDLS_PEER))
sinfo->sta_flags.set |= BIT(NL80211_STA_FLAG_TDLS_PEER);
 
-   /* check if the driver has a SW RC implementation */
-   if (ref && ref->ops->get_expected_throughput)
-   thr = ref->ops->get_expected_throughput(sta->rate_ctrl_priv);
-   else
-   thr = drv_get_expected_throughput(local, >sta);
+   sta_get_expected_throughput(sta, );
 
if (thr != 0) {
sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
sinfo->expected_throughput = thr;
}
 }
+
+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))
+   ref = local->rate_ctrl;
+
+   /* check if the driver has a SW RC implementation */
+   if (ref && ref->ops->get_expected_throughput)
+   *thr = ref->ops->get_expected_throughput(sta->rate_ctrl_priv);
+   else
+   *thr = drv_get_expected_throughput(local, >sta);
+}
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 2cafb21..8535443 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -661,6 +661,8 @@ void sta_set_rate_info_tx(struct sta_info *sta,
  struct rate_info *rinfo);
 void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo);
 
+void sta_get_expected_throughput(struct sta_info *sta, u32 *thr);
+
 void ieee80211_sta_expire(struct ieee80211_sub_if_data *sdata,
  unsigned long exp_time);
 u8 sta_info_tx_streams(struct sta_info *sta);
-- 
2.9.0

--
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] staging: wilc1000: fix spelling mistake: "interupts" -> "interrupts"

[Colin King]

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 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index a839a79..39b73fb2 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -1006,7 +1006,7 @@ static int sdio_sync_ext(struct wilc *wilc, int nint)
u32 reg;
 
if (nint > MAX_NUM_INT) {
-   dev_err(>dev, "Too many interupts (%d)...\n", nint);
+   dev_err(>dev, "Too many interrupts (%d)...\n", nint);
return 0;
}
if (nint > MAX_NUN_INT_THRPT_ENH2) {
diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 4268e2f..22cf4b7 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -1082,7 +1082,7 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)
int ret, i;
 
if (nint > MAX_NUM_INT) {
-   dev_err(>dev, "Too many interupts (%d)...\n", nint);
+   dev_err(>dev, "Too many interrupts (%d)...\n", nint);
return 0;
}
 
-- 
2.8.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

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

[Luis de Bethencourt]

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 a/drivers/staging/wilc1000/wilc_debugfs.c 
b/drivers/staging/wilc1000/wilc_debugfs.c
index 48797dc..6252931 100644
--- a/drivers/staging/wilc1000/wilc_debugfs.c
+++ b/drivers/staging/wilc1000/wilc_debugfs.c
@@ -115,7 +115,7 @@ static int __init wilc_debugfs_init(void)
 
if (!wilc_dir) {
printk("ERR, debugfs create dir\n");
-   return -1;
+   return -EINVAL;
}
 
for (i = 0; i < ARRAY_SIZE(debugfs_info); i++) {
@@ -129,7 +129,7 @@ static int __init wilc_debugfs_init(void)
if (!debugfs_files) {
printk("ERR fail to create the debugfs file, %s\n", 
info->name);
debugfs_remove_recursive(wilc_dir);
-   return -1;
+   return -EINVAL;
}
}
return 0;
-- 
2.6.4

--
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 v2 1/2] staging: wilc1000: fix error handling in wilc_debugfs_init()

[Luis de Bethencourt]

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 
---
 drivers/staging/wilc1000/wilc_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_debugfs.c 
b/drivers/staging/wilc1000/wilc_debugfs.c
index fcbc95d..48797dc 100644
--- a/drivers/staging/wilc1000/wilc_debugfs.c
+++ b/drivers/staging/wilc1000/wilc_debugfs.c
@@ -107,7 +107,7 @@ static int __init wilc_debugfs_init(void)
struct wilc_debugfs_info_t *info;
 
wilc_dir = debugfs_create_dir("wilc_wifi", NULL);
-   if (wilc_dir ==  ERR_PTR(-ENODEV)) {
+   if (PTR_ERR(wilc_dir) == -ENODEV) {
/* it's not error. the debugfs is just not being enabled. */
printk("ERR, kernel has built without debugfs support\n");
return 0;
-- 
2.6.4

--
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: Problems with mwifiex_pcie firmware activation

[Stanislaw Gruszka]

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 device initalize, I'll provide missed dmesg when I get back
> the access.

Have the access now, dmesg is in attachment.

Stanislaw
[0.00] Linux version 4.7.0-rc3+ 
(r...@iot-r5s1-01.wlan.rhts.eng.bos.redhat.com) (gcc version 4.8.5 20150623 
(Red Hat 4.8.5-4) (GCC) ) #3 SMP Fri Jun 17 05:16:00 EDT 2016
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.7.0-rc3+ 
root=/dev/mapper/rhel_iot--r5s1--01-root ro crashkernel=auto 
rd.lvm.lv=rhel_iot-r5s1-01/root rd.lvm.lv=rhel_iot-r5s1-01/swap 
console=ttyS3,115200n81 LANG=en_US.UTF-8
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable
[0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1eff] usable
[0.00] BIOS-e820: [mem 0x1f00-0x1f0f] reserved
[0.00] BIOS-e820: [mem 0x1f10-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x200f] reserved
[0.00] BIOS-e820: [mem 0x2010-0x76e40fff] usable
[0.00] BIOS-e820: [mem 0x76e41000-0x76e70fff] reserved
[0.00] BIOS-e820: [mem 0x76e71000-0x76e96fff] ACPI data
[0.00] BIOS-e820: [mem 0x76e97000-0x77420fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x77421000-0x7771efff] reserved
[0.00] BIOS-e820: [mem 0x7771f000-0x7771] usable
[0.00] BIOS-e820: [mem 0x7772-0x77761fff] reserved
[0.00] BIOS-e820: [mem 0x77762000-0x789e4fff] usable
[0.00] BIOS-e820: [mem 0x789e5000-0x78ff9fff] reserved
[0.00] BIOS-e820: [mem 0x78ffa000-0x78ff] usable
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved
[0.00] BIOS-e820: [mem 0xfed03000-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved
[0.00] BIOS-e820: [mem 0xfed0c000-0xfed0] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1cfff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xfef0-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xff90-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00027fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.8 present.
[0.00] DMI: Dell Inc. Edge Gateway 5000/  , BIOS 00.03.08 11/09/2015
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x28 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 07900 mask FFF00 uncachable
[0.00]   2 base 07A00 mask FFE00 uncachable
[0.00]   3 base 07C00 mask FFC00 uncachable
[0.00]   4 base 1 mask F write-back
[0.00]   5 base 2 mask F8000 write-back
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] total RAM covered: 8080M
[0.00] Found optimal setting for mtrr clean up
[0.00]  gran_size: 64K  chunk_size: 128Mnum_reg: 6  lose 
cover RAM: 0G
[0.00] e820: update [mem 0x7900-0x] usable ==> reserved
[0.00] e820: last_pfn = 0x79000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fd840-0x000fd84f] mapped at 
[880fd840]
[0.00] Base memory trampoline at [88096000] 96000 size 24576
[0.00] BRK [0x0224e000, 0x0224efff] PGTABLE
[0.00] BRK [0x0224f000, 0x0224] PGTABLE
[0.00] BRK [0x0225, 0x02250fff] PGTABLE
[0.00] BRK 

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

[Johannes Berg]

> > 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 thought that the size changed, but missed that you
replaced a u32 with two u16. Thanks for checking :)

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] wlcore: time sync : add support for 64 bit clock

[Machani, Yaniv]

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 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:
> 
> > @@ -74,10 +74,16 @@ struct wl18xx_event_mailbox {
> 
> This struct is evidently used for firmware/host communication.
> 
> >     __le16 bss_loss_bitmap;
> >
> >     /* bitmap of stations (by HLID) which exceeded max tx retries */
> > -   __le32 tx_retry_exceeded_bitmap;
> > +   __le16 tx_retry_exceeded_bitmap;
> > +
> > +   /* time sync high msb*/
> > +   u16 time_sync_tsf_high_msb;
> 
> So first of all, just using u16 instead of __le16 seems wrong.

Agree, should be changed.

> 
> 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.
Of course that for actually using the 64bit information, you will have to 
upgrade the firmware.

Yaniv

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

[Luis de Bethencourt]

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.
>>
>> Also, if there was an error returning -EINVAL instead of -1 is more
>> appropriate.
> 
> These two changes could be argued to be separate changes deserving of
> their own patches.
> 
>> Signed-off-by: Luis de Bethencourt 
> 
> However if everyone else is ok with that, this is:
> 
> Reviewed-by: Julian Calaby 
> 
> Thanks,
> 

Hi Julian,

If you don't mind I will resend as two separate patches and include your
Reviewed-by in both.

Thanks for the review,
Luis
--
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] wlcore: time sync : add support for 64 bit clock

[Johannes Berg]

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:

> @@ -74,10 +74,16 @@ struct wl18xx_event_mailbox {

This struct is evidently used for firmware/host communication.

>   __le16 bss_loss_bitmap;
>  
>   /* bitmap of stations (by HLID) which exceeded max tx
> retries */
> - __le32 tx_retry_exceeded_bitmap;
> + __le16 tx_retry_exceeded_bitmap;
> +
> + /* time sync high msb*/
> + u16 time_sync_tsf_high_msb;

So first of all, just using u16 instead of __le16 seems wrong.

Additionally, this looks like it changes the firmware API, so that
older firmware images will no longer work?

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] wlcore: time sync : add support for 64 bit clock

[Yaniv Machani]

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 +--
 2 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/ti/wl18xx/event.c 
b/drivers/net/wireless/ti/wl18xx/event.c
index ef81184..2c5df43 100644
--- a/drivers/net/wireless/ti/wl18xx/event.c
+++ b/drivers/net/wireless/ti/wl18xx/event.c
@@ -112,12 +112,18 @@ static int wlcore_smart_config_decode_event(struct wl1271 
*wl,
return 0;
 }
 
-static void wlcore_event_time_sync(struct wl1271 *wl, u16 tsf_msb, u16 tsf_lsb)
+static void wlcore_event_time_sync(struct wl1271 *wl,
+  u16 tsf_high_msb, u16 tsf_high_lsb,
+  u16 tsf_low_msb, u16 tsf_low_lsb)
 {
-   u32 clock;
-   /* convert the MSB+LSB to a u32 TSF value */
-   clock = (tsf_msb << 16) | tsf_lsb;
-   wl1271_info("TIME_SYNC_EVENT_ID: clock %u", clock);
+   u32 clock_low;
+   u32 clock_high;
+
+   clock_high = (tsf_high_msb << 16) | tsf_high_lsb;
+   clock_low = (tsf_low_msb << 16) | tsf_low_lsb;
+
+   wl1271_info("TIME_SYNC_EVENT_ID: clock_high %u, clock low %u",
+   clock_high, clock_low);
 }
 
 int wl18xx_process_mailbox_events(struct wl1271 *wl)
@@ -138,8 +144,10 @@ int wl18xx_process_mailbox_events(struct wl1271 *wl)
 
if (vector & TIME_SYNC_EVENT_ID)
wlcore_event_time_sync(wl,
-   mbox->time_sync_tsf_msb,
-   mbox->time_sync_tsf_lsb);
+   mbox->time_sync_tsf_high_msb,
+   mbox->time_sync_tsf_high_lsb,
+   mbox->time_sync_tsf_low_msb,
+   mbox->time_sync_tsf_low_lsb);
 
if (vector & RADAR_DETECTED_EVENT_ID) {
wl1271_info("radar event: channel %d type %s",
@@ -187,11 +195,11 @@ int wl18xx_process_mailbox_events(struct wl1271 *wl)
 */
if (vector & MAX_TX_FAILURE_EVENT_ID)
wlcore_event_max_tx_failure(wl,
-   le32_to_cpu(mbox->tx_retry_exceeded_bitmap));
+   le16_to_cpu(mbox->tx_retry_exceeded_bitmap));
 
if (vector & INACTIVE_STA_EVENT_ID)
wlcore_event_inactive_sta(wl,
-   le32_to_cpu(mbox->inactive_sta_bitmap));
+   le16_to_cpu(mbox->inactive_sta_bitmap));
 
if (vector & REMAIN_ON_CHANNEL_COMPLETE_EVENT_ID)
wlcore_event_roc_complete(wl);
diff --git a/drivers/net/wireless/ti/wl18xx/event.h 
b/drivers/net/wireless/ti/wl18xx/event.h
index 070de12..b436bf9 100644
--- a/drivers/net/wireless/ti/wl18xx/event.h
+++ b/drivers/net/wireless/ti/wl18xx/event.h
@@ -74,10 +74,16 @@ struct wl18xx_event_mailbox {
__le16 bss_loss_bitmap;
 
/* bitmap of stations (by HLID) which exceeded max tx retries */
-   __le32 tx_retry_exceeded_bitmap;
+   __le16 tx_retry_exceeded_bitmap;
+
+   /* time sync high msb*/
+   u16 time_sync_tsf_high_msb;
 
/* bitmap of inactive stations (by HLID) */
-   __le32 inactive_sta_bitmap;
+   __le16 inactive_sta_bitmap;
+
+   /* time sync high lsb*/
+   u16 time_sync_tsf_high_lsb;
 
/* rx BA win size indicated by RX_BA_WIN_SIZE_CHANGE_EVENT_ID */
u8 rx_ba_role_id;
@@ -98,14 +104,15 @@ struct wl18xx_event_mailbox {
u8 sc_sync_channel;
u8 sc_sync_band;
 
-   /* time sync msb*/
-   u16 time_sync_tsf_msb;
+   /* time sync low msb*/
+   u16 time_sync_tsf_low_msb;
+
/* radar detect */
u8 radar_channel;
u8 radar_type;
 
-   /* time sync lsb*/
-   u16 time_sync_tsf_lsb;
+   /* time sync low lsb*/
+   u16 time_sync_tsf_low_lsb;
 
 } __packed;
 
-- 
2.9.0

--
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

Driver for rtl8188ee

[jenda]

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 majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Arnd Bergmann]

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
> generating the patch. It is corrected in v4.
> 
> This patchset [v4] is part of the second patch series for 'wilc1000'.
> The original patch series consisted 7 patches of which only the first 5
> are good. The patch 6 and 7 are being worked on in this series
> in a different way.
> 
> This patch series removes the semaphore 'sem' in 'wilc1000' and also
> restructures the implementation of kthread / message_queue logic with
> a create_singlethread_workqueue() / queue_work() setup.
> 
> These are part of a bigger effort to eliminate all semaphores
> from the linux kernel.
> 
> They build correctly (individually and as a whole).
> 
> NB: The changes are untested

Very nice work!

Whole series
Reviewed-by: Arnd Bergmann 

ARnd
--
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: rt2800usb maintainer/expert?

[Rafał Miłecki]

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 days.
>>
>> And that has to be done in private, because...?
>
> Not at all; it would be great to have some help on this mailing list. I'm 
> struggling to resolve a rt2800usb driver issue, and I've asked a few 
> questions about it on this list. Any help would be greatly appreciated, since 
> I'm struggling with this complex area of the kernel code (I'm comfortable 
> writing Linux drivers, but debugging Wi-Fi and USB issues is new to me.)

Oh, I had to forgot about your e-mails then. If there is someone
interested in the driver, he probably follows linux-wireless@. You can
also take a look at MAINTAINERS or just use
./scripts/get_maintainer.pl -f drivers/net/wireless/ralink/rt2x00/

-- 
Rafał
--
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: WARNING: CPU: 1 PID: 103 at drivers/net/wireless/ath/ath9k/hw.c:2778

[Mika Westerberg]

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: 0x43
> > [6.761794] ath: EEPROM regdomain: 0x6a
> > [6.761796] ath: EEPROM indicates we should expect a direct regpair map
> > [6.761799] ath: Country alpha2 being used: 00
> > [6.761800] ath: Regpair used: 0x6a
> > [6.773482] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> > [6.774048] ieee80211 phy0: Atheros AR9462 Rev:3 mem=0xc9b0, 
> > irq=19
> > [6.774054] [ cut here ]
> > [6.774070] WARNING: CPU: 1 PID: 103 at 
> > drivers/net/wireless/ath/ath9k/hw.c:2778 ath9k_hw_gpio_get+0x161/0x1b0 
> > [ath9k_hw]
> 
> Should be fixed by this:
> 
> ath9k: fix GPIO mask for AR9462 and AR9565
> 
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=e024111f6946f45cf1559a8c6fd48d2d0f696d07
> 

Indeed, that fixes it. 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: rt2800usb firmware rt2870.bin 0.36 not scanning

[Craig McQueen]

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 Yocto. We're using ConnMan
> > > > > 1.30 at the
> > > moment.
> > > >
> > > > Try it with a _desktop x86_64 distribution_ , with a *recent
> > > > kernel* as
> > > > Fedora: (WORK is gnome)
> > > > https://alt.fedoraproject.org/pub/alt/live-respins/
> > >
> > > Hmm, that is non-trivial but I may try it.
> > >
> > > For now, I'll also try a 4.4.6 kernel running on a BeagleBone Black
> > > (with a USB hub to work around another issue with the rt2800usb
> > > driver crashing as described in another e-mail).
> > >
> > > > > We've been finding some instabilities with it periodically
> > > > > disconnecting from some networks. So we tried upgrading the
> > > > > firmware file rt2870.bin from version 0.29 to 0.36. That seems
> > > > > to be more stable with the network. However, we're finding that
> > > > > it initially doesn't connect, until the Wi-Fi has been disabled
> > > > > and then re-
> > enabled. '
> > > > scan wifi'
> > > > > and 'iwlist scan' don't return anything until Wi-Fi has been
> > > > > disabled and then re-enabled.
> > > >
> > > > Don't use any wrapper(NM, ConnMan, wicd, ...), usually are buggy.
> > > > You should use raw commands "iw" and "wpa_supplicant". Hints:
> > > > https://wireless.wiki.kernel.org/en/users/documentation/iw and
> > > > wpa_supplicant always running with "-Dnl80211"
> > >
> > > Okay, I've stripped down the system so ConnMan, udev rules aren't
> > running.
> > >
> > > On all systems, after plugging in the device, I have to issue:
> > >
> > > ip link set wlan0 up
> > >
> > > After this, I try to do a scan:
> > >
> > > iw dev wlan0 scan
> > >
> > > On kernel 4.4.6, with firmware 0.36, it works fine (lists APs it
> > > finds). On kernel 3.14.x, with firmware 0.29, it works fine. But on
> > > kernel 3.14.x, with firmware 0.36, it returns nothing. But then, if I do 
> > > this:
> > >
> > > ip link set wlan0 down
> > > ip link set wlan0 up
> > > iw dev wlan0 scan
> > >
> > > Then it works fine.
> > >
> > > So, the question is, why does firmware 0.36 with kernel 3.14.x not
> > > work until I've made the interface go up, then down, and then up again?
> >
> > I've managed to build, using Yocto, kernel 4.4.12 for BeagleBone. When
> > I run it, it has the same problem. That's different from the Ubuntu
> > 16.04 for BeagleBone using 4.4.6 kernel.
> >
> > With my Yocto build, it had a different version of the 'ip' and 'iw'
> commands.
> > So I tried copying the Ubuntu versions, but that didn't make a
> > difference. I tried using the Yocto built 4.4.12 kernel with the
> > Ubuntu root filesystem, but it halted during the boot process (don't
> > know why). My best guess is that there's some kernel config difference
> > that makes a difference, but there are many differences, so I'm not sure
> which one it might be.
> >
> > I'm not sure at this point how to narrow it down to the root cause.
> > Any advice?
> >
> > I wonder if maybe there's a race condition in the rt2800usb driver
> > between loading the rt2870.bin firmware and doing the interface-up
> initialisation.
> > Normally the firmware loads at the point of doing the 'iw link set wlan0 up'
> > command. Is there a way to force the firmware to load before that
> > command?
> 
> I've got two rt2800 devices:
> 
> * D-Link DWA-140 with RT chipset 5392, rev 0223, and RF chipset 5372
> * Edup EP-N8537 with RT chipset 5390, rev 0502, and RF chipset 5370
> 
> I've also found that with the Yocto-built 4.4.12 kernel, this no-scan issue 
> only
> happens to the Edup with the 5390 chipset. The D-Link is fine.

Actually, I was wrong. With the 3.14.x Yocto-built kernel, this no-scan issue 
only happens with the Edup with the 5390 chipset, and the D-Link is fine.

But further testing with the 4.4.12 Yocto-built kernel shows that it randomly 
sometimes happens and sometimes doesn't with either the Edup or D-Link devices. 
That's especially interesting, because it suggests that there may be a race 
condition happening during the driver initialisation code (called from 
rt2x00lib_start()). At first I thought it was a race condition between the 
calls to rt2x00lib_load_firmware() and rt2x00lib_initialize(), but adding a 
time delay between those calls didn't help.

I'm wondering what the difference is between the two chipsets, so that the 
problem happens more on one chipset than the other. But not exclusively, as I 
mentioned above, so again, this points to a marginal timing issue that affects 
one more than the other.

> With the Ubuntu 4.4.6 kernel, both devices work fine, without this no-scan
> problem.
> ...

-- 
Craig McQueen

RE: rt2800usb maintainer/expert?

[Craig McQueen]

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 great to have some help on this mailing list. I'm 
struggling to resolve a rt2800usb driver issue, and I've asked a few questions 
about it on this list. Any help would be greatly appreciated, since I'm 
struggling with this complex area of the kernel code (I'm comfortable writing 
Linux drivers, but debugging Wi-Fi and USB issues is new to me.)

Regards,
Craig

N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: rt2800usb maintainer/expert?

[Rafał Miłecki]

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 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