* Re: rtl8723be on Fedora27
From: Rákosi Gergely @ 2017-11-18 7:50 UTC (permalink / raw)
To: rosenp, linux-wireless
In-Reply-To: <1510981609.5145.0.camel@gmail.com>
Hello,
I put in to blacklist the module rtlwifi and rtl8723be, and now I get:
- kde's networkmanager did not recognize wireless devices
- in the messages log there are the following :
"registered new interface driver rtl8xxxu
Bluetooth: hci0: rtl : Direct firmware load for
rtl_bt/rtl8723b_config.bin failed with error -2
- ifconfig give no wireless devices (wlp2s0 or wlan0)
If I blacklist only rtlwifi then load the rtl8723be module like normal.
Thanks,
Geri
2017-11-18 06:06 keltezéssel, rosenp@gmail.com írta:
> On Fri, 2017-11-17 at 09:16 +0100, Rákosi Gergely wrote:
>> Hello,
>>
>> I'm trying to use rtl8723be wifi on Fedora27 but I still get
>> continuosly
>> disconnection. The error in the dmesg is "Init MAC failed"
>> I tried with the following module options too : "fwlps=0 swlps=0" and
>> the variant of "ant_sel=1 or 2 or 0"
>> I downloaded the git files from your repo, and do the usual make,make
>> install, and modprobe stuffs, and then restart the notebook, but I
>> get
>> the same result.
>>
> Could try blacklisting rtlwifi. That way it uses rtl8xxxu.
>> Thanks your help,
>> Regards,
>> Gergely
^ permalink raw reply
* Re: ath6kl : intermittent Wi-Fi on Fedora 27 (Linux 4.13.12-300)
From: Steve deRosier @ 2017-11-18 5:37 UTC (permalink / raw)
To: Ken Harris; +Cc: linux-wireless
In-Reply-To: <CAK_-F2LuLNCUA9U4AS3A2puLLVWd8Ld66YPAd0NspQUMuUEzGA@mail.gmail.com>
Hi Ken,
On Fri, Nov 17, 2017 at 11:58 AM, Ken Harris <kjh@hokulea.org> wrote:
> Yesterday, I installed Fedora 27 on a Dell Venue 8 Pro (5830).
>
> I installed the ath6kl firmware from https://github.com/qca/ath6kl-firmware/
>
> The Wi-Fi works for a while, but then stops. It seems to start up
> again about 30 minutes later.
>
> Is this a known problem ? Is there any to fix it ?
Hard to know. You've not really given us enough information that would
be helpful to help you. Kernel version? dmesg dump? Backports? Which
chip? SDIO or USB? Network manager or other? All of this information
is necessary to help.
Usually your distro would come with the right firmware, and if it
doesn't, usually the proper place to get it from is
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
Though, if you're needing ar6004/hw3.0 it's missing for some reason
(@Kalle, why isn't that fw in linux-firmware?)
What I can tell you is I have ath6kl on many kernel versions on both
6003 and 6004 connected solid for months at a time with 0 noticeable
drops.
This might help:
https://wireless.wiki.kernel.org/en/users/documentation/reporting_bugs
>
> FYI, I added :
>
> echo options ath6kl_core debug_mask=0x140400 > /etc/modprobe.d/55-ath6k.conf
>
> ... so I'm getting more debug info. Are the other debug bits I should try ?
>
Not bad, but I'd also suggest adding the recovery bit. 0x940400 would
be a good place to start.
Get us a kernel messages dump and maybe we can help more.
- Steve
^ permalink raw reply
* Re: rtl8723be on Fedora27
From: rosenp @ 2017-11-18 5:06 UTC (permalink / raw)
To: Rákosi Gergely, linux-wireless
In-Reply-To: <f5876284-360c-e6bf-01c8-ed95c4298647@gmail.com>
On Fri, 2017-11-17 at 09:16 +0100, Rákosi Gergely wrote:
> Hello,
>
> I'm trying to use rtl8723be wifi on Fedora27 but I still get
> continuosly
> disconnection. The error in the dmesg is "Init MAC failed"
> I tried with the following module options too : "fwlps=0 swlps=0" and
> the variant of "ant_sel=1 or 2 or 0"
> I downloaded the git files from your repo, and do the usual make,make
> install, and modprobe stuffs, and then restart the notebook, but I
> get
> the same result.
>
Could try blacklisting rtlwifi. That way it uses rtl8xxxu.
> Thanks your help,
> Regards,
> Gergely
^ permalink raw reply
* Re: rtl8723be on Fedora27
From: Rákosi Gergely @ 2017-11-18 0:22 UTC (permalink / raw)
To: Larry Finger, linux-wireless
In-Reply-To: <3a1fc541-9104-2d13-409f-c8e64845a86d@lwfinger.net>
Hello Larry,
First of all, thanks your help.
Lets see...here is the kernel version: 4.13.12-300
The machine is an Asus ROG 553VE
The firmware which loading in the dmesg is : rtlwifi/rtl8723befw_36.bin
The output of md5sum is : 1850c1308fbcd95e9f6a7f58ede1e35f
Thanks again,
Best Regards,
Gergely
2017-11-17 16:51 keltezéssel, Larry Finger írta:
> On 11/17/2017 02:16 AM, Rákosi Gergely wrote:
>> Hello,
>>
>> I'm trying to use rtl8723be wifi on Fedora27 but I still get continuosly
>> disconnection. The error in the dmesg is "Init MAC failed"
>> I tried with the following module options too : "fwlps=0 swlps=0" and
>> the variant of "ant_sel=1 or 2 or 0"
>> I downloaded the git files from your repo, and do the usual make,make
>> install, and modprobe stuffs, and then restart the notebook, but I get
>> the same result.
>
> I know from the E-mail you sent to me privately that you are new to
> this process, thus I am going to give you some pointers. It is
> important for you to give your kernel version. Yes, for devoted Fedora
> users, saying that you are using F27 might be sufficient; however, I
> am not one of them. You should always supply the output of the command
> 'uname -r'.
>
> On the RTL8723BE, "Init MAC failed" is not the dmesg that is expected
> from either the HP ant_sel problem, or a power-save problem.
> Incidentally, although there are many "fixes" that require modifying
> the XXps options, the underlying cause of that issue was fixed almost
> one year ago.
>
> The main software component that might be wrong is the firmware.
> Please find the name of the firmware file that is being loaded from
> the dmesg output. It will be rtlwifi/... Once you locate that name,
> run the command
>
> md5sum /lib/firmware/rtlwifi/xxx
>
> Substitute the actual name for the xxx. Post the output of the md5sum.
>
> Larry
^ permalink raw reply
* Re: bug in commit: mac80211: Fix possible sband related NULL pointer de-reference
From: Ben Greear @ 2017-11-17 23:09 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan, linux-wireless@vger.kernel.org
In-Reply-To: <238cb9e7-c78f-66e4-01ed-5fead4f35820@candelatech.com>
On 11/17/2017 02:30 PM, Ben Greear wrote:
> Author: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> Date: Thu Apr 27 12:45:38 2017 +0530
>
> mac80211: Fix possible sband related NULL pointer de-reference
>
> Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even
> if the channel context configuration is NULL. This crashes for chipsets
> which support 5 Ghz alone when it tries to access members of 'sband'.
> Channel context configuration can be NULL in multivif case and when
> channel switch is in progress (or) when it fails. Fix this by replacing
> the API 'ieee80211_get_sdata_band' with 'ieee80211_get_sband' which
> returns a NULL pointer for sband when the channel configuration is NULL.
>
> ...
>
> This commit appears to break sta_set_rate_info_tx on drivers that are not using chantx,
> because it calls ieee80211_get_sband, which does a WARN_ON when there is no chantx.
>
> Any idea how to make this work for chandef drivers?
Maybe there are other issues in my case. I'll test out a patch to make it WARN_ON_ONCE
and submit once I get some other problems ironed out.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* bug in commit: mac80211: Fix possible sband related NULL pointer de-reference
From: Ben Greear @ 2017-11-17 22:30 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan, linux-wireless@vger.kernel.org
Author: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Date: Thu Apr 27 12:45:38 2017 +0530
mac80211: Fix possible sband related NULL pointer de-reference
Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even
if the channel context configuration is NULL. This crashes for chipsets
which support 5 Ghz alone when it tries to access members of 'sband'.
Channel context configuration can be NULL in multivif case and when
channel switch is in progress (or) when it fails. Fix this by replacing
the API 'ieee80211_get_sdata_band' with 'ieee80211_get_sband' which
returns a NULL pointer for sband when the channel configuration is NULL.
...
This commit appears to break sta_set_rate_info_tx on drivers that are not using chantx,
because it calls ieee80211_get_sband, which does a WARN_ON when there is no chantx.
Any idea how to make this work for chandef drivers?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* ath6kl : intermittent Wi-Fi on Fedora 27 (Linux 4.13.12-300)
From: Ken Harris @ 2017-11-17 19:58 UTC (permalink / raw)
To: linux-wireless
Yesterday, I installed Fedora 27 on a Dell Venue 8 Pro (5830).
I installed the ath6kl firmware from https://github.com/qca/ath6kl-firmware/
The Wi-Fi works for a while, but then stops. It seems to start up
again about 30 minutes later.
Is this a known problem ? Is there any to fix it ?
FYI, I added :
echo options ath6kl_core debug_mask=0x140400 > /etc/modprobe.d/55-ath6k.conf
... so I'm getting more debug info. Are the other debug bits I should try ?
Thanks
^ permalink raw reply
* Re: What would it take to get WDS working with channel contexts?
From: Ben Greear @ 2017-11-17 16:46 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <1510911915.2030.37.camel@sipsolutions.net>
On 11/17/2017 01:45 AM, Johannes Berg wrote:
> On Thu, 2017-11-16 at 16:28 -0800, Ben Greear wrote:
>> I have a user interested in getting WDS working on ath10k, but evidently
>> this is not supported since ath10k uses channel-contexts:
>>
>> From net/mac80211/main.c:
>>
>> /*
>> * WDS is currently prohibited when channel contexts are used
>> * because there's no clear definition of which channel WDS
>> * type interfaces use
>> */
>>
>>
>> Anyone have any suggestions as to how this could be made to work?
>
> You probably don't want to hear this, but:
>
> WDS isn't even properly working without them right now, since for
> example there's absolutely no feature negotiation between the peers as
> to which rates and other capabilities, bandwidths, etc. are acceptable
> (at any given moment in time).
>
> I therefore don't see any value in WDS mode at all unless these issues
> are fixed [*], and as such wouldn't want to take any patches that just
> do some minimal patching over to allow it with channel contexts.
>
> If you ask me, WDS is entirely useless without vendor-specific
> extensions to allow newer features, and the Linux "vendor-specific"
> extension to do that is AP/client 4-addr mode.
>
> johannes
>
> [*] and since the spec doesn't define this, you can't even fix them in
> any reasonable way, I think, unless you implement some vendor-specific
> things that maybe one vendor happens to do.
It looks like my options are to hack the mac80211 stack to be minimally
functional with WDS and channel-contexts, or to hack ath10k driver to
disable chan-tx in order to try to fix the ath10k firmware WDS issues.
I'd guess the former is of slightly more use to society. Do you have
any quick hacks to allow mac80211 to work with chantx and WDS, even
if you wouldn't want them upstream?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: rtl8723be on Fedora27
From: Larry Finger @ 2017-11-17 15:51 UTC (permalink / raw)
To: Rákosi Gergely, linux-wireless
In-Reply-To: <f5876284-360c-e6bf-01c8-ed95c4298647@gmail.com>
On 11/17/2017 02:16 AM, Rákosi Gergely wrote:
> Hello,
>
> I'm trying to use rtl8723be wifi on Fedora27 but I still get continuosly
> disconnection. The error in the dmesg is "Init MAC failed"
> I tried with the following module options too : "fwlps=0 swlps=0" and
> the variant of "ant_sel=1 or 2 or 0"
> I downloaded the git files from your repo, and do the usual make,make
> install, and modprobe stuffs, and then restart the notebook, but I get
> the same result.
I know from the E-mail you sent to me privately that you are new to this
process, thus I am going to give you some pointers. It is important for you to
give your kernel version. Yes, for devoted Fedora users, saying that you are
using F27 might be sufficient; however, I am not one of them. You should always
supply the output of the command 'uname -r'.
On the RTL8723BE, "Init MAC failed" is not the dmesg that is expected from
either the HP ant_sel problem, or a power-save problem. Incidentally, although
there are many "fixes" that require modifying the XXps options, the underlying
cause of that issue was fixed almost one year ago.
The main software component that might be wrong is the firmware. Please find the
name of the firmware file that is being loaded from the dmesg output. It will be
rtlwifi/... Once you locate that name, run the command
md5sum /lib/firmware/rtlwifi/xxx
Substitute the actual name for the xxx. Post the output of the md5sum.
Larry
^ permalink raw reply
* Re: AP6335 with mainline kernel
From: Vanessa Maegima @ 2017-11-17 15:24 UTC (permalink / raw)
To: arend.vanspriel@broadcom.com, van.ayumi@gmail.com
Cc: linux-wireless@vger.kernel.org, embed3d@gmail.com
In-Reply-To: <5A0EDC25.7030505@broadcom.com>
SGkgQXJlbmQsDQoNCk9uIFNleCwgMjAxNy0xMS0xNyBhdCAxMzo1NSArMDEwMCwgQXJlbmQgdmFu
IFNwcmllbCB3cm90ZToNCj4gT24gMTEvMTcvMjAxNyAxMjowOCBQTSwgVmFuZXNzYSBNYWVnaW1h
IHdyb3RlOg0KPiA+IA0KPiA+IEhpIEFyZW5kLA0KPiA+IA0KPiA+IE9uIFNleCwgMjAxNy0xMS0x
MCBhdCAyMDo1OCArMDEwMCwgQXJlbmQgdmFuIFNwcmllbCB3cm90ZToNCj4gPiA+IA0KPiA+ID4g
T24gMTAtMTEtMTcgMTM6NDMsIFZhbmVzc2EgTWFlZ2ltYSB3cm90ZToNCj4gPiA+ID4gDQo+ID4g
PiA+IA0KPiA+ID4gPiBIaSwNCj4gPiA+ID4gDQo+ID4gPiA+IE9uIFF1aSwgMjAxNy0wOS0yMSBh
dCAxMjozMCAtMDMwMCwgVmFuZXNzYSBBeXVtaSBNYWVnaW1hIHdyb3RlOg0KPiA+ID4gPiA+IA0K
PiA+ID4gPiA+IA0KPiA+ID4gPiA+IEhpIEFyZW5kLA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IE9u
IFRodSwgU2VwIDIxLCAyMDE3IGF0IDQ6MjYgQU0sIEFyZW5kIHZhbiBTcHJpZWwNCj4gPiA+ID4g
PiA8YXJlbmQudmFuc3ByaWVsQGJyb2FkY29tLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4gPiANCj4g
PiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBPbiAyMC0wOS0xNyAyMTozMywg
VmFuZXNzYSBBeXVtaSBNYWVnaW1hIHdyb3RlOg0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+
ID4gDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gSGksDQo+
ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBJIGFtIHRyeWluZyB0byBlbmFibGUgV2lmaSBv
biBpbXg3ZC1waWNvIHVzaW5nIG1haW5saW5lDQo+ID4gPiA+ID4gPiA+IGtlcm5lbC4NCj4gPiA+
ID4gPiA+ID4gaW14N2QtcGljbw0KPiA+ID4gPiA+ID4gPiBoYXMgYW4gQVA2MzM1IGNoaXAuDQo+
ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBJIGFtIGZhY2luZyBzb21lIGlzc3VlcyByZWxh
dGVkIHRvIHRoZSBudnJhbSBmaWxlLiBJIGFtDQo+ID4gPiA+ID4gPiA+IHVzaW5nDQo+ID4gPiA+
ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gPiBmaXJtd2FyZQ0KPiA+ID4gPiA+ID4gPiBwcm92aWRl
ZCBieSBCdWlsZHJvb3QgKGJyY21mbWFjNDMzOS1zZGlvLmJpbikuIEkgZ2V0IHRoZQ0KPiA+ID4g
PiA+ID4gPiBmb2xsb3dpbmcgZXJyb3I6DQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBb
wqDCoMKgwqA4LjYzMDM4MF0gYnJjbWZtYWM6IGJyY21mX3NkaW9faHRjbGs6IEhUIEF2YWlsDQo+
ID4gPiA+ID4gPiA+IHRpbWVvdXQNCj4gPiA+ID4gPiA+ID4gKDEwMDAwMDApOg0KPiA+ID4gPiA+
ID4gPiBjbGtjdGwgMHg1MA0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gSSBoYXZlIHRy
aWVkIHRvIHVzZSB0aGUgZmlybXdhcmUgYW5kIG52cmFtIHByb3ZpZGVkIGJ5DQo+ID4gPiA+ID4g
PiA+IFRlY2hOZXhpb24NCj4gPiA+ID4gPiA+ID4gYnV0IEkNCj4gPiA+ID4gPiA+ID4gZ2V0DQo+
ID4gPiA+ID4gPiA+IHRoZSBzYW1lIGVycm9yLg0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+
ID4gSXMgdGhlcmUgYW55b25lIHRoYXQgY291bGQgZW5hYmxlIFdpZmkgb24gQVA2MzM1IHVzaW5n
DQo+ID4gPiA+ID4gPiA+IGtlcm5lbA0KPiA+ID4gPiA+ID4gPiBtYWlubGluZT8NCj4gPiA+ID4g
PiA+ID4gV2hhdCBudnJhbSBmaWxlIHdhcyB1c2VkPw0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4g
PiA+ID4gSSBhbSBhYmxlIHRvIHVzZSBXaWZpIG9uIHRoZSBib2FyZCBpZiBJIHVzZSB0aGUgZmly
bXdhcmUsDQo+ID4gPiA+ID4gPiA+IG52cmFtDQo+ID4gPiA+ID4gPiA+IGZpbGUgYW5kDQo+ID4g
PiA+ID4gPiA+IGtlcm5lbA0KPiA+ID4gPiA+ID4gPiBwcm92aWRlZCBieSBUZWNoTmV4aW9uLiBU
aGV5IHVzZSBhIDQuMSBrZXJuZWwgZnJvbSBOWFANCj4gPiA+ID4gPiA+ID4gd2l0aA0KPiA+ID4g
PiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4gYmNtZGhkDQo+ID4gPiA+ID4gPiA+IGRyaXZlci4N
Cj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IFNvIEkga25vdyB0aGF0IHRoZSBoYXJkd2Fy
ZSBpcyBmdW5jdGlvbmFsLg0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gQW55IHN1Z2dl
c3Rpb25zIGFzIGhvdyB0byBnZXQgaXQgd29ya2luZyB3aXRoIGEgNC4xMyBhbmQNCj4gPiA+ID4g
PiA+ID4gYnJjbWZtYWMNCj4gPiA+ID4gPiA+ID4gZHJpdmVyDQo+ID4gPiA+ID4gPiA+IGlzDQo+
ID4gPiA+ID4gPiA+IGFwcHJlY2lhdGVkLg0KPiA+ID4gPiA+ID4gU28gdGhlIG52cmFtIGZpbGUg
aXMgc3BlY2lmaWMgdG8gdGhlIHdpZmkgY2hpcHNldCBvbiB5b3VyDQo+ID4gPiA+ID4gPiBwbGF0
Zm9ybQ0KPiA+ID4gPiA+ID4gc28gYmVzdA0KPiA+ID4gPiA+ID4gdG8gc3RpY2sgd2l0aCB0aGUg
cHJvdmlkZWQgb25lLiBUaGUgIkhUIEF2YWlsIHRpbWVvdXQiIG1vc3QNCj4gPiA+ID4gPiA+IG9m
dGVuDQo+ID4gPiA+ID4gPiBpcyBhbg0KPiA+ID4gPiA+ID4gaW5kaWNhdGlvbiB0aGF0IHRoZSBm
aXJtd2FyZSBjcmFzaGVkLiBTbyBnZXR0aW5nIG1vcmUgZGVidWcNCj4gPiA+ID4gPiA+IG91dHB1
dA0KPiA+ID4gPiA+ID4gd291bGQNCj4gPiA+ID4gPiA+IGhlbHAgdXMgdW5kZXJzdGFuZCBob3cg
aXQgZW5kZWQgdXAgbGlrZSB0aGF0LiBDYW4geW91IGJ1aWxkDQo+ID4gPiA+ID4gPiB0aGUNCj4g
PiA+ID4gPiA+IGJyY21mbWFjDQo+ID4gPiA+ID4gPiB3aXRoIENPTkZJR19CUkNNREJHIGFuZCBs
b2FkIHRoZSBkcml2ZXIgdXNpbmc6DQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ICQgaW5zbW9k
IGJyY21mbWFjLmtvIGRlYnVnPTB4MTQxNg0KPiA+ID4gPiA+IFRoYW5rcyBmb3IgdGhlIHJlcGx5
IQ0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEhlcmUgaXMgdGhlIGxvZyAodXNpbmcgNC4xNC1yYzEp
Og0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ICMgZG1lc2cgfCBncmVwIGJyY21mbWFjDQo+ID4gPiA+
ID4gW8KgwqDCoDE5LjI5NzIwNl0gYnJjbWZtYWM6IGJyY21mbWFjX21vZHVsZV9pbml0IE5vIHBs
YXRmb3JtDQo+ID4gPiA+ID4gZGF0YQ0KPiA+ID4gPiA+IGF2YWlsYWJsZS4NCj4gPiA+ID4gPiBb
wqDCoMKgMTkuMzA3MDc1XSBicmNtZm1hYzogYnJjbWZfc2Rpb19wcm9iZSBFbnRlcg0KPiA+ID4g
PiA+IFvCoMKgwqAxOS4zMDgzODRdIGJyY21mbWFjOiBGMSBzaWduYXR1cmUgcmVhZA0KPiA+ID4g
PiA+IEAweDE4MDAwMDAwPTB4MTYyMjQzMzUNCj4gPiA+ID4gPiBbwqDCoMKgMTkuMzA5MDI2XSBi
cmNtZm1hYzogYnJjbWZfY2hpcF9yZWNvZ25pdGlvbiBmb3VuZCBBWEkNCj4gPiA+ID4gPiBjaGlw
Og0KPiA+ID4gPiA+IEJDTTQzMzksIHJldj0yDQo+ID4gPiA+ID4gW8KgwqDCoDE5LjMxNzExNV0g
YnJjbWZtYWM6IGJyY21mX2NoaXBfY29yZXNfY2hlY2vCoMKgWzEgXSBjb3JlDQo+ID4gPiA+ID4g
MHg4MDA6NDYNCj4gPiA+ID4gPiBiYXNlIDB4MTgwMDAwMDAgd3JhcCAweDE4MTAwMDAwDQo+ID4g
PiA+ID4gW8KgwqDCoDE5LjMxNzE0MV0gYnJjbWZtYWM6IGJyY21mX2NoaXBfY29yZXNfY2hlY2vC
oMKgWzIgXSBjb3JlDQo+ID4gPiA+ID4gMHg4MTI6NDYNCj4gPiA+ID4gPiBiYXNlIDB4MTgwMDEw
MDAgd3JhcCAweDE4MTAxMDAwDQo+ID4gPiA+ID4gW8KgwqDCoDE5LjMxNzE2NV0gYnJjbWZtYWM6
IGJyY21mX2NoaXBfY29yZXNfY2hlY2vCoMKgWzMgXSBjb3JlDQo+ID4gPiA+ID4gMHg4M2U6NA0K
PiA+ID4gPiA+IGJhc2UgMHgxODAwMjAwMCB3cmFwIDB4MTgxMDIwMDANCj4gPiA+ID4gPiBbwqDC
oMKgMTkuMzE3MTg4XSBicmNtZm1hYzogYnJjbWZfY2hpcF9jb3Jlc19jaGVja8KgwqBbNCBdIGNv
cmUNCj4gPiA+ID4gPiAweDgzYzo0DQo+ID4gPiA+ID4gYmFzZSAweDE4MDAzMDAwIHdyYXAgMHgx
ODEwMzAwMA0KPiA+ID4gPiA+IFvCoMKgwqAxOS4zMTcyMTBdIGJyY21mbWFjOiBicmNtZl9jaGlw
X2NvcmVzX2NoZWNrwqDCoFs1IF0gY29yZQ0KPiA+ID4gPiA+IDB4ODFhOjIwDQo+ID4gPiA+ID4g
YmFzZSAweDE4MDA0MDAwIHdyYXAgMHgxODEwNDAwMA0KPiA+ID4gPiA+IFvCoMKgwqAxOS4zMTcy
MzNdIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2NoZWNrwqDCoFs2IF0gY29yZQ0KPiA+ID4g
PiA+IDB4ODI5OjIxDQo+ID4gPiA+ID4gYmFzZSAweDE4MDA1MDAwIHdyYXAgMHgxODEwNTAwMA0K
PiA+ID4gPiA+IFvCoMKgwqAxOS4zMTcyNTZdIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2No
ZWNrwqDCoFs3IF0gY29yZQ0KPiA+ID4gPiA+IDB4MTM1OjANCj4gPiA+ID4gPiBiYXNlIDB4MDAw
MDAwMDAgd3JhcCAweDE4MTA5MDAwDQo+ID4gPiA+ID4gW8KgwqDCoDE5LjMxNzI3OV0gYnJjbWZt
YWM6IGJyY21mX2NoaXBfY29yZXNfY2hlY2vCoMKgWzggXSBjb3JlDQo+ID4gPiA+ID4gMHgyNDA6
MA0KPiA+ID4gPiA+IGJhc2UgMHgwMDAwMDAwMCB3cmFwIDB4MDAwMDAwMDANCj4gPiA+ID4gPiBb
wqDCoMKgMTkuMzE3Mjk4XSBicmNtZm1hYzogYnJjbWZfY2hpcF9zZXRfcGFzc2l2ZSBFbnRlcg0K
PiA+ID4gPiA+IFvCoMKgwqAxOS4zMjIyMzJdIGJyY21mbWFjOiBicmNtZl9jaGlwX2dldF9yYW1p
bmZvIFJBTToNCj4gPiA+ID4gPiBiYXNlPTB4MTgwMDAwDQo+ID4gPiA+ID4gc2l6ZT03ODY0MzIg
KDB4YzAwMDApIHNyPTAgKDB4MCkNCj4gPiA+ID4gPiBbwqDCoMKgMTkuMzIyNDU3XSBicmNtZm1h
YzogYnJjbWZfY2hpcF9zZXR1cCBjY3Jldj00NiwNCj4gPiA+ID4gPiBwbXVyZXY9MjMsDQo+ID4g
PiA+ID4gcG11Y2Fwcz0weDM5Y2M1ZjE3DQo+ID4gPiA+ID4gW8KgwqDCoDE5LjMyMjQ4MV0gYnJj
bWZtYWM6IGJyY21mX2dldF9tb2R1bGVfcGFyYW0gRW50ZXIsIGJ1cz0wLA0KPiA+ID4gPiA+IGNo
aXA9MTcyMDksIHJldj0yDQo+ID4gPiA+ID4gW8KgwqDCoDE5LjMyMjUwNF0gYnJjbWZtYWM6IGJy
Y21mX3NkaW9kX3NndGFibGVfYWxsb2MgbmVudHM9MzUNCj4gPiA+ID4gPiBbwqDCoMKgMTkuMzIy
NTMxXSBicmNtZm1hYzogYnJjbWZfc2Rpb19rc29faW5pdCBFbnRlcg0KPiA+ID4gPiA+IFvCoMKg
wqAxOS4zMjI2MThdIGJyY21mbWFjOiBicmNtZl9zZGlvX2RyaXZlc3RyZW5ndGhpbml0IE5vIFNE
SU8NCj4gPiA+ID4gPiBkcml2ZXINCj4gPiA+ID4gPiBzdHJlbmd0aCBpbml0IG5lZWRlZCBmb3Ig
Y2hpcCA0Mw0KPiA+ID4gPiA+IDM5IHJldiAyIHBtdXJldiAyMw0KPiA+ID4gPiA+IFvCoMKgwqAx
OS4zMjMyMzVdIGJyY21mbWFjOiBicmNtZl9hdHRhY2ggRW50ZXINCj4gPiA+ID4gPiBbwqDCoMKg
MTkuMzIzNzI1XSBicmNtZm1hYzogYnJjbWZfcHJvdG9fYXR0YWNoIEVudGVyDQo+ID4gPiA+ID4g
W8KgwqDCoDE5LjMyMzc2OV0gYnJjbWZtYWM6IGJyY21mX2Z3ZWhfcmVnaXN0ZXIgZXZlbnQgaGFu
ZGxlcg0KPiA+ID4gPiA+IHJlZ2lzdGVyZWQNCj4gPiA+ID4gPiBmb3IgUFNNX1dBVENIRE9HDQo+
ID4gPiA+ID4gW8KgwqDCoDE5LjMyNDMwNl0gYnJjbWZtYWM6IGJyY21mX3NkaW9fcHJvYmUgY29t
cGxldGVkISENCj4gPiA+ID4gPiBbwqDCoMKgMTkuMzI0MzM3XSBicmNtZm1hYzogYnJjbWZfZndf
bWFwX2NoaXBfdG9fbmFtZTogdXNpbmcNCj4gPiA+ID4gPiBicmNtL2JyY21mbWFjNDMzOS1zZGlv
LmJpbiBmb3IgY2hpcCAweDAwNDMzDQo+ID4gPiA+ID4gOSgxNzIwOSkgcmV2IDB4MDAwMDAyDQo+
ID4gPiA+ID4gW8KgwqDCoDE5LjMzNTM1M10gYnJjbWZtYWM6IGJyY21mX2Z3X2dldF9maXJtd2Fy
ZXNfcGNpZSBlbnRlcjoNCj4gPiA+ID4gPiBkZXY9bW1jMDowMDAxOjENCj4gPiA+ID4gPiBbwqDC
oMKgMTkuMzUxNzg3XSBicmNtZm1hYzogYnJjbWZfZndfcmVxdWVzdF9jb2RlX2RvbmUgZW50ZXI6
DQo+ID4gPiA+ID4gZGV2PW1tYzA6MDAwMToxDQo+ID4gPiA+ID4gW8KgwqDCoDE5LjM1MzIwMl0g
YnJjbWZtYWM6IGJyY21mX2Z3X3JlcXVlc3RfbnZyYW1fZG9uZSBlbnRlcjoNCj4gPiA+ID4gPiBk
ZXY9bW1jMDowMDAxOjENCj4gPiA+ID4gPiBbwqDCoMKgMTkuMzUzNDI0XSBicmNtZm1hYzogYnJj
bWZfc2Rpb19maXJtd2FyZV9jYWxsYmFjayBFbnRlcjoNCj4gPiA+ID4gPiBkZXY9bW1jMDowMDAx
OjEsIGVycj0wDQo+ID4gPiA+ID4gW8KgwqDCoDE5LjM1MzgxNF0gYnJjbWZtYWM6IGJyY21mX3Nk
aW9fZG93bmxvYWRfY29kZV9maWxlIEVudGVyDQo+ID4gPiA+ID4gW8KgwqDCoDE5LjM4ODU4Nl0g
YnJjbWZtYWM6IGJyY21mX3NkaW9fdmVyaWZ5bWVtb3J5IENvbXBhcmUgUkFNDQo+ID4gPiA+ID4g
ZGwgJg0KPiA+ID4gPiA+IHVsDQo+ID4gPiA+ID4gYXQgMHgwMDE4MDAwMDsgc2l6ZT00OTM1OTkN
Cj4gPiA+ID4gPiBbwqDCoMKgMTkuNTQ2Njc1XSBicmNtZm1hYzogYnJjbWZfc2Rpb19kb3dubG9h
ZF9udnJhbSBFbnRlcg0KPiA+ID4gPiA+IFvCoMKgwqAxOS41NDc0MzJdIGJyY21mbWFjOiBicmNt
Zl9zZGlvX3ZlcmlmeW1lbW9yeSBDb21wYXJlIFJBTQ0KPiA+ID4gPiA+IGRsICYNCj4gPiA+ID4g
PiB1bA0KPiA+ID4gPiA+IGF0IDB4MDAyM2Y3MzA7IHNpemU9MjI1Ng0KPiA+ID4gPiA+IFvCoMKg
wqAxOS41NDg2NjVdIGJyY21mbWFjOiBicmNtZl9jaGlwX3NldF9hY3RpdmUgRW50ZXINCj4gPiA+
ID4gPiBbwqDCoMKgMjAuNTYyOTc0XSBicmNtZm1hYzogYnJjbWZfc2Rpb19odGNsazogSFQgQXZh
aWwgdGltZW91dA0KPiA+ID4gPiA+ICgxMDAwMDAwKToNCj4gPiA+ID4gPiBjbGtjdGwgMHg1MA0K
PiA+ID4gPiA+IFvCoMKgwqAyMC41NzA0OTBdIGJyY21mbWFjOiBicmNtZl9zZGlvX2Zpcm13YXJl
X2NhbGxiYWNrIGZhaWxlZDoNCj4gPiA+ID4gPiBkZXY9bW1jMDowMDAxOjEsIGVycj0wDQo+ID4g
PiA+ID4gW8KgwqDCoDIwLjU3MDczOV0gYnJjbWZtYWM6IGJyY21mX3NkaW9fcmVtb3ZlIEVudGVy
DQo+ID4gPiA+ID4gW8KgwqDCoDIwLjU3MDc3NV0gYnJjbWZtYWM6IGJyY21mX2RldGFjaCBFbnRl
cg0KPiA+ID4gPiA+IFvCoMKgwqAyMC42MTA0MTRdIGJyY21mbWFjOiBicmNtZl9idXNfY2hhbmdl
X3N0YXRlIDAgLT4gMA0KPiA+ID4gPiA+IFvCoMKgwqAyMC42MTA0NDFdIGJyY21mbWFjOiBicmNt
Zl9zZGlvX2J1c19zdG9wIEVudGVyDQo+ID4gPiA+ID4gW8KgwqDCoDIxLjYyMjQ3N10gYnJjbWZt
YWM6IGJyY21mX3NkaW9faHRjbGs6IEhUIEF2YWlsIHRpbWVvdXQNCj4gPiA+ID4gPiAoMTAwMDAw
MCk6DQo+ID4gPiA+ID4gY2xrY3RsIDB4NTANCj4gPiA+ID4gPiBbwqDCoMKgMjEuNjMwOTEyXSBi
cmNtZm1hYzogYnJjbWZfcHJvdG9fZGV0YWNoIEVudGVyDQo+ID4gPiA+ID4gW8KgwqDCoDIxLjYz
MDk2N10gYnJjbWZtYWM6IGJyY21mX2Z3ZWhfdW5yZWdpc3RlciBldmVudCBoYW5kbGVyDQo+ID4g
PiA+ID4gY2xlYXJlZA0KPiA+ID4gPiA+IGZvciBQU01fV0FUQ0hET0cNCj4gPiA+ID4gPiBbwqDC
oMKgMjIuNjQyNDU3XSBicmNtZm1hYzogYnJjbWZfc2Rpb19odGNsazogSFQgQXZhaWwgdGltZW91
dA0KPiA+ID4gPiA+ICgxMDAwMDAwKToNCj4gPiA+ID4gPiBjbGtjdGwgMHg1MA0KPiA+ID4gPiA+
IFvCoMKgwqAyMi42ODAxMzFdIGJyY21mbWFjOiBicmNtZl9jaGlwX3NldF9wYXNzaXZlIEVudGVy
DQo+ID4gPiA+ID4gW8KgwqDCoDIyLjY4MjU4MF0gYnJjbWZtYWM6IGJyY21mX3NkaW9fcmVtb3Zl
IERpc2Nvbm5lY3RlZA0KPiA+ID4gPiA+IA0KPiA+ID4gPiBBbnkgc3VnZ2VzdGlvbnMgb24gdGhp
cz8NCj4gPiA+IFNvcnJ5IGZvciBub3QgZ2V0dGluZyBiYWNrIHRvIHlvdXIgZWFybGllciBlbWFp
bC4gVGhhbmtzIGZvciB0aGUNCj4gPiA+IHJlbWluZGVyLiBTbyB5b3UgdHJpZWQgZGlmZmVyZW50
IGZpcm13YXJlcywgcmlnaHQ/IENhbiB5b3UNCj4gPiA+IHByb3ZpZGUNCj4gPiA+IG91dHB1dCBv
ZiB0aGUgZm9sbG93aW5nIGNvbW1hbmQ6DQo+ID4gPiANCj4gPiA+ICQgc3RyaW5ncyBmaXJtd2Fy
ZS5iaW4gfCB0YWlsIC0xDQo+ID4gPiANCj4gPiA+IGZvciB0aGUgZmlybXdhcmVzIHlvdSB0cmll
ZC4NCj4gPiA+IA0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IEFyZW5kDQo+ID4gVGhhbmtzIGZvciB0
aGUgcmVwbHkhDQo+ID4gDQo+ID4gSGVyZSdzIHRoZSBvdXRwdXQ6DQo+ID4gDQo+ID4gRm9yIFRl
Y2huZXhpb24gZmlybXdhcmU6DQo+ID4gDQo+ID4gIyBzdHJpbmdzIC9saWIvZmlybXdhcmUvYnJj
bS9icmNtZm1hYzQzMzktc2Rpby5iaW4gfCB0YWlsIC0xDQo+ID4gNDMzOWEwLXJvbWwvc2Rpby1h
Zy1wb29sLXAycC1wbm8tcGt0ZmlsdGVyLWtlZXBhbGl2ZS1hb2Utc3ItbWNoYW4tDQo+ID4gcHJv
cHR4c3RhdHVzLWxwYy10ZGxzLWF1dG9hYm4tdHhiZi0NCj4gPiByY2Mtd2Vwc28tb2tjLW5kb2Ug
VmVyc2lvbjogNi4zNy4zMi4yOCBDUkM6IDMwNzVmMTJlIERhdGU6IFRodQ0KPiA+IDIwMTQtMDQt
DQo+ID4gMDMgMTI6MTU6MzEgQ1NUIEZXSUQgMDEtNGFlNGFkDQo+ID4gMDMNCj4gPiANCj4gPiBG
b3IgbGludXgtZmlybXdhcmUgYW5kIEJ1aWxkcm9vdCBmaXJtd2FyZToNCj4gPiANCj4gPiAjIHN0
cmluZ3MgL2xpYi9maXJtd2FyZS9icmNtL2JyY21mbWFjNDMzOS1zZGlvLmJpbiB8IHRhaWwgLTEN
Cj4gPiA0MzM5YTAtcm9tbC9zZGlvLWFnLXBvb2wtYXV0b2Fibi1scGMgVmVyc2lvbjogNi4zNy4z
NC4yOCBDUkM6DQo+ID4gYTY5Njg5N2INCj4gPiBEYXRlOiBUaHUgMjAxNC0wOC0yOCAxODo0MDox
Mg0KPiA+IFBEVCBGV0lEIDAxLWExMzEyMGZjDQo+ID4gDQo+ID4gSW4gYm90aCBjYXNlcywgSSBh
bSB1c2luZyB0aGUgbnZyYW0gcHJvdmlkZWQgYnkgVGVjaG5leGlvbi4NCj4gVGhhdCBzaG91bGQg
YmUgZmluZS4NCj4gDQo+IENhbiB5b3UgdHJ5IHRoZSBwYXRjaCBiZWxvdy4gSXQgd291bGQgZ2l2
ZSBtZSBtb3JlIGluZm8gb24gc3RhdGUgb2bCoA0KPiBmaXJtd2FyZS4NCj4gDQo+IFJlZ2FyZHMs
DQo+IEFyZW5kDQo+IA0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvYnJvYWRj
b20vYnJjbTgwMjExL2JyY21mbWFjL3NkaW8uY8KgDQo+IGIvZHJpdmVycy9uZQ0KPiBpbmRleCBm
MzU1NjEyLi42MzFjNWNiIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9icm9h
ZGNvbS9icmNtODAyMTEvYnJjbWZtYWMvc2Rpby5jDQo+ICsrKyBiL2RyaXZlcnMvbmV0L3dpcmVs
ZXNzL2Jyb2FkY29tL2JyY204MDIxMS9icmNtZm1hYy9zZGlvLmMNCj4gQEAgLTgyOCw4ICs4Mjgs
MjcgQEAgc3RhdGljIGludCBicmNtZl9zZGlvX2h0Y2xrKHN0cnVjdCBicmNtZl9zZGlvDQo+ICpi
dXMswqANCj4gYm9vbCBvbiwNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqByZXR1cm4gLUVCQURFOw0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgfQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgaWYgKCFTQlNE
SU9fQ0xLQVYoY2xrY3RsLCBidXMtPmFscF9vbmx5KSkgew0KPiArwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHN0cnVjdCBicmNtZl9jb3JlICpwbXUgPcKgDQo+
IGJyY21mX2NoaXBfZ2V0X3BtdShidXMtPmNpKTsNCj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB1MzIgcmVnYWRkcjsNCj4gK8KgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB1MzIgdmFsOw0KPiArDQo+IMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgYnJjbWZfZXJyKCJIVCBBdmFp
bCB0aW1lb3V0ICglZCk6IGNsa2N0bA0KPiAweCUwMnhcbiIsDQo+IMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBQTVVf
TUFYX1RSQU5TSVRJT05fRExZLCBjbGtjdGwpOw0KPiArDQo+ICvCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgLyogREVCVUcgSU5GTyAqLw0KPiArwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHJlZ2FkZHIgPSBDT1JFX0NDX1JF
RyhwbXUtPmJhc2UsIHBtdWNvbnRyb2wpOw0KPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoHZhbCA9IGJyY21mX3NkaW9kX3JlZ3JsKGJ1cy0+c2Rpb2RldiwN
Cj4gcmVnYWRkcizCoA0KPiAmZXJyKTsNCj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqBicmNtZl9lcnIoIsKgwqBwbXVjb250cm9swqDCoMKgPSAlMDh4XG4i
LCB2YWwpOw0KPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oHJlZ2FkZHIgPSBDT1JFX0NDX1JFRyhwbXUtPmJhc2UsIHBtdXN0YXR1cyk7DQo+ICvCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgdmFsID0gYnJjbWZfc2Rpb2Rf
cmVncmwoYnVzLT5zZGlvZGV2LA0KPiByZWdhZGRyLMKgDQo+ICZlcnIpOw0KPiArwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGJyY21mX2VycigiwqDCoHBtdXN0
YXR1c8KgwqDCoMKgPSAlMDh4XG4iLCB2YWwpOw0KPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoHJlZ2FkZHIgPSBDT1JFX0NDX1JFRyhwbXUtPmJhc2UsDQo+
IG1pbl9yZXNfbWFzayk7DQo+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgdmFsID0gYnJjbWZfc2Rpb2RfcmVncmwoYnVzLT5zZGlvZGV2LA0KPiByZWdhZGRy
LMKgDQo+ICZlcnIpOw0KPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoGJyY21mX2VycigiwqDCoG1pbl9yZXNfbWFzayA9ICUwOHhcbiIsIHZhbCk7DQo+ICvC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgcmVnYWRkciA9IENP
UkVfQ0NfUkVHKHBtdS0+YmFzZSwNCj4gbWF4X3Jlc19tYXNrKTsNCj4gK8KgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB2YWwgPSBicmNtZl9zZGlvZF9yZWdybChi
dXMtPnNkaW9kZXYsDQo+IHJlZ2FkZHIswqANCj4gJmVycik7DQo+ICvCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgYnJjbWZfZXJyKCLCoMKgbWF4X3Jlc19tYXNr
ID0gJTA4eFxuIiwgdmFsKTsNCj4gKw0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoHJldHVybiAtRUJBREU7DQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqB9DQo+IA0KPiANCg0KSGVyZSdzIHRoZSBvdXRwdXQgZm9yIGJvdGggZmly
bXdhcmVzOg0KDQpUZWNobmV4aW9uOg0KIyBkbWVzZyB8IGdyZXAgYnJjbWZtYWMNClvCoMKgwqDC
oDUuMzA3MDY3XSBicmNtZm1hYzogYnJjbWZfZndfbWFwX2NoaXBfdG9fbmFtZTogdXNpbmcNCmJy
Y20vYnJjbWZtYWM0MzM5LXNkaW8uYmluIGZvciBjaGlwIDB4MDA0MzMNCjkoMTcyMDkpIHJldiAw
eDAwMDAwMg0KW8KgwqDCoMKgNi40MDA3OTJdIGJyY21mbWFjOiBicmNtZl9zZGlvX2h0Y2xrOiBI
VCBBdmFpbCB0aW1lb3V0ICgxMDAwMDAwKToNCmNsa2N0bCAweDUwDQpbwqDCoMKgwqA2LjQwODQ0
NF0gYnJjbWZtYWM6IGJyY21mX3NkaW9faHRjbGs6wqDCoMKgcG11Y29udHJvbMKgwqDCoD0gMDE3
NzQzODENClvCoMKgwqDCoDYuNDE1NTk1XSBicmNtZm1hYzogYnJjbWZfc2Rpb19odGNsazrCoMKg
wqBwbXVzdGF0dXPCoMKgwqDCoD0gMDAwMDAwMmENClvCoMKgwqDCoDYuNDIxOTE1XSBicmNtZm1h
YzogYnJjbWZfc2Rpb19odGNsazrCoMKgwqBtaW5fcmVzX21hc2sgPSAwZmNhZmY3Nw0KW8KgwqDC
oMKgNi40MjgxMjRdIGJyY21mbWFjOiBicmNtZl9zZGlvX2h0Y2xrOsKgwqDCoG1heF9yZXNfbWFz
ayA9IDBmY2VmZjc3DQpbwqDCoMKgwqA3LjQ4MjY2OF0gYnJjbWZtYWM6IGJyY21mX3NkaW9faHRj
bGs6IEhUIEF2YWlsIHRpbWVvdXQgKDEwMDAwMDApOg0KY2xrY3RsIDB4NTANClvCoMKgwqDCoDcu
NDkwMjE0XSBicmNtZm1hYzogYnJjbWZfc2Rpb19odGNsazrCoMKgwqBwbXVjb250cm9swqDCoMKg
PSAwMTc3NDM4MQ0KW8KgwqDCoMKgNy40OTY0MTRdIGJyY21mbWFjOiBicmNtZl9zZGlvX2h0Y2xr
OsKgwqDCoHBtdXN0YXR1c8KgwqDCoMKgPSAwMDAwMDAyYQ0KW8KgwqDCoMKgNy41MDM4NzNdIGJy
Y21mbWFjOiBicmNtZl9zZGlvX2h0Y2xrOsKgwqDCoG1pbl9yZXNfbWFzayA9IDBmY2FmZjc3DQpb
wqDCoMKgwqA3LjUxMDE4Ml0gYnJjbWZtYWM6IGJyY21mX3NkaW9faHRjbGs6wqDCoMKgbWF4X3Jl
c19tYXNrID0gMGZjZWZmNzcNCiPCoMKgc3RyaW5ncyAvbGliL2Zpcm13YXJlL2JyY20vYnJjbWZt
YWM0MzM5LXNkaW8uYmluIHwgdGFpbCAtMQ0KNDMzOWEwLXJvbWwvc2Rpby1hZy1wb29sLXAycC1w
bm8tcGt0ZmlsdGVyLWtlZXBhbGl2ZS1hb2Utc3ItbWNoYW4tDQpwcm9wdHhzdGF0dXMtbHBjLXRk
bHMtYXV0b2Fibi10eGJmLQ0KcmNjLXdlcHNvLW9rYy1uZG9lIFZlcnNpb246IDYuMzcuMzIuMjgg
Q1JDOiAzMDc1ZjEyZSBEYXRlOiBUaHUgMjAxNC0wNC0NCjAzIDEyOjE1OjMxIENTVCBGV0lEIDAx
LTRhZTRhZA0KMDMNCg0KQnVpbGRyb290Og0KIyBkbWVzZyB8IGdyZXAgYnJjbWZtYWMNClvCoMKg
wqDCoDUuMzQzMTE4XSBicmNtZm1hYzogYnJjbWZfZndfbWFwX2NoaXBfdG9fbmFtZTogdXNpbmcN
CmJyY20vYnJjbWZtYWM0MzM5LXNkaW8uYmluIGZvciBjaGlwIDB4MDA0MzMNCjkoMTcyMDkpIHJl
diAweDAwMDAwMg0KW8KgwqDCoMKgNi40MjAwNzBdIGJyY21mbWFjOiBicmNtZl9zZGlvX2h0Y2xr
OiBIVCBBdmFpbCB0aW1lb3V0ICgxMDAwMDAwKToNCmNsa2N0bCAweDUwDQpbwqDCoMKgwqA2LjQy
NzcyMl0gYnJjbWZtYWM6IGJyY21mX3NkaW9faHRjbGs6wqDCoMKgcG11Y29udHJvbMKgwqDCoD0g
MDE3NzQzODENClvCoMKgwqDCoDYuNDM0ODY1XSBicmNtZm1hYzogYnJjbWZfc2Rpb19odGNsazrC
oMKgwqBwbXVzdGF0dXPCoMKgwqDCoD0gMDAwMDAwMmENClvCoMKgwqDCoDYuNDQxMTc0XSBicmNt
Zm1hYzogYnJjbWZfc2Rpb19odGNsazrCoMKgwqBtaW5fcmVzX21hc2sgPSAwZmNhZmY3Nw0KW8Kg
wqDCoMKgNi40NDczNzldIGJyY21mbWFjOiBicmNtZl9zZGlvX2h0Y2xrOsKgwqDCoG1heF9yZXNf
bWFzayA9IDBmY2VmZjc3DQpbwqDCoMKgwqA3LjUwMjY1M10gYnJjbWZtYWM6IGJyY21mX3NkaW9f
aHRjbGs6IEhUIEF2YWlsIHRpbWVvdXQgKDEwMDAwMDApOg0KY2xrY3RsIDB4NTANClvCoMKgwqDC
oDcuNTEwMjAwXSBicmNtZm1hYzogYnJjbWZfc2Rpb19odGNsazrCoMKgwqBwbXVjb250cm9swqDC
oMKgPSAwMTc3NDM4MQ0KW8KgwqDCoMKgNy41MTYzOThdIGJyY21mbWFjOiBicmNtZl9zZGlvX2h0
Y2xrOsKgwqDCoHBtdXN0YXR1c8KgwqDCoMKgPSAwMDAwMDAyYQ0KW8KgwqDCoMKgNy41MjM4MjZd
IGJyY21mbWFjOiBicmNtZl9zZGlvX2h0Y2xrOsKgwqDCoG1pbl9yZXNfbWFzayA9IDBmY2FmZjc3
DQpbwqDCoMKgwqA3LjUzMDExN10gYnJjbWZtYWM6IGJyY21mX3NkaW9faHRjbGs6wqDCoMKgbWF4
X3Jlc19tYXNrID0gMGZjZWZmNzcNCiMgc3RyaW5ncyAvbGliL2Zpcm13YXJlL2JyY20vYnJjbWZt
YWM0MzM5LXNkaW8uYmluIHwgdGFpbCAtMQ0KNDMzOWEwLXJvbWwvc2Rpby1hZy1wb29sLWF1dG9h
Ym4tbHBjIFZlcnNpb246IDYuMzcuMzQuMjggQ1JDOiBhNjk2ODk3Yg0KRGF0ZTogVGh1IDIwMTQt
MDgtMjggMTg6NDA6MTLCoA0KUERUIEZXSUQgMDEtYTEzMTIwZmMNCg0KVGhhbmtzIQ0KDQpSZWdh
cmRzLA0KVmFuZXNzYQ==
^ permalink raw reply
* Re: AP6335 with mainline kernel
From: Arend van Spriel @ 2017-11-17 12:55 UTC (permalink / raw)
To: Vanessa Maegima, van.ayumi@gmail.com
Cc: linux-wireless@vger.kernel.org, embed3d@gmail.com,
joerg.krause@embedded.rocks
In-Reply-To: <1510916848.26896.2.camel@nxp.com>
On 11/17/2017 12:08 PM, Vanessa Maegima wrote:
> Hi Arend,
>
> On Sex, 2017-11-10 at 20:58 +0100, Arend van Spriel wrote:
>> On 10-11-17 13:43, Vanessa Maegima wrote:
>>>
>>> Hi,
>>>
>>> On Qui, 2017-09-21 at 12:30 -0300, Vanessa Ayumi Maegima wrote:
>>>>
>>>> Hi Arend,
>>>>
>>>> On Thu, Sep 21, 2017 at 4:26 AM, Arend van Spriel
>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>
>>>>>
>>>>> On 20-09-17 21:33, Vanessa Ayumi Maegima wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am trying to enable Wifi on imx7d-pico using mainline
>>>>>> kernel.
>>>>>> imx7d-pico
>>>>>> has an AP6335 chip.
>>>>>>
>>>>>> I am facing some issues related to the nvram file. I am using
>>>>>> the
>>>>>> firmware
>>>>>> provided by Buildroot (brcmfmac4339-sdio.bin). I get the
>>>>>> following error:
>>>>>>
>>>>>> [ 8.630380] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>>>> (1000000):
>>>>>> clkctl 0x50
>>>>>>
>>>>>> I have tried to use the firmware and nvram provided by
>>>>>> TechNexion
>>>>>> but I
>>>>>> get
>>>>>> the same error.
>>>>>>
>>>>>> Is there anyone that could enable Wifi on AP6335 using kernel
>>>>>> mainline?
>>>>>> What nvram file was used?
>>>>>>
>>>>>> I am able to use Wifi on the board if I use the firmware,
>>>>>> nvram
>>>>>> file and
>>>>>> kernel
>>>>>> provided by TechNexion. They use a 4.1 kernel from NXP with
>>>>>> the
>>>>>> bcmdhd
>>>>>> driver.
>>>>>>
>>>>>> So I know that the hardware is functional.
>>>>>>
>>>>>> Any suggestions as how to get it working with a 4.13 and
>>>>>> brcmfmac
>>>>>> driver
>>>>>> is
>>>>>> appreciated.
>>>>> So the nvram file is specific to the wifi chipset on your
>>>>> platform
>>>>> so best
>>>>> to stick with the provided one. The "HT Avail timeout" most
>>>>> often
>>>>> is an
>>>>> indication that the firmware crashed. So getting more debug
>>>>> output
>>>>> would
>>>>> help us understand how it ended up like that. Can you build the
>>>>> brcmfmac
>>>>> with CONFIG_BRCMDBG and load the driver using:
>>>>>
>>>>> $ insmod brcmfmac.ko debug=0x1416
>>>> Thanks for the reply!
>>>>
>>>> Here is the log (using 4.14-rc1):
>>>>
>>>> # dmesg | grep brcmfmac
>>>> [ 19.297206] brcmfmac: brcmfmac_module_init No platform data
>>>> available.
>>>> [ 19.307075] brcmfmac: brcmf_sdio_probe Enter
>>>> [ 19.308384] brcmfmac: F1 signature read @0x18000000=0x16224335
>>>> [ 19.309026] brcmfmac: brcmf_chip_recognition found AXI chip:
>>>> BCM4339, rev=2
>>>> [ 19.317115] brcmfmac: brcmf_chip_cores_check [1 ] core
>>>> 0x800:46
>>>> base 0x18000000 wrap 0x18100000
>>>> [ 19.317141] brcmfmac: brcmf_chip_cores_check [2 ] core
>>>> 0x812:46
>>>> base 0x18001000 wrap 0x18101000
>>>> [ 19.317165] brcmfmac: brcmf_chip_cores_check [3 ] core
>>>> 0x83e:4
>>>> base 0x18002000 wrap 0x18102000
>>>> [ 19.317188] brcmfmac: brcmf_chip_cores_check [4 ] core
>>>> 0x83c:4
>>>> base 0x18003000 wrap 0x18103000
>>>> [ 19.317210] brcmfmac: brcmf_chip_cores_check [5 ] core
>>>> 0x81a:20
>>>> base 0x18004000 wrap 0x18104000
>>>> [ 19.317233] brcmfmac: brcmf_chip_cores_check [6 ] core
>>>> 0x829:21
>>>> base 0x18005000 wrap 0x18105000
>>>> [ 19.317256] brcmfmac: brcmf_chip_cores_check [7 ] core
>>>> 0x135:0
>>>> base 0x00000000 wrap 0x18109000
>>>> [ 19.317279] brcmfmac: brcmf_chip_cores_check [8 ] core
>>>> 0x240:0
>>>> base 0x00000000 wrap 0x00000000
>>>> [ 19.317298] brcmfmac: brcmf_chip_set_passive Enter
>>>> [ 19.322232] brcmfmac: brcmf_chip_get_raminfo RAM:
>>>> base=0x180000
>>>> size=786432 (0xc0000) sr=0 (0x0)
>>>> [ 19.322457] brcmfmac: brcmf_chip_setup ccrev=46, pmurev=23,
>>>> pmucaps=0x39cc5f17
>>>> [ 19.322481] brcmfmac: brcmf_get_module_param Enter, bus=0,
>>>> chip=17209, rev=2
>>>> [ 19.322504] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
>>>> [ 19.322531] brcmfmac: brcmf_sdio_kso_init Enter
>>>> [ 19.322618] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO
>>>> driver
>>>> strength init needed for chip 43
>>>> 39 rev 2 pmurev 23
>>>> [ 19.323235] brcmfmac: brcmf_attach Enter
>>>> [ 19.323725] brcmfmac: brcmf_proto_attach Enter
>>>> [ 19.323769] brcmfmac: brcmf_fweh_register event handler
>>>> registered
>>>> for PSM_WATCHDOG
>>>> [ 19.324306] brcmfmac: brcmf_sdio_probe completed!!
>>>> [ 19.324337] brcmfmac: brcmf_fw_map_chip_to_name: using
>>>> brcm/brcmfmac4339-sdio.bin for chip 0x00433
>>>> 9(17209) rev 0x000002
>>>> [ 19.335353] brcmfmac: brcmf_fw_get_firmwares_pcie enter:
>>>> dev=mmc0:0001:1
>>>> [ 19.351787] brcmfmac: brcmf_fw_request_code_done enter:
>>>> dev=mmc0:0001:1
>>>> [ 19.353202] brcmfmac: brcmf_fw_request_nvram_done enter:
>>>> dev=mmc0:0001:1
>>>> [ 19.353424] brcmfmac: brcmf_sdio_firmware_callback Enter:
>>>> dev=mmc0:0001:1, err=0
>>>> [ 19.353814] brcmfmac: brcmf_sdio_download_code_file Enter
>>>> [ 19.388586] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl &
>>>> ul
>>>> at 0x00180000; size=493599
>>>> [ 19.546675] brcmfmac: brcmf_sdio_download_nvram Enter
>>>> [ 19.547432] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl &
>>>> ul
>>>> at 0x0023f730; size=2256
>>>> [ 19.548665] brcmfmac: brcmf_chip_set_active Enter
>>>> [ 20.562974] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>> (1000000):
>>>> clkctl 0x50
>>>> [ 20.570490] brcmfmac: brcmf_sdio_firmware_callback failed:
>>>> dev=mmc0:0001:1, err=0
>>>> [ 20.570739] brcmfmac: brcmf_sdio_remove Enter
>>>> [ 20.570775] brcmfmac: brcmf_detach Enter
>>>> [ 20.610414] brcmfmac: brcmf_bus_change_state 0 -> 0
>>>> [ 20.610441] brcmfmac: brcmf_sdio_bus_stop Enter
>>>> [ 21.622477] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>> (1000000):
>>>> clkctl 0x50
>>>> [ 21.630912] brcmfmac: brcmf_proto_detach Enter
>>>> [ 21.630967] brcmfmac: brcmf_fweh_unregister event handler
>>>> cleared
>>>> for PSM_WATCHDOG
>>>> [ 22.642457] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>> (1000000):
>>>> clkctl 0x50
>>>> [ 22.680131] brcmfmac: brcmf_chip_set_passive Enter
>>>> [ 22.682580] brcmfmac: brcmf_sdio_remove Disconnected
>>>>
>>> Any suggestions on this?
>> Sorry for not getting back to your earlier email. Thanks for the
>> reminder. So you tried different firmwares, right? Can you provide
>> output of the following command:
>>
>> $ strings firmware.bin | tail -1
>>
>> for the firmwares you tried.
>>
>> Regards,
>> Arend
>
> Thanks for the reply!
>
> Here's the output:
>
> For Technexion firmware:
>
> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
> 4339a0-roml/sdio-ag-pool-p2p-pno-pktfilter-keepalive-aoe-sr-mchan-
> proptxstatus-lpc-tdls-autoabn-txbf-
> rcc-wepso-okc-ndoe Version: 6.37.32.28 CRC: 3075f12e Date: Thu 2014-04-
> 03 12:15:31 CST FWID 01-4ae4ad
> 03
>
> For linux-firmware and Buildroot firmware:
>
> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
> 4339a0-roml/sdio-ag-pool-autoabn-lpc Version: 6.37.34.28 CRC: a696897b
> Date: Thu 2014-08-28 18:40:12
> PDT FWID 01-a13120fc
>
> In both cases, I am using the nvram provided by Technexion.
That should be fine.
Can you try the patch below. It would give me more info on state of
firmware.
Regards,
Arend
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/ne
index f355612..631c5cb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -828,8 +828,27 @@ static int brcmf_sdio_htclk(struct brcmf_sdio *bus,
bool on,
return -EBADE;
}
if (!SBSDIO_CLKAV(clkctl, bus->alp_only)) {
+ struct brcmf_core *pmu =
brcmf_chip_get_pmu(bus->ci);
+ u32 regaddr;
+ u32 val;
+
brcmf_err("HT Avail timeout (%d): clkctl 0x%02x\n",
PMU_MAX_TRANSITION_DLY, clkctl);
+
+ /* DEBUG INFO */
+ regaddr = CORE_CC_REG(pmu->base, pmucontrol);
+ val = brcmf_sdiod_regrl(bus->sdiodev, regaddr,
&err);
+ brcmf_err(" pmucontrol = %08x\n", val);
+ regaddr = CORE_CC_REG(pmu->base, pmustatus);
+ val = brcmf_sdiod_regrl(bus->sdiodev, regaddr,
&err);
+ brcmf_err(" pmustatus = %08x\n", val);
+ regaddr = CORE_CC_REG(pmu->base, min_res_mask);
+ val = brcmf_sdiod_regrl(bus->sdiodev, regaddr,
&err);
+ brcmf_err(" min_res_mask = %08x\n", val);
+ regaddr = CORE_CC_REG(pmu->base, max_res_mask);
+ val = brcmf_sdiod_regrl(bus->sdiodev, regaddr,
&err);
+ brcmf_err(" max_res_mask = %08x\n", val);
+
return -EBADE;
}
^ permalink raw reply related
* Re: AP6335 with mainline kernel
From: Vanessa Maegima @ 2017-11-17 11:08 UTC (permalink / raw)
To: arend.vanspriel@broadcom.com, van.ayumi@gmail.com
Cc: linux-wireless@vger.kernel.org, embed3d@gmail.com,
joerg.krause@embedded.rocks
In-Reply-To: <85717463-11e2-e2e3-b08e-b758986687b5@broadcom.com>
SGkgQXJlbmQsDQoNCk9uIFNleCwgMjAxNy0xMS0xMCBhdCAyMDo1OCArMDEwMCwgQXJlbmQgdmFu
IFNwcmllbCB3cm90ZToNCj4gT24gMTAtMTEtMTcgMTM6NDMsIFZhbmVzc2EgTWFlZ2ltYSB3cm90
ZToNCj4gPiANCj4gPiBIaSwNCj4gPiANCj4gPiBPbiBRdWksIDIwMTctMDktMjEgYXQgMTI6MzAg
LTAzMDAsIFZhbmVzc2EgQXl1bWkgTWFlZ2ltYSB3cm90ZToNCj4gPiA+IA0KPiA+ID4gSGkgQXJl
bmQsDQo+ID4gPiANCj4gPiA+IE9uIFRodSwgU2VwIDIxLCAyMDE3IGF0IDQ6MjYgQU0sIEFyZW5k
IHZhbiBTcHJpZWwNCj4gPiA+IDxhcmVuZC52YW5zcHJpZWxAYnJvYWRjb20uY29tPiB3cm90ZToN
Cj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBPbiAyMC0wOS0xNyAyMTozMywgVmFuZXNzYSBB
eXVtaSBNYWVnaW1hIHdyb3RlOg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0K
PiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEkgYW0gdHJ5aW5nIHRvIGVuYWJs
ZSBXaWZpIG9uIGlteDdkLXBpY28gdXNpbmcgbWFpbmxpbmUNCj4gPiA+ID4gPiBrZXJuZWwuDQo+
ID4gPiA+ID4gaW14N2QtcGljbw0KPiA+ID4gPiA+IGhhcyBhbiBBUDYzMzUgY2hpcC4NCj4gPiA+
ID4gPiANCj4gPiA+ID4gPiBJIGFtIGZhY2luZyBzb21lIGlzc3VlcyByZWxhdGVkIHRvIHRoZSBu
dnJhbSBmaWxlLiBJIGFtIHVzaW5nDQo+ID4gPiA+ID4gdGhlDQo+ID4gPiA+ID4gZmlybXdhcmUN
Cj4gPiA+ID4gPiBwcm92aWRlZCBieSBCdWlsZHJvb3QgKGJyY21mbWFjNDMzOS1zZGlvLmJpbiku
IEkgZ2V0IHRoZQ0KPiA+ID4gPiA+IGZvbGxvd2luZyBlcnJvcjoNCj4gPiA+ID4gPiANCj4gPiA+
ID4gPiBbwqDCoMKgwqA4LjYzMDM4MF0gYnJjbWZtYWM6IGJyY21mX3NkaW9faHRjbGs6IEhUIEF2
YWlsIHRpbWVvdXQNCj4gPiA+ID4gPiAoMTAwMDAwMCk6DQo+ID4gPiA+ID4gY2xrY3RsIDB4NTAN
Cj4gPiA+ID4gPiANCj4gPiA+ID4gPiBJIGhhdmUgdHJpZWQgdG8gdXNlIHRoZSBmaXJtd2FyZSBh
bmQgbnZyYW0gcHJvdmlkZWQgYnkNCj4gPiA+ID4gPiBUZWNoTmV4aW9uDQo+ID4gPiA+ID4gYnV0
IEkNCj4gPiA+ID4gPiBnZXQNCj4gPiA+ID4gPiB0aGUgc2FtZSBlcnJvci4NCj4gPiA+ID4gPiAN
Cj4gPiA+ID4gPiBJcyB0aGVyZSBhbnlvbmUgdGhhdCBjb3VsZCBlbmFibGUgV2lmaSBvbiBBUDYz
MzUgdXNpbmcga2VybmVsDQo+ID4gPiA+ID4gbWFpbmxpbmU/DQo+ID4gPiA+ID4gV2hhdCBudnJh
bSBmaWxlIHdhcyB1c2VkPw0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEkgYW0gYWJsZSB0byB1c2Ug
V2lmaSBvbiB0aGUgYm9hcmQgaWYgSSB1c2UgdGhlIGZpcm13YXJlLA0KPiA+ID4gPiA+IG52cmFt
DQo+ID4gPiA+ID4gZmlsZSBhbmQNCj4gPiA+ID4gPiBrZXJuZWwNCj4gPiA+ID4gPiBwcm92aWRl
ZCBieSBUZWNoTmV4aW9uLiBUaGV5IHVzZSBhIDQuMSBrZXJuZWwgZnJvbSBOWFAgd2l0aA0KPiA+
ID4gPiA+IHRoZQ0KPiA+ID4gPiA+IGJjbWRoZA0KPiA+ID4gPiA+IGRyaXZlci4NCj4gPiA+ID4g
PiANCj4gPiA+ID4gPiBTbyBJIGtub3cgdGhhdCB0aGUgaGFyZHdhcmUgaXMgZnVuY3Rpb25hbC4N
Cj4gPiA+ID4gPiANCj4gPiA+ID4gPiBBbnkgc3VnZ2VzdGlvbnMgYXMgaG93IHRvIGdldCBpdCB3
b3JraW5nIHdpdGggYSA0LjEzIGFuZA0KPiA+ID4gPiA+IGJyY21mbWFjDQo+ID4gPiA+ID4gZHJp
dmVyDQo+ID4gPiA+ID4gaXMNCj4gPiA+ID4gPiBhcHByZWNpYXRlZC4NCj4gPiA+ID4gU28gdGhl
IG52cmFtIGZpbGUgaXMgc3BlY2lmaWMgdG8gdGhlIHdpZmkgY2hpcHNldCBvbiB5b3VyDQo+ID4g
PiA+IHBsYXRmb3JtDQo+ID4gPiA+IHNvIGJlc3QNCj4gPiA+ID4gdG8gc3RpY2sgd2l0aCB0aGUg
cHJvdmlkZWQgb25lLiBUaGUgIkhUIEF2YWlsIHRpbWVvdXQiIG1vc3QNCj4gPiA+ID4gb2Z0ZW4N
Cj4gPiA+ID4gaXMgYW4NCj4gPiA+ID4gaW5kaWNhdGlvbiB0aGF0IHRoZSBmaXJtd2FyZSBjcmFz
aGVkLiBTbyBnZXR0aW5nIG1vcmUgZGVidWcNCj4gPiA+ID4gb3V0cHV0DQo+ID4gPiA+IHdvdWxk
DQo+ID4gPiA+IGhlbHAgdXMgdW5kZXJzdGFuZCBob3cgaXQgZW5kZWQgdXAgbGlrZSB0aGF0LiBD
YW4geW91IGJ1aWxkIHRoZQ0KPiA+ID4gPiBicmNtZm1hYw0KPiA+ID4gPiB3aXRoIENPTkZJR19C
UkNNREJHIGFuZCBsb2FkIHRoZSBkcml2ZXIgdXNpbmc6DQo+ID4gPiA+IA0KPiA+ID4gPiAkIGlu
c21vZCBicmNtZm1hYy5rbyBkZWJ1Zz0weDE0MTYNCj4gPiA+IFRoYW5rcyBmb3IgdGhlIHJlcGx5
IQ0KPiA+ID4gDQo+ID4gPiBIZXJlIGlzIHRoZSBsb2cgKHVzaW5nIDQuMTQtcmMxKToNCj4gPiA+
IA0KPiA+ID4gIyBkbWVzZyB8IGdyZXAgYnJjbWZtYWMNCj4gPiA+IFvCoMKgwqAxOS4yOTcyMDZd
IGJyY21mbWFjOiBicmNtZm1hY19tb2R1bGVfaW5pdCBObyBwbGF0Zm9ybSBkYXRhDQo+ID4gPiBh
dmFpbGFibGUuDQo+ID4gPiBbwqDCoMKgMTkuMzA3MDc1XSBicmNtZm1hYzogYnJjbWZfc2Rpb19w
cm9iZSBFbnRlcg0KPiA+ID4gW8KgwqDCoDE5LjMwODM4NF0gYnJjbWZtYWM6IEYxIHNpZ25hdHVy
ZSByZWFkIEAweDE4MDAwMDAwPTB4MTYyMjQzMzUNCj4gPiA+IFvCoMKgwqAxOS4zMDkwMjZdIGJy
Y21mbWFjOiBicmNtZl9jaGlwX3JlY29nbml0aW9uIGZvdW5kIEFYSSBjaGlwOg0KPiA+ID4gQkNN
NDMzOSwgcmV2PTINCj4gPiA+IFvCoMKgwqAxOS4zMTcxMTVdIGJyY21mbWFjOiBicmNtZl9jaGlw
X2NvcmVzX2NoZWNrwqDCoFsxIF0gY29yZQ0KPiA+ID4gMHg4MDA6NDYNCj4gPiA+IGJhc2UgMHgx
ODAwMDAwMCB3cmFwIDB4MTgxMDAwMDANCj4gPiA+IFvCoMKgwqAxOS4zMTcxNDFdIGJyY21mbWFj
OiBicmNtZl9jaGlwX2NvcmVzX2NoZWNrwqDCoFsyIF0gY29yZQ0KPiA+ID4gMHg4MTI6NDYNCj4g
PiA+IGJhc2UgMHgxODAwMTAwMCB3cmFwIDB4MTgxMDEwMDANCj4gPiA+IFvCoMKgwqAxOS4zMTcx
NjVdIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2NoZWNrwqDCoFszIF0gY29yZQ0KPiA+ID4g
MHg4M2U6NA0KPiA+ID4gYmFzZSAweDE4MDAyMDAwIHdyYXAgMHgxODEwMjAwMA0KPiA+ID4gW8Kg
wqDCoDE5LjMxNzE4OF0gYnJjbWZtYWM6IGJyY21mX2NoaXBfY29yZXNfY2hlY2vCoMKgWzQgXSBj
b3JlDQo+ID4gPiAweDgzYzo0DQo+ID4gPiBiYXNlIDB4MTgwMDMwMDAgd3JhcCAweDE4MTAzMDAw
DQo+ID4gPiBbwqDCoMKgMTkuMzE3MjEwXSBicmNtZm1hYzogYnJjbWZfY2hpcF9jb3Jlc19jaGVj
a8KgwqBbNSBdIGNvcmUNCj4gPiA+IDB4ODFhOjIwDQo+ID4gPiBiYXNlIDB4MTgwMDQwMDAgd3Jh
cCAweDE4MTA0MDAwDQo+ID4gPiBbwqDCoMKgMTkuMzE3MjMzXSBicmNtZm1hYzogYnJjbWZfY2hp
cF9jb3Jlc19jaGVja8KgwqBbNiBdIGNvcmUNCj4gPiA+IDB4ODI5OjIxDQo+ID4gPiBiYXNlIDB4
MTgwMDUwMDAgd3JhcCAweDE4MTA1MDAwDQo+ID4gPiBbwqDCoMKgMTkuMzE3MjU2XSBicmNtZm1h
YzogYnJjbWZfY2hpcF9jb3Jlc19jaGVja8KgwqBbNyBdIGNvcmUNCj4gPiA+IDB4MTM1OjANCj4g
PiA+IGJhc2UgMHgwMDAwMDAwMCB3cmFwIDB4MTgxMDkwMDANCj4gPiA+IFvCoMKgwqAxOS4zMTcy
NzldIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2NoZWNrwqDCoFs4IF0gY29yZQ0KPiA+ID4g
MHgyNDA6MA0KPiA+ID4gYmFzZSAweDAwMDAwMDAwIHdyYXAgMHgwMDAwMDAwMA0KPiA+ID4gW8Kg
wqDCoDE5LjMxNzI5OF0gYnJjbWZtYWM6IGJyY21mX2NoaXBfc2V0X3Bhc3NpdmUgRW50ZXINCj4g
PiA+IFvCoMKgwqAxOS4zMjIyMzJdIGJyY21mbWFjOiBicmNtZl9jaGlwX2dldF9yYW1pbmZvIFJB
TToNCj4gPiA+IGJhc2U9MHgxODAwMDANCj4gPiA+IHNpemU9Nzg2NDMyICgweGMwMDAwKSBzcj0w
ICgweDApDQo+ID4gPiBbwqDCoMKgMTkuMzIyNDU3XSBicmNtZm1hYzogYnJjbWZfY2hpcF9zZXR1
cCBjY3Jldj00NiwgcG11cmV2PTIzLA0KPiA+ID4gcG11Y2Fwcz0weDM5Y2M1ZjE3DQo+ID4gPiBb
wqDCoMKgMTkuMzIyNDgxXSBicmNtZm1hYzogYnJjbWZfZ2V0X21vZHVsZV9wYXJhbSBFbnRlciwg
YnVzPTAsDQo+ID4gPiBjaGlwPTE3MjA5LCByZXY9Mg0KPiA+ID4gW8KgwqDCoDE5LjMyMjUwNF0g
YnJjbWZtYWM6IGJyY21mX3NkaW9kX3NndGFibGVfYWxsb2MgbmVudHM9MzUNCj4gPiA+IFvCoMKg
wqAxOS4zMjI1MzFdIGJyY21mbWFjOiBicmNtZl9zZGlvX2tzb19pbml0IEVudGVyDQo+ID4gPiBb
wqDCoMKgMTkuMzIyNjE4XSBicmNtZm1hYzogYnJjbWZfc2Rpb19kcml2ZXN0cmVuZ3RoaW5pdCBO
byBTRElPDQo+ID4gPiBkcml2ZXINCj4gPiA+IHN0cmVuZ3RoIGluaXQgbmVlZGVkIGZvciBjaGlw
IDQzDQo+ID4gPiAzOSByZXYgMiBwbXVyZXYgMjMNCj4gPiA+IFvCoMKgwqAxOS4zMjMyMzVdIGJy
Y21mbWFjOiBicmNtZl9hdHRhY2ggRW50ZXINCj4gPiA+IFvCoMKgwqAxOS4zMjM3MjVdIGJyY21m
bWFjOiBicmNtZl9wcm90b19hdHRhY2ggRW50ZXINCj4gPiA+IFvCoMKgwqAxOS4zMjM3NjldIGJy
Y21mbWFjOiBicmNtZl9md2VoX3JlZ2lzdGVyIGV2ZW50IGhhbmRsZXINCj4gPiA+IHJlZ2lzdGVy
ZWQNCj4gPiA+IGZvciBQU01fV0FUQ0hET0cNCj4gPiA+IFvCoMKgwqAxOS4zMjQzMDZdIGJyY21m
bWFjOiBicmNtZl9zZGlvX3Byb2JlIGNvbXBsZXRlZCEhDQo+ID4gPiBbwqDCoMKgMTkuMzI0MzM3
XSBicmNtZm1hYzogYnJjbWZfZndfbWFwX2NoaXBfdG9fbmFtZTogdXNpbmcNCj4gPiA+IGJyY20v
YnJjbWZtYWM0MzM5LXNkaW8uYmluIGZvciBjaGlwIDB4MDA0MzMNCj4gPiA+IDkoMTcyMDkpIHJl
diAweDAwMDAwMg0KPiA+ID4gW8KgwqDCoDE5LjMzNTM1M10gYnJjbWZtYWM6IGJyY21mX2Z3X2dl
dF9maXJtd2FyZXNfcGNpZSBlbnRlcjoNCj4gPiA+IGRldj1tbWMwOjAwMDE6MQ0KPiA+ID4gW8Kg
wqDCoDE5LjM1MTc4N10gYnJjbWZtYWM6IGJyY21mX2Z3X3JlcXVlc3RfY29kZV9kb25lIGVudGVy
Og0KPiA+ID4gZGV2PW1tYzA6MDAwMToxDQo+ID4gPiBbwqDCoMKgMTkuMzUzMjAyXSBicmNtZm1h
YzogYnJjbWZfZndfcmVxdWVzdF9udnJhbV9kb25lIGVudGVyOg0KPiA+ID4gZGV2PW1tYzA6MDAw
MToxDQo+ID4gPiBbwqDCoMKgMTkuMzUzNDI0XSBicmNtZm1hYzogYnJjbWZfc2Rpb19maXJtd2Fy
ZV9jYWxsYmFjayBFbnRlcjoNCj4gPiA+IGRldj1tbWMwOjAwMDE6MSwgZXJyPTANCj4gPiA+IFvC
oMKgwqAxOS4zNTM4MTRdIGJyY21mbWFjOiBicmNtZl9zZGlvX2Rvd25sb2FkX2NvZGVfZmlsZSBF
bnRlcg0KPiA+ID4gW8KgwqDCoDE5LjM4ODU4Nl0gYnJjbWZtYWM6IGJyY21mX3NkaW9fdmVyaWZ5
bWVtb3J5IENvbXBhcmUgUkFNIGRsICYNCj4gPiA+IHVsDQo+ID4gPiBhdCAweDAwMTgwMDAwOyBz
aXplPTQ5MzU5OQ0KPiA+ID4gW8KgwqDCoDE5LjU0NjY3NV0gYnJjbWZtYWM6IGJyY21mX3NkaW9f
ZG93bmxvYWRfbnZyYW0gRW50ZXINCj4gPiA+IFvCoMKgwqAxOS41NDc0MzJdIGJyY21mbWFjOiBi
cmNtZl9zZGlvX3ZlcmlmeW1lbW9yeSBDb21wYXJlIFJBTSBkbCAmDQo+ID4gPiB1bA0KPiA+ID4g
YXQgMHgwMDIzZjczMDsgc2l6ZT0yMjU2DQo+ID4gPiBbwqDCoMKgMTkuNTQ4NjY1XSBicmNtZm1h
YzogYnJjbWZfY2hpcF9zZXRfYWN0aXZlIEVudGVyDQo+ID4gPiBbwqDCoMKgMjAuNTYyOTc0XSBi
cmNtZm1hYzogYnJjbWZfc2Rpb19odGNsazogSFQgQXZhaWwgdGltZW91dA0KPiA+ID4gKDEwMDAw
MDApOg0KPiA+ID4gY2xrY3RsIDB4NTANCj4gPiA+IFvCoMKgwqAyMC41NzA0OTBdIGJyY21mbWFj
OiBicmNtZl9zZGlvX2Zpcm13YXJlX2NhbGxiYWNrIGZhaWxlZDoNCj4gPiA+IGRldj1tbWMwOjAw
MDE6MSwgZXJyPTANCj4gPiA+IFvCoMKgwqAyMC41NzA3MzldIGJyY21mbWFjOiBicmNtZl9zZGlv
X3JlbW92ZSBFbnRlcg0KPiA+ID4gW8KgwqDCoDIwLjU3MDc3NV0gYnJjbWZtYWM6IGJyY21mX2Rl
dGFjaCBFbnRlcg0KPiA+ID4gW8KgwqDCoDIwLjYxMDQxNF0gYnJjbWZtYWM6IGJyY21mX2J1c19j
aGFuZ2Vfc3RhdGUgMCAtPiAwDQo+ID4gPiBbwqDCoMKgMjAuNjEwNDQxXSBicmNtZm1hYzogYnJj
bWZfc2Rpb19idXNfc3RvcCBFbnRlcg0KPiA+ID4gW8KgwqDCoDIxLjYyMjQ3N10gYnJjbWZtYWM6
IGJyY21mX3NkaW9faHRjbGs6IEhUIEF2YWlsIHRpbWVvdXQNCj4gPiA+ICgxMDAwMDAwKToNCj4g
PiA+IGNsa2N0bCAweDUwDQo+ID4gPiBbwqDCoMKgMjEuNjMwOTEyXSBicmNtZm1hYzogYnJjbWZf
cHJvdG9fZGV0YWNoIEVudGVyDQo+ID4gPiBbwqDCoMKgMjEuNjMwOTY3XSBicmNtZm1hYzogYnJj
bWZfZndlaF91bnJlZ2lzdGVyIGV2ZW50IGhhbmRsZXINCj4gPiA+IGNsZWFyZWQNCj4gPiA+IGZv
ciBQU01fV0FUQ0hET0cNCj4gPiA+IFvCoMKgwqAyMi42NDI0NTddIGJyY21mbWFjOiBicmNtZl9z
ZGlvX2h0Y2xrOiBIVCBBdmFpbCB0aW1lb3V0DQo+ID4gPiAoMTAwMDAwMCk6DQo+ID4gPiBjbGtj
dGwgMHg1MA0KPiA+ID4gW8KgwqDCoDIyLjY4MDEzMV0gYnJjbWZtYWM6IGJyY21mX2NoaXBfc2V0
X3Bhc3NpdmUgRW50ZXINCj4gPiA+IFvCoMKgwqAyMi42ODI1ODBdIGJyY21mbWFjOiBicmNtZl9z
ZGlvX3JlbW92ZSBEaXNjb25uZWN0ZWQNCj4gPiA+IA0KPiA+IEFueSBzdWdnZXN0aW9ucyBvbiB0
aGlzPw0KPiBTb3JyeSBmb3Igbm90IGdldHRpbmcgYmFjayB0byB5b3VyIGVhcmxpZXIgZW1haWwu
IFRoYW5rcyBmb3IgdGhlwqANCj4gcmVtaW5kZXIuIFNvIHlvdSB0cmllZCBkaWZmZXJlbnQgZmly
bXdhcmVzLCByaWdodD8gQ2FuIHlvdSBwcm92aWRlwqANCj4gb3V0cHV0IG9mIHRoZSBmb2xsb3dp
bmcgY29tbWFuZDoNCj4gDQo+ICQgc3RyaW5ncyBmaXJtd2FyZS5iaW4gfCB0YWlsIC0xDQo+IA0K
PiBmb3IgdGhlIGZpcm13YXJlcyB5b3UgdHJpZWQuDQo+IA0KPiBSZWdhcmRzLA0KPiBBcmVuZA0K
DQpUaGFua3MgZm9yIHRoZSByZXBseSENCg0KSGVyZSdzIHRoZSBvdXRwdXQ6DQoNCkZvciBUZWNo
bmV4aW9uIGZpcm13YXJlOg0KDQojIHN0cmluZ3MgL2xpYi9maXJtd2FyZS9icmNtL2JyY21mbWFj
NDMzOS1zZGlvLmJpbiB8IHRhaWwgLTENCjQzMzlhMC1yb21sL3NkaW8tYWctcG9vbC1wMnAtcG5v
LXBrdGZpbHRlci1rZWVwYWxpdmUtYW9lLXNyLW1jaGFuLQ0KcHJvcHR4c3RhdHVzLWxwYy10ZGxz
LWF1dG9hYm4tdHhiZi0NCnJjYy13ZXBzby1va2MtbmRvZSBWZXJzaW9uOiA2LjM3LjMyLjI4IENS
QzogMzA3NWYxMmUgRGF0ZTogVGh1IDIwMTQtMDQtDQowMyAxMjoxNTozMSBDU1QgRldJRCAwMS00
YWU0YWQNCjAzDQoNCkZvciBsaW51eC1maXJtd2FyZSBhbmQgQnVpbGRyb290IGZpcm13YXJlOg0K
DQojIHN0cmluZ3MgL2xpYi9maXJtd2FyZS9icmNtL2JyY21mbWFjNDMzOS1zZGlvLmJpbiB8IHRh
aWwgLTENCjQzMzlhMC1yb21sL3NkaW8tYWctcG9vbC1hdXRvYWJuLWxwYyBWZXJzaW9uOiA2LjM3
LjM0LjI4IENSQzogYTY5Njg5N2INCkRhdGU6IFRodSAyMDE0LTA4LTI4IDE4OjQwOjEywqANClBE
VCBGV0lEIDAxLWExMzEyMGZjDQoNCkluIGJvdGggY2FzZXMsIEkgYW0gdXNpbmcgdGhlIG52cmFt
IHByb3ZpZGVkIGJ5IFRlY2huZXhpb24uDQoNClRoYW5rcyENCg0KUmVnYXJkcywNClZhbmVzc2EN
Cg0KPiA+IA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IFJl
Z2FyZHMsDQo+ID4gPiA+IEFyZW5kDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4g
DQo+ID4gPiA+ID4gVGhhbmtzIQ0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IFJlZ2FyZHMsDQo+ID4g
PiA+ID4gVmFuZXNzYQ==
^ permalink raw reply
* Re: [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Sven Eckelmann @ 2017-11-17 11:06 UTC (permalink / raw)
To: ath10k; +Cc: akolli, akolli, linux-wireless, Daniel Jeang, Yifeng Tu
In-Reply-To: <1479227849-10042-1-git-send-email-akolli@qti.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
On Dienstag, 15. November 2016 22:07:29 CET akolli@qti.qualcomm.com wrote:
> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
> event, Firmware sends one HTT event for every four PPDUs.
> HTT payload has success pkts/bytes, failed pkts/bytes, retry
> pkts/bytes and rate info per ppdu.
> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
> which are nowadays enabled by default.
>
> Parse peer stats and update the tx rate information per STA.
>
> tx rate, Peer stats are tested on QCA4019 with Firmware version
> 10.4-3.2.1-00028.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Why is the support for 10.2.4 firmware not upstreamed? I mean the one which is
using pktlog to transfer the PEER_STATS information.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Need support for Intel new wifi module 9462NGW
From: Chris Chiu @ 2017-11-17 10:14 UTC (permalink / raw)
To: Luca Coelho
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <1510905186.4011.202.camel@coelho.fi>
On Fri, Nov 17, 2017 at 3:53 PM, Luca Coelho <luca@coelho.fi> wrote:
> On Fri, 2017-11-17 at 15:38 +0800, Chris Chiu wrote:
>> On Fri, Nov 17, 2017 at 2:46 PM, Luca Coelho <luca@coelho.fi> wrote:
>> > On Fri, 2017-11-17 at 14:39 +0800, Chris Chiu wrote:
>> > > On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho <luca@coelho.fi>
>> > > wrote:
>> > > > Hi Chris,
>> > > >
>> > > > On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
>> > > > > Hi Luca,
>> > > > > Any suggestion for the "Failed to start INIT ucode: -110"
>> > > > > issue
>> > > > > for the firmware?
>> > > >
>> > > > There were a few problems which should now be fixed. We
>> > > > published
>> > > > new
>> > > > firmwares in our linux-firmware.git tree[1] and also made some
>> > > > fixes in
>> > > > the driver[2]. Please update your system accordingly and let
>> > > > me
>> > > > know
>> > > > if it works for you.
>> > > >
>> > > > Thanks!
>> > > >
>> > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/lin
>> > > > ux-f
>> > > > irmware.git/
>> > > > [2] https://patchwork.kernel.org/patch/10059871/
>> > > > https://patchwork.kernel.org/patch/10059875/
>> > > > https://patchwork.kernel.org/patch/10059873/
>> > > >
>> > > > --
>> > > > Cheers,
>> > > > Luca.
>> > >
>> > > Hi Luca,
>> >
>> > Hi Chris,
>> >
>> >
>> > > Thanks for your patch and updated firmware. The driver can
>> > > initialize w/o error now. However, it always fails on ip-config
>> > > after
>> > > 4-way handshake complete. I have to mention that I removed the
>> > > field
>> > > ".soc_latency" in all new iwl_cfg you added in
>> > > https://patchwork.kernel.org/patch/10059875/ to remove compile
>> > > error
>> > > based on the linux mainline 4.14.
>> > > I don't know whether if this causes the problem. Do you need
>> > > me
>> > > to
>> > > do anything for more information?
>> >
>> > That was my fault, I forgot to include one file in my commit. I
>> > have
>> > sent v2 of the two last patches to solve the problem. Can you try
>> > them?
>> >
>> > The problem you're seeing could be related to that, because we use
>> > a
>> > bit longer wait period for HW stabilization with integrated
>> > devices.
>> > And if you remove it, you may encounter random problems...
>> >
>> > --
>> > Cheers,
>> > Luca.
>>
>> Hi Luca,
>> Thanks for your quick response. I tried your v2 patch but things
>> remain the same. The signal strength and scan results seems nothing
>> wrong but still fail to get ip from DHCP server. Please let me know
>> what I can help here.
>
> Can you provide the dmesg output and trace-cmd logs as explained here?
>
> https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging
>
>
> --
> Cheers,
> Luca.
Hi Luca,
Here's the dmesg log of the fail case on DHCP.
https://gist.github.com/mschiu77/ec1a4579e6b863da68b703205cf8a0e4
Chris
^ permalink raw reply
* Re: What would it take to get WDS working with channel contexts?
From: Johannes Berg @ 2017-11-17 9:45 UTC (permalink / raw)
To: Ben Greear, linux-wireless@vger.kernel.org
In-Reply-To: <24f85baf-5e19-a2c9-517d-9b69a47860d9@candelatech.com>
On Thu, 2017-11-16 at 16:28 -0800, Ben Greear wrote:
> I have a user interested in getting WDS working on ath10k, but evidently
> this is not supported since ath10k uses channel-contexts:
>
> From net/mac80211/main.c:
>
> /*
> * WDS is currently prohibited when channel contexts are used
> * because there's no clear definition of which channel WDS
> * type interfaces use
> */
>
>
> Anyone have any suggestions as to how this could be made to work?
You probably don't want to hear this, but:
WDS isn't even properly working without them right now, since for
example there's absolutely no feature negotiation between the peers as
to which rates and other capabilities, bandwidths, etc. are acceptable
(at any given moment in time).
I therefore don't see any value in WDS mode at all unless these issues
are fixed [*], and as such wouldn't want to take any patches that just
do some minimal patching over to allow it with channel contexts.
If you ask me, WDS is entirely useless without vendor-specific
extensions to allow newer features, and the Linux "vendor-specific"
extension to do that is AP/client 4-addr mode.
johannes
[*] and since the spec doesn't define this, you can't even fix them in
any reasonable way, I think, unless you implement some vendor-specific
things that maybe one vendor happens to do.
^ permalink raw reply
* Re: ath10k_pci / qca6174 firmware crash...
From: Kalle Valo @ 2017-11-17 9:40 UTC (permalink / raw)
To: Thomas Backlund; +Cc: linux-wireless, ath10k
In-Reply-To: <6679116b-1bb3-bace-71de-5a21eea170f9@mageia.org>
Thomas Backlund <tmb@mageia.org> writes:
> I have a Lenovo Yoga 720 running linux 4.13.10
>
>
> Got a firmware crash, and a reboot was needed to get the wireless back.
>
> is this known ?
Please CC ath10k list when reporting ath10k bugs. Adding it now.
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/support
Thomas' report:
> kernel logs:
>> [22881.494830] ath10k_pci 0000:3f:00.0: firmware crashed! (uuid n/a)
>> [22881.494840] ath10k_pci 0000:3f:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 17aa:0827
>> [22881.494842] ath10k_pci 0000:3f:00.0: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
>> [22881.495227] ath10k_pci 0000:3f:00.0: firmware ver WLAN.RM.4.4.1-00051-QCARMSWP-1 api 6 features wowlan,ignore-otp crc32 c3fd4411
>> [22881.495495] ath10k_pci 0000:3f:00.0: board_file api 2 bmi_id N/A crc32 0e26ef70
>> [22881.495498] ath10k_pci 0000:3f:00.0: htt-ver 3.44 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
>> [22881.507606] ath10k_pci 0000:3f:00.0: failed to get memcpy hi address for firmware address 4: -16
>> [22881.507607] ath10k_pci 0000:3f:00.0: failed to read firmware dump area: -16
>> [22881.507609] ath10k_pci 0000:3f:00.0: Copy Engine register dump:
>> [22881.507625] ath10k_pci 0000:3f:00.0: [00]: 0x00034400 2 2 3 3
>> [22881.507637] ath10k_pci 0000:3f:00.0: [01]: 0x00034800 24 24 357 358
>> [22881.507644] ath10k_pci 0000:3f:00.0: [02]: 0x00034c00 35 35 97 99
>> [22881.507655] ath10k_pci 0000:3f:00.0: [03]: 0x00035000 2 2 4 2
>> [22881.507663] ath10k_pci 0000:3f:00.0: [04]: 0x00035400 847 847 233 169
>> [22881.507672] ath10k_pci 0000:3f:00.0: [05]: 0x00035800 0 0 64 0
>> [22881.507684] ath10k_pci 0000:3f:00.0: [06]: 0x00035c00 26 26 26 26
>> [22881.507691] ath10k_pci 0000:3f:00.0: [07]: 0x00036000 1 1 1 1
>> [22881.571157] ieee80211 phy0: Hardware restart was requested
>> [22882.260322] ath10k_pci 0000:3f:00.0: Unknown eventid: 118809
>> [22882.262835] ath10k_pci 0000:3f:00.0: Unknown eventid: 90118
>> [22882.356074] ath10k_pci 0000:3f:00.0: device successfully recovered
>
>
>
> At this point network is still broken.
>
> Here I tried to disable/enable wireless to recover network access :
> (sometimes it work, but not this time)
>
>> [23596.617062] wlp63s0: deauthenticating from 18:8b:45:02:96:cf by local choice (Reason: 3=DEAUTH_LEAVING)
>> [23602.583145] ath10k_pci 0000:3f:00.0: Unknown eventid: 118809
>> [23602.585917] ath10k_pci 0000:3f:00.0: Unknown eventid: 90118
>> [23602.642812] IPv6: ADDRCONF(NETDEV_UP): wlp63s0: link is not ready
>> [23602.655518] IPv6: ADDRCONF(NETDEV_UP): wlp63s0: link is not ready
>> [23609.249013] ath10k_pci 0000:3f:00.0: failed to receive control response completion, polling..
>> [23609.281698] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x00000001 at 0x00034430: -110
>> [23609.314384] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x00034444: -110
>> [23609.347066] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x0000001e at 0x00034430: -110
>> [23609.379755] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x00000001 at 0x00034830: -110
>> [23609.412449] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x00000001 at 0x00035430: -110
>> [23609.445129] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x00035444: -110
>> [23609.477809] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x0000001e at 0x00035430: -110
>> [23609.510497] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x0000001e at 0x00034830: -110
>> [23609.543184] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x00000001 at 0x00034c30: -110
>> [23610.977362] ath10k_pci 0000:3f:00.0: ctl_resp never came in (-110)
>> [23610.977365] ath10k_pci 0000:3f:00.0: failed to connect to HTC: -110
>> [23614.269213] ath10k_warn: 112 callbacks suppressed
>> [23614.269215] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0xffff0800 at 0x00035010: -110
>> [23614.301897] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x00035010: -110
>> [23614.334583] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0xfffeffff at 0x00035010: -110
>> [23614.367258] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003504c: -110
>> [23614.399936] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x0000ffff at 0x0003504c: -110
>> [23614.432615] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003504c: -110
>> [23614.465293] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0xffff0020 at 0x0003504c: -110
>> [23614.497976] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x00035444: -110
>> [23614.530657] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003543c: -110
>> [23614.563341] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x0d040000 at 0x00035400: -110
>> [23618.745947] ath10k_pci 0000:3f:00.0: failed to read device register, device is gone
>> [23619.277892] ath10k_warn: 143 callbacks suppressed
>> [23619.277895] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0xfffeffff at 0x00034410: -110
>> [23619.310205] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003444c: -110
>> [23619.342469] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x0000ffff at 0x0003444c: -110
>> [23619.375152] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003444c: -110
>> [23619.407560] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0xffff0010 at 0x0003444c: -110
>> [23619.440211] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x00034848: -110
>> [23619.472846] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x00034840: -110
>> [23619.505155] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x0d03e000 at 0x00034808: -110
>> [23619.537721] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0x00000200 at 0x0003480c: -110
>> [23619.570447] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x00034810: -110
>> [23624.291033] ath10k_warn: 144 callbacks suppressed
>> [23624.291036] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.323722] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.356179] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.388309] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.420669] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.453327] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.485783] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.517940] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.550562] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.582722] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23624.745569] ath10k_pci 0000:3f:00.0: failed to read device register, device is gone
>> [23626.469140] ath10k_pci 0000:3f:00.0: Could not init core: -110
>> [23626.481714] IPv6: ADDRCONF(NETDEV_UP): wlp63s0: link is not ready
>> [23650.593887] ath10k_warn: 59 callbacks suppressed
>> [23650.593889] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x00080008: -110
>> [23650.626577] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0xffffffff at 0x00080008: -110
>> [23650.680865] ath10k_pci 0000:3f:00.0: failed to wake target for write32 of 0xfffffffe at 0x00080008: -110
>> [23650.735049] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23650.767735] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23650.800425] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23650.833110] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23650.865796] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23650.898478] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23650.931164] ath10k_pci 0000:3f:00.0: failed to wake target for read32 at 0x0003a028: -110
>> [23653.871963] ath10k_pci 0000:3f:00.0: failed to read device register, device is gone
>> [23653.970010] ath10k_pci 0000:3f:00.0: firmware crashed! (uuid n/a)
>> [23653.970013] ath10k_pci 0000:3f:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 17aa:0827
>> [23653.970014] ath10k_pci 0000:3f:00.0: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
>> [23653.970387] ath10k_pci 0000:3f:00.0: firmware ver WLAN.RM.4.4.1-00051-QCARMSWP-1 api 6 features wowlan,ignore-otp crc32 c3fd4411
>> [23653.970644] ath10k_pci 0000:3f:00.0: board_file api 2 bmi_id N/A crc32 0e26ef70
>> [23653.970645] ath10k_pci 0000:3f:00.0: htt-ver 3.44 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
>> [23654.472884] ath10k_pci 0000:3f:00.0: failed to read firmware dump area: -16
>> [23654.472886] ath10k_pci 0000:3f:00.0: Copy Engine register dump:
>> [23654.603625] ath10k_pci 0000:3f:00.0: [00]: 0x00034400 4294967295 4294967295 4294967295 4294967295
>> [23654.734356] ath10k_pci 0000:3f:00.0: [01]: 0x00034800 4294967295 4294967295 4294967295 4294967295
>> [23654.865098] ath10k_pci 0000:3f:00.0: [02]: 0x00034c00 4294967295 4294967295 4294967295 4294967295
>> [23654.995839] ath10k_pci 0000:3f:00.0: [03]: 0x00035000 4294967295 4294967295 4294967295 4294967295
>> [23655.126570] ath10k_pci 0000:3f:00.0: [04]: 0x00035400 4294967295 4294967295 4294967295 4294967295
>> [23655.257293] ath10k_pci 0000:3f:00.0: [05]: 0x00035800 4294967295 4294967295 4294967295 4294967295
>> [23655.388016] ath10k_pci 0000:3f:00.0: [06]: 0x00035c00 4294967295 4294967295 4294967295 4294967295
>> [23655.518515] ath10k_pci 0000:3f:00.0: [07]: 0x00036000 4294967295 4294967295 4294967295 4294967295
>> [23655.518530] ath10k_pci 0000:3f:00.0: failed to reset chip: -5
>> [23655.518531] ath10k_pci 0000:3f:00.0: Could not init hif: -5
>
>
> --
> Thomas
--
Kalle Valo
^ permalink raw reply
* rtl8723be on Fedora27
From: Rákosi Gergely @ 2017-11-17 8:16 UTC (permalink / raw)
To: linux-wireless
Hello,
I'm trying to use rtl8723be wifi on Fedora27 but I still get continuosly
disconnection. The error in the dmesg is "Init MAC failed"
I tried with the following module options too : "fwlps=0 swlps=0" and
the variant of "ant_sel=1 or 2 or 0"
I downloaded the git files from your repo, and do the usual make,make
install, and modprobe stuffs, and then restart the notebook, but I get
the same result.
Thanks your help,
Regards,
Gergely
^ permalink raw reply
* Re: Need support for Intel new wifi module 9462NGW
From: Luca Coelho @ 2017-11-17 7:53 UTC (permalink / raw)
To: Chris Chiu
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <CAB4CAwcit2jqHXs7x2cowHdi31OH3wKnmyW4=v-6RGO-+1gjog@mail.gmail.com>
On Fri, 2017-11-17 at 15:38 +0800, Chris Chiu wrote:
> On Fri, Nov 17, 2017 at 2:46 PM, Luca Coelho <luca@coelho.fi> wrote:
> > On Fri, 2017-11-17 at 14:39 +0800, Chris Chiu wrote:
> > > On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho <luca@coelho.fi>
> > > wrote:
> > > > Hi Chris,
> > > >
> > > > On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
> > > > > Hi Luca,
> > > > > Any suggestion for the "Failed to start INIT ucode: -110"
> > > > > issue
> > > > > for the firmware?
> > > >
> > > > There were a few problems which should now be fixed. We
> > > > published
> > > > new
> > > > firmwares in our linux-firmware.git tree[1] and also made some
> > > > fixes in
> > > > the driver[2]. Please update your system accordingly and let
> > > > me
> > > > know
> > > > if it works for you.
> > > >
> > > > Thanks!
> > > >
> > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/lin
> > > > ux-f
> > > > irmware.git/
> > > > [2] https://patchwork.kernel.org/patch/10059871/
> > > > https://patchwork.kernel.org/patch/10059875/
> > > > https://patchwork.kernel.org/patch/10059873/
> > > >
> > > > --
> > > > Cheers,
> > > > Luca.
> > >
> > > Hi Luca,
> >
> > Hi Chris,
> >
> >
> > > Thanks for your patch and updated firmware. The driver can
> > > initialize w/o error now. However, it always fails on ip-config
> > > after
> > > 4-way handshake complete. I have to mention that I removed the
> > > field
> > > ".soc_latency" in all new iwl_cfg you added in
> > > https://patchwork.kernel.org/patch/10059875/ to remove compile
> > > error
> > > based on the linux mainline 4.14.
> > > I don't know whether if this causes the problem. Do you need
> > > me
> > > to
> > > do anything for more information?
> >
> > That was my fault, I forgot to include one file in my commit. I
> > have
> > sent v2 of the two last patches to solve the problem. Can you try
> > them?
> >
> > The problem you're seeing could be related to that, because we use
> > a
> > bit longer wait period for HW stabilization with integrated
> > devices.
> > And if you remove it, you may encounter random problems...
> >
> > --
> > Cheers,
> > Luca.
>
> Hi Luca,
> Thanks for your quick response. I tried your v2 patch but things
> remain the same. The signal strength and scan results seems nothing
> wrong but still fail to get ip from DHCP server. Please let me know
> what I can help here.
Can you provide the dmesg output and trace-cmd logs as explained here?
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging
--
Cheers,
Luca.
^ permalink raw reply
* Re: Need support for Intel new wifi module 9462NGW
From: Chris Chiu @ 2017-11-17 7:38 UTC (permalink / raw)
To: Luca Coelho
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <1510901207.4011.197.camel@coelho.fi>
On Fri, Nov 17, 2017 at 2:46 PM, Luca Coelho <luca@coelho.fi> wrote:
> On Fri, 2017-11-17 at 14:39 +0800, Chris Chiu wrote:
>> On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho <luca@coelho.fi> wrote:
>> > Hi Chris,
>> >
>> > On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
>> > > Hi Luca,
>> > > Any suggestion for the "Failed to start INIT ucode: -110"
>> > > issue
>> > > for the firmware?
>> >
>> > There were a few problems which should now be fixed. We published
>> > new
>> > firmwares in our linux-firmware.git tree[1] and also made some
>> > fixes in
>> > the driver[2]. Please update your system accordingly and let me
>> > know
>> > if it works for you.
>> >
>> > Thanks!
>> >
>> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-f
>> > irmware.git/
>> > [2] https://patchwork.kernel.org/patch/10059871/
>> > https://patchwork.kernel.org/patch/10059875/
>> > https://patchwork.kernel.org/patch/10059873/
>> >
>> > --
>> > Cheers,
>> > Luca.
>>
>> Hi Luca,
>
> Hi Chris,
>
>
>> Thanks for your patch and updated firmware. The driver can
>> initialize w/o error now. However, it always fails on ip-config after
>> 4-way handshake complete. I have to mention that I removed the field
>> ".soc_latency" in all new iwl_cfg you added in
>> https://patchwork.kernel.org/patch/10059875/ to remove compile error
>> based on the linux mainline 4.14.
>> I don't know whether if this causes the problem. Do you need me
>> to
>> do anything for more information?
>
> That was my fault, I forgot to include one file in my commit. I have
> sent v2 of the two last patches to solve the problem. Can you try
> them?
>
> The problem you're seeing could be related to that, because we use a
> bit longer wait period for HW stabilization with integrated devices.
> And if you remove it, you may encounter random problems...
>
> --
> Cheers,
> Luca.
Hi Luca,
Thanks for your quick response. I tried your v2 patch but things
remain the same. The signal strength and scan results seems nothing
wrong but still fail to get ip from DHCP server. Please let me know
what I can help here.
Chris
^ permalink raw reply
* Re: Need support for Intel new wifi module 9462NGW
From: Luca Coelho @ 2017-11-17 7:23 UTC (permalink / raw)
To: Chris Chiu
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <1510901207.4011.197.camel@coelho.fi>
Here are the links to v2 of the last two patches, please try with these
instead (keep the first one that you already have):
https://patchwork.kernel.org/patch/10060837/
https://patchwork.kernel.org/patch/10060839/
--
Cheers,
Luca.
On Fri, 2017-11-17 at 08:46 +0200, Luca Coelho wrote:
> On Fri, 2017-11-17 at 14:39 +0800, Chris Chiu wrote:
> > On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho <luca@coelho.fi>
> > wrote:
> > > Hi Chris,
> > >
> > > On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
> > > > Hi Luca,
> > > > Any suggestion for the "Failed to start INIT ucode: -110"
> > > > issue
> > > > for the firmware?
> > >
> > > There were a few problems which should now be fixed. We
> > > published
> > > new
> > > firmwares in our linux-firmware.git tree[1] and also made some
> > > fixes in
> > > the driver[2]. Please update your system accordingly and let me
> > > know
> > > if it works for you.
> > >
> > > Thanks!
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux
> > > -f
> > > irmware.git/
> > > [2] https://patchwork.kernel.org/patch/10059871/
> > > https://patchwork.kernel.org/patch/10059875/
> > > https://patchwork.kernel.org/patch/10059873/
> > >
> > > --
> > > Cheers,
> > > Luca.
> >
> > Hi Luca,
>
> Hi Chris,
>
>
> > Thanks for your patch and updated firmware. The driver can
> > initialize w/o error now. However, it always fails on ip-config
> > after
> > 4-way handshake complete. I have to mention that I removed the
> > field
> > ".soc_latency" in all new iwl_cfg you added in
> > https://patchwork.kernel.org/patch/10059875/ to remove compile
> > error
> > based on the linux mainline 4.14.
> > I don't know whether if this causes the problem. Do you need me
> > to
> > do anything for more information?
>
> That was my fault, I forgot to include one file in my commit. I have
> sent v2 of the two last patches to solve the problem. Can you try
> them?
>
> The problem you're seeing could be related to that, because we use a
> bit longer wait period for HW stabilization with integrated devices.
> And if you remove it, you may encounter random problems...
>
> --
> Cheers,
> Luca.
^ permalink raw reply
* Re: Need support for Intel new wifi module 9462NGW
From: Luca Coelho @ 2017-11-17 6:46 UTC (permalink / raw)
To: Chris Chiu
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <CAB4CAwfg73wRoNca2GBaMn4eN04vf+uR3xdzYO0UWG1Nmaqo=w@mail.gmail.com>
On Fri, 2017-11-17 at 14:39 +0800, Chris Chiu wrote:
> On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho <luca@coelho.fi> wrote:
> > Hi Chris,
> >
> > On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
> > > Hi Luca,
> > > Any suggestion for the "Failed to start INIT ucode: -110"
> > > issue
> > > for the firmware?
> >
> > There were a few problems which should now be fixed. We published
> > new
> > firmwares in our linux-firmware.git tree[1] and also made some
> > fixes in
> > the driver[2]. Please update your system accordingly and let me
> > know
> > if it works for you.
> >
> > Thanks!
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-f
> > irmware.git/
> > [2] https://patchwork.kernel.org/patch/10059871/
> > https://patchwork.kernel.org/patch/10059875/
> > https://patchwork.kernel.org/patch/10059873/
> >
> > --
> > Cheers,
> > Luca.
>
> Hi Luca,
Hi Chris,
> Thanks for your patch and updated firmware. The driver can
> initialize w/o error now. However, it always fails on ip-config after
> 4-way handshake complete. I have to mention that I removed the field
> ".soc_latency" in all new iwl_cfg you added in
> https://patchwork.kernel.org/patch/10059875/ to remove compile error
> based on the linux mainline 4.14.
> I don't know whether if this causes the problem. Do you need me
> to
> do anything for more information?
That was my fault, I forgot to include one file in my commit. I have
sent v2 of the two last patches to solve the problem. Can you try
them?
The problem you're seeing could be related to that, because we use a
bit longer wait period for HW stabilization with integrated devices.
And if you remove it, you may encounter random problems...
--
Cheers,
Luca.
^ permalink raw reply
* Re: Need support for Intel new wifi module 9462NGW
From: Chris Chiu @ 2017-11-17 6:39 UTC (permalink / raw)
To: Luca Coelho
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <1510825750.4011.179.camel@coelho.fi>
On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho <luca@coelho.fi> wrote:
> Hi Chris,
>
> On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
>> Hi Luca,
>> Any suggestion for the "Failed to start INIT ucode: -110" issue
>> for the firmware?
>
> There were a few problems which should now be fixed. We published new
> firmwares in our linux-firmware.git tree[1] and also made some fixes in
> the driver[2]. Please update your system accordingly and let me know
> if it works for you.
>
> Thanks!
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/
> [2] https://patchwork.kernel.org/patch/10059871/
> https://patchwork.kernel.org/patch/10059875/
> https://patchwork.kernel.org/patch/10059873/
>
> --
> Cheers,
> Luca.
Hi Luca,
Thanks for your patch and updated firmware. The driver can
initialize w/o error now. However, it always fails on ip-config after
4-way handshake complete. I have to mention that I removed the field
".soc_latency" in all new iwl_cfg you added in
https://patchwork.kernel.org/patch/10059875/ to remove compile error
based on the linux mainline 4.14.
I don't know whether if this causes the problem. Do you need me to
do anything for more information?
Chris
^ permalink raw reply
* wlcore: wl18xx: Trouble suspending caused by wifi being enabled?
From: John Stultz @ 2017-11-17 4:51 UTC (permalink / raw)
To: Kalle Valo, Maxim Altshul; +Cc: lkml, linux-wireless
Hey Folks,
So, for awhile recently, I've noticed my HiKey board (which uses the
TI WL1835MOD chip for wifi) has had trouble when it tries to suspend.
Basically it keeps on waking up while suspending, and then
re-suspending over and over until it lucks out in whatever race is
going on and manages to suspend before the wifi wakes it up.
Here's an example suspend-immediate-wake cycle:
[ 241.975754] PM: suspend entry (deep)
[ 241.979590] PM: Syncing filesystems ... done.
[ 241.997363] Freezing user space processes ... (elapsed 0.003 seconds) done.
[ 242.007903] OOM killer disabled.
[ 242.011157] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[ 242.020715] Suspending console(s) (use no_console_suspend to debug)
[ 242.028155] wlan0: deauthenticating from 70:3a:cb:12:90:28 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 242.029797] dwc2 f72c0000.usb: suspending usb gadget configfs-gadget
[ 242.029885] dwc2 f72c0000.usb: dwc2_hsotg_ep_disable: called for ep0
[ 242.029893] dwc2 f72c0000.usb: dwc2_hsotg_ep_disable: called for ep0
[ 242.071475] wlcore: down
[ 242.071795] queueing ieee80211 work while going to suspend
[ 242.071808] wlcore: down
[ 242.072120] queueing ieee80211 work while going to suspend
[ 242.073796] PM: Wakeup pending, aborting suspend
[ 242.073810] PM: Some devices failed to suspend, or early wake event detected
[ 242.091277] mmc_host mmc2: Bus speed (slot 0) = 24800000Hz (slot
req 400000Hz, actual 400000HZ div = 31)
[ 242.128593] mmc_host mmc2: Bus speed (slot 0) = 24800000Hz (slot
req 25000000Hz, actual 24800000HZ div = 0)
[ 242.129197] dwc2 f72c0000.usb: resuming usb gadget configfs-gadget
[ 242.337364] dwc2 f72c0000.usb: new device is high-speed
[ 242.413119] dwc2 f72c0000.usb: new device is high-speed
[ 242.452173] wlcore: PHY firmware version: Rev 8.2.0.0.237
[ 242.484959] dwc2 f72c0000.usb: new address 8
[ 242.499012] wlcore: firmware booted (Rev 8.9.0.0.70)
[ 242.506240] configfs-gadget gadget: high-speed config #1: b
[ 242.627752] OOM killer enabled.
[ 242.630899] Restarting tasks ... done.
[ 242.647180] PM: suspend exit
Eventually it will luck out and manage to suspend itself, but it can
take close to a minute. If I disable wifi the system reliably
suspends every time.
This used to not be the case, but its been so long, I'm not really
sure when this issue cropped up.
I wanted to see if anyone else had similar trouble or maybe had ideas
how to chase this down?
thanks
-john
^ permalink raw reply
* What would it take to get WDS working with channel contexts?
From: Ben Greear @ 2017-11-17 0:28 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
I have a user interested in getting WDS working on ath10k, but evidently
this is not supported since ath10k uses channel-contexts:
From net/mac80211/main.c:
/*
* WDS is currently prohibited when channel contexts are used
* because there's no clear definition of which channel WDS
* type interfaces use
*/
Anyone have any suggestions as to how this could be made to work?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* ath9k: Question regarding adaptivity and ETSI compliance
From: Florian Hercher @ 2017-11-16 19:44 UTC (permalink / raw)
To: linux-wireless
Hi all,
ETSI EN-300-328 in version 2.1.1 (2016-11) requires an "adaptive" behaviour of
Wi-Fi Access Points, see clause 4.3.2.6.1 and annex B.7. As far as I
understand this adaptive behavior requires the Wi-Fi card to stop transmitting
whenever an (non Wi-Fi) interference signal with a power level of more than
-70dBm/Mhz is present.
Does ath9k comply with this requirement? Or more specifically: Does ath9k
running on a AR9331 (MAC version: AR9330, MAC revision: 1) comply?
Right now I'm trying to understand the "clear channel assessment" (CCA)
related settings in the driver and I would like to ask for some clarification:
The CCA related definitions in ar9003_phy.h e.g.
"AR_PHY_CCA_MAX_GOOD_VAL_9300_2GHZ" - are they part of the "higher" CCA
function, where still decodable Wi-FI signals are handled?
Where is the energy detection threshold defined, is it "thres62" in "struct
ar9300_eeprom"?
I'm quite confused about this and any help is highly appreciated!
best regards
Florian
---
http://www.etsi.org/deliver/etsi_en/300300_300399/300328/02.01.01_60/
en_300328v020101p.pdf
^ 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