* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Pali Rohár @ 2016-12-24 18:44 UTC (permalink / raw)
To: Pavel Machek
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20161224181730.GD13590@amd>
[-- Attachment #1: Type: Text/Plain, Size: 1277 bytes --]
On Saturday 24 December 2016 19:17:30 Pavel Machek wrote:
> Hi!
>
> > In case there is no valid MAC address kernel generates random one.
> > This patch propagate this generated MAC address back to NVS data
> > which will be uploaded to wl1251 chip. So HW would have same MAC
> > address as linux kernel uses.
> >
> > return 0;
> >
> > }
> >
> > +static int wl1251_write_nvs_mac(struct wl1251 *wl)
> > +{
>
> The name is quite confusing, this sounds like writing into
> non-volatile storage.
>
> > + int i;
> > +
> > + if (wl->nvs_len < 0x24)
> > + return -ENODATA;
> > +
> > + /* length is 2 and data address is 0x546c (mask is 0xfffe) */
>
> You don't actually check for the mask.
It is quite complicated. { 0x6d, 0x54 } (= 0x546d) in data represent
address 0x546c and content are data. You need to apply mask 0xfffe for
0x546d and you get address where data will be written (so 0x546c).
> > + if (wl->nvs[0x19] != 2 || wl->nvs[0x1a] != 0x6d || wl->nvs[0x1b]
> > != 0x54) + return -EINVAL;
>
> You have two copies of these. Does it make sense to move it to helper
> function?
I'm thinking if checks is really needed. But probably moving it to
separate function is good idea.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] wl1251: Parse and use MAC address from supplied NVS data
From: Pali Rohár @ 2016-12-24 18:40 UTC (permalink / raw)
To: Pavel Machek
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20161224181421.GC13590@amd>
[-- Attachment #1: Type: Text/Plain, Size: 663 bytes --]
On Saturday 24 December 2016 19:14:21 Pavel Machek wrote:
> On Sat 2016-12-24 17:53:00, Pali Rohár wrote:
> > @@ -1581,10 +1598,16 @@ int wl1251_init_ieee80211(struct wl1251
> > *wl)
> >
> > wl->hw->queues = 4;
> >
> > + if (wl->nvs == NULL && !wl->use_eeprom) {
> > + ret = wl1251_fetch_nvs(wl);
> > + if (ret < 0)
> > + goto out;
> > + }
>
> Is goto out here good idea? IMNSHO it is copy&paste bug, it should
> just proceed with generating random address.
No, goto is correct here. wl1251 cannot be initialized without NVS data.
And when fetching (from userspace) fails it is fatal error.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] wl1251: Generate random MAC address only if driver does not have valid
From: Pali Rohár @ 2016-12-24 18:38 UTC (permalink / raw)
To: Pavel Machek
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20161224180854.GB13590@amd>
[-- Attachment #1: Type: Text/Plain, Size: 1251 bytes --]
On Saturday 24 December 2016 19:08:54 Pavel Machek wrote:
> On Sat 2016-12-24 17:52:59, Pali Rohár wrote:
> > Before this patch driver generated random MAC address every time
> > when was doing initialization. And after that random MAC address
> > could be overwritten with fixed one if provided.
>
> Before this patch, driver generated random MAC address every time it
> was initialized. After that random MAC address could be overwritten
> with fixed one, if provided.
>
> > This patch changes order. First it tries to read fixed MAC address
> > and if it fails then driver generates random MAC address.
>
> I don't quite get where the advantage is supposed to be. Is it that
> "use_eeprom" is set, but reading fails?
Random bytes are read from kernel only if random MAC address is needed.
And in wl->mac_addr is always either invalid address or permanenent mac
address which will be used. Without patch in wl->mac_addr can be random
temporary address for some time...
> The only case where this helps is if wl1251_read_eeprom_mac()
> succeeds but reads invalid address.
>
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>
> Acked-by: Pavel Machek <pavel@ucw.cz>
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Pavel Machek @ 2016-12-24 18:17 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-7-git-send-email-pali.rohar@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]
Hi!
> In case there is no valid MAC address kernel generates random one. This
> patch propagate this generated MAC address back to NVS data which will be
> uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
> uses.
> return 0;
> }
>
> +static int wl1251_write_nvs_mac(struct wl1251 *wl)
> +{
The name is quite confusing, this sounds like writing into
non-volatile storage.
> + int i;
> +
> + if (wl->nvs_len < 0x24)
> + return -ENODATA;
> +
> + /* length is 2 and data address is 0x546c (mask is 0xfffe) */
You don't actually check for the mask.
> + if (wl->nvs[0x19] != 2 || wl->nvs[0x1a] != 0x6d || wl->nvs[0x1b] != 0x54)
> + return -EINVAL;
You have two copies of these. Does it make sense to move it to helper
function?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] wl1251: Parse and use MAC address from supplied NVS data
From: Pavel Machek @ 2016-12-24 18:14 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-6-git-send-email-pali.rohar@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3501 bytes --]
On Sat 2016-12-24 17:53:00, Pali Rohár wrote:
> This patch implements parsing MAC address from NVS data which are sent to
> wl1251 chip. Calibration NVS data could contain valid MAC address and it
> will be used instead randomly generated.
will be used instead of randomly generated one.
> This patch also move code for requesting NVS data from userspace to driver
"moves"
> initialization code to make sure that NVS data will be there at time when
> permanent MAC address is needed.
"at a time"
> Calibration NVS data for wl1251 are model specific. Every one device with
"device specific"? "Every device".
> wl1251 chip should have been calibrated in factory and needs to provide own
> calibration data.
>
> Default example wl1251-nvs.bin data found in linux-firmware repository and
"are found"
> contains MAC address 00:00:20:07:03:09. So this MAC address is marked as
"contain"
> invalid as it is not real device specific address, just example one.
>
> Format of calibration NVS data can be found at:
> http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
> drivers/net/wireless/ti/wl1251/main.c | 39 ++++++++++++++++++++++++++-------
> 1 file changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
> index c3fa0b6..1454ba2 100644
> --- a/drivers/net/wireless/ti/wl1251/main.c
> +++ b/drivers/net/wireless/ti/wl1251/main.c
> @@ -205,13 +205,6 @@ static int wl1251_chip_wakeup(struct wl1251 *wl)
> goto out;
> }
>
> - if (wl->nvs == NULL && !wl->use_eeprom) {
> - /* No NVS from netlink, try to get it from the filesystem */
> - ret = wl1251_fetch_nvs(wl);
> - if (ret < 0)
> - goto out;
> - }
> -
> out:
> return ret;
> }
> @@ -1538,6 +1531,30 @@ static int wl1251_read_eeprom_mac(struct wl1251 *wl)
> return 0;
> }
>
> +static int wl1251_read_nvs_mac(struct wl1251 *wl)
> +{
> + u8 mac[ETH_ALEN];
> + int i;
> +
> + if (wl->nvs_len < 0x24)
> + return -ENODATA;
> +
> + /* length is 2 and data address is 0x546c (mask is 0xfffe) */
> + if (wl->nvs[0x19] != 2 || wl->nvs[0x1a] != 0x6d || wl->nvs[0x1b] != 0x54)
> + return -EINVAL;
> +
> + /* MAC is stored in reverse order */
> + for (i = 0; i < ETH_ALEN; i++)
> + mac[i] = wl->nvs[0x1c + ETH_ALEN - i - 1];
> +
> + /* 00:00:20:07:03:09 is in default example wl1251-nvs.bin, so invalid */
remove "default".
> + if (ether_addr_equal_unaligned(mac, "\x00\x00\x20\x07\x03\x09"))
> + return -EINVAL;
> +
> + memcpy(wl->mac_addr, mac, ETH_ALEN);
> + return 0;
> +}
> +
> static int wl1251_register_hw(struct wl1251 *wl)
> {
> int ret;
> @@ -1581,10 +1598,16 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
>
> wl->hw->queues = 4;
>
> + if (wl->nvs == NULL && !wl->use_eeprom) {
> + ret = wl1251_fetch_nvs(wl);
> + if (ret < 0)
> + goto out;
> + }
Is goto out here good idea? IMNSHO it is copy&paste bug, it should
just proceed with generating random address.
> if (wl->use_eeprom)
> ret = wl1251_read_eeprom_mac(wl);
> else
> - ret = -EINVAL;
> + ret = wl1251_read_nvs_mac(wl);
>
> if (ret == 0 && !is_valid_ether_addr(wl->mac_addr))
> ret = -EINVAL;
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] wl1251: Generate random MAC address only if driver does not have valid
From: Pavel Machek @ 2016-12-24 18:08 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-5-git-send-email-pali.rohar@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 991 bytes --]
On Sat 2016-12-24 17:52:59, Pali Rohár wrote:
> Before this patch driver generated random MAC address every time when was
> doing initialization. And after that random MAC address could be
> overwritten with fixed one if provided.
Before this patch, driver generated random MAC address every time it
was initialized. After that random MAC address could be overwritten
with fixed one, if provided.
> This patch changes order. First it tries to read fixed MAC address and if
> it fails then driver generates random MAC address.
I don't quite get where the advantage is supposed to be. Is it that
"use_eeprom" is set, but reading fails?
The only case where this helps is if wl1251_read_eeprom_mac() succeeds
but reads invalid address.
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] wl1251: Update wl->nvs_len after wl->nvs is valid
From: Pavel Machek @ 2016-12-24 18:02 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-4-git-send-email-pali.rohar@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]
On Sat 2016-12-24 17:52:58, Pali Rohár wrote:
> In case kmemdup fails thne wl->nvs_len will contains invalid non-zero size.
> This patch fixes it.
If kmemdup fails, then wl->nvs_len will contain invalid non-zero size.
?
This probably should go as first in series, as it is bugfix?
Pavel
Acked-by: Pavel Machek <pavel@ucw.cz>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
> drivers/net/wireless/ti/wl1251/main.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
> index 24f8866..8971b64 100644
> --- a/drivers/net/wireless/ti/wl1251/main.c
> +++ b/drivers/net/wireless/ti/wl1251/main.c
> @@ -124,8 +124,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> goto out;
> }
>
> - wl->nvs_len = fw->size;
> - wl->nvs = kmemdup(fw->data, wl->nvs_len, GFP_KERNEL);
> + wl->nvs = kmemdup(fw->data, fw->size, GFP_KERNEL);
>
> if (!wl->nvs) {
> wl1251_error("could not allocate memory for the nvs file");
> @@ -133,6 +132,8 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> goto out;
> }
>
> + wl->nvs_len = fw->size;
> +
> ret = 0;
>
> out:
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Mark Greer @ 2016-12-24 17:24 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, robh+dt, mark.rutland, netdev, devicetree,
linux-kernel, Justin Bronder, Jaret Cantu
In-Reply-To: <CAO7Z3W+n85jbr8cmj3HJV1c+eL=oRh-XRy+O=iZ+mD=ov2WABA@mail.gmail.com>
On Sat, Dec 24, 2016 at 11:17:18AM -0500, Geoff Lansberry wrote:
> Mark - I'm sorry, but I did not write this code, and therefore was not
> able to accurately describe it. It is fixing a different issue, not
> the neard segfault that we are still chasing. Last week Jaret Cantu
> sent a separate email explaining the purpose of the code, which had
> you copied, did you see that?
Hm, no, I didn't. I received an email from Justin Bronder but not from
Jaret Cantu. Justin's email did help but is still pretty high-level.
We need a clear understanding as to what is happening in the digital
layer and the driver to know how execution is getting into a block of
error handling code that should never be executed. Once we understand
that we can start thinking about what the best fix is.
> Does it explain why it was done to
> your satisfaction? I've asked him to join in on the effort to push
> the change upstream, however he will not be available until the new
> year.
I expect that it would help if he joins. After the holidays is fine -
I think many people are taking it easy for the next week or so, anyway.
> I know you did suggest that we split off that change from the others,
> and if now is the time to do that, let me know. If you don't have
> the email from Jaret, also please let me know and I will forward it to
> you.
I think it would help you if you split it off because the first two patches
have a good chance of being accepted but this one doesn't (yet). If you
separate the them, it will make it easier for Samuel to take the first two
(or he may take the first two anyway but its always good to make it as
easy maintainers as you can).
Mark
--
^ permalink raw reply
* [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Pali Rohár @ 2016-12-24 16:53 UTC (permalink / raw)
To: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas
Cc: linux-kernel, linux-wireless, netdev, Pali Rohár
In-Reply-To: <1482598381-16513-1-git-send-email-pali.rohar@gmail.com>
In case there is no valid MAC address kernel generates random one. This
patch propagate this generated MAC address back to NVS data which will be
uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
uses.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
drivers/net/wireless/ti/wl1251/main.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
index 1454ba2..895ae05 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -1555,6 +1555,24 @@ static int wl1251_read_nvs_mac(struct wl1251 *wl)
return 0;
}
+static int wl1251_write_nvs_mac(struct wl1251 *wl)
+{
+ int i;
+
+ if (wl->nvs_len < 0x24)
+ return -ENODATA;
+
+ /* length is 2 and data address is 0x546c (mask is 0xfffe) */
+ if (wl->nvs[0x19] != 2 || wl->nvs[0x1a] != 0x6d || wl->nvs[0x1b] != 0x54)
+ return -EINVAL;
+
+ /* MAC is stored in reverse order */
+ for (i = 0; i < ETH_ALEN; i++)
+ wl->nvs[0x1c + i] = wl->mac_addr[ETH_ALEN - i - 1];
+
+ return 0;
+}
+
static int wl1251_register_hw(struct wl1251 *wl)
{
int ret;
@@ -1620,6 +1638,8 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
static const u8 nokia_oui[3] = {0x00, 0x1f, 0xdf};
memcpy(wl->mac_addr, nokia_oui, 3);
get_random_bytes(wl->mac_addr + 3, 3);
+ if (!wl->use_eeprom)
+ wl1251_write_nvs_mac(wl);
wl1251_warning("MAC address in eeprom or nvs data is not valid");
wl1251_warning("Setting random MAC address: %pM", wl->mac_addr);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/6] wl1251: Generate random MAC address only if driver does not have valid
From: Pali Rohár @ 2016-12-24 16:52 UTC (permalink / raw)
To: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas
Cc: linux-kernel, linux-wireless, netdev, Pali Rohár
In-Reply-To: <1482598381-16513-1-git-send-email-pali.rohar@gmail.com>
Before this patch driver generated random MAC address every time when was
doing initialization. And after that random MAC address could be
overwritten with fixed one if provided.
This patch changes order. First it tries to read fixed MAC address and if
it fails then driver generates random MAC address.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
drivers/net/wireless/ti/wl1251/main.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
index 8971b64..c3fa0b6 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -1582,7 +1582,24 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
wl->hw->queues = 4;
if (wl->use_eeprom)
- wl1251_read_eeprom_mac(wl);
+ ret = wl1251_read_eeprom_mac(wl);
+ else
+ ret = -EINVAL;
+
+ if (ret == 0 && !is_valid_ether_addr(wl->mac_addr))
+ ret = -EINVAL;
+
+ if (ret < 0) {
+ /*
+ * In case our MAC address is not correctly set,
+ * we use a random but Nokia MAC.
+ */
+ static const u8 nokia_oui[3] = {0x00, 0x1f, 0xdf};
+ memcpy(wl->mac_addr, nokia_oui, 3);
+ get_random_bytes(wl->mac_addr + 3, 3);
+ wl1251_warning("MAC address in eeprom or nvs data is not valid");
+ wl1251_warning("Setting random MAC address: %pM", wl->mac_addr);
+ }
ret = wl1251_register_hw(wl);
if (ret)
@@ -1623,7 +1640,6 @@ struct ieee80211_hw *wl1251_alloc_hw(void)
struct ieee80211_hw *hw;
struct wl1251 *wl;
int i;
- static const u8 nokia_oui[3] = {0x00, 0x1f, 0xdf};
hw = ieee80211_alloc_hw(sizeof(*wl), &wl1251_ops);
if (!hw) {
@@ -1674,13 +1690,6 @@ struct ieee80211_hw *wl1251_alloc_hw(void)
INIT_WORK(&wl->irq_work, wl1251_irq_work);
INIT_WORK(&wl->tx_work, wl1251_tx_work);
- /*
- * In case our MAC address is not correctly set,
- * we use a random but Nokia MAC.
- */
- memcpy(wl->mac_addr, nokia_oui, 3);
- get_random_bytes(wl->mac_addr + 3, 3);
-
wl->state = WL1251_STATE_OFF;
mutex_init(&wl->mutex);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/6] wl1251: Parse and use MAC address from supplied NVS data
From: Pali Rohár @ 2016-12-24 16:53 UTC (permalink / raw)
To: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas
Cc: linux-kernel, linux-wireless, netdev, Pali Rohár
In-Reply-To: <1482598381-16513-1-git-send-email-pali.rohar@gmail.com>
This patch implements parsing MAC address from NVS data which are sent to
wl1251 chip. Calibration NVS data could contain valid MAC address and it
will be used instead randomly generated.
This patch also move code for requesting NVS data from userspace to driver
initialization code to make sure that NVS data will be there at time when
permanent MAC address is needed.
Calibration NVS data for wl1251 are model specific. Every one device with
wl1251 chip should have been calibrated in factory and needs to provide own
calibration data.
Default example wl1251-nvs.bin data found in linux-firmware repository and
contains MAC address 00:00:20:07:03:09. So this MAC address is marked as
invalid as it is not real device specific address, just example one.
Format of calibration NVS data can be found at:
http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
drivers/net/wireless/ti/wl1251/main.c | 39 ++++++++++++++++++++++++++-------
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
index c3fa0b6..1454ba2 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -205,13 +205,6 @@ static int wl1251_chip_wakeup(struct wl1251 *wl)
goto out;
}
- if (wl->nvs == NULL && !wl->use_eeprom) {
- /* No NVS from netlink, try to get it from the filesystem */
- ret = wl1251_fetch_nvs(wl);
- if (ret < 0)
- goto out;
- }
-
out:
return ret;
}
@@ -1538,6 +1531,30 @@ static int wl1251_read_eeprom_mac(struct wl1251 *wl)
return 0;
}
+static int wl1251_read_nvs_mac(struct wl1251 *wl)
+{
+ u8 mac[ETH_ALEN];
+ int i;
+
+ if (wl->nvs_len < 0x24)
+ return -ENODATA;
+
+ /* length is 2 and data address is 0x546c (mask is 0xfffe) */
+ if (wl->nvs[0x19] != 2 || wl->nvs[0x1a] != 0x6d || wl->nvs[0x1b] != 0x54)
+ return -EINVAL;
+
+ /* MAC is stored in reverse order */
+ for (i = 0; i < ETH_ALEN; i++)
+ mac[i] = wl->nvs[0x1c + ETH_ALEN - i - 1];
+
+ /* 00:00:20:07:03:09 is in default example wl1251-nvs.bin, so invalid */
+ if (ether_addr_equal_unaligned(mac, "\x00\x00\x20\x07\x03\x09"))
+ return -EINVAL;
+
+ memcpy(wl->mac_addr, mac, ETH_ALEN);
+ return 0;
+}
+
static int wl1251_register_hw(struct wl1251 *wl)
{
int ret;
@@ -1581,10 +1598,16 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
wl->hw->queues = 4;
+ if (wl->nvs == NULL && !wl->use_eeprom) {
+ ret = wl1251_fetch_nvs(wl);
+ if (ret < 0)
+ goto out;
+ }
+
if (wl->use_eeprom)
ret = wl1251_read_eeprom_mac(wl);
else
- ret = -EINVAL;
+ ret = wl1251_read_nvs_mac(wl);
if (ret == 0 && !is_valid_ether_addr(wl->mac_addr))
ret = -EINVAL;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/6] firmware: Add request_firmware_prefer_user() function
From: Pali Rohár @ 2016-12-24 16:52 UTC (permalink / raw)
To: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas
Cc: linux-kernel, linux-wireless, netdev, Pali Rohár
In-Reply-To: <1482598381-16513-1-git-send-email-pali.rohar@gmail.com>
This function works pretty much like request_firmware(), but it prefer
usermode helper. If usermode helper fails then it fallback to direct
access. Useful for dynamic or model specific firmware data.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
drivers/base/firmware_class.c | 45 +++++++++++++++++++++++++++++++++++++++--
include/linux/firmware.h | 9 +++++++++
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 22d1760..6a8c261 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -119,6 +119,11 @@ static inline long firmware_loading_timeout(void)
#endif
#define FW_OPT_NO_WARN (1U << 3)
#define FW_OPT_NOCACHE (1U << 4)
+#ifdef CONFIG_FW_LOADER_USER_HELPER
+#define FW_OPT_PREFER_USER (1U << 5)
+#else
+#define FW_OPT_PREFER_USER 0
+#endif
struct firmware_cache {
/* firmware_buf instance will be added into the below list */
@@ -1169,13 +1174,26 @@ static int assign_firmware_buf(struct firmware *fw, struct device *device,
}
}
- ret = fw_get_filesystem_firmware(device, fw->priv);
+ if (opt_flags & FW_OPT_PREFER_USER) {
+ ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout);
+ if (ret && !(opt_flags & FW_OPT_NO_WARN)) {
+ dev_warn(device,
+ "User helper firmware load for %s failed with error %d\n",
+ name, ret);
+ dev_warn(device, "Falling back to direct firmware load\n");
+ }
+ } else {
+ ret = -EINVAL;
+ }
+
+ if (ret)
+ ret = fw_get_filesystem_firmware(device, fw->priv);
if (ret) {
if (!(opt_flags & FW_OPT_NO_WARN))
dev_warn(device,
"Direct firmware load for %s failed with error %d\n",
name, ret);
- if (opt_flags & FW_OPT_USERHELPER) {
+ if ((opt_flags & FW_OPT_USERHELPER) && !(opt_flags & FW_OPT_PREFER_USER)) {
dev_warn(device, "Falling back to user helper\n");
ret = fw_load_from_user_helper(fw, name, device,
opt_flags, timeout);
@@ -1287,6 +1305,29 @@ int request_firmware_direct(const struct firmware **firmware_p,
EXPORT_SYMBOL(request_firmware_into_buf);
/**
+ * request_firmware_prefer_user: - prefer usermode helper for loading firmware
+ * @firmware_p: pointer to firmware image
+ * @name: name of firmware file
+ * @device: device for which firmware is being loaded
+ *
+ * This function works pretty much like request_firmware(), but it prefer
+ * usermode helper. If usermode helper fails then it fallback to direct access.
+ * Useful for dynamic or model specific firmware data.
+ **/
+int request_firmware_prefer_user(const struct firmware **firmware_p,
+ const char *name, struct device *device)
+{
+ int ret;
+
+ __module_get(THIS_MODULE);
+ ret = _request_firmware(firmware_p, name, device, NULL, 0,
+ FW_OPT_UEVENT | FW_OPT_PREFER_USER);
+ module_put(THIS_MODULE);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
+
+/**
* release_firmware: - release the resource associated with a firmware image
* @fw: firmware resource to release
**/
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index b1f9f0c..01f7a85 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -47,6 +47,8 @@ int request_firmware_nowait(
void (*cont)(const struct firmware *fw, void *context));
int request_firmware_direct(const struct firmware **fw, const char *name,
struct device *device);
+int request_firmware_prefer_user(const struct firmware **fw, const char *name,
+ struct device *device);
int request_firmware_into_buf(const struct firmware **firmware_p,
const char *name, struct device *device, void *buf, size_t size);
@@ -77,6 +79,13 @@ static inline int request_firmware_direct(const struct firmware **fw,
return -EINVAL;
}
+static inline int request_firmware_prefer_user(const struct firmware **fw,
+ const char *name,
+ struct device *device)
+{
+ return -EINVAL;
+}
+
static inline int request_firmware_into_buf(const struct firmware **firmware_p,
const char *name, struct device *device, void *buf, size_t size)
{
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/6] wl1251: Update wl->nvs_len after wl->nvs is valid
From: Pali Rohár @ 2016-12-24 16:52 UTC (permalink / raw)
To: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas
Cc: linux-kernel, linux-wireless, netdev, Pali Rohár
In-Reply-To: <1482598381-16513-1-git-send-email-pali.rohar@gmail.com>
In case kmemdup fails thne wl->nvs_len will contains invalid non-zero size.
This patch fixes it.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
drivers/net/wireless/ti/wl1251/main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
index 24f8866..8971b64 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -124,8 +124,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
goto out;
}
- wl->nvs_len = fw->size;
- wl->nvs = kmemdup(fw->data, wl->nvs_len, GFP_KERNEL);
+ wl->nvs = kmemdup(fw->data, fw->size, GFP_KERNEL);
if (!wl->nvs) {
wl1251_error("could not allocate memory for the nvs file");
@@ -133,6 +132,8 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
goto out;
}
+ wl->nvs_len = fw->size;
+
ret = 0;
out:
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/6] wl1251: Fix MAC address for Nokia N900
From: Pali Rohár @ 2016-12-24 16:52 UTC (permalink / raw)
To: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas
Cc: linux-kernel, linux-wireless, netdev, Pali Rohár
This patch series fix processing MAC address for wl1251 chip found in Nokia N900.
Pali Rohár (6):
firmware: Add request_firmware_prefer_user() function
wl1251: Use request_firmware_prefer_user() for loading NVS
calibration data
wl1251: Update wl->nvs_len after wl->nvs is valid
wl1251: Generate random MAC address only if driver does not have
valid
wl1251: Parse and use MAC address from supplied NVS data
wl1251: Set generated MAC address back to NVS data
drivers/base/firmware_class.c | 45 +++++++++++++++-
drivers/net/wireless/ti/wl1251/Kconfig | 1 +
drivers/net/wireless/ti/wl1251/main.c | 91 +++++++++++++++++++++++++-------
include/linux/firmware.h | 9 ++++
4 files changed, 125 insertions(+), 21 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2016-12-24 16:52 UTC (permalink / raw)
To: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas
Cc: linux-kernel, linux-wireless, netdev, Pali Rohár
In-Reply-To: <1482598381-16513-1-git-send-email-pali.rohar@gmail.com>
NVS calibration data for wl1251 are model specific. Every one device with
wl1251 chip has different and calibrated in factory.
Not all wl1251 chips have own EEPROM where are calibration data stored. And
in that case there is no "standard" place. Every device has stored them on
different place (some in rootfs file, some in dedicated nand partition,
some in another proprietary structure).
Kernel wl1251 driver cannot support every one different storage decided by
device manufacture so it will use request_firmware_prefer_user() call for
loading NVS calibration data and userspace helper will be responsible to
prepare correct data.
In case userspace helper fails request_firmware_prefer_user() still try to
load data file directly from VFS as fallback mechanism.
On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
in CAL nand partition. CAL is proprietary Nokia key/value format for nand
devices.
With this patch it is finally possible to load correct model specific NVS
calibration data for Nokia N900.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
drivers/net/wireless/ti/wl1251/Kconfig | 1 +
drivers/net/wireless/ti/wl1251/main.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
index 7142ccf..affe154 100644
--- a/drivers/net/wireless/ti/wl1251/Kconfig
+++ b/drivers/net/wireless/ti/wl1251/Kconfig
@@ -2,6 +2,7 @@ config WL1251
tristate "TI wl1251 driver support"
depends on MAC80211
select FW_LOADER
+ select FW_LOADER_USER_HELPER
select CRC7
---help---
This will enable TI wl1251 driver support. The drivers make
diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
index 208f062..24f8866 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
struct device *dev = wiphy_dev(wl->hw->wiphy);
int ret;
- ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
+ ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
if (ret < 0) {
wl1251_error("could not get nvs file: %d", ret);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Geoff Lansberry @ 2016-12-24 16:17 UTC (permalink / raw)
To: Mark Greer
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, robh+dt, mark.rutland, netdev, devicetree,
linux-kernel, Justin Bronder, Jaret Cantu
In-Reply-To: <20161224060141.GA9069@animalcreek.com>
Mark - I'm sorry, but I did not write this code, and therefore was not
able to accurately describe it. It is fixing a different issue, not
the neard segfault that we are still chasing. Last week Jaret Cantu
sent a separate email explaining the purpose of the code, which had
you copied, did you see that? Does it explain why it was done to
your satisfaction? I've asked him to join in on the effort to push
the change upstream, however he will not be available until the new
year.
I know you did suggest that we split off that change from the others,
and if now is the time to do that, let me know. If you don't have
the email from Jaret, also please let me know and I will forward it to
you.
Geoff
Geoff Lansberry
Engineering Guy
Kuv=C3=A9e, Inc
125 Kingston St., 3rd Floor
Boston, MA 02111
1-617-290-1118 (m)
geoff.lansberry (skype)
http://www.kuvee.com
On Sat, Dec 24, 2016 at 1:01 AM, Mark Greer <mgreer@animalcreek.com> wrote:
> On Wed, Dec 21, 2016 at 11:18:34PM -0500, Geoff Lansberry wrote:
>> From: Jaret Cantu <jaret.cantu@timesys.com>
>>
>> Repeated polling attempts cause a NULL dereference error to occur.
>> This is because the state of the trf7970a is currently reading but
>> another request has been made to send a command before it has finished.
>>
>> The solution is to properly kill the waiting reading (workqueue)
>> before failing on the send.
>>
>> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
>> ---
>
> You've still provided virtually no information on the actual problem(s)
> nor justified why you think this is the best solution. You're adding
> code to a section of code that should _never_ be executed so the only
> reasonable things I can infer is that there are, at least, two problems:
>
> 1) There is a bug causing execution to get into this block of code.
>
> 2) Once in this block of code, there is another bug.
>
> You seem to be attempting to fix 2) and completely ignoring 1).
> 1) is the first bug that needs to be root-caused and fixed.
>
> Also, what exactly is the "NULL dereference error" you mention?
> Is this the neard crash you talked about in another thread or is
> this a kernel crash? If it is the kernel crash, please post the
> relevant information. If this is the neard crash - which seems
> unlikely - then how can changing a section of kernel code that
> shouldn't be executed in the first place fix that?
>
> Mark
> --
^ permalink raw reply
* Re: wl1251 NVS calibration data format
From: Pali Rohár @ 2016-12-24 12:57 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Gery Kahn, Shahar Lev, Kalle Valo, linux-wireless, linux-kernel,
Pavel Machek, Ivaylo Dimitrov
In-Reply-To: <201612171214.50820@pali>
[-- Attachment #1: Type: Text/Plain, Size: 921 bytes --]
On Saturday 17 December 2016 12:14:50 Pali Rohár wrote:
> I will try to play with driver if it is really truth!
>
> I already looked into original TI's multiplatform HAL driver for
> wl1251 chip (big mess) and found there that there is wl1251 command
> to read mac address from chip. It could be done by this wl1251
> function:
>
> wl1251_cmd_interrogate(wl, DOT11_STATION_ID, mac, sizeof(*mac))
>
> (same id as for setting permanent mac address, but opposite to read
> it)
Confirmed! Calling that function (before setting real linux mac address)
returns MAC address 00:00:20:07:03:09.
Changing NVS data at position 0x1c-0x21 changes also what above function
returns.
So really at position 0x1c-0x21 in NVS data is stored MAC address (in
reverse order). Just default is some unknown 00:00:20:07:03:09.
So MAC address is really part of NVS data.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Mark Greer @ 2016-12-24 6:01 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin,
Jaret Cantu
In-Reply-To: <1482380314-16440-3-git-send-email-geoff@kuvee.com>
On Wed, Dec 21, 2016 at 11:18:34PM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu <jaret.cantu@timesys.com>
>
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the state of the trf7970a is currently reading but
> another request has been made to send a command before it has finished.
>
> The solution is to properly kill the waiting reading (workqueue)
> before failing on the send.
>
> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
> ---
You've still provided virtually no information on the actual problem(s)
nor justified why you think this is the best solution. You're adding
code to a section of code that should _never_ be executed so the only
reasonable things I can infer is that there are, at least, two problems:
1) There is a bug causing execution to get into this block of code.
2) Once in this block of code, there is another bug.
You seem to be attempting to fix 2) and completely ignoring 1).
1) is the first bug that needs to be root-caused and fixed.
Also, what exactly is the "NULL dereference error" you mention?
Is this the neard crash you talked about in another thread or is
this a kernel crash? If it is the kernel crash, please post the
relevant information. If this is the neard crash - which seems
unlikely - then how can changing a section of kernel code that
shouldn't be executed in the first place fix that?
Mark
--
^ permalink raw reply
* Re: [PATCH] brcmfmac: fix spelling mistakes on "Ivalid"
From: Arend Van Spriel @ 2016-12-23 19:38 UTC (permalink / raw)
To: Colin King, Franky Lin, Hante Meuleman, Kalle Valo,
Pieter-Paul Giesberts, Rafał Miłecki, linux-wireless,
brcm80211-dev-list.pdl, netdev
Cc: linux-kernel
In-Reply-To: <20161223004322.7300-1-colin.king@canonical.com>
On 23-12-2016 1:43, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fixes to spelling mistake "Ivalid" to "Invalid" in
> brcmf_err error messages.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 7ffc4ab..15eaf72 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -3971,7 +3971,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
> pval |= AES_ENABLED;
> break;
> default:
> - brcmf_err("Ivalid unicast security info\n");
> + brcmf_err("Invalid unicast security info\n");
> }
> offset++;
> }
> @@ -4015,7 +4015,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
> wpa_auth |= WPA2_AUTH_1X_SHA256;
> break;
> default:
> - brcmf_err("Ivalid key mgmt info\n");
> + brcmf_err("Invalid key mgmt info\n");
> }
> offset++;
> }
>
^ permalink raw reply
* Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: Christian Lamparter @ 2016-12-23 17:47 UTC (permalink / raw)
To: igor.mitsyanko.os
Cc: linux-firmware, linux-wireless, Igor Mitsyanko, Kamlesh Rath,
Sergey Matyukevich, Avinash Patil
In-Reply-To: <1482505955-9310-1-git-send-email-igor.mitsyanko.os@quantenna.com>
On Friday, December 23, 2016 6:12:35 PM CET igor.mitsyanko.os@quantenna.com wrote:
> From: Igor Mitsyanko <imitsyanko@quantenna.com>
>
> QSR10G is Quantenna's 8x8, 160M, 11ac WiFi card.
>
> Signed-off-by: Kamlesh Rath <krath@quantenna.com>
> Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
> Signed-off-by: Avinash Patil <avinashp@quantenna.com>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
> ---
> This is an RFC patch that we sent to linux-wireless mailing list a while ago,
> and it spawned a discussion regarding whether GPL sources has to be submitted
> together with this firmware. We would like to clarify with linux-firmware maintainers
> to understnad what should be our actions to allow this to be accepted.
> - firmware contains GPL components;
> - LICENCE file states that sources for GPL components will be provided on request
> to oslegal@quantenna.com
>
> There was an opinion that it is not enough: precedent case like this with carl9170
> firmware was resolved by submitting GPL sources into linux-firmware repository
> itself.
The ar9170-usb firmware was released as GPL v2.0 from the get-go.
<http://git.sipsolutions.net/ar9170-fw.git/commit/GPL?id=2e3574ce10c74a82047a06b046855de14d969948>
And this was never a problem. What is THE PROBLEM though:
"if all the patches from ar9170fw to carl9170fw and beyond (i.e new versions)
have to be added to linux-firmware.git." Or not.
That's why there was never a update to the carl9170fw.
So be prepared for this scenario too.
> Does the same applies to qsr10g firmware?
>
> The SDK that we use to build it is quite heavy (> 100MB, but with toolchain).
> Maybe we can take another approach to place SDK separately on Quantenna website
> (as a compressed archive), and add a link in linux-firmware?
Yes, I would like to know this as well.
Regards,
Christian
^ permalink raw reply
* [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: igor.mitsyanko.os @ 2016-12-23 15:12 UTC (permalink / raw)
To: linux-firmware
Cc: linux-wireless, Igor Mitsyanko, Kamlesh Rath, Sergey Matyukevich,
Avinash Patil, Igor Mitsyanko
In-Reply-To: <87d1hmnrqj.fsf@purkki.adurom.net>
From: Igor Mitsyanko <imitsyanko@quantenna.com>
QSR10G is Quantenna's 8x8, 160M, 11ac WiFi card.
Signed-off-by: Kamlesh Rath <krath@quantenna.com>
Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
Signed-off-by: Avinash Patil <avinashp@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
This is an RFC patch that we sent to linux-wireless mailing list a while ago,
and it spawned a discussion regarding whether GPL sources has to be submitted
together with this firmware. We would like to clarify with linux-firmware maintainers
to understnad what should be our actions to allow this to be accepted.
- firmware contains GPL components;
- LICENCE file states that sources for GPL components will be provided on request
to oslegal@quantenna.com
There was an opinion that it is not enough: precedent case like this with carl9170
firmware was resolved by submitting GPL sources into linux-firmware repository
itself.
Does the same applies to qsr10g firmware?
The SDK that we use to build it is quite heavy (> 100MB, but with toolchain).
Maybe we can take another approach to place SDK separately on Quantenna website
(as a compressed archive), and add a link in linux-firmware?
LICENCE.Quantenna_fmac | 74 +++++++++++++++++++++++++++++++++++++++++++++++++
WHENCE | 9 ++++++
qtn/fmac_qsr10g.img | Bin 0 -> 9559676 bytes
3 files changed, 83 insertions(+)
create mode 100644 LICENCE.Quantenna_fmac
create mode 100644 qtn/fmac_qsr10g.img
diff --git a/LICENCE.Quantenna_fmac b/LICENCE.Quantenna_fmac
new file mode 100644
index 0000000..e6f9f72
--- /dev/null
+++ b/LICENCE.Quantenna_fmac
@@ -0,0 +1,74 @@
+Copyright (c) 2016, Quantenna, Inc.
+All rights reserved.
+
+Redistribution. Reproduction and redistribution in binary form, without
+modification, for use solely in conjunction with a Quantenna, Inc. chipset, is
+permitted provided that the following conditions are met:
+
+ - Redistributions must reproduce the above copyright notice and the
+ following disclaimer in the documentation and/or other materials provided
+ with the distribution.
+
+ - Neither the name of Quantenna, Inc. nor the names of its suppliers may be
+ used to endorse or promote products derived from this Software without
+ specific prior written permission.
+
+ - No reverse engineering, decompilation, or disassembly of this Software is
+ permitted, except and solely to the extent that such a restriction is
+ impermissible pursuant to applicable law or third party license.
+
+ - Your reproduction and distribution must comply with all applicable laws,
+ including without limitation all applicable U.S., European, and other
+ export laws.
+
+Limited Patent License. Subject to your compliance with all terms of this
+license, Quantenna, Inc. (“Licensor”) grants you (“Licensee”) a limited,
+worldwide, royalty-free, non-exclusive license under the Licensed Patents to
+make, have made, use, import, offer to sell and sell the Software solely in
+conjunction with a validly purchased Quantenna, Inc. chipset. No hardware
+per se is licensed hereunder.
+
+The term “Licensed Patents” as used in this agreement means only those patents
+or patent applications owned solely and exclusively by Licensor as of the date
+of Licensor’s submission of the Software that would necessarily be infringed by
+the operation of the Software, alone, or in combination with a supported
+version of the Linux operating system. The patent license shall not apply to
+any other combinations which include the Software. The term “Licensed Patents”
+expressly excludes any patent or patent application owned by any current or
+future affiliate of Quantenna, Inc. The term “Software” as used in this
+agreement means the unmodified firmware image submitted by Licensor, under the
+terms of this license, to
+git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git.
+
+Notwithstanding anything to the contrary herein, Licensor does not grant and
+Licensee does not receive, by virtue of this agreement or the Licensor’s
+submission of any Software, any license or other rights under any patent or
+patent application owned by any current or future affiliate of Licensor or any
+other entity (other than Licensor), whether expressly, impliedly, by virtue of
+estoppel or exhaustion, or otherwise. If Licensee has a separate agreement with
+Licensor covering use of the Software, then that separate agreement shall
+control.
+
+Open Source Software. The Software may include components that are licensed
+pursuant to open source software (“Open Source Components”). Information
+regarding the Open Source Components included with the Software is available
+upon request to oslegal@quantenna.com. To the extent such Open Source
+Components are required to be licensed to you under the terms of a separate
+license (such as an open source license) then such other terms shall apply, and
+nothing herein shall be deemed or interpreted to limit any rights you may have
+under any such applicable license.
+
+DISCLAIMER. THIS SOFTWARE (INCLUDING ANY APPLICABLE OPEN SOURCE COMPONENTS) IS
+PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFREINGEMENT ARE
+EXPRESSLY DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNERS, AUTHORS, OR
+CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
+OF SUCH DAMAGE, AND REGARDLESS OF ANY FAILURE OF ESSENTIAL PURPOSE OF ANY
+LIMITED REMEDY PROVIDED HEREIN.
+
diff --git a/WHENCE b/WHENCE
index 534c2da..78f6b73 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3347,3 +3347,12 @@ File: rockchip/dptx.bin
Version: 2.9
Licence: Redistributable. See LICENCE.rockchip for details.
+
+--------------------------------------------------------------------------
+
+Driver: qtnfmac - FullMAC driver for Quantenna QSR10G wireless card
+
+File: qtn/fmac_qsr10g.img
+
+Licence: Redistributable. See LICENCE.Quantenna_fmac for details.
+
diff --git a/qtn/fmac_qsr10g.img b/qtn/fmac_qsr10g.img
new file mode 100644
index 0000000..a65e6ec
Binary files /dev/null and b/qtn/fmac_qsr10g.img differ
--
2.7.4
^ permalink raw reply related
* Re: ath10k mesh error 80MHz channel
From: Thiagarajan, Vasanthakumar @ 2016-12-23 5:18 UTC (permalink / raw)
To: Matteo Grandi, LinuxWireless Mailing List
In-Reply-To: <CAHdg3xb2TCo6-m36zvNS_SADPM+SxE4bg_aHRc+RBo3zOaGX=Q@mail.gmail.com>
T24gV2VkbmVzZGF5IDIxIERlY2VtYmVyIDIwMTYgMDg6NTEgUE0sIE1hdHRlbyBHcmFuZGkgd3Jv
dGU6DQo+IEhpIGFsbCBhZ2FpbiwganVzdCBhbiB1cGRhdGUgdG8gdGhlIHByZXZpb3VzIG1lc3Nh
Z2U6DQo+DQo+IGxvb2tpbmcgYXQgaXcgbGlzdCBJIGZvdW5kIHRoaXMgc2l0dWF0aW9uOg0KPg0K
PiAgICAgICAgICBGcmVxdWVuY2llczoNCj4gICAgICAgICAgICAgICogNTE4MCBNSHogWzM2XSAo
MjAuMCBkQm0pDQo+ICAgICAgICAgICAgICAqIDUyMDAgTUh6IFs0MF0gKDIwLjAgZEJtKQ0KPiAg
ICAgICAgICAgICAgKiA1MjIwIE1IeiBbNDRdICgyMC4wIGRCbSkNCj4gICAgICAgICAgICAgICog
NTI0MCBNSHogWzQ4XSAoMjAuMCBkQm0pDQo+ICAgICAgICAgICAgICAqIDUyNjAgTUh6IFs1Ml0g
KDIwLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTI4
MCBNSHogWzU2XSAoMjAuMCBkQm0pIChubyBJUiwgcmFkYXIgZGV0ZWN0aW9uKQ0KPiAgICAgICAg
ICAgICAgKiA1MzAwIE1IeiBbNjBdICgyMC4wIGRCbSkgKG5vIElSLCByYWRhciBkZXRlY3Rpb24p
DQo+ICAgICAgICAgICAgICAqIDUzMjAgTUh6IFs2NF0gKDIwLjAgZEJtKSAobm8gSVIsIHJhZGFy
IGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTUwMCBNSHogWzEwMF0gKDIzLjAgZEJtKSAo
bm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTUyMCBNSHogWzEwNF0g
KDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTU0
MCBNSHogWzEwOF0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAg
ICAgICAgICogNTU2MCBNSHogWzExMl0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlv
bikNCj4gICAgICAgICAgICAgICogNTU4MCBNSHogWzExNl0gKDIzLjAgZEJtKSAobm8gSVIsIHJh
ZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTYwMCBNSHogWzEyMF0gKDIzLjAgZEJt
KSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTYyMCBNSHogWzEy
NF0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICog
NTY0MCBNSHogWzEyOF0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAg
ICAgICAgICAgICogNTY2MCBNSHogWzEzMl0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVj
dGlvbikNCj4gICAgICAgICAgICAgICogNTY4MCBNSHogWzEzNl0gKDIzLjAgZEJtKSAobm8gSVIs
IHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTcwMCBNSHogWzE0MF0gKDIzLjAg
ZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTc0NSBNSHog
WzE0OV0gKGRpc2FibGVkKQ0KPiAgICAgICAgICAgICAgKiA1NzY1IE1IeiBbMTUzXSAoZGlzYWJs
ZWQpDQo+ICAgICAgICAgICAgICAqIDU3ODUgTUh6IFsxNTddIChkaXNhYmxlZCkNCj4gICAgICAg
ICAgICAgICogNTgwNSBNSHogWzE2MV0gKGRpc2FibGVkKQ0KPiAgICAgICAgICAgICAgKiA1ODI1
IE1IeiBbMTY1XSAoZGlzYWJsZWQpDQo+ICAgICAgU3VwcG9ydGVkIGNvbW1hbmRzOg0KPiAgICAg
ICAgICAgKiBuZXdfaW50ZXJmYWNlDQo+ICAgICAgICAgICAqIHNldF9pbnRlcmZhY2UNCj4gICAg
ICAgICAgICogbmV3X2tleQ0KPg0KPiBUaGUgbm8gSW5pdGlhbCBSYWRpYXRpb24gcHJldmVudCB0
aGUgaW50ZXJmYWNlIHRvIHN0YXJ0IHRyYW5zbWl0dGluZy4NCj4gSSdtIGFsbW9zdCBzdXJlIHRo
YXQgaXQncyBhIHJlZ3VsYXRvcnkgZG9tYWluIGlzc3VlLCBidXQgaSBhbHJlYWR5DQo+IHRyaWVk
IHRvIHJlaW5zdGFsbCB0aGUgQ1JEIEFnZW50LCBhbmQgZXZlbiBjaGFuZ2luZyB0aGUgcmVndWxh
dG9yeQ0KPiBkb21haW4gaXQgY2hhbmdlIG9ubHkgdGhlIGdsb2JhbCAoaS5lLiBDSCkgd2hpbGUg
dGhlIGl3IGxpc3QgcHJvdmlkZQ0KPiB0aGUgc2FtZSByZXN1bHRzLg0KPiByb290QE1yUHJvcGVy
On4jIGl3IHJlZyBnZXQNCj4gZ2xvYmFsDQo+IGNvdW50cnkgQ0g6IERGUy1FVFNJDQo+ICAgICAg
KDI0MDIgLSAyNDgyIEAgNDApLCAoTi9BLCAyMCksIChOL0EpDQo+ICAgICAgKDUxNzAgLSA1MjUw
IEAgODApLCAoTi9BLCAyMCksIChOL0EpLCBBVVRPLUJXDQo+ICAgICAgKDUyNTAgLSA1MzMwIEAg
ODApLCAoTi9BLCAyMCksICgwIG1zKSwgREZTLCBBVVRPLUJXDQo+ICAgICAgKDU0OTAgLSA1NzEw
IEAgMTYwKSwgKE4vQSwgMjcpLCAoMCBtcyksIERGUw0KPiAgICAgICg1NzAwMCAtIDY2MDAwIEAg
MjE2MCksIChOL0EsIDQwKSwgKE4vQSkNCj4NCj4gcGh5IzENCj4gY291bnRyeSBVUzogREZTLUZD
Qw0KPiAgICAgICgyNDAyIC0gMjQ3MiBAIDQwKSwgKE4vQSwgMzApLCAoTi9BKQ0KPiAgICAgICg1
MTcwIC0gNTI1MCBAIDgwKSwgKE4vQSwgMjMpLCAoTi9BKSwgQVVUTy1CVw0KPiAgICAgICg1MjUw
IC0gNTMzMCBAIDgwKSwgKE4vQSwgMjMpLCAoMCBtcyksIERGUywgQVVUTy1CVw0KPiAgICAgICg1
NDkwIC0gNTczMCBAIDE2MCksIChOL0EsIDIzKSwgKDAgbXMpLCBERlMNCj4gICAgICAoNTczNSAt
IDU4MzUgQCA4MCksIChOL0EsIDMwKSwgKE4vQSkNCj4gICAgICAoNTcyNDAgLSA2MzcyMCBAIDIx
NjApLCAoTi9BLCA0MCksIChOL0EpDQo+DQo+IHBoeSMwDQo+IGNvdW50cnkgVVM6IERGUy1GQ0MN
Cj4gICAgICAoMjQwMiAtIDI0NzIgQCA0MCksIChOL0EsIDMwKSwgKE4vQSkNCj4gICAgICAoNTE3
MCAtIDUyNTAgQCA4MCksIChOL0EsIDIzKSwgKE4vQSksIEFVVE8tQlcNCj4gICAgICAoNTI1MCAt
IDUzMzAgQCA4MCksIChOL0EsIDIzKSwgKDAgbXMpLCBERlMsIEFVVE8tQlcNCj4gICAgICAoNTQ5
MCAtIDU3MzAgQCAxNjApLCAoTi9BLCAyMyksICgwIG1zKSwgREZTDQo+ICAgICAgKDU3MzUgLSA1
ODM1IEAgODApLCAoTi9BLCAzMCksIChOL0EpDQo+ICAgICAgKDU3MjQwIC0gNjM3MjAgQCAyMTYw
KSwgKE4vQSwgNDApLCAoTi9BKQ0KPg0KPiBwaHkjMg0KPiBjb3VudHJ5IFVTOiBERlMtRkNDDQo+
ICAgICAgKDI0MDIgLSAyNDcyIEAgNDApLCAoTi9BLCAzMCksIChOL0EpDQo+ICAgICAgKDUxNzAg
LSA1MjUwIEAgODApLCAoTi9BLCAyMyksIChOL0EpLCBBVVRPLUJXDQo+ICAgICAgKDUyNTAgLSA1
MzMwIEAgODApLCAoTi9BLCAyMyksICgwIG1zKSwgREZTLCBBVVRPLUJXDQo+ICAgICAgKDU0OTAg
LSA1NzMwIEAgMTYwKSwgKE4vQSwgMjMpLCAoMCBtcyksIERGUw0KPiAgICAgICg1NzM1IC0gNTgz
NSBAIDgwKSwgKE4vQSwgMzApLCAoTi9BKQ0KPiAgICAgICg1NzI0MCAtIDYzNzIwIEAgMjE2MCks
IChOL0EsIDQwKSwgKE4vQSkNCj4NCj4gSXMgdGhlcmUgYSB3YXkgdG8gcmVtb3ZlIHRoZSBubyBJ
UiBmbGFncyBpbiB0aGUgYWxsb3dlZCBjaGFubmVscz8NCg0KDQpJIGFzc3VtZSB5b3UgYXJlIHRy
eWluZyB0byBicmluZyB1cCBtZXNoIG9uIG9uZSBvZiBERlMgY2hhbm5lbHMgd2hlcmUNCkNBQyBp
cyBtYW5kYXRvcnkgYmVmb3JlIHN0YXJ0aW5nIHRoZSBvcGVyYXRpb24uIFBlcmhhcHMgdHJ5IGNv
bXBsZXRpbmcNCkNBQyBvbiB0aGUgY2hhbm5lbCBhbmQgYnJpbmcgdXAgbWVzaC4NCg0KSWYgeW91
IHdhbnQgdG8gb3BlcmF0ZSBtZXNoIG5ldHdvcmsgb24gY2hhbm5lbCA1MiB3aXRoIDgwIE1oeiBi
YW5kd2lkdGgsDQp5b3UgbWF5IG5lZWQgdG8gcnVuIGNhYyBzb21ldGhpbmcgbGlrZSBiZWxvdyBm
cm9tIGl3IChhIHJlY2VudCBvbmUgd2hpY2ggaGFzDQpzdXBwb3J0IHRvIHRyaWdnZXIgQ0FDKS4N
Cg0Kc3VkbyBpdyB3bGFuWCBjYWMgdHJpZ2dlciBjaGFubmVsIDUyIDgwTUhaDQoNCg0KVmFzYW50
aA0KDQo+DQo+IDIwMTYtMTItMjEgMTU6MTkgR01UKzAxOjAwIE1hdHRlbyBHcmFuZGkgPGl1NWJk
cEBnbWFpbC5jb20+Og0KPj4gRGVhciBhbGwsDQo+Pg0KPj4gSSdtIGNvbmZpZ3VyaW5nIGEgc2lt
cGxlIG1lc2ggbmV0d29yayB1c2luZyBmb3VyIG1pbmlQQ0llIGFkYXB0ZXJzDQo+PiAoQ29tcGV4
IFdMRTkwMFZYKSBvbiB0d28gR2F0ZXdvcmtzIFZlbnRhbmEgNTQxMCBib2FyZHMuDQo+PiBBY3R1
YWxseSwgYmFzZWQgb24gdGhlIGd1aWRlDQo+PiBodHRwczovL3dpcmVsZXNzLndpa2kua2VybmVs
Lm9yZy9lbi91c2Vycy9kcml2ZXJzL2F0aDEway9tZXNoDQo+PiBJIGRvbid0IGhhdmUgYW55IHBy
b2JsZW0gc2V0dGluZyB1cCB0aGUgbWVzaCBuZXR3b3JrIG9uIGNoYW5uZWxzIDM2LA0KPj4gMTQ5
LCAxNTMsIHJlc3BlY3RpdmVseSA1MTgwIDgwIDUyMTAsIDU3NDUgODAgNTc3NSwgYW5kIDU3NjUg
ODAgNTc5NQ0KPj4gKGV2ZW4gaWYgTUlNTyBpcyBub3Qgd29ya2luZykuDQo+Pg0KPj4gQnV0IHdo
aWxlIGNvbmZpZ3VyaW5nIHRoZSBpbnRlcmZhY2VzIHRvIHdvcmsgaW4gODBNSHogY2hhbm5lbA0K
Pj4gYmFuZHdpZHRoICg4MDIuMTFhYyB1c2luZyBhdGgxMGsgZHJpdmVyKSBvbiBhIGRpZmZlcmVu
dCBjaGFubmVsICBJDQo+PiBidW1wIGludG8gdGhlIGVycm9yOg0KPj4NCj4+IGNvbW1hbmQgZmFp
bGVkOiBJbnZhbGlkIGFyZ3VtZW50ICgtMjIpDQo+Pg0KPj4gaW1tZWRpYXRlbHkgYWZ0ZXIgbGF1
bmNoaW5nIHRoZSBjb21tYW5kICBmb3Igam9pbmluZyB0aGUgbWVzaDogaXcgZGV2DQo+PiA8aWZf
bmFtZT4gbWVzaCBqb2luIDxtZXNoX25hbWU+Lg0KPj4NCj4+IFRoZSBzeXNsb2cgcHJvdmlkZSBv
bmx5IHRoaXM6DQo+Pg0KPj4gRGVjIDIxIDEzOjUyOjAzIE1yUHJvcGVyIGtlcm5lbDogWyA3MjU3
LjA1ODYxN10gdXRpbC5jIHwNCj4+IGllZWU4MDIxMV9zZXRfd21tX2RlZmF1bHQ6IGFjPTAsIGVu
YWJsZV9xb3M9dHJ1ZSwgdmlmLnR5cGU9NywNCj4+IE5MODAyMTFfSUZUWVBFX1NUQVRJT049Mg0K
Pj4gRGVjIDIxIDEzOjUyOjAzIE1yUHJvcGVyIGtlcm5lbDogWyA3MjU3LjA1OTY1NF0gSVB2NjoN
Cj4+IEFERFJDT05GKE5FVERFVl9VUCk6IG1wcDE6IGxpbmsgaXMgbm90IHJlYWR5DQo+PiBEZWMg
MjEgMTM6NTI6MDMgTXJQcm9wZXIga2VybmVsOiBbIDcyNTcuMjA1OTExXSBhdGgxMGtfcGNpDQo+
PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykh
DQo+PiBEZWMgMjEgMTM6NTI6MDMgTXJQcm9wZXIga2VybmVsOiBbIDcyNTcuNTgxODk4XSBhdGgx
MGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3Jpbmcg
ZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDMgTXJQcm9wZXIga2VybmVsOiBbIDcyNTcuNjEz
NjI3XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsg
aWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDQgTXJQcm9wZXIga2VybmVsOiBb
IDcyNTguMDg0NzMzXSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29u
ZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDQgTXJQcm9wZXIg
a2VybmVsOiBbIDcyNTguMTgwOTYzXSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNo
YW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDQg
TXJQcm9wZXIga2VybmVsOiBbIDcyNTguMzI1MzgyXSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAw
LjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEg
MTM6NTI6MDQgTXJQcm9wZXIga2VybmVsOiBbIDcyNTguNjYxNTM0XSBhdGgxMGtfcGNpDQo+PiAw
MDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+
PiBEZWMgMjEgMTM6NTI6MDUgTXJQcm9wZXIga2VybmVsOiBbIDcyNTkuMDI5NTI1XSBhdGgxMGtf
cGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJh
bWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDUgTXJQcm9wZXIga2VybmVsOiBbIDcyNTkuMzkyNTYz
XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdu
b3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDggTXJQcm9wZXIga2VybmVsOiBbIDcy
NjIuMzg2MTAxXSBhdGgxMGtfd2FybjogMTgNCj4+IGNhbGxiYWNrcyBzdXBwcmVzc2VkDQo+PiBE
ZWMgMjEgMTM6NTI6MDggTXJQcm9wZXIga2VybmVsOiBbIDcyNjIuMzg2MTU0XSBhdGgxMGtfcGNp
DQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUo
cykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjIuNzM3NTIwXSBh
dGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3Jp
bmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjIu
Nzg1NTk3XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJl
ZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVs
OiBbIDcyNjIuOTcxMTQ0XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwg
Y29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9w
ZXIga2VybmVsOiBbIDcyNjIuOTgxNDE0XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5v
IGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6
MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjMuMDkxNTc4XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3
OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMg
MjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjMuNDQ1NjAzXSBhdGgxMGtfcGNpDQo+
PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykh
DQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjMuNDU4NzI3XSBhdGgx
MGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3Jpbmcg
ZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjMuNTgy
MTgwXSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsg
aWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBb
IDcyNjMuNTg5NjQ5XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29u
ZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MTQgTXJQcm9wZXIg
a2VybmVsOiBbIDcyNjcuNzQyODM4XSBhdGgxMGtfd2FybjogNDQNCj4+IGNhbGxiYWNrcyBzdXBw
cmVzc2VkDQo+PiBEZWMgMjEgMTM6NTI6MTQgTXJQcm9wZXIga2VybmVsOiBbIDcyNjcuNzQyODg3
XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdu
b3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MTQgTXJQcm9wZXIga2VybmVsOiBbIDcy
NjcuNzQ0NDY2XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwNCj4+DQo+
PiBEaWQgc29tZW9uZSBoYXZlIGEgc2ltaWxhciBpc3N1ZT8NCj4+IEFyZSB0aGVyZSwgbWF5YmUs
IHNvbWUgY2hhbm5lbHMgdGhhdCBldmVuIHByZXNlbnQgaW4gdGhlIHJlZ3VsYXRvcnkNCj4+IGRv
bWFpbiB3aXRoIHRoZSBAODAgZmxhZ3MgYXJlIG5vdCBjb25maWd1cmFibGUgaW4gdGhpcyB3YXk/
ICgzNiwgNTIsDQo+PiAxMDAsIDExNiwgMTMyLCAxNDkgc2hvdWxkIGJlIG9rLCBidXQgb25seSAz
NiBhbmQgMTQ5IHdvcmspDQo+PiBPciBtYXliZSBpdCdzIG15IHJlZy1kb21haW4gaXNzdWUgKHNl
ZSBiZWxvdyk/DQo+Pg0KPj4gcm9vdEBNclByb3Blcjp+IyBpdyByZWcgZ2V0DQo+PiBnbG9iYWwN
Cj4+IGNvdW50cnkgVVM6IERGUy1GQ0MNCj4+ICAgICAgKDI0MDIgLSAyNDcyIEAgNDApLCAoTi9B
LCAzMCksIChOL0EpDQo+PiAgICAgICg1MTcwIC0gNTI1MCBAIDgwKSwgKE4vQSwgMjMpLCAoTi9B
KSwgQVVUTy1CVw0KPj4gICAgICAoNTI1MCAtIDUzMzAgQCA4MCksIChOL0EsIDIzKSwgKDAgbXMp
LCBERlMsIEFVVE8tQlcNCj4+ICAgICAgKDU0OTAgLSA1NzMwIEAgMTYwKSwgKE4vQSwgMjMpLCAo
MCBtcyksIERGUw0KPj4gICAgICAoNTczNSAtIDU4MzUgQCA4MCksIChOL0EsIDMwKSwgKE4vQSkN
Cj4+ICAgICAgKDU3MjQwIC0gNjM3MjAgQCAyMTYwKSwgKE4vQSwgNDApLCAoTi9BKQ0KPj4NCj4+
IHBoeSMxDQo+PiBjb3VudHJ5IFVTOiBERlMtRkNDDQo+PiAgICAgICgyNDAyIC0gMjQ3MiBAIDQw
KSwgKE4vQSwgMzApLCAoTi9BKQ0KPj4gICAgICAoNTE3MCAtIDUyNTAgQCA4MCksIChOL0EsIDIz
KSwgKE4vQSksIEFVVE8tQlcNCj4+ICAgICAgKDUyNTAgLSA1MzMwIEAgODApLCAoTi9BLCAyMyks
ICgwIG1zKSwgREZTLCBBVVRPLUJXDQo+PiAgICAgICg1NDkwIC0gNTczMCBAIDE2MCksIChOL0Es
IDIzKSwgKDAgbXMpLCBERlMNCj4+ICAgICAgKDU3MzUgLSA1ODM1IEAgODApLCAoTi9BLCAzMCks
IChOL0EpDQo+PiAgICAgICg1NzI0MCAtIDYzNzIwIEAgMjE2MCksIChOL0EsIDQwKSwgKE4vQSkN
Cj4+DQo+PiBwaHkjMA0KPj4gY291bnRyeSBVUzogREZTLUZDQw0KPj4gICAgICAoMjQwMiAtIDI0
NzIgQCA0MCksIChOL0EsIDMwKSwgKE4vQSkNCj4+ICAgICAgKDUxNzAgLSA1MjUwIEAgODApLCAo
Ti9BLCAyMyksIChOL0EpLCBBVVRPLUJXDQo+PiAgICAgICg1MjUwIC0gNTMzMCBAIDgwKSwgKE4v
QSwgMjMpLCAoMCBtcyksIERGUywgQVVUTy1CVw0KPj4gICAgICAoNTQ5MCAtIDU3MzAgQCAxNjAp
LCAoTi9BLCAyMyksICgwIG1zKSwgREZTDQo+PiAgICAgICg1NzM1IC0gNTgzNSBAIDgwKSwgKE4v
QSwgMzApLCAoTi9BKQ0KPj4gICAgICAoNTcyNDAgLSA2MzcyMCBAIDIxNjApLCAoTi9BLCA0MCks
IChOL0EpDQo+Pg0KPj4gcGh5IzINCj4+IGNvdW50cnkgVVM6IERGUy1GQ0MNCj4+ICAgICAgKDI0
MDIgLSAyNDcyIEAgNDApLCAoTi9BLCAzMCksIChOL0EpDQo+PiAgICAgICg1MTcwIC0gNTI1MCBA
IDgwKSwgKE4vQSwgMjMpLCAoTi9BKSwgQVVUTy1CVw0KPj4gICAgICAoNTI1MCAtIDUzMzAgQCA4
MCksIChOL0EsIDIzKSwgKDAgbXMpLCBERlMsIEFVVE8tQlcNCj4+ICAgICAgKDU0OTAgLSA1NzMw
IEAgMTYwKSwgKE4vQSwgMjMpLCAoMCBtcyksIERGUw0KPj4gICAgICAoNTczNSAtIDU4MzUgQCA4
MCksIChOL0EsIDMwKSwgKE4vQSkNCj4+ICAgICAgKDU3MjQwIC0gNjM3MjAgQCAyMTYwKSwgKE4v
QSwgNDApLCAoTi9BKQ0KPj4NCj4+DQo+PiBUaGFua3MgYSBsb3QgZm9yIGV2ZXJ5IGhpbnQhDQo+
Pg0KPj4gTWF0dGVvDQo=
^ permalink raw reply
* [PATCH] brcmfmac: fix spelling mistakes on "Ivalid"
From: Colin King @ 2016-12-23 0:43 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo,
Pieter-Paul Giesberts, Rafał Miłecki, linux-wireless,
brcm80211-dev-list.pdl, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fixes to spelling mistake "Ivalid" to "Invalid" in
brcmf_err error messages.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 7ffc4ab..15eaf72 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3971,7 +3971,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
pval |= AES_ENABLED;
break;
default:
- brcmf_err("Ivalid unicast security info\n");
+ brcmf_err("Invalid unicast security info\n");
}
offset++;
}
@@ -4015,7 +4015,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
wpa_auth |= WPA2_AUTH_1X_SHA256;
break;
default:
- brcmf_err("Ivalid key mgmt info\n");
+ brcmf_err("Invalid key mgmt info\n");
}
offset++;
}
--
2.10.2
^ permalink raw reply related
* [PATCH] ath10k: ignore configuring the incorrect board_id
From: ryanhsu @ 2016-12-22 23:02 UTC (permalink / raw)
To: ath10k, linux-wireless; +Cc: ryanhsu
From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
With command to get board_id from otp, in the case of following
boot get otp board id result 0x00000000 board_id 0 chip_id 0
boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0"
...
failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from
ath10k/QCA6174/hw3.0/board-2.bin
The invalid board_id=0 will be used as index to search in the board-2.bin.
Ignore the case with board_id=0, as it means the otp is not carrying
the board id information.
Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 749e381..1bf67ad 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -694,8 +694,11 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k *ar)
"boot get otp board id result 0x%08x board_id %d chip_id %d\n",
result, board_id, chip_id);
- if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0)
+ if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0 ||
+ (board_id == 0)) {
+ ath10k_warn(ar, "board id is not exist in otp, ignore it\n");
return -EOPNOTSUPP;
+ }
ar->id.bmi_ids_valid = true;
ar->id.bmi_board_id = board_id;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Rob Herring @ 2016-12-22 23:02 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo,
mark.rutland, netdev, devicetree, linux-kernel, mgreer, justin
In-Reply-To: <1482380314-16440-2-git-send-email-geoff@kuvee.com>
On Wed, Dec 21, 2016 at 11:18:33PM -0500, Geoff Lansberry wrote:
> The TRF7970A has configuration options for supporting hardware designs
> with 1.8 Volt or 3.3 Volt IO. This commit adds a device tree option,
> using a fixed regulator binding, for setting the io voltage to match
> the hardware configuration. If no option is supplied it defaults to
> 3.3 volt configuration.
>
> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
> ---
> .../devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/nfc/trf7970a.c | 26 +++++++++++++++++++++-
> 2 files changed, 27 insertions(+), 1 deletion(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox