* Re: [PATCH 1/3] ath9k: Add a module parameter to set btcoex duty cycle
From: Valo, Kalle @ 2016-11-25 15:25 UTC (permalink / raw)
To: miaoqing@codeaurora.org; +Cc: linux-wireless@vger.kernel.org, ath9k-devel
In-Reply-To: <1479970402-13796-1-git-send-email-miaoqing@codeaurora.org>
miaoqing@codeaurora.org writes:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> btcoex duty cyle allows user to balance the performance
> between WLAN and BT.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
[...]
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -73,6 +73,12 @@ struct ath9k_eeprom_ctx {
> =20
> #endif /* CONFIG_ATH9K_CHANNEL_CONTEXT */
> =20
> +#ifdef CONFIG_ATH9K_BTCOEX_SUPPORT
> +static int ath9k_btcoex_duty_cycle =3D ATH_BTCOEX_DEF_DUTY_CYCLE;
> +module_param_named(btcoex_duty_cycle, ath9k_btcoex_duty_cycle, int, 0444=
);
> +MODULE_PARM_DESC(btcoex_duty_cycle, "BT coexistence duty cycle");
> +#endif
I don't think module parameters are really meant for providing protocol
settings like this, especially as these would be global for all radios.
nl80211 (if used in production) or debugfs (if used only in testing) are
much better choises.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH v2] ath9k: Introduce airtime fairness scheduling between stations
From: Valo, Kalle @ 2016-11-25 15:16 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20161124135455.29327-1-toke@toke.dk>
KFRoZSBtYWtlLXdpZmktZmFzdCBsaXN0IGlzIGFubm95aW5nIGFzIGl0IGFsd2F5cyBzcGFtcyBt
ZSB3aGVuIGl0J3Mgb24NCkNDLCBzbyBkcm9wcGVkIGl0LikNCg0KVG9rZSBIw7hpbGFuZC1Kw7hy
Z2Vuc2VuIDx0b2tlQHRva2UuZGs+IHdyaXRlczoNCg0KPiBUaGlzIHJld29ya3MgdGhlIGF0aDlr
IGRyaXZlciB0byBzY2hlZHVsZSB0cmFuc21pc3Npb25zIHRvIGNvbm5lY3RlZA0KPiBzdGF0aW9u
cyBpbiBhIHdheSB0aGF0IGVuZm9yY2VzIGFpcnRpbWUgZmFpcm5lc3MgYmV0d2VlbiB0aGVtLiBJ
dA0KPiBhY2NvbXBsaXNoZXMgdGhpcyBieSBtZWFzdXJpbmcgdGhlIHRpbWUgc3BlbnQgdHJhbnNt
aXR0aW5nIHRvIG9yDQo+IHJlY2VpdmluZyBmcm9tIGEgc3RhdGlvbiBhdCBUWCBhbmQgUlggY29t
cGxldGlvbiwgYW5kIGFjY291bnRpbmcgdGhpcyB0bw0KPiBhIHBlci1zdGF0aW9uLCBwZXItUW9T
IGxldmVsIGFpcnRpbWUgZGVmaWNpdC4gVGhlbiwgYW4gRlEtQ29EZWwgYmFzZWQNCj4gZGVmaWNp
dCBzY2hlZHVsZXIgaXMgZW1wbG95ZWQgYXQgcGFja2V0IGRlcXVldWUgdGltZSwgdG8gY29udHJv
bCB3aGljaA0KPiBzdGF0aW9uIGdldHMgdGhlIG5leHQgdHJhbnNtaXNzaW9uIG9wcG9ydHVuaXR5
Lg0KPg0KPiBBaXJ0aW1lIGZhaXJuZXNzIGNhbiBzaWduaWZpY2FudGx5IGltcHJvdmUgdGhlIGVm
ZmljaWVuY3kgb2YgdGhlIG5ldHdvcmsNCj4gd2hlbiBzdGF0aW9uIHJhdGVzIHZhcnkuIFRoZSBm
b2xsb3dpbmcgdGhyb3VnaHB1dCB2YWx1ZXMgYXJlIGZyb20gYQ0KPiBzaW1wbGUgdGhyZWUtc3Rh
dGlvbiB0ZXN0IHNjZW5hcmlvLCB3aGVyZSB0d28gc3RhdGlvbnMgb3BlcmF0ZSBhdCB0aGUNCj4g
aGlnaGVzdCBIVDIwIHJhdGUsIGFuZCBvbmUgc3RhdGlvbiBhdCB0aGUgbG93ZXN0LCBhbmQgdGhl
IHNjaGVkdWxlciBpcw0KPiBlbXBsb3llZCBhdCB0aGUgYWNjZXNzIHBvaW50Og0KPg0KPiAgICAg
ICAgICAgICAgICAgICBCZWZvcmUgICAvICAgQWZ0ZXINCj4gRmFzdCBzdGF0aW9uIDE6ICAgIDE5
LjE3ICAgLyAgIDI1LjA5IE1icHMNCj4gRmFzdCBzdGF0aW9uIDI6ICAgIDE5LjgzICAgLyAgIDI1
LjIxIE1icHMNCj4gU2xvdyBzdGF0aW9uOiAgICAgICAyLjU4ICAgLyAgICAxLjc3IE1icHMNCj4g
VG90YWw6ICAgICAgICAgICAgIDQxLjU4ICAgLyAgIDUyLjA3IE1icHMNCj4NCj4gVGhlIGJlbmVm
aXQgb2YgYWlydGltZSBmYWlybmVzcyBnb2VzIHVwIHRoZSBtb3JlIHN0YXRpb25zIGFyZSBwcmVz
ZW50Lg0KPiBJbiBhIDMwLXN0YXRpb24gdGVzdCB3aXRoIG9uZSBzdGF0aW9uIGFydGlmaWNpYWxs
eSBsaW1pdGVkIHRvIDEgTWJwcywNCj4gd2UgaGF2ZSBzZWVuIGFnZ3JlZ2F0ZSB0aHJvdWdocHV0
IGdvIGZyb20gMi4xNCB0byAxNy43NiBNYnBzLg0KPg0KPiBTaWduZWQtb2ZmLWJ5OiBUb2tlIEjD
uGlsYW5kLUrDuHJnZW5zZW4gPHRva2VAdG9rZS5kaz4NCg0KWy4uLl0NCg0KPiArdm9pZCBhdGhf
YWNxX2xvY2soc3RydWN0IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBhdGhfYWNxICphY3EpDQo+ICsJ
X19hY3F1aXJlcygmYWNxLT5sb2NrKQ0KPiArew0KPiArCXNwaW5fbG9ja19iaCgmYWNxLT5sb2Nr
KTsNCj4gK30NCj4gKw0KPiArdm9pZCBhdGhfYWNxX3VubG9jayhzdHJ1Y3QgYXRoX3NvZnRjICpz
Yywgc3RydWN0IGF0aF9hY3EgKmFjcSkNCj4gKwlfX3JlbGVhc2VzKCZhY3EtPmxvY2spDQo+ICt7
DQo+ICsJc3Bpbl91bmxvY2tfYmgoJmFjcS0+bG9jayk7DQo+ICt9DQoNCldoeSB0aGVzZT8gVG8g
bWUgaXQgbG9va3MgbGlrZSB0aGV5IGp1c3QgYWRkIGFuIGV4dHJhIGZ1bmN0aW9uIGp1bXAgYW5k
DQp1bm5lY2Nlc3NhcnkgZXh0cmEgbGF5ZXIuDQoNCi0tIA0KS2FsbGUgVmFsbw==
^ permalink raw reply
* Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements
From: Valo, Kalle @ 2016-11-25 15:06 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, devicetree@vger.kernel.org,
arnd@arndb.de, chunkeey@googlemail.com, nbd@nbd.name
In-Reply-To: <87insxg0yc.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>
>> There are two types of swapping the EEPROM data in the ath9k driver.
>> Before this series one type of swapping could not be used without the
>> other.
>>
>> The first type of swapping looks at the "magic bytes" at the start of
>> the EEPROM data and performs swab16 on the EEPROM contents if needed.
>> The second type of swapping is EEPROM format specific and swaps
>> specific fields within the EEPROM itself (swab16, swab32 - depends on
>> the EEPROM format).
>>
>> With this series the second part now looks at the EEPMISC register
>> inside the EEPROM, which uses a bit to indicate if the EEPROM data
>> is Big Endian (this is also done by the FreeBSD kernel).
>> This has a nice advantage: currently there are some out-of-tree hacks
>> (in OpenWrt and LEDE) where the EEPROM has a Big Endian header on a
>> Big Endian system (=3D no swab16 is performed) but the EEPROM itself
>> indicates that it's data is Little Endian. Until now the out-of-tree
>> code simply did a swab16 before passing the data to ath9k, so ath9k
>> first did the swab16 - this also enabled the format specific swapping.
>> These out-of-tree hacks are still working with the new logic, but it
>> is recommended to remove them. This implementation is based on a
>> discussion with Arnd Bergmann who raised concerns about the
>> robustness and portability of the swapping logic in the original OF
>> support patch review, see [0].
>>
>> After a second round of patches (=3D v1 of this series) neither Arnd
>> Bergmann nor I were really happy with the complexity of the EEPROM
>> swapping logic. Based on a discussion (see [1] and [2]) we decided
>> that ath9k should use a defined format (specifying the endianness
>> of the data - I went with __le16 and __le32) when accessing the
>> EEPROM fields. A benefit of this is that we enable the EEPMISC based
>> swapping logic by default, just like the FreeBSD driver, see [3]. On
>> the devices which I have tested (see below) ath9k now works without
>> having to specify the "endian_check" field in ath9k_platform_data (or
>> a similar logic which could provide this via devicetree) as ath9k now
>> detects the endianness automatically. Only EEPROMs which are mangled
>> by some out-of-tree code still need the endian_check flag (or one can
>> simply remove that mangling from the out-of-tree code).
>>
>> Testing:
>> - tested by myself on AR9287 with Big Endian EEPROM
>> - tested by myself on AR9227 with Little Endian EEPROM
>> - tested by myself on AR9381 (using the ar9003_eeprom implementation,
>> which did not suffer from this whole problem)
>> - how do we proceed with testing? maybe we could keep this in a
>> feature-branch and add these patches to LEDE once we have an ACK to
>> get more people to test this
>>
>> This series depends on my other series (v7):
>> "add devicetree support to ath9k" - see [4]
>
> I think this looks pretty good. If there's a bug somewhere it should be
> quite easy to fix so I'm not that worried and would be willing to take
> these as soon as I have applied the dependency series. IIRC your
> devicetree patches will have at least one more review round so that will
> take some time still. In the meantime it would be great if LEDE folks
> could take a look at these and comment (or test).
So are everyone happy with this? I haven't seen any comments. If I don't
here anything I'm planning to take these, most likely for 4.11.
--=20
Kalle Valo=
^ permalink raw reply
* [PATCH] mt7601u: wait for clear rxq when stopping mac
From: Anthony Romano @ 2016-11-25 11:13 UTC (permalink / raw)
To: linux-wireless; +Cc: kubakici
mt7601u_mac_stop_hw should stop polling the rxq once it remains empty
but instead continues polling after the rxq status stays clear; bringing
down the interface takes about six seconds from this alone.
Speed up path by exiting rxq loop once status repeatedly polls empty.
Signed-off-by: Anthony Romano <anthony.romano@coreos.com>
---
drivers/net/wireless/mediatek/mt7601u/init.c | 14 +++++++-------
drivers/net/wireless/mediatek/mt7601u/regs.h | 3 +++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/init.c b/drivers/net/wireless/mediatek/mt7601u/init.c
index 44d46e25db80..a6e901766226 100644
--- a/drivers/net/wireless/mediatek/mt7601u/init.c
+++ b/drivers/net/wireless/mediatek/mt7601u/init.c
@@ -293,13 +293,13 @@ static void mt7601u_mac_stop_hw(struct mt7601u_dev *dev)
ok = 0;
i = 200;
while (i--) {
- if ((mt76_rr(dev, 0x0430) & 0x00ff0000) ||
- (mt76_rr(dev, 0x0a30) & 0xffffffff) ||
- (mt76_rr(dev, 0x0a34) & 0xffffffff))
- ok++;
- if (ok > 6)
- break;
-
+ if (!(mt76_rr(dev, MT_RXQ_STA) & 0x00ff0000) &&
+ !mt76_rr(dev, 0x0a30) &&
+ !mt76_rr(dev, 0x0a34)) {
+ if (ok++ > 5)
+ break;
+ continue;
+ }
msleep(1);
}
diff --git a/drivers/net/wireless/mediatek/mt7601u/regs.h b/drivers/net/wireless/mediatek/mt7601u/regs.h
index 27a429d90cec..2a8837002f00 100644
--- a/drivers/net/wireless/mediatek/mt7601u/regs.h
+++ b/drivers/net/wireless/mediatek/mt7601u/regs.h
@@ -192,6 +192,9 @@
#define MT_BCN_OFFSET_BASE 0x041c
#define MT_BCN_OFFSET(_n) (MT_BCN_OFFSET_BASE + ((_n) << 2))
+#define MT_RXQ_STA 0x0430
+#define MT_TXQ_STA 0x0434
+
#define MT_RF_CSR_CFG 0x0500
#define MT_RF_CSR_CFG_DATA GENMASK(7, 0)
#define MT_RF_CSR_CFG_REG_ID GENMASK(13, 8)
--
2.11.0.rc2
^ permalink raw reply related
* Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: IgorMitsyanko @ 2016-11-25 10:16 UTC (permalink / raw)
To: Kalle Valo
Cc: Johannes Berg, linux-wireless, btherthala, hwang, smaksimenko,
dlebed, Igor Mitsyanko, Kamlesh Rath, Sergey Matyukevich,
Avinash Patil, Ben Hutchings, Kyle McMartin
In-Reply-To: <87shqhf5rs.fsf@kamboji.qca.qualcomm.com>
On 11/24/2016 02:59 PM, Kalle Valo wrote:
> IgorMitsyanko <igor.mitsyanko.os@quantenna.com> writes:
>
>> On 11/23/2016 06:25 PM, Kalle Valo wrote:
>>> IgorMitsyanko <igor.mitsyanko.os@quantenna.com> writes:
>>>
>>>> To clarify with you and Kalle, as persons involved with
>>>> linux-wireless: is my understanding correct that submitting firmware
>>>> into linux-fimware repository is a prerequisite to accepting new
>>>> driver into linux-wireless?
>>> In my opinion the most important is that the device is usable with an
>>> upstream driver so that anyone can start using the driver (if they have
>>> the hardware).
>>>
>>>> There is an option to start Quantenna device from internal flash
>>>> memory, no external binary files involved. If we will introduce this
>>>> functionality and remove code handling external firmware for now
>>>> (until firmware problem resolved), would that allow driver to be
>>>> reviewed/accepted?
>>> Do all the publically available hardware contain the firmware in
>>> internal flash (flashed in the factory)? Or is this something which must
>>> be installed separately for each board's internal flash by the user?
>> Each board must have flash installed on it, preflashed in the factory
>> with uboot and firmware binary, otherwise board won't boot
> Will the preflashed firmware binary will have all the normal
> functionality needed by this driver? I mean that you can start an AP
> interface etc.
Yes, we tried to design system in a way that the same firmware will
support working as a FullMAC device with cfg80211 framework, as well as
working in a default mode of emulating ethernet card (when all wireless
rated components are hidden inside device itself); it's just a problem
of telling device which mode it should boot to.
>> (won't boot without uboot, firmware itself is not mandatory).
> Are you expecting that there are devices on the field which have uboot
> preflashed but not the firmware?
For the new QSR10G chipset, there are no such devices right now. I think
it is possible for them to appear in the future: makes sense to have
designs with smaller flash sizes, to save a few cents on each device,
but hopefully by that time we will have firmware binary accepted in
linux-firmare.
>
>> Booting from flash is default behavior on boards that are currently on
>> the market, but for developemnt purpuses it's not very convenient and
>> harder to upgrade.
> Sure, I understand.
>
>>> BTW, the original mail with the firmware image didn't make it to the
>>> list, I guess it was too big? It would be good if you could post the
>>> license separately so that people can see it.
>>>
>> I resent the email without binary patch to linux-wireless.
> Saw it now, thanks.
>
^ permalink raw reply
* Re: [PATCH] nl80211: provide minimum scheduled scan (plan) interval
From: Luca Coelho @ 2016-11-25 10:30 UTC (permalink / raw)
To: Arend van Spriel, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <3fa55a67-4447-9c41-23d2-689db818b60d@broadcom.com>
On Fri, 2016-11-25 at 11:06 +0100, Arend van Spriel wrote:
>
> On 11/25/2016 9:25 AM, Johannes Berg wrote:
> > Sorry, forgot to reply to this until Luca's email bumped it up...
> >
> > On Tue, 2016-11-22 at 21:06 +0100, Arend Van Spriel wrote:
> >
> > > Are we? Currently, the minimum is not checked in nl80211, but that
> > > does not say anything about the driver which might validate the
> > > interval as well and return an error.
> >
> > Well, since drivers currently don't return an error (even if they
> > ignore the value!) that *does* change the API.
> >
> > > What made me start looking at this is that in brcmfmac the interval
> > > in the request was ignored and a fixed interval was provisioned in
> > > the device. I wanted to fix that but was not sure if I needed to
> > > check it against our firmware min..max range and what the appropriate
> > > error handling should be. If silently changing what user-space is
> > > requesting is fine for this, I am happy to make it so. Preferably in
> > > nl80211.
> >
> > I think (agreeing with Luca) bumping it up is fine.
>
> Fine by me although the "drift over time" reason seems only more reason
> to have minimum validation mainly because nowhere is nl80211.h it is
> stated that the interval is a "soft" requirement. Now Luca proposes
> bumping to minimum should be done in the driver. What is your opinion?
>
> I will update the kernel doc to clarify what can be expected from the
> interval value.
Yeah, I was almost sure there was a statement somewhere that the
interval is "soft", but there isn't. I was confusing with the match
logic, which is clearly documented as not-guaranteed: "...there is no
guarantee that the reported BSSs are fully complying with the match
sets and userspace needs to be able to ignore them by itself."
A clarification in the documentation would be great.
--
Luca.
^ permalink raw reply
* Re: [PATCH] nl80211: provide minimum scheduled scan (plan) interval
From: Arend van Spriel @ 2016-11-25 10:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <1480062330.4317.2.camel@sipsolutions.net>
On 11/25/2016 9:25 AM, Johannes Berg wrote:
> Sorry, forgot to reply to this until Luca's email bumped it up...
>
> On Tue, 2016-11-22 at 21:06 +0100, Arend Van Spriel wrote:
>
>> Are we? Currently, the minimum is not checked in nl80211, but that
>> does not say anything about the driver which might validate the
>> interval as well and return an error.
>
> Well, since drivers currently don't return an error (even if they
> ignore the value!) that *does* change the API.
>
>> What made me start looking at this is that in brcmfmac the interval
>> in the request was ignored and a fixed interval was provisioned in
>> the device. I wanted to fix that but was not sure if I needed to
>> check it against our firmware min..max range and what the appropriate
>> error handling should be. If silently changing what user-space is
>> requesting is fine for this, I am happy to make it so. Preferably in
>> nl80211.
>
> I think (agreeing with Luca) bumping it up is fine.
Fine by me although the "drift over time" reason seems only more reason
to have minimum validation mainly because nowhere is nl80211.h it is
stated that the interval is a "soft" requirement. Now Luca proposes
bumping to minimum should be done in the driver. What is your opinion?
I will update the kernel doc to clarify what can be expected from the
interval value.
Regards,
Arend
^ permalink raw reply
* Re: [1/4] rsi: Add support to filter rx frames
From: Kalle Valo @ 2016-11-25 9:48 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk,
prameela.garnepudi, Prameela Rani Garnepudi
In-Reply-To: <1479465429-2412-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> wrote:
> Filtering rx frames after connection in station mode avoids the
> overhead of processing un-necessary frames. Hence rx filter frame
> is added which can be configured to device at suitable times.
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
4 patches applied to wireless-drivers-next.git, thanks.
e6d6428449c5 rsi: Add support to filter rx frames
8b36de8cf5ab rsi: Add support for configuring tx power
4edbcd1aa783 rsi: Add support for antenna selection
61d108421422 rsi: Add support for 802.11d
--
https://patchwork.kernel.org/patch/9436189/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmsmac: fix array out-of-bounds access in qm_log10
From: Kalle Valo @ 2016-11-25 9:57 UTC (permalink / raw)
To: Tobias Regnery
Cc: linux-wireless, arend.vanspriel, franky.lin, hante.meuleman,
brcm80211-dev-list.pdl, Tobias Regnery
In-Reply-To: <1479734949-6300-1-git-send-email-tobias.regnery@gmail.com>
Tobias Regnery <tobias.regnery@gmail.com> wrote:
> I get the following UBSAN warning during boot on my laptop:
>
> ================================================================================
> UBSAN: Undefined behaviour in drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c:280:21
> index 32 is out of range for type 's16 [32]'
> CPU: 0 PID: 879 Comm: NetworkManager Not tainted 4.9.0-rc4 #28
> Hardware name: LENOVO Lenovo IdeaPad N581/INVALID, BIOS 5ECN96WW(V9.01) 03/14/2013
> ffff8800b74a6478 ffffffff828e59d2 0000000041b58ab3 ffffffff8398330c
> ffffffff828e5920 ffff8800b74a64a0 ffff8800b74a6450 0000000000000020
> 1ffffffff845848c ffffed0016e94bf1 ffffffffc22c2460 000000006b9c0514
> Call Trace:
> [<ffffffff828e59d2>] dump_stack+0xb2/0x110
> [<ffffffff828e5920>] ? _atomic_dec_and_lock+0x150/0x150
> [<ffffffff82968c9d>] ubsan_epilogue+0xd/0x4e
> [<ffffffff82969875>] __ubsan_handle_out_of_bounds+0xfa/0x13e
> [<ffffffff8296977b>] ? __ubsan_handle_shift_out_of_bounds+0x241/0x241
> [<ffffffffc0d48379>] ? bcma_host_pci_read16+0x59/0xa0 [bcma]
> [<ffffffffc0d48388>] ? bcma_host_pci_read16+0x68/0xa0 [bcma]
> [<ffffffffc212ad78>] ? read_phy_reg+0xe8/0x180 [brcmsmac]
> [<ffffffffc2184714>] qm_log10+0x2e4/0x350 [brcmsmac]
> [<ffffffffc2142eb8>] wlc_phy_init_lcnphy+0x538/0x1f20 [brcmsmac]
> [<ffffffffc2142980>] ? wlc_lcnphy_periodic_cal+0x5c0/0x5c0 [brcmsmac]
> [<ffffffffc1ba0c93>] ? ieee80211_open+0xb3/0x110 [mac80211]
> [<ffffffff82f73a02>] ? sk_busy_loop+0x1e2/0x840
> [<ffffffff82f7a6ce>] ? __dev_change_flags+0xae/0x220
> ...
>
> The report is valid: doing the math in this function, with an input value
> N=63 the variable s16tableIndex gets a value of 31. This value is used as
> an index in the array log_table with 32 entries. But the next line is:
>
> s16errorApproximation = (s16) qm_mulu16(u16offset,
> (u16) (log_table[s16tableIndex + 1] -
> log_table[s16tableIndex]));
>
> With s16tableIndex + 1 we are trying an out-of-bounds access to the array.
>
> The log_table array provides log2 values in q.15 format and the above
> statement tries an error approximation with the next value. To fix this
> issue add the next value to the array and update the comment accordingly.
>
> Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
4c0bfeaae9f9 brcmsmac: fix array out-of-bounds access in qm_log10
--
https://patchwork.kernel.org/patch/9439423/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: Disable adhoc feature based on firmware capability
From: Kalle Valo @ 2016-11-25 9:55 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Karthik D A,
Amitkumar Karwar
In-Reply-To: <1479730744-8964-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Karthik D A <karthida@marvell.com>
>
> We will read fw_cap_info filled by firmware to check whether to
> skip ADHOC related commands or not. Also, IBSS_COALESCING_STATUS
> command has been moved from init path to adhoc network creation
> path.
>
> Signed-off-by: Karthik D A <karthida@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Patch applied to wireless-drivers-next.git, thanks.
e267e71e68ae mwifiex: Disable adhoc feature based on firmware capability
--
https://patchwork.kernel.org/patch/9439379/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/7] rtl8xxxu: Fix memory leak in handling rxdesc16 packets
From: Kalle Valo @ 2016-11-25 9:51 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, Larry.Finger, Jes Sorensen
In-Reply-To: <1479505468-29383-2-git-send-email-Jes.Sorensen@redhat.com>
Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> A device running without RX package aggregation could return more data
> in the USB packet than the actual network packet. In this case the
> could would clone the skb but then determine that that there was no
> packet to handle and exit without freeing the cloned skb first.
>
> This has so far only been observed with 8188eu devices, but could
> affect others.
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
7 patches applied to wireless-drivers-next.git, thanks.
a0aba89763f8 rtl8xxxu: Fix memory leak in handling rxdesc16 packets
cf7cfef06462 rtl8xxxu: Fix big-endian problem reporting mactime
b9af93551127 rtl8xxxu: Fix rtl8723bu driver reload issue
5d03f882c2fc rtl8xxxu: Fix rtl8192eu driver reload issue
a748a11038f8 rtl8xxxu: Obtain RTS rates from mac80211
b4c3d9cfb607 rtl8xxxu: Pass tx_info to fill_txdesc in order to have access to retry count
13e1349aff82 rtl8xxxu: Fix non static symbol warning
--
https://patchwork.kernel.org/patch/9437419/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] mwifiex: cleanup wake-IRQ handling if suspend fails
From: Kalle Valo @ 2016-11-25 9:50 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, rajatja, briannorris, dmitry.torokhov,
Brian Norris, Amitkumar Karwar
In-Reply-To: <1479489205-30288-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Brian Norris <briannorris@chromium.org>
>
> We don't want to leave the wake IRQ enabled.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
2 patches applied to wireless-drivers-next.git, thanks.
d96e39270ba5 mwifiex: cleanup wake-IRQ handling if suspend fails
b9da4d223bda mwifiex: avoid double-disable_irq() race
--
https://patchwork.kernel.org/patch/9437097/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* pull-request: wireless-drivers-next 2016-11-25
From: Kalle Valo @ 2016-11-25 9:39 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request for 4.10. ath9k has now been converted to use
mac80211 intermediate software queues to fix bufferbloat problems. rsi
has become active again and latevy mwifiex has been getting a _lot_ of
love.
I'm not expecting to see any problems with this pull request. When you
pull git will do lots of automerging but at least I didn't see any
conflicts. Please let me know if you have any problems.
Kalle
The following changes since commit 6edf10173a1feb1078f2fc8c655baf9614e83493:
devlink: Prevent port_type_set() callback when it's not needed (2016-10-2=
6 17:30:32 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next=
.git tags/wireless-drivers-next-for-davem-2016-11-25
for you to fetch changes up to 159a55a64d44acbbd6f0d8f3c082e628d6d75670:
rt2800: disable CCK rates on HT (2016-11-23 17:38:53 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.10
Major changes:
iwlwifi
* finalize and enable dynamic queue allocation
* use dev_coredumpmsg() to prevent locking the driver
* small fix to pass the AID to the FW
* use FW PS decisions with multi-queue
ath9k
* add device tree bindings
* switch to use mac80211 intermediate software queues to reduce
latency and fix bufferbloat
wl18xx
* allow scanning in AP mode
----------------------------------------------------------------
Amitkumar Karwar (6):
mwifiex: prevent register accesses after host is sleeping
mwifiex: report error to PCIe for suspend failure
mwifiex: Fix NULL pointer dereference in skb_dequeue()
mwifiex: add memrw command information in README
mwifiex: ignore calibration data failure
mwifiex: remove redundant pdev check in suspend/resume handlers
Anilkumar Kolli (1):
ath10k: add cc_wraparound type for QCA9888 and QCA9884
Arnd Bergmann (2):
wireless: fix bogus maybe-uninitialized warning
cw1200: fix bogus maybe-uninitialized warning
Aviya Erenfeld (1):
iwlwifi: mvm: use dev_coredumpsg()
Bartosz Markowski (1):
ath10k: add platform regulatory domain support
Benjamin Berg (1):
ath10k: allow setting coverage class
Brian Norris (8):
mwifiex: don't do unbalanced free()'ing in cleanup_if()
mwifiex: resolve races between async FW init (failure) and device rem=
oval
mwifiex: don't pretend to resume while remove()'ing
mwifiex: resolve suspend() race with async FW init failure
mwifiex: usb: handle HS failures
mwifiex: sdio: don't check for NULL sdio_func
mwifiex: stop checking for NULL drvata/intfdata
mwifiex: pcie: stop checking for NULL adapter->card
Colin Ian King (1):
ath9k_htc: fix minor mistakes in dev_err messages
Emmanuel Grumbach (1):
iwlwifi: mvm: tell the firmware about the AID of the peer
James Minor (4):
ath6kl: fix busreqs so they can be reused when sg is cleaned up
ath6kl: after cleanup properly reflect that sg is disabled
ath6kl: configure SDIO when power is reapplied
wlcore: Allow scans when in AP mode
Jiri Slaby (1):
p54: memset(0) whole array
Johannes Berg (1):
iwlwifi: mvm: use firmware station PM notification for AP_LINK_PS
Johannes Thumshirn (1):
cw1200: Don't leak memory if krealloc failes
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2016-10-25-2' of git://git.kernel.o=
rg/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthik D A (2):
mwifiex: vendor_ie length check for parse WMM IEs
mwifiex: fix p2p device doesn't find in scan problem
Larry Finger (9):
rtlwifi: rtl8192de: Remove address of Free Software Foundation
rtlwifi: rtl8192se: Remove address of Free Software Foundation
rtlwifi: rtl8192ce: Remove address of Free Software Foundation
rtlwifi: rtl8192cu: Remove address of Free Software Foundation
rtlwifi: rtl8723ae: Remove address of Free Software Foundation
rtlwifi: rtl8188ee: Remove address of Free Software Foundation
rtlwifi: rtl8192c: Remove address of Free Software Foundation
rtlwifi: Remove address of Free Software Foundation
ssb: Fix error routine when fallback SPROM fails
Liad Kaufman (5):
iwlwifi: mvm: update txq metadata to current owner
iwlwifi: mvm: fix reserved txq freeing
iwlwifi: mvm: support MONITOR vif in DQA mode
iwlwifi: mvm: fix dqa deferred frames marking
iwlwifi: mvm: enable dynamic queue allocation mode
Maharaja Kennadyrajan (1):
ath10k: provide provision to get Transmit Power Control stats for 10.4
Martin Blumenstingl (3):
Documentation: dt: net: add ath9k wireless device binding
ath9k: add a helper to get the string representation of ath_bus_type
ath9k: parse the device configuration from an OF node
Mathias Kresin (1):
rt2x00: add support for mac addr from device tree
Maxim Altshul (2):
wlcore: Pass win_size taken from ieee80211_sta to FW
wlcore: Add RX_BA_WIN_SIZE_CHANGE_EVENT event
Miaoqing Pan (1):
ath9k: change entropy formula for easier understanding
Michal Kazior (1):
ath: export alpha2 helper
Mohammed Shafi Shajakhan (4):
ath10k: cleanup calling ath10k_htt_rx_h_unchain
ath10k: fix failure to send NULL func frame for 10.4
ath10k: clean up HTT tx buffer allocation and free
ath10k: remove extraneous error message in tx alloc
Nicolas Iooss (1):
ath10k: use the right length of "background"
Prameela Rani Garnepudi (2):
rsi: Fix memory leak in module unload
rsi: Host to device command frame vap_capabilites modified with new f=
ield vap status
Rafa=C5=82 Mi=C5=82ecki (2):
brcmfmac: proto: add callback for queuing TX data
brcmfmac: print name of connect status event
Rajat Jain (4):
mwifiex: report wakeup for wowlan
mwifiex: Allow mwifiex early access to device structure
mwifiex: Introduce mwifiex_probe_of() to parse common properties
mwifiex: Enable WoWLAN for both sdio and pcie
Ricky Liang (1):
mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()
Sara Sharon (1):
iwlwifi: mvm: assign cab queue to the correct station
Sharon Dvir (1):
iwlwifi: pcie: give a meaningful name to interrupt request
Shengzhen Li (3):
mwifiex: add power save parameters in hs_cfg cmd
mwifiex: check tx_hw_pending before downloading sleep confirm
mwifiex: complete blocked power save handshake in main process
Stanislaw Gruszka (9):
rt2800: correctly report MCS TX parameters
rt2800usb: do not wipe out USB_DMA_CFG settings
rt2800: OFDM rates are mandatory
rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
rt2800: correct AUTO_RSP_CFG
rt2800: correct TX_SW_CFG1 for 5592
rt2800: use RTS/CTS protection instead of CTS-to-self
rt2800: tune *_PROT_CFG parameters
rt2800: disable CCK rates on HT
Toke H=C3=B8iland-J=C3=B8rgensen (1):
ath9k: Switch to using mac80211 intermediate software queues.
Vasanthakumar Thiagarajan (1):
ath10k: fix kernel panic due to race in accessing arvif list
Vishal Thanki (1):
rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB
Vittorio Gambaletta (VittGam) (1):
ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.
Wei Yongjun (2):
mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virt=
ual_intf()
rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb
Wright Feng (1):
brcmfmac: update beacon IE after bss up and clear when AP stopped
Xinming Hu (4):
mwifiex: update tx_pkts_queued for requeued packets
mwifiex: fix command timeout problem seen in stress tests
mwifiex: parse device tree node for PCIe
mwifiex: reset card->adapter during device unregister
.../{marvell-sd8xxx.txt =3D> marvell-8xxx.txt} | 8 +-
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 48 +++
drivers/net/wireless/ath/ath.h | 6 +
drivers/net/wireless/ath/ath10k/core.c | 13 +
drivers/net/wireless/ath/ath10k/core.h | 20 +-
drivers/net/wireless/ath/ath10k/debug.h | 22 ++
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 79 +++--
drivers/net/wireless/ath/ath10k/hw.c | 142 ++++++++
drivers/net/wireless/ath/ath10k/hw.h | 28 +-
drivers/net/wireless/ath/ath10k/mac.c | 140 +++++++-
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 54 +++-
drivers/net/wireless/ath/ath6kl/sdio.c | 15 +-
drivers/net/wireless/ath/ath6kl/wmi.c | 8 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 27 +-
drivers/net/wireless/ath/ath9k/channel.c | 2 -
drivers/net/wireless/ath/ath9k/debug.c | 14 +-
drivers/net/wireless/ath/ath9k/debug.h | 2 -
drivers/net/wireless/ath/ath9k/debug_sta.c | 4 +-
drivers/net/wireless/ath/ath9k/htc_hst.c | 6 +-
drivers/net/wireless/ath/ath9k/init.c | 44 ++-
drivers/net/wireless/ath/ath9k/main.c | 9 +-
drivers/net/wireless/ath/ath9k/pci.c | 7 +-
drivers/net/wireless/ath/ath9k/rng.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 338 ++++++++--------=
----
drivers/net/wireless/ath/main.c | 7 +
drivers/net/wireless/ath/regd.c | 3 +-
drivers/net/wireless/ath/regd.h | 1 +
.../wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 12 +
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 8 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 8 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.h | 2 +
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 15 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.h | 1 +
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 6 +-
.../wireless/broadcom/brcm80211/brcmfmac/proto.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/proto.h | 9 +
drivers/net/wireless/intel/ipw2x00/libipw_rx.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 2 +
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rx.h | 26 ++
.../net/wireless/intel/iwlwifi/mvm/fw-api-sta.h | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 100 +++---
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 86 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3 +
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 37 ++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 1 +
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 29 +-
.../net/wireless/intersil/hostap/hostap_80211_rx.c | 2 +-
drivers/net/wireless/intersil/p54/fwio.c | 2 +-
drivers/net/wireless/marvell/mwifiex/README | 23 ++
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 12 +-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 5 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 10 +
drivers/net/wireless/marvell/mwifiex/init.c | 1 +
drivers/net/wireless/marvell/mwifiex/main.c | 113 +++++--
drivers/net/wireless/marvell/mwifiex/main.h | 40 ++-
drivers/net/wireless/marvell/mwifiex/pcie.c | 166 +++++-----
drivers/net/wireless/marvell/mwifiex/pcie.h | 2 +
drivers/net/wireless/marvell/mwifiex/scan.c | 4 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 153 +++------
drivers/net/wireless/marvell/mwifiex/sdio.h | 9 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 49 +--
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 60 ++--
drivers/net/wireless/marvell/mwifiex/usb.h | 2 +
drivers/net/wireless/marvell/mwifiex/wmm.c | 31 +-
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 67 ++--
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 19 +-
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 4 -
drivers/net/wireless/realtek/rtlwifi/pci.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/fw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/led.c | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/dm_common.c | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/dm_common.h | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192c/main.c | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 4 -
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/def.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/dm.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/led.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/led.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/reg.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/rf.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/rf.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/table.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/table.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/def.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/dm.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/led.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/led.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/reg.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/rf.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/table.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/table.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/def.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/dm.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/led.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/led.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/reg.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/rf.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/rf.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/table.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/table.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/def.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/dm.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/fw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/fw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/led.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/led.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/reg.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/rf.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/rf.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/table.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/table.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8723ae/dm.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.h | 4 -
.../realtek/rtlwifi/rtl8723ae/hal_bt_coexist.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8723ae/led.c | 4 -
drivers/net/wireless/realtek/rtlwifi/usb.c | 4 -
drivers/net/wireless/realtek/rtlwifi/usb.h | 4 -
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 19 +-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 5 +-
drivers/net/wireless/rsi/rsi_mgmt.h | 9 +-
drivers/net/wireless/st/cw1200/wsm.c | 24 +-
drivers/net/wireless/ti/wl18xx/event.c | 28 ++
drivers/net/wireless/ti/wl18xx/event.h | 1 +
drivers/net/wireless/ti/wl18xx/main.c | 3 +-
drivers/net/wireless/ti/wlcore/acx.c | 5 +-
drivers/net/wireless/ti/wlcore/acx.h | 3 +-
drivers/net/wireless/ti/wlcore/main.c | 8 +-
drivers/ssb/pci.c | 1 +
net/wireless/lib80211_crypt_tkip.c | 2 +-
189 files changed, 1607 insertions(+), 1152 deletions(-)
rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt =
=3D> marvell-8xxx.txt} (91%)
create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9=
k.txt
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Luca Coelho @ 2016-11-25 9:21 UTC (permalink / raw)
To: Jouni Malinen, Johannes Berg; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1479938857-1788-2-git-send-email-jouni@qca.qualcomm.com>
IMHO "report better BSSs" is vague in this context. It would better to
use something more concrete like "add relative RSSI attribute to sched
scan".
On Thu, 2016-11-24 at 00:07 +0200, Jouni Malinen wrote:
> From: vamsi krishna <vamsin@qti.qualcomm.com>
>
> Enhance sched scan to support option of finding a better BSS while in
> connected state. Firmware scans the medium and reports when it finds
a
> known BSS which has a significantly better RSSI than the current
"Significantly" is dependent on the value you use. :)
> connected BSS.
>
> Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
> Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
> ---
> include/net/cfg80211.h | 17 +++++++++++++++++
> include/uapi/linux/nl80211.h | 17 +++++++++++++++++
> net/wireless/nl80211.c | 32 ++++++++++++++++++++++++++++++--
> 3 files changed, 64 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index ef42749..c62c42a 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1626,6 +1626,20 @@ struct cfg80211_sched_scan_plan {
> * cycle. The driver may ignore this parameter and start
> * immediately (or at any other time), if this feature is not
> * supported.
> + * @relative_rssi: Relative RSSI threshold to restrict scan result
reporting in
> + * connected state to cases where a matching BSS is
determined to have a
> + * significantly better RSSI than the current connected BSS.
What happens with this attribute if we're not connected? Also, I think
you should specify the attribute type (int?) and the unit here.
> + * @relative_rssi_5g_pref: The amount of RSSI preference that is given to a
> + * 5 GHz BSS over 2.4 GHz BSS while looking for better BSSs in connected
> + * state.
> + * If the current connected BSS is in the 2.4 GHz band, other BSSs in the
> + * 2.4 GHz band to be reported should have better RSSI by @relative_rssi
> + * and other BSSs in the 5 GHz band to be reported should have better RSSI
> + * by (@relative_rssi - @relative_rssi_5g_pref).
> + * If the current connected BSS is in the 5 GHz band, other BSSs in the
> + * 2.4 GHz band to be reported should have better RSSI by
> + * (@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz
> + * band to be reported should have better RSSI by by @relative_rssi.
Could there be cases where you want the opposite? Meaning,
relative_rssi_5g_pref being negative?
> */
> struct cfg80211_sched_scan_request {
> struct cfg80211_ssid *ssids;
> @@ -1645,6 +1659,9 @@ struct cfg80211_sched_scan_request {
> u8 mac_addr[ETH_ALEN] __aligned(2);
> u8 mac_addr_mask[ETH_ALEN] __aligned(2);
>
> + int relative_rssi;
> + int relative_rssi_5g_pref;
I'm not sure it was your intention, but for flexibility, it's good that
both these attributes are ints so that you can find relative values on
both sides (greater than and smaller than).
It doesn't apply to the "better BSS" case, but maybe people find a
different use for it in the future?
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 984a35ac..34b16a4 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -1981,6 +1981,16 @@ enum nl80211_commands {
> * %NL80211_ATTR_MAC has also been used in various commands/events for
> * specifying the BSSID.
> *
> + * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI: Relative RSSI threshold by which
> + * other BSSs has to be better than the current connected BSS so that they
> + * get reported to user space. This will give an opportunity to userspace
> + * to consider connecting to other matching BSSs which have better RSSI
> + * than the current connected BSS.
The userspace can always do this, but the advantage here is that it
doesn't need to be woken up and check the results itself, since it
would only receive results that matter.
> + *
> + * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF: The amount of RSSI preference
> + * to be given to 5 GHz APs over 2.4 GHz APs while searching for better
> + * BSSs than the current connected BSS.
> + *
> * @NUM_NL80211_ATTR: total number of nl80211_attrs available
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> * @__NL80211_ATTR_AFTER_LAST: internal use
> @@ -2387,6 +2397,9 @@ enum nl80211_attrs {
>
> NL80211_ATTR_BSSID,
>
> + NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
> + NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
> +
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> @@ -4698,6 +4711,9 @@ enum nl80211_feature_flags {
> * configuration (AP/mesh) with VHT rates.
> * @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
> * with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
> + * @NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS: The driver supports sched_scan
Should be "RELATIVE_RSSI" instead of "BETTER_BSS".
[...]
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 8db5cb1..af018a5 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -405,6 +405,8 @@ enum nl80211_multicast_groups {
> [NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
> [NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
> [NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
> + [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI] = { .type = NLA_U32 },
> + [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF] = { .type = NLA_U32 },
This should probably be NLA_S32 (if we want to allow negative values as
well).
[...]
>
@@ -7156,6 +7166,14 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
> request->delay =
> nla_get_u32(attrs[NL80211_ATTR_SCHED_SCAN_DELAY]);
>
> + if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI])
> + request->relative_rssi = nla_get_s32(
> + attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]);
> +
> + if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF])
> + request->relative_rssi_5g_pref = nla_get_s32(
> + attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF]);
Good, I see you use s32 here. :)
[...]
> @@ -9649,7 +9667,8 @@ static int nl80211_send_wowlan_tcp(struct sk_buff *msg,
> return 0;
> }
>
> -static int nl80211_send_wowlan_nd(struct sk_buff *msg,
> +static int nl80211_send_wowlan_nd(struct wiphy *wiphy,
> + struct sk_buff *msg,
> struct cfg80211_sched_scan_request *req)
> {
> struct nlattr *nd, *freqs, *matches, *match, *scan_plans, *scan_plan;
> @@ -9670,6 +9689,15 @@ static int nl80211_send_wowlan_nd(struct sk_buff *msg,
> if (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_DELAY, req->delay))
> return -ENOBUFS;
>
> + if (wiphy_ext_feature_isset(
> + wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS) &&
> + (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
> + req->relative_rssi) ||
> + nla_put_u32(msg,
> + NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
> + req->relative_rssi_5g_pref)))
> + return -ENOBUFS;
> +
Why did you add this to nl80211_send_wowlan_nd() function?
[...]
--
Luca.
^ permalink raw reply
* Re: [PATCH 1/2] nl80211: Use different attrs for BSSID and random MAC addr in scan req
From: Luca Coelho @ 2016-11-25 8:44 UTC (permalink / raw)
To: Jouni Malinen, Johannes Berg; +Cc: linux-wireless, Vamsi Krishna
In-Reply-To: <1479938857-1788-1-git-send-email-jouni@qca.qualcomm.com>
On Thu, 2016-11-24 at 00:07 +0200, Jouni Malinen wrote:
> From: Vamsi Krishna <vamsin@qti.qualcomm.com>
>
> NL80211_ATTR_MAC was used to set both the specific BSSID to be scanned
> and the random MAC address to be used when privacy is enabled. When both
> the features are enabled, both the BSSID and the local MAC address were
> getting same value causing Probe Request frames to go with unintended
> DA. Hence, this has been fixed by using a different NL80211_ATTR_BSSID
> attribute to set the specific BSSID (which was the more recent addition
> in cfg80211) for a scan.
>
> Backwards compatibility with old userspace software is maintained to
> some extend by allowing NL80211_ATTR_MAC to be used to set the specific
typo, extent
> BSSID when scanning without enabling random MAC address use.
Hopefully nobody expects the broken functionality to be the correct
behavior, so we can slightly break backwards compatibility.
> Scanning with random source MAC address was introduced by commit
> ad2b26abc157 ("cfg80211: allow drivers to support random MAC addresses
> for scan") and the issue was introduced with the addition of the second
> user for the same attribute in commit 818965d39177 ("cfg80211: Allow a
> scan request for a specific BSSID").
>
> Fixes: 818965d39177 ("cfg80211: Allow a scan request for a specific BSSID")
> Signed-off-by: Vamsi Krishna <vamsin@qti.qualcomm.com>
> Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
> ---
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 259c9c7..984a35ac 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
[...]
> @@ -1977,6 +1977,10 @@ enum nl80211_commands {
> * @NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED: Indicates whether or not multicast
> * packets should be send out as unicast to all stations (flag attribute).
> *
> + * @NL80211_ATTR_BSSID: The BSSID of the AP (various uses). Note that
The BSSID may also be used for other things, like P2P GO, right? Also
"various uses" is probably unnecessary? Every command using this
attribute should describe it's use in their description.
> + * %NL80211_ATTR_MAC has also been used in various commands/events for
> + * specifying the BSSID.
This can be a bit confusing. Maybe you can specify which commands
*used* to use NL80211_ATTR_MAC but now use NL80211_ATTR_BSSID?
[...]
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index e4f718e..8db5cb1 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
[...]
> @@ -6703,7 +6704,20 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
> request->no_cck =
> nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
>
> - if (info->attrs[NL80211_ATTR_MAC])
> + /* Initial implementation used NL80211_ATTR_MAC to set the specific
> + * BSSID to scan for. This was problematic because that same attribute
> + * was already used for another purpose (local random MAC address). The
> + * NL80211_ATTR_BSSID attribute was added to fix this. For backwards
> + * compatibility with older userspace components, also use the
> + * NL80211_ATTR_MAC value here if it can be determined to be used for
> + * the specific BSSID use case instead of the random MAC address
> + * (NL80211_ATTR_SCAN_FLAGS is used to enable random MAC address use).
> + */
You should probably add this information to the
NL80211_CMD_TRIGGER_SCAN description.
> + if (info->attrs[NL80211_ATTR_BSSID])
> + memcpy(request->bssid,
> + nla_data(info->attrs[NL80211_ATTR_BSSID]), ETH_ALEN);
> + else if (!info->attrs[NL80211_ATTR_SCAN_FLAGS] &&
You should actually check that the SCAN_FLAGS attribute either doesn't
exist (as you already do) or, if it exists, that it doesn't have the
NL80211_SCAN_FLAG_RANDOM_ADDR flags.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] nl80211: provide minimum scheduled scan (plan) interval
From: Luca Coelho @ 2016-11-25 8:04 UTC (permalink / raw)
To: Arend van Spriel, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1479821515-13261-1-git-send-email-arend.vanspriel@broadcom.com>
Hi Arend,
On Tue, 2016-11-22 at 13:31 +0000, Arend van Spriel wrote:
> The interval for scheduled scan may have a minimum value for
> the device. Allow drivers to specify a minimum value in the
> struct wiphy so user-space interval values can be validated
> against it.
>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> ---
I'm not sure this is necessary, because the interval is a "soft"
requirement, there being no guarantee on the accuracy of the intervals.
The minimum interval a firmware can support is probably variable,
depending on how long time it takes for a scan to complete. Let's say
it takes 1 second to scan a certain amount of channels. In this case,
the minimum interval is probably 1 second (i.e. you can start a new
scan immediately after the first one completed). Now, if you're
scanning more channels and it takes, say, 4 seconds to complete, the
minimum interval would be 4 seconds.
The iwlwifi firmware treats the interval as the amount of time to wait
*after* one scan cycle completes before starting the cycle. Since
sched scan is mostly used while the system is suspended, the interval
can be quite large and the accuracy really doesn't matter. The
absoulte time when the scan cycles occur will drift over time, but does
it matter?
So, for firmwares that really need to get a minimum value, I think
bumping up to the minimum allowed if the provided value is too low,
should be done in the driver.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] nl80211: provide minimum scheduled scan (plan) interval
From: Johannes Berg @ 2016-11-25 8:25 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless
In-Reply-To: <5c249c34-5e8c-093a-c5df-3507cabc8872@broadcom.com>
Sorry, forgot to reply to this until Luca's email bumped it up...
On Tue, 2016-11-22 at 21:06 +0100, Arend Van Spriel wrote:
> Are we? Currently, the minimum is not checked in nl80211, but that
> does not say anything about the driver which might validate the
> interval as well and return an error.
Well, since drivers currently don't return an error (even if they
ignore the value!) that *does* change the API.
> What made me start looking at this is that in brcmfmac the interval
> in the request was ignored and a fixed interval was provisioned in
> the device. I wanted to fix that but was not sure if I needed to
> check it against our firmware min..max range and what the appropriate
> error handling should be. If silently changing what user-space is
> requesting is fine for this, I am happy to make it so. Preferably in
> nl80211.
I think (agreeing with Luca) bumping it up is fine.
johannes
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Aaro Koskinen @ 2016-11-24 18:46 UTC (permalink / raw)
To: Pali Rohár
Cc: Sebastian Reichel, Pavel Machek, Michal Kazior, Kalle Valo,
Ivaylo Dimitrov, Tony Lindgren, linux-wireless,
Network Development, linux-kernel
In-Reply-To: <20161124152045.GK13735@pali>
Hi,
On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> Proprietary, signed and closed bootloader NOLO does not support DT. So
> for booting you need to append DTS file to kernel image.
>
> U-Boot is optional and can be used as intermediate bootloader between
> NOLO and kernel. But still it has problems with reading from nand, so
> cannot read NVS data nor MAC address.
You could use kexec to pass the fixed DT.
A.
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-24 18:35 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161124181138.4i6ehkpohjxfgpbn@earth>
[-- Attachment #1: Type: Text/Plain, Size: 8119 bytes --]
On Thursday 24 November 2016 19:11:39 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > > > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > > > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > > > > "ifconfig hw ether XX" normally sets the address. I
> > > > > > > > > guess that's ioctl?
> > > > > > > >
> > > > > > > > This sets temporary address and it is ioctl. IIRC same
> > > > > > > > as what ethtool uses. (ifconfig is already
> > > > > > > > deprecated).
> > > > > > > >
> > > > > > > > > And I guess we should use similar mechanism for
> > > > > > > > > permanent address.
> > > > > > > >
> > > > > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing
> > > > > > > > temporary mac address. But here we do not want to
> > > > > > > > change permanent mac address. We want to tell kernel
> > > > > > > > driver current permanent mac address which is stored
> > > > > > >
> > > > > > > Well... I'd still use similar mechanism :-).
> > > > > >
> > > > > > Thats problematic, because in time when wlan0 interface is
> > > > > > registered into system and visible in ifconfig output it
> > > > > > already needs to have permanent mac address assigned.
> > > > > >
> > > > > > We should assign permanent mac address before wlan0 of
> > > > > > wl1251 is registered into system.
> > > > >
> > > > > You can just add the MAC address to the NVS data, which is
> > > > > also required for the device initialization.
> > > >
> > > > NVS data file has fixed size, there is IIRC no place for it.
> > > >
> > > > But one of my suggestion was to use another request_firmware
> > > > for MAC address. So this is similar to what you are proposing,
> > > > as NVS data are loaded by request_firmware too...
> > >
> > > Just append it to NVS data and modify the size check accordingly?
> >
> > First that would mean to have request_firmware() function which
> > will not use direct VFS access, but instead use userspace helper.
>
> Permanent MAC is device specific init data, NVS is device specific
> init data => load together.
>
> The userspace helper stuff is only needed to get the data from
> the NAND calibration area on the fly.
But it is needed... and currently request_firmware() prefer direct VFS
access...
> > NVS data file with some default values (not suitable for usage) is
> > already present in linux-firmware and available in
> > /lib/firmware/...
>
> You mentioned NVS data is fixed size, so this should be enough?
>
> switch(loaded_size)
> case IMAGE_SIZE + MAC_SIZE:
> /* extract mac */
> /* fallthrough */
> case IMAGE_SIZE:
> /* load NVS */
> break;
> default:
> /* fail */
> }
>
> > Also I'm not sure if such thing is allowed by license:
> > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmwar
> > e.git/tree/LICENCE.ti-connectivity
>
> concating data is not a modification, otherwise you can't
> put the file in a filesystem.
Ok, if net maintainers agree.
> > > > > I wonder if those information could be put into DT. Iirc some
> > > > > network devices get their MAC address from DT. Maybe we can
> > > > > add all NVS info to DT? How much data is it?
> > > >
> > > > Proprietary, signed and closed bootloader NOLO does not support
> > > > DT. So for booting you need to append DTS file to kernel
> > > > image.
> > >
> > > Yeah, so NOLO without U-Boot will depend on userspace to fixup
> > > DT.
> > >
> > > > U-Boot is optional and can be used as intermediate bootloader
> > > > between NOLO and kernel. But still it has problems with reading
> > > > from nand, so cannot read NVS data nor MAC address.
> > >
> > > It may in the future?
> >
> > I already tried that, but I failed. I was not able to access N900's
> > nand from u-boot. No idea where was problem...
> >
> > And if somebody fix onenand in u-boot, then needs to reimplement
> > Nokia's proprietary parser of that partition where is stored NVS
> > and mac address && make this support in upstream u-boot.
>
> Are we talking about this?
>
> https://github.com/community-ssu/libcal/blob/master/cal.c
>
> That's ~1k loc for read-only.
Yes. There is also read-only alternative library:
https://github.com/pali/0xFFFF/blob/master/src/cal.c
But still, this is proprietary format useful only for one device (or
two) and I do not know if such thing could be accepted by u-boot
developers...
> Getting NAND working looks harder than porting this to me.
Right.
> > So... I doubt it will be in any future.
> >
> > + no men power
>
> yeah :(
>
> But with that reasoning you should just extract the NVS data
> from NAND and put it in your rootfs.
Not a clean solution. Some rootfs parts can used as readonly. And
normally rootfs is flashed into nand, so I still will say that roofs
(image) should not contain any device specific data.
> > > > > Userspace application can add all those information to the DT
> > > > > using a DT overlay. Also the u-boot could parse and add it at
> > > > > some point in the future.
> > > >
> > > > In case when wl1251 is statically linked into kernel image, it
> > > > is loaded and initialized before even userspace applications
> > > > starts.
> > > >
> > > > So no... adding NVS data or MAC address into DT or DT overlay
> > > > is not a solution.
> > >
> > > Actually with data loaded from DT you *can* load data quite early
> > > in the boot process, while your suggestions always require
> > > userspace. So you argument against yourself?
> >
> > You cannot add DTS in uboot (no support).
>
> AFAIK that's supported:
>
> http://www.denx.de/wiki/DULG/LinuxFDTBlob
>
> "Note that U-Boot makes some automatic modifications to the blob
> before passing it to the kernel - mainly adding and modifying
> information that is learnt at run-time."
I mean we do not have support for due to n900 nand.
> > And if you modify DTS on running kernel from userspace, then it is
> > too late when wl1251 is statically linked into kernel image.
> >
> > wl1251 will not wait until some userspace modify DTS and add
> > data...
>
> if (nvs info missing)
> return -EPROBE_DEFER;
Forever? Only N times? How long? Only N second?
Here we do not know if userspace is going to send data or not.
My guess is that such code will not be accepted into net/wireless
subsystem or drivers by maintainers.
> > But request_firmware() in fallback mode *can* wait for userspace so
> > wl1251 can postpone its operation until mdev/udev/whatever starts
> > listening for events and push needed firmware data to kernel.
>
> As you said one workaround is waiting. That's not a solution, that
> only works with request_firmware().
Yes, but request_firmware() uses interaction with userspace. Your
proposed solution does not do any interaction with userspace that some
process needs to fill missing data into DT.
And request_firmware() is already used for loading NVS data.
> > So no, there is no argument against... request_firmware() in
> > fallback mode with userspace helper is by design blocking and
> > waiting for userspace. But waiting for some change in DTS in
> > kernel is just nonsense.
>
> I would just mark the wlan device with status = "disabled" and
> enable it in the overlay together with adding the NVS & MAC info.
So if you think that this solution make sense, we can wait what net
wireless maintainers say about it...
For me it looks like that solution can be:
extending request_firmware() to use only userspace helper
and load mac address also via request_firmware() either by appending it
into NVS data or via separate call
--
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: wl1251 & mac address & calibration data
From: Sebastian Reichel @ 2016-11-24 18:11 UTC (permalink / raw)
To: Pali Rohár
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <201611241749.33681@pali>
[-- Attachment #1: Type: text/plain, Size: 6231 bytes --]
Hi,
On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote:
> On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > > > "ifconfig hw ether XX" normally sets the address. I guess
> > > > > > > > that's ioctl?
> > > > > > >
> > > > > > > This sets temporary address and it is ioctl. IIRC same as
> > > > > > > what ethtool uses. (ifconfig is already deprecated).
> > > > > > >
> > > > > > > > And I guess we should use similar mechanism for permanent
> > > > > > > > address.
> > > > > > >
> > > > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing
> > > > > > > temporary mac address. But here we do not want to change
> > > > > > > permanent mac address. We want to tell kernel driver
> > > > > > > current permanent mac address which is stored
> > > > > >
> > > > > > Well... I'd still use similar mechanism :-).
> > > > >
> > > > > Thats problematic, because in time when wlan0 interface is
> > > > > registered into system and visible in ifconfig output it
> > > > > already needs to have permanent mac address assigned.
> > > > >
> > > > > We should assign permanent mac address before wlan0 of wl1251
> > > > > is registered into system.
> > > >
> > > > You can just add the MAC address to the NVS data, which is also
> > > > required for the device initialization.
> > >
> > > NVS data file has fixed size, there is IIRC no place for it.
> > >
> > > But one of my suggestion was to use another request_firmware for
> > > MAC address. So this is similar to what you are proposing, as NVS
> > > data are loaded by request_firmware too...
> >
> > Just append it to NVS data and modify the size check accordingly?
>
> First that would mean to have request_firmware() function which will not
> use direct VFS access, but instead use userspace helper.
Permanent MAC is device specific init data, NVS is device specific
init data => load together.
The userspace helper stuff is only needed to get the data from
the NAND calibration area on the fly.
> NVS data file with some default values (not suitable for usage) is
> already present in linux-firmware and available in /lib/firmware/...
You mentioned NVS data is fixed size, so this should be enough?
switch(loaded_size)
case IMAGE_SIZE + MAC_SIZE:
/* extract mac */
/* fallthrough */
case IMAGE_SIZE:
/* load NVS */
break;
default:
/* fail */
}
> Also I'm not sure if such thing is allowed by license:
> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.ti-connectivity
concating data is not a modification, otherwise you can't
put the file in a filesystem.
> > > > I wonder if those information could be put into DT. Iirc some
> > > > network devices get their MAC address from DT. Maybe we can add
> > > > all NVS info to DT? How much data is it?
> > >
> > > Proprietary, signed and closed bootloader NOLO does not support DT.
> > > So for booting you need to append DTS file to kernel image.
> >
> > Yeah, so NOLO without U-Boot will depend on userspace to fixup DT.
> >
> > > U-Boot is optional and can be used as intermediate bootloader
> > > between NOLO and kernel. But still it has problems with reading
> > > from nand, so cannot read NVS data nor MAC address.
> >
> > It may in the future?
>
> I already tried that, but I failed. I was not able to access N900's nand
> from u-boot. No idea where was problem...
>
> And if somebody fix onenand in u-boot, then needs to reimplement Nokia's
> proprietary parser of that partition where is stored NVS and mac address
> && make this support in upstream u-boot.
Are we talking about this?
https://github.com/community-ssu/libcal/blob/master/cal.c
That's ~1k loc for read-only. Getting NAND working looks harder than
porting this to me.
> So... I doubt it will be in any future.
>
> + no men power
yeah :(
But with that reasoning you should just extract the NVS data
from NAND and put it in your rootfs.
> > > > Userspace application can add all those information to the DT
> > > > using a DT overlay. Also the u-boot could parse and add it at
> > > > some point in the future.
> > >
> > > In case when wl1251 is statically linked into kernel image, it is
> > > loaded and initialized before even userspace applications starts.
> > >
> > > So no... adding NVS data or MAC address into DT or DT overlay is
> > > not a solution.
> >
> > Actually with data loaded from DT you *can* load data quite early in
> > the boot process, while your suggestions always require userspace.
> > So you argument against yourself?
>
> You cannot add DTS in uboot (no support).
AFAIK that's supported:
http://www.denx.de/wiki/DULG/LinuxFDTBlob
"Note that U-Boot makes some automatic modifications to the blob
before passing it to the kernel - mainly adding and modifying
information that is learnt at run-time."
> And if you modify DTS on running kernel from userspace, then it is
> too late when wl1251 is statically linked into kernel image.
>
> wl1251 will not wait until some userspace modify DTS and add data...
if (nvs info missing)
return -EPROBE_DEFER;
> But request_firmware() in fallback mode *can* wait for userspace so
> wl1251 can postpone its operation until mdev/udev/whatever starts
> listening for events and push needed firmware data to kernel.
As you said one workaround is waiting. That's not a solution, that
only works with request_firmware().
> So no, there is no argument against... request_firmware() in fallback
> mode with userspace helper is by design blocking and waiting for
> userspace. But waiting for some change in DTS in kernel is just
> nonsense.
I would just mark the wlan device with status = "disabled" and
enable it in the overlay together with adding the NVS & MAC info.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-24 16:49 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161124160830.kdpbonsz3l26uuo5@earth>
[-- Attachment #1: Type: Text/Plain, Size: 4604 bytes --]
On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > > "ifconfig hw ether XX" normally sets the address. I guess
> > > > > > > that's ioctl?
> > > > > >
> > > > > > This sets temporary address and it is ioctl. IIRC same as
> > > > > > what ethtool uses. (ifconfig is already deprecated).
> > > > > >
> > > > > > > And I guess we should use similar mechanism for permanent
> > > > > > > address.
> > > > > >
> > > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing
> > > > > > temporary mac address. But here we do not want to change
> > > > > > permanent mac address. We want to tell kernel driver
> > > > > > current permanent mac address which is stored
> > > > >
> > > > > Well... I'd still use similar mechanism :-).
> > > >
> > > > Thats problematic, because in time when wlan0 interface is
> > > > registered into system and visible in ifconfig output it
> > > > already needs to have permanent mac address assigned.
> > > >
> > > > We should assign permanent mac address before wlan0 of wl1251
> > > > is registered into system.
> > >
> > > You can just add the MAC address to the NVS data, which is also
> > > required for the device initialization.
> >
> > NVS data file has fixed size, there is IIRC no place for it.
> >
> > But one of my suggestion was to use another request_firmware for
> > MAC address. So this is similar to what you are proposing, as NVS
> > data are loaded by request_firmware too...
>
> Just append it to NVS data and modify the size check accordingly?
First that would mean to have request_firmware() function which will not
use direct VFS access, but instead use userspace helper.
NVS data file with some default values (not suitable for usage) is
already present in linux-firmware and available in /lib/firmware/...
Also I'm not sure if such thing is allowed by license:
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.ti-connectivity
> > > I wonder if those information could be put into DT. Iirc some
> > > network devices get their MAC address from DT. Maybe we can add
> > > all NVS info to DT? How much data is it?
> >
> > Proprietary, signed and closed bootloader NOLO does not support DT.
> > So for booting you need to append DTS file to kernel image.
>
> Yeah, so NOLO without U-Boot will depend on userspace to fixup DT.
>
> > U-Boot is optional and can be used as intermediate bootloader
> > between NOLO and kernel. But still it has problems with reading
> > from nand, so cannot read NVS data nor MAC address.
>
> It may in the future?
I already tried that, but I failed. I was not able to access N900's nand
from u-boot. No idea where was problem...
And if somebody fix onenand in u-boot, then needs to reimplement Nokia's
proprietary parser of that partition where is stored NVS and mac address
&& make this support in upstream u-boot.
So... I doubt it will be in any future.
+ no men power
> > > Userspace application can add all those information to the DT
> > > using a DT overlay. Also the u-boot could parse and add it at
> > > some point in the future.
> >
> > In case when wl1251 is statically linked into kernel image, it is
> > loaded and initialized before even userspace applications starts.
> >
> > So no... adding NVS data or MAC address into DT or DT overlay is
> > not a solution.
>
> Actually with data loaded from DT you *can* load data quite early in
> the boot process, while your suggestions always require userspace.
> So you argument against yourself?
You cannot add DTS in uboot (no support). And if you modify DTS on
running kernel from userspace, then it is too late when wl1251 is
statically linked into kernel image.
wl1251 will not wait until some userspace modify DTS and add data...
But request_firmware() in fallback mode *can* wait for userspace so
wl1251 can postpone its operation until mdev/udev/whatever starts
listening for events and push needed firmware data to kernel.
So no, there is no argument against... request_firmware() in fallback
mode with userspace helper is by design blocking and waiting for
userspace. But waiting for some change in DST in kernel is just
nonsense.
--
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: wl1251 & mac address & calibration data
From: Sebastian Reichel @ 2016-11-24 16:08 UTC (permalink / raw)
To: Pali Rohár
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161124152045.GK13735@pali>
[-- Attachment #1: Type: text/plain, Size: 2902 bytes --]
Hi,
On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > "ifconfig hw ether XX" normally sets the address. I guess that's
> > > > > > ioctl?
> > > > >
> > > > > This sets temporary address and it is ioctl. IIRC same as what ethtool
> > > > > uses. (ifconfig is already deprecated).
> > > > >
> > > > > > And I guess we should use similar mechanism for permanent
> > > > > > address.
> > > > >
> > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac
> > > > > address. But here we do not want to change permanent mac address. We
> > > > > want to tell kernel driver current permanent mac address which is
> > > > > stored
> > > >
> > > > Well... I'd still use similar mechanism :-).
> > >
> > > Thats problematic, because in time when wlan0 interface is registered
> > > into system and visible in ifconfig output it already needs to have
> > > permanent mac address assigned.
> > >
> > > We should assign permanent mac address before wlan0 of wl1251 is
> > > registered into system.
> >
> > You can just add the MAC address to the NVS data, which is also
> > required for the device initialization.
>
> NVS data file has fixed size, there is IIRC no place for it.
>
> But one of my suggestion was to use another request_firmware for MAC
> address. So this is similar to what you are proposing, as NVS data are
> loaded by request_firmware too...
Just append it to NVS data and modify the size check accordingly?
> > I wonder if those information could be put into DT. Iirc some
> > network devices get their MAC address from DT. Maybe we can add
> > all NVS info to DT? How much data is it?
>
> Proprietary, signed and closed bootloader NOLO does not support DT. So
> for booting you need to append DTS file to kernel image.
Yeah, so NOLO without U-Boot will depend on userspace to fixup DT.
> U-Boot is optional and can be used as intermediate bootloader between
> NOLO and kernel. But still it has problems with reading from nand, so
> cannot read NVS data nor MAC address.
It may in the future?
> > Userspace application can add all those information to the DT
> > using a DT overlay. Also the u-boot could parse and add it at
> > some point in the future.
>
> In case when wl1251 is statically linked into kernel image, it is loaded
> and initialized before even userspace applications starts.
>
> So no... adding NVS data or MAC address into DT or DT overlay is not a
> solution.
Actually with data loaded from DT you *can* load data quite early in
the boot process, while your suggestions always require userspace.
So you argument against yourself?
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Ivaylo Dimitrov @ 2016-11-24 15:31 UTC (permalink / raw)
To: Pali Rohár, Sebastian Reichel
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Aaro Koskinen,
Tony Lindgren, linux-wireless, Network Development, linux-kernel
In-Reply-To: <20161124152045.GK13735@pali>
Hi,
On 24.11.2016 17:20, Pali Rohár wrote:
>
> In case when wl1251 is statically linked into kernel image, it is loaded
> and initialized before even userspace applications starts.
>
Which leaves no option, but integrating libcal into kernel :).
Ivo
^ permalink raw reply
* Re: many "changed bandwidth, new config is" messages in the log
From: Michal Hocko @ 2016-11-24 15:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: LKML, linux-wireless
In-Reply-To: <1480000334.4388.2.camel@sipsolutions.net>
On Thu 24-11-16 16:12:14, Johannes Berg wrote:
> On Thu, 2016-11-24 at 15:07 +0000, Michal Hocko wrote:
>
> > I have only now managed to move to 4.9-rc5 (from 4.8) and started
> > seeing quite a lot of following messages
> > "
> > [ 346.612211] wlan0: AP c0:4a:00:f1:48:f2 changed bandwidth, new
> > config is 2472 MHz, width 1 (2472/0 MHz)
> > [ 352.655929] wlan0: AP c0:4a:00:f1:48:f2 changed bandwidth, new
> > config is 2472 MHz, width 2 (2462/0 MHz)
> > "
>
> I don't think these messages are new in any way. checking ... nope,
> it's been around that way since 3.9 :-)
Right you are. I must have missed them before and git grep + git blame
fooled me.
> > It always seems to be changing width from 1 -> 2 and back
>
> Makes sense, that's 20 MHz <-> 40 MHz.
>
> Did you buy a new device that says it's 40 MHz incompatible or
> something?
I am using this device for years now. It is a cheap TP-Link home
wireless router. So hard to tell about above. I am far from an expert.
> Or perhaps one of your neighbors did ... Or something is
> causing interference that makes the AP switch around.
This might be possible. There are quite some devices broadcasting around
$ sudo iwlist wlan0 scan | grep "Channel:" | sort | uniq -c
6 Channel:1
6 Channel:11
1 Channel:112
2 Channel:13
2 Channel:3
7 Channel:6
1 Channel:9
my router is at channel 13 so there seems to be something else sitting
there as well.
> > $ dmesg | grep "changed bandwidth" | wc -l
> > 42
> > in 13 minutes of uptime. I have noticed this came in via 30eb1dc2c430
> > ("mac80211: properly track HT/VHT operation changes").
>
> Right, but that went into 3.9 :-)
>
> > Is this something to be worried about?
>
> Not at all. I suppose we could make this a debug message though, it's
> not super useful when it happens OK (sometimes it causes disconnections
> when we can't support the new mode, which is more relevant).
OK, I see. Then I would suggest lowering the loglevel ;)
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-24 15:20 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Pavel Machek, Michal Kazior, Kalle Valo, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161124151317.34yoza3dzuh46oa4@earth>
On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > Hi!
> > >
> > > > > "ifconfig hw ether XX" normally sets the address. I guess that's
> > > > > ioctl?
> > > >
> > > > This sets temporary address and it is ioctl. IIRC same as what ethtool
> > > > uses. (ifconfig is already deprecated).
> > > >
> > > > > And I guess we should use similar mechanism for permanent
> > > > > address.
> > > >
> > > > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac
> > > > address. But here we do not want to change permanent mac address. We
> > > > want to tell kernel driver current permanent mac address which is
> > > > stored
> > >
> > > Well... I'd still use similar mechanism :-).
> >
> > Thats problematic, because in time when wlan0 interface is registered
> > into system and visible in ifconfig output it already needs to have
> > permanent mac address assigned.
> >
> > We should assign permanent mac address before wlan0 of wl1251 is
> > registered into system.
>
> You can just add the MAC address to the NVS data, which is also
> required for the device initialization.
NVS data file has fixed size, there is IIRC no place for it.
But one of my suggestion was to use another request_firmware for MAC
address. So this is similar to what you are proposing, as NVS data are
loaded by request_firmware too...
> I wonder if those information could be put into DT. Iirc some
> network devices get their MAC address from DT. Maybe we can add
> all NVS info to DT? How much data is it?
Proprietary, signed and closed bootloader NOLO does not support DT. So
for booting you need to append DTS file to kernel image.
U-Boot is optional and can be used as intermediate bootloader between
NOLO and kernel. But still it has problems with reading from nand, so
cannot read NVS data nor MAC address.
> Userspace application can add all those information to the DT
> using a DT overlay. Also the u-boot could parse and add it at
> some point in the future.
In case when wl1251 is statically linked into kernel image, it is loaded
and initialized before even userspace applications starts.
So no... adding NVS data or MAC address into DT or DT overlay is not a
solution.
--
Pali Rohár
pali.rohar@gmail.com
^ 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