* Re: [PATCH] ath9k: remove set but not used variable 'acq'
From: Toke Høiland-Jørgensen @ 2019-02-25 9:50 UTC (permalink / raw)
To: YueHaibing, QCA ath9k Development, Kalle Valo
Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
In-Reply-To: <20190225033246.127410-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> writes:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
> drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
> variable 'acq' set but not used [-Wunused-but-set-variable]
>
> It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
> and airtime APIs"). Also remove related variables.
Ah, right, seems I forgot to clean that up. I wonder why I didn't get a
compiler warning for it. Anyway, nice catch :)
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
-Toke
^ permalink raw reply
* Re: [PATCH] ila: Fix uninitialised return value in ila_xlat_nl_cmd_flush
From: David Miller @ 2019-02-25 5:55 UTC (permalink / raw)
To: herbert
Cc: dan.carpenter, kbuild, kbuild-all, linux-wireless, johannes.berg,
netdev
In-Reply-To: <20190223053047.tiwcuvs6tcg2htie@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 23 Feb 2019 13:30:47 +0800
> This patch fixes an uninitialised return value error in
> ila_xlat_nl_cmd_flush.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Fixes: 6c4128f65857 ("rhashtable: Remove obsolete...")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: FW: [PATCH] ath10k: fix return value check in wake_tx_q op
From: Yibo Zhao @ 2019-02-25 4:40 UTC (permalink / raw)
To: Kalle Valo; +Cc: erik.stromdahl, linux-wireless, ath10k, linux-wireless-owner
In-Reply-To: <87sgwz8ylw.fsf@kamboji.qca.qualcomm.com>
在 2019-02-07 22:25，Kalle Valo 写道：
> Yibo Zhao <yiboz@codeaurora.org> writes:
>
>> We have met performance issue on our two-core system after applying
>> your patch. In WDS mode, we found that the peak throughput in TCP-DL
>> and UDP-DL dropped more than 10% compared with previous one. And in
>> some cases, though throughput stays the same, one CPU usage rises
>> about 20% which leads to 10% in total CPU usage. With your change, I
>> think driver will try its best to push as many packets as it can.
>> During this time, the driver's queue lock will be held for too much
>> time in one CPU and as a result, the other CPU will be blocked if it
>> wants to acquired the same lock. Working in this way seems not
>> efficiency.
>>
>> So I think it is better to revert the change till we come up with a
>> new solution.
>
> I don't think reverting is a clear option at this stage because that
> again creates problems for SDIO. IIRC without this patch SDIO was
> sending one packet a time (or something like that, can't remember all
> the details right now).
>
Below is the aqm result after 1 min test with Erik's patch.
target 19999us interval 99999us ecn yes
tid ac backlog-bytes backlog-packets new-flows drops marks overlimit
collisions tx-bytes tx-packets flags
0 2 0 0 5342229 0 0 0 0 3867657029 5342229 0x0(RUN)
1 3 0 0 0 0 0 0 0 0 0 0x0(RUN)
2 3 0 0 0 0 0 0 0 0 0 0x0(RUN)
3 2 0 0 0 0 0 0 0 0 0 0x0(RUN)
4 1 0 0 0 0 0 0 0 0 0 0x0(RUN)
5 1 0 0 0 0 0 0 0 0 0 0x0(RUN)
6 0 0 0 2 0 0 0 0 144 2 0x0(RUN)
7 0 0 0 2 0 0 0 0 282 2 0x0(RUN)
8 2 0 0 0 0 0 0 0 0 0 0x0(RUN)
9 3 0 0 0 0 0 0 0 0 0 0x0(RUN)
10 3 0 0 0 0 0 0 0 0 0 0x0(RUN)
11 2 0 0 0 0 0 0 0 0 0 0x0(RUN)
12 1 0 0 0 0 0 0 0 0 0 0x0(RUN)
13 1 0 0 0 0 0 0 0 0 0 0x0(RUN)
14 0 0 0 0 0 0 0 0 0 0 0x0(RUN)
15 0 0 0 0 0 0 0 0 0 0 0x0(RUN)
we see no difference between tx-packets and new-flows.
Whereas if we revert the patch, we get：
target 19999us interval 99999us ecn yes
tid ac backlog-bytes backlog-packets new-flows drops marks overlimit
collisions tx-bytes tx-packets flags
0 2 0 0 2233059 3 0 9236 12 1159661783 6380867 0x0(RUN)
1 3 0 0 0 0 0 0 0 0 0 0x0(RUN)
2 3 0 0 0 0 0 0 0 0 0 0x0(RUN)
3 2 0 0 0 0 0 0 0 0 0 0x0(RUN)
4 1 0 0 0 0 0 0 0 0 0 0x0(RUN)
5 1 0 0 0 0 0 0 0 0 0 0x0(RUN)
6 0 0 0 1 0 0 0 0 144 2 0x0(RUN)
7 0 0 0 1 0 0 0 0 282 2 0x0(RUN)
8 2 0 0 0 0 0 0 0 0 0 0x0(RUN)
9 3 0 0 0 0 0 0 0 0 0 0x0(RUN)
10 3 0 0 0 0 0 0 0 0 0 0x0(RUN)
11 2 0 0 0 0 0 0 0 0 0 0x0(RUN)
12 1 0 0 0 0 0 0 0 0 0 0x0(RUN)
13 1 0 0 0 0 0 0 0 0 0 0x0(RUN)
14 0 0 0 0 0 0 0 0 0 0 0x0(RUN)
15 0 0 0 0 0 0 0 0 0 0 0x0(RUN)
new-flows are roughly one-third of the total tx-packets.
IMHO, with Erik's change, Erik's change has changed the way fq's
schedule behavior and it looks like there is no other packets in the fq
after a packet has been dequeued. And as a result, this flow's deficit
will be refill and then removed from fq list at once in the same CPU.
And during this time, the other CPU could be blocked. When new packet
comes, same thing happens. So we get equal new flows and tx-packets.
Things would be different without Erik's change. After a packet has been
dequeued, this flow's deficit will not be refill immediately in
CPU0. It is possible that the deficit to be refilled in CPU1 while at
the same time CPU0 can fetch data from ethernet. So we can see more
tx-packets delivered to FW from aqm.
> Why does this happen only WDS mode? Did you test other modes, like AP
> or
> client mode?
AP mode has same issue. UDP throughput drops more than 10%. As for TCP,
CPU usage rising a lot although throughput stays similiar.
So, I'd say Erik's change does not work for us.
--
Yibo
^ permalink raw reply
* [PATCH] ath9k: remove set but not used variable 'acq'
From: YueHaibing @ 2019-02-25 3:32 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo
Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
variable 'acq' set but not used [-Wunused-but-set-variable]
It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
and airtime APIs"). Also remove related variables.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 285a62d3019d..4e97f7f3b2a3 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1006,9 +1006,6 @@ static void ath_rx_count_airtime(struct ath_softc *sc,
struct ath_rx_status *rs,
struct sk_buff *skb)
{
- struct ath_node *an;
- struct ath_acq *acq;
- struct ath_vif *avp;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
@@ -1019,7 +1016,7 @@ static void ath_rx_count_airtime(struct ath_softc *sc,
int phy;
u16 len = rs->rs_datalen;
u32 airtime = 0;
- u8 tidno, acno;
+ u8 tidno;
if (!ieee80211_is_data(hdr->frame_control))
return;
@@ -1029,11 +1026,7 @@ static void ath_rx_count_airtime(struct ath_softc *sc,
sta = ieee80211_find_sta_by_ifaddr(sc->hw, hdr->addr2, NULL);
if (!sta)
goto exit;
- an = (struct ath_node *) sta->drv_priv;
- avp = (struct ath_vif *) an->vif->drv_priv;
tidno = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
- acno = TID_TO_WME_AC(tidno);
- acq = &avp->chanctx->acq[acno];
rxs = IEEE80211_SKB_RXCB(skb);
^ permalink raw reply related
* [PATCH] rtl_bt: Update firmware for BT part of RTL8822C
From: Larry Finger @ 2019-02-25 1:12 UTC (permalink / raw)
To: linux-firmware; +Cc: linux-wireless, Larry Finger, netdev, Max Chou
The file was sent to me by Max Chou <max.chou@realtek.com>.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Max Chou <max.chou@realtek.com>
---
WHENCE | 2 ++
rtl_bt/rtl8822cu_fw.bin | Bin 22412 -> 41588 bytes
2 files changed, 2 insertions(+)
diff --git a/WHENCE b/WHENCE
index 853990b..351b312 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3254,6 +3254,8 @@ Files rtl_bt/rtl8822b_* came directly from Realtek. These files are
updated on April 14, 2017.
Files rtl_bt/rtl8821c_* and rtl_bt/rtl8723d_* came directly from Realtek.
File rtl_bt/rtl8822cu_fw.bin came directly from Realtek.
+updated on February 24, 2019
+File rtl_bt/rtl8822cu_fw.bin came directly from Realtek.
--------------------------------------------------------------------------
diff --git a/rtl_bt/rtl8822cu_fw.bin b/rtl_bt/rtl8822cu_fw.bin
index 558037c14cb51243528cfb433c6ad4a829b716f7..9a43075277f8a01ab00e9d78a4e33e87d258e8a8 100644
GIT binary patch
delta 22071
zcmb8X3tUuX{y%=s%$W-?z+nJEyp4bt5R<FgX4?R2UO>@qhP8VJqysZ&pwRl(w(XqE
z%35sEu{5jiZyeAJ(8U?Bc7L@$0_{TTB6PLwx0F~o3_74@?e}Z^-k&p!+WvO`um2BT
z&+|E#=XuU^`FuXl=k`q9AK6PsRg2eFSfouA<(2WzKBreRETdvL#=nT0ma!z0VHo*V
zWcMRo`@34MDNFU3_oR9YayRG7AEkKBA35vTiQ7-bCkm%$d1rfs)3d#D;13OI>q=jp
zPY$f^+TK0Yar<oH^i1z8kDO?jFPvr)-}xm|q1nY;P?s|mgMZ`YyBVW=C(?%>@$#!N
zM)_b5FY|Fmx&3oqUL0wZZ~c^)>!XbF6TQ6rR<u#xev+3faeph|2PiieunsWI&C81t
zjIw~XzQVJQCm7`)Px4dcOQ@9gS6*IMg2HJ0xA@3e+&>EVkn?HQIq~cvUS5c*>_J}6
zz$Z2PcsUpFHD{J8mVME=M75HA(z{*dRIB>`=AEfcV%g`t`8tun8~Oz*_I>Bq;s3#Q
zIq!|w9`kIPxr@aNXnD2O+$ATz<ovIQzoW#LhUU5Nr=>_U`P_{&E%Dx>A=a9b!rE*@
zv6!3vSwgp*IF`j!$cYD){3WM1^7p8BThye9FQu{41dpjZf~S&HX1t_xV^kIUyz{H5
z{AkM@rXp;YzMi?D!OY(5oEzPRPLD*tqGGGO+l<Y6mT}%ZX$E_b^VgFWuxFjSCe3BP
za2}hK!mf3mo0P{6I;Txu!1B&}Cf~v?aXKfjpUO&O_HDivU&qMmuB-MsU!He*Ahvq>
z_r@CTV@;paFlBXeN~%{l{l9Hx-6`JRo=&t0flb}X-bYR+dmlxT1H$Qb&L^g<pE2+y
zFLPMyw{J+y7q~yo%YLLEkT~zvDSu_zQ_d69a>7n!Y;RCwu$A60(_>oQ$;?Ada-z%m
z+{`&)Co|m#Ht&`bPdeY3nY=bx@7d-vf2sEffi@I5nfdCTAaW5Jw78g7hT$3JPez&0
zSK~1U-d0MzG+v6Sxc*KEG}1d~)~t!Qoy=@%8b{Lcx?!Fd_E7tOY0`TzA#T<t`M6|l
z8$C<3UoT7FZSy`iE0$$XI$xVTH{ncHIF|^zVI;G!QM_N=+0>5D0Apr95&nKw(Rmu?
zSeCOg?ZCXSjI0hhF*<X*C?{^oU@FG!DQN$$j0MHXZLX2YcDiONOl=(_99=taOTUH9
zcRrq8KI;#7E+?+d-YkYl%XDv$6lmO-x=ecil2bG1cJ?`E@thIIpR(ym^gPOUDJT_0
ztQVB)KO^U_jZ>X2CuS?<2{p&;5#zlIzoA$9P_NLF>nrd97Q6@Pb0njjw5UI#be6(V
zobO~bu$<E}_i^@a?^kp85)C;rZ%6)q=G@5E*~bSNn<kkiqTR`6rJAf8L}RZ?yoYBW
z3KP`RRS!i7(fnLb*f$*`rS333-TBx2IkBcT&Bv}0gS2~C_ldUWA9nT<?|d?=%InYC
zsRETenTthnZd)?Zc_=puUwS7uft}#|B=>c8lk<tZ<@D{myVzaMDf81b&(Ah@nVgo}
zW1YX6AH^m(?eixge{TM+h{_zMg0=CW+2@^e7EEF*owqNzI&oJzBSr9W9@(u=6*`Hk
zjUJ-t_nr4IoR0P#3%5lPxAP<2)tvI|=--@4H>a{YoVVQ^Kl>_JoCO@|osW6>p-+%-
z{q!kbZk=J2qfGCbGffNw$T%OoInjX&ImPs#L=WiYY!m-{n#s(hn_6bfG40B~$;6wf
z%>406R3^)0(q@}xF*&9lN49AuU_Iarz!Jbzz;*U)QwqHYOs4mM|MIy5FQ!vPKoj5x
zfYSiC0!{^71~>(<18_2+3^)nU444GCJ2Kle5pW$~B47_-0$@Gh1i%u&c)$+;;{dk;
z#sV$_Gy*z0a1nzG8IT7w14aXWuF5t=0qzEj1Y8Gb0PF#b0IUZL2P^>$1N;C`54aUj
z2e=GS3)lgu0h9qbKr^74-m}>z6_evIb>M=f0)Pw^U@^TaS`H?F2lcDfL0AJA&Zz3+
ze_#SK;EO-xGEDz`=F3Na!K{%MGL-@oD8utBKWxx~D3t46xSq+Vv<pEH41@A#7BV)0
zF)<~qiD6YHX6h}snP#e0xHB^hQ@}9nV!)-$7G@dK!>qt{5z;EAo+)AUb!!<W=}z3=
z%`m2Q4CDOnmXsMO9V#{zX$I0vq*+L_kuY#}Izg0WoC%9kVwP~V>SFbS>QZ&Jda7Dd
zS9n)0ie&ZGB@EMD`?%g|x%Jo12XEDE&*buQz~FMm1%qq|2H767kEzJ^W<w~*_U0hZ
z8P9WZo$FQd?N#}X8ErGX@|QE(W+I=d<d7iTYS2&JkQ}J#O!20mLW(yPdFpsR1J^T@
z52Si;xK^Hwv%mkv%fA96z7Hu4n|gdBFK>!9%Fng%a+|>@Uw(s^8ORV<*I}oh4f$XO
z;OE%!D^cO{UPu8DD9!=~Q0d-3@^T}DiRBP5HlXZdfRoptu?CPc4?zTQ5O6M}h*P-!
z0dfWF{qdLgu#<(ijB?^Hf}4-}hW_o#WMyanymii2bDSm>g^HXXnhT?NT*V;8Ayu_I
zlk$HVe#329{x8Bt&=*ZBFPoebvntekFNT4?O?Tc@uuAv#UwHY}LY?!of-KeCKRUw;
zr>aI8z3GL5O3hrJ46b*Z+I%_I`PU^`b6seD!<)fR8OJ{t1!zE`!HzeDF7R@+bMDf|
zArHK<^tSK`c%O)bu8l73Oise(J8z*c;8M4~%E-k?Gy-aZn%{od`RVO{4!;-E7<}yA
zvur+_Kvk}{#LM@G>EtE*c<29ExWt*UVzz_9+Hpw4CBp&7Zi`Wt<-_k7WfKqcgnMgG
zhePfN_db9mAw7CJ{D#?ODz+R#*P3|wFqW$L058X2y^rB~%{#pOU*%zC`ct}|*jDpy
zwRET5>|?8A4zo4I7tAk@U76;vNf)@j&<iSZw^D?2GB2wF42nq?lxKr%HN>s$Iz{06
zt=1^ZNMT-Kbaw-5-R2WU*LCT<I-sh~tM^o%)+09!LIAEH9D4^y*{Z=*0`>r&0Ad<|
zH&@FYnzHK~?}YTIBj)`@L(wT`_lx_N?|)|hf&Jb4<y==@$Nb{+!+t$RZ68+ix}S}n
zKG2#Aq<&2;Z~ITR{Eza8vhY)3J#noNTwH9`m~F04BB`z;#+%{O^l5vyi&yQ770E8L
z3QcjRB9#WIc!p1#9PWvLcsE%Q?;>`EZx6$mwGcAtLm^~Y^1NF9JjW<^01rdTKu{$}
z!yKe}mE6-GsBrfOwzxY+7`yWjo5)UgzRyl^BzffSq_#;O#wMRm@?igj{5-MEd_0(h
zqt~Ge&saO<%G;w8X;M3X#JajbqEGx!=n$aqd=E$#Fs&^p&{IblC^aUa=ZV80d5|mN
zBoP`YVCpr5d>aqmLi#h(WTZ(*Q=Lz&oTEDXma}Q4l_T15ZYfG-|Kfe4=-2G@BHR-J
z_uqv%r|X3fy8w?Obs%**(^mbOH8`JJWpfaH-ORF#N%O#6&-sJcT-LZ)9Fsm>SvM56
zo)<X7h8+8V@cV}b7(Y{yz}&*bG7hE?IsH##80#8dWix*tU!BjFySX{6G|MZ0q~Uez
zXSA^vtxY)2*t*0VKE>P7tg_8R8P&!Jf!i1@up8A&1<uA)&)}zcUv2)fIf9?;b&YIo
zc8$E(tl=km&4I1W=D>T+9rHWpZ#&P~V)!^ncSjq|fh~=Yb<a!wt+_|>Cerz%X3_*g
zJe9;+L((SA*AIVj9$8)MQ0S}2(5jM{>If8T6<I6S8}8BcYI|78bx~KXxsp&r82ghw
zq_5<&Du!kxgiOIU#wzOunanY3-U=qOc(7GeNeY!$Q+r|K?a3G8&|YGVHq@R&p~o8=
z`>{N-%y25A$NVZMGHV|ZsQRs_p5Joe%Css@0*3br-*eTK-^bM~RGOijsmMQ2bdI+c
zol~a)TbFD39FM6948poFtLR*o*W7%QZ*p>`BG~KumMA=;V}z}73|%O?fC|<OU-5->
z<@FMKdIeQ1y0Ba%ZliaaKC&E8TP5GDbZAKp+EjDbbg%i#>B?uPdjvNty)ZO!j?g)+
zb(+Vt$Gn@mV?MW83|_G|t}oK7?bY<LlKef7@lULwnfb{c?;Tqu$#!!?^KhN-Ae3-(
zSL80k_K14c%3RQuho+Y}G_4q6dWduV0pwCoTjLOx0ndxT%@%8oUT?_}mFlv=X}crO
zL7Nc~fC*{mc19k6j*+_1DE|@nZAc!ZRy-%}A0mMLEOVq4_mOx<I|h9_NyQwg=OEkS
zp0<J`NYO~4{)LER%&POkkkGKo&tZx*&S`f>I;aiWm_n=itVd`Hx2_*z)6Wj_KDIW>
zvc<EuNuB<bS7_FxJmtj{b;*!O7~AhWwcRpUjL^wgU89M%M}1GU8Helxu0U;rW+P`|
zZI6QWXnA%877N;4c&Xp=h_WOP;~RLk(I~J^F(Pu(gI)%$l8`TSS3}Hatzo??p0S60
zB02vMk>C(-c+Xn($~*lhWv%7|Xr(qw2z^0SYW^VIa=+KyFeb4p>U_BGTJP0cR4^Qr
zDqki>7&Ii@gL_tDtmY3?z~4K8za<_s5JlTt4A?)K2>b<E^{)1qvw;b#yp{&W%BHZ^
zVy~-#kyZ_>X232Xt?;DoQ3I*j>1@^QUSZ^~4Z_IbhAih@hBWpTr^7JOF(1uE`6j35
zdGfsT-|TRk0+(KQjVx|32R1Ye`|Lhad|P}ceG%#NJmw~Sx_*Z?J?uqpt~w(YHPy*;
z(9u~^GTN?gNbxY829GJQvC|aD?PP3_<+`yYHqGA1u4FOcLU#~72|1Yx;-4EFz?Bd#
z5nh%24blZ99%9vme<ZMw5JGrE9C|7eap{-6y!;hX2!}4s4dNByDB<iOB*H<$SHj0m
zToWDzS&g~zHXHM*<jbseln5!coP|b_A{FrowNowFx<*#HRi#S=Ri-L)CeifwOeXWa
zI@9c{7gIbK2X-v3H(B9HD(NRXb158DnN$N?Pwi~W6pz6-E1A$`62?CX^@*O7lm$kv
z+)boADbd3@#v6-9W1Lmn%PP%H!Rk(^F)CGnX;zj8&W#&;XcRO`P^&_@Gy~8J7@D0H
z$QC358~~)*p_zh|cugdj(`tr5P;_qEbjF5Zf-)RwUJjgvJ}g``;IoM}By0a<uX7!8
z^|)5MhFo^nbqQn|-r0vU_^BS1ZDOl=PeFD;w&c?%!}irdBV?r{*sUUYj87RSEFl;>
z*+U3&C`B`8z+l0_2%VSo3Kyp-qoqCOC;N@^1_?DZg3ub1fb%wNJT$VOkJfo4D%D~B
zGBn3T(9CF(<Z7ZXOT&@FW}h@XK{0R`e0(xvjl-ykqt=V2(J*{IzJ^ymPx*DbS`}mm
zk}dy&PLMpoz-mezxRI${6N)sL=ZD^QR^R=IS{My;es}lW%CnGtzj`IeAm;*pFz@<c
z!hWZd^U-KfdAw1He12Ss+zhzuUnr3byQ+Qyt5R8i+Y8m~z@yhxvnh`MF4vW5d)8pk
zYrJb(gNEA@a6|A846DRb;;lSg;;lkj11Sw<lzc7nwccQU2d?k%2J<^{eW#c5{y@H~
zKOnfw*>+!lpv)!Y2sy<={eeOk^F2M&2MFCIhp!-~KVa_Y4_G>w?+dcaa94)A!j8q>
zC1_^Jc)k?Za-haVmSc%5#~qB-G_tHC-<yv&`Q8HL1><=kt_!`vd@-&UdxQB6?J0v>
zg51GW-1s3=z~M4m?Y<|(k}gx=cP>-l*BvV5{!ZNgs^eCrVld}yi$D*$U0TQ!9GKJW
zv%FjeG4eqqvhls~70l6~xQC!Q9z>dsv<2GYVW=IC0#-roxX*!$HMm#@>F_d;v;`aN
zSuisWx@Q(d{|u;;_d@h1)iVt`Y9`dqiGY_-?@8cF8>yZ9d3iU;_Z&X36(76{AE-pV
zcc9Y*Ajeh!k{Y@lHdKb{!>&r|>s;tNj!n3T{G6BjsYeiozc>M92o3x<>8NNhQ*V^*
z=-3ng#mEcsk<hNX++%Sw)|ffV+SUxnjmx~nXXMdmy0CA7`D;oqS@Oa3$~rf6CiD4+
z^IO+^UEJT=Adf!K*fMlm`(0;U``8sNL%4Sw4OSSo{G#m^OfG9zm4*q+4#=ZRKU|J{
z*@t(!<k1!H-sH)5>ymTYvf5!t@M)@(#o5V>Ez9#@cb12()bui7gj|nCl1HajKXoy_
zW-dxyv8Q;-F0FGLV1`X;OT!bDeX0i^ZIVYH?3PC>0Ug-!N3CvobW^8^pXx1X1|yKJ
z*lDjV`G~}*B(J7VBe_PS&}?jtzAvHGJgDu}JGoQZQ(%I46I1=oWlfEF5VdTa$I^MD
zJQcvQ-giJJZ@Jqj=Pm?G09yzLC!Tw=R*nOFBNm3eb$^CtJ;2Lzm+Iu_exa3}{7vhk
zF5&HDNJbKNqB_p`$W2odB2bw$1jeQY;+X~+D^n5vmeJXK({cwDr=qyO#=424VmMV0
zWh%|Sx^s!=CV1T<QyuRy4qE!LGwm)D*X(9jM5MoN25;+Qq+5%lj}Si_5w*^U^at`Z
z)^)?%cN;v$;jP7H-=RFl#wL&1f(*A%Bo%Kbgfwix4*BXawLBb9%iF=UzTOj5T{LKl
zOrac>;nB{ZCh+h{PMHa^Itz_jh`6fSI198%w>sTGf(2M@nAhB;B&sik1-Am|5-j$$
zkUpWuK*NyIT2=B}dWTUaMy5#r6_M#-UQ=Le1LP3DE>+hi9MyS+SIk3PFSkPnzY<se
z?y6uXsFAmU;QudmZyv8p9}m^lI!<YN#;Q0mW3c5Mn-*!}J+z^WVLQ<W80+*RX}EY8
zquZnB!#!it^dg~&Ms?-NG-w6VaJ@*%$zc(^WV=S;CMK+W9j5l`!RyMoud(9Qv_?+6
z+vCq&KEU;w0;?KSwQ?ZAvh{$&6ewzV0emqgowb^eZ9RZBx0(X24eR_xZARa7-)waq
z^3TjL1)L3R5%R7E7bms&HF&a9d9t(171-rgZHlw(-L1dG<DE9u6?ndhEkfQM#>b2>
zR36Xjm1p(cTU}g6N1(*b*4|@z%HdL3>wI@4b31r@^YBwmnV#hXvZ4zW`RjZI*)6^?
zdy7w<oETs>nJwtzdtl#zRb8{ZSI-EqZ_c0Du39O)4_4sU_L_$^eJSnc;q9V!M{--%
zfcYqEo!-9qoV;(fPvfNBgZaKNyT~v3<zu>xNnZ1iw%0*`k+eIKyg~y%XJVVs*dV@s
zZidL(Th8gH7YzwVHFM%U@m`WD<c2~QYg+*+gmap^ZWJHPHwDE>?6F6Bz(LO)R>}7H
ztgHw36p<cV#L6*9Yr!lx;NAt?c>t{bza7dh%GgyBj7EdUM5D6)=BA>d`^Cy`S=qFR
z(S@f6?Iwm~mBd})?Pl1Bv^;PD*iX_7Q*nJishGpcga^;v!phTuY@YxU)o>{HbPMPJ
z8XLJtUyRns4tf!6V7wWnG1jI9rwEbEt#>nW))q!y{x~Dwff4*r9$gl7Dzb-ogldyU
zJbrGTg}EfXM)GHPpV=4jS-8{u<wVG~_qro?v5<Ka&}zLnjjtCYK8wdSYrkL2>V860
zIk1{bFqNi@jJ4z=Q(&M=+Y{y4yeDjj?j`*$65mM8SM#LqpAw^YMQx7+p6k(jVj#r4
zrhluFkA1?+cg`@%#V<4R8r;*MZZwJ(X9s8C#%BjNXoEH}bK}}<RqX_@lEr&ewMGju
z6H@jff~pzxW&Ir19@f@yG^}0d#*{+`2~8q(AQ@9U6N%Ia2DWpu7*Pkx8u@F>XF|IX
zXdmqg;WxIMX4j)(JsPIz|9QjL8<o+h6GmFc*Vwr)BW2=S^o^Kn?1H%zVi!OZ;Hm_+
z0iz<=#IK;*g)5tFIBmAqw%W^<;QEGG#>h-g*>Y&Bxm2D|HsMr!PXwG}Or^2+{-ASg
zmf{_Y=QGE>V<A7;uiW8$2K=O@ZeFVMX_B2qSvlIvQ>!hP!<;b%w>Y9OHdcytvdhQF
z>T&Pu7Is<DAh%8>FjadK5_V149$!ybX(*??j^v=wwiYs}0@W&2n^MIk;_*Sf<!Ld@
z%h<VI^N{8<%`R@ocG0bH!XELu-IS>ytoWh{JBkA{MRK^gE0{Vjz1^Uee(!Jbe{;#z
z(0S?AuKe*kxhoQC{qOzeE(5#<2Gk$~WGaF=Az{b`8QMmu!=e3^_Rxo+GCc-SXgXpJ
zXobuz>?LPhVVvsgW@mcg9tV|O215oZpKS+W$-6(eH{XiwZv&oRDUT`RPeu2bTT;bo
zmnPQUZZYp0t5sXf`^Rdd1;!fEp;VG(gsV=w6kP+Y(f1EKV_U?hD*Y=HHPCyeLGPLF
zdCEP#)iPqN)_!aX{K1trI?++{54#RG^)5Z~7hGW<7q|_5;k^n`N+8oc@(2%iGGnJF
zI}cFKRK&FtoFy5Y;m{7v$6zY}ACB3@Z;u8whLy{2G>8g+f&uMP0;X$RD4BstFk`?$
zSp;U|V=-_=I&`2DR-u!xE~}h#@@{cfFP-V2nV?w-&89tplOKZw8&otFw{W8AVtB1i
zFkOtSoq{~9HbzM2&95%9Ep{)>uJ)y-vr@cwLi?7k2~a~OC>>6Mv9{3_higuokPepG
z#PUKT?Q!ddqP<36)i*HFxT7~}E!!P?f{V=7ss&o;dfHW$JvB(!JTn_3A>uB+s!=-n
z7^D?V5_iq)zZgqqzGSR*1=JSiRkO=jJ4uKwjTSVuwSu;k6V$e9-z~{6^3m9PjY14^
zR(OGr1Jnp{rH*n-M(r};m$iCf3x7L!kQ`tzq9vZk`2v@!RwJlu;|1a$5A*r01?b?D
zyT@!rL+bT*;mO^%;okMKjW2XPkY10yi^G)#SB(8;ykRQV^9zB?LE~eAYm2MgwKjdF
zt0Z01my7q@$J|cMGN($EbGM%XrCE#onRv|F>%};H{MPghu0rTx`N4OCvy~>x#ClQF
zN65$8HO{BRRL?B1_f$_RxwakC+S?DxxhMRG{9MKqrM!lRj1TTm?i;csdLC{na8>)%
z>9kBtMS+V$XK9&$Ysk0%jE>VW@8@87$OMNU0hzGy20h%zD~y+riO4Ai_e4HVB9sT%
z79l?bd;Mz&$@xO%JbinUBZPrOqTAp}Bc@Gt17P6y{+$gX8Due9L-`U@%L($Ou-Z!D
zf57TbVsPn^=9a~c6^)6*OS8FJ<KVmfS%RiijYYXx*v7{KXA-eATlqV8TMFa=m$F*1
z4z7mjmBl7-r{nX-`C?eBO5FdE><X-PMb~b$Kn8NLwKWzwaOVMgsm-z!1Akf+(>nsY
zTpfWHSE1+Ee8R?GTc|u=yWa9lBU4T5{H=HwAG`4m3w=tTlBawqFZ7|$72F=42g$qr
zn~uQheYYv!(?!*$3*oglJ4Y5IIOg)Po90+h5Ozuv?3CNi?0jYKV*QM%?QC_&v8nCy
zSHuE$ei<y02r^lI22HtRk|)y&Ns;^{&lY!h>W0pwcGi~UAzS4vNij2#`30*-Tc{y<
z@f$RUYRn{4tFf40{(X~TWm-(4%DA`+L%|IcPmA;fbkuhqX63xUvdW?diO+P6_}($-
zh%1m!Pt9D4an4&Y!$Ask1`_%8vH{7jN1I61xL+^I6Aiy!H2iwe-WsF_kR+r>k)l0i
zr=w|D6?9D{c;vyIaVP9C2Vs}F6?*W?aKTPTx*101HMl?bIuLClkg1!`lV59w;|JLJ
z8WeIa0lI}Z9gU=q=W}p9$E)Pmyi~fNk19p+QB8r5YDydO(^J}@XP#!IDdex}oB|n)
z&}T9{Qo*$0Xb=j3uH&qI@9{}^hjet3;;s7dLpcAS*`Iiimv_P<V0km>wVH7>=&hnz
zfsCri5ApDTwxDc&=AZGB)O=J32{Wmn51M-7d5e%1B4r@WLAuFVrJ5G8FamE|A=<vn
zJ8h~djvMafo4l?@Q(zO!#D|8+P|Si+rFq`Pvpd|3{iKggX6>xC#kUytoK$aDqtJk-
zR1%u7G<>wNC9imRs^|F7?e1fZ59Zj1Px?rKWNoaqXz0VnO*sdL_BR%t@0h=8_~?B0
z{u4v*H@@W%i-zCIV;}ikJUGO+v%lK6?}Nr4M8EI8?32UALojR3KsW3~!(pE18<)CW
zdG_HKt~Dz8%-PGbO@jx0gn=~d^2RXCy{l0VeXy--FFNk+s%)(2tY{QFt&OI^2Rgy1
zP>#xTo{HzyDULC#X;AW+2A8?%#Z(acYWH-Q8Vbe9Z4VE~Bd7L_JrX0hMn2r9vA=b`
zC-6bx(fOwa<QC)b=3)4|1XkMSQ`c$*b|tvvkaqomMU@=wE$E8!JmB8quFTnzyKU%c
zcY(VOuq3;9D9p3j&E3aZ)Y2F<sC5Xo8MFh7sYfK0QYUEZReP4Z9k%<Fw{%b1KglHp
zjT^{22y;bPDR~DMXD=TxKfmVRdI#6?Dr=eI9V~3%urJN>JlPHJV5#CAwB{doFxF0T
z4|+P9RMvTXAv8?52O+Z1e#%)D@1W<^rZ1b|9rVCE*aYuj6TE|no7>t1?_g6$&^u`T
znRn1ybiOF$9c+Wj*;wZ*KF?a8Y$(Yt>>}~H&X?as8nMgq%8hPALRS+w!CROOlF*g`
z?`dPJ^P%rH4QR#Ett(Y~;n~Ep<$pxwRd|};#8l9A1eUK99)}B8l3+YAx9Gi<4XX8=
zW$a24P+7%mY{f&uiJ&EgX59Ri^O>S#_Lt5#itbTVswZ1ETk%0#oo{okp*^xK%;Gvo
z8a?Ur=2yq0$BVQOUB)Eg;NwLhZ9b%K{bpQ;hY!)F_>-jFzB%ni|Ms&Tfj>5~564*K
zz}C7lKPzkyd1=oOn{jq9wQYZkap>R~AxCiJl;c0R*@l<)TNvw91kmkhVeQZQTKoyA
zN*J3j2@M_|5CZl8)R6IdLpQV&QTml-Y-5zCZiuyPXsYNoc%S}#<L}=b=(y65y=r*n
zS?yZJs<LePh{bHeGD=LHELb%4vk|01$QY93D_h1kt`O2N!L9D4GqA_l-x`|P4sY4n
z_9pY_+U7&PThdoFrg)38m!C1ax#aRj4z`}GbhrcD;iYpeQ?c4p+ov6&<(>+MX6l@&
zUS^b$NJ9`_Da$Ey<kSr%r6hTi4$DQZX6Qw>SBnh8_F>^=!!X%$;K_s`#nmj^f=|su
zhGA|83+KqV@&H9d0|k@Tl?Fn(y$JΖi^Nv$U9JQ>=^+(J4OQ5ANQJr2ee$-A1q
zhCQ&wZ-5+h$gj=_QZ;jF*`CpK-5lt8d-UxplCvQ(ht_>JOttjU(1$`ZW;(1QT&fga
z#^`d2hNgJtr3miu_3X+t3si0pJzF~q`zvO_1}BLF_6dV;TJi);&g40eh!4Y@q|C#V
zpUp$eznurj$f3DVW`agaGcX-86^;C#M;+m1?dDhTX_#va$qw@?D(VNiK@=dtdPA0n
zkm5v*y*$cXvj<yRn9<<)Bp<G7vkuRJooA)b{B9<2<U#l3lzARnM6!v^^^6Z;4=ts>
zH{Gk>L4$+VqAce0BD2rn7-p?AAnj^+Q=l5A=A0BbJ>O-)l%Te}Yw|Evrf%%4Zg%4Y
zOQLsT>lmCuu4ZBPm~?zt50!FCQM}i2Wm+{gEbK;;LwLT!r1;@tpjDC4MFZ#PlOqxE
z#7(Xt#Rq;lYslZ|Actcvris?_#;KyIn~xOIjzSjkBzXKWQ;HQZ$~QBav@k}x(epp<
z_?Hs1!T&D6(2Dm<>}<8!mvKSwgqurZKH_>K&^c{SzvD_cyi5~o$Wrl>J=81e6md2R
zCE9`%>I7k}rG>ZZBp6haHJ&G%g2vYnQc|5_C_N#)bgZiG-2LKfqA4)D6TCC9{3sdZ
zRva}2Rw5N4If{|3LRx*4shs206CJ}K5&6kiV&u0d+Qlv#vlb0%*G0Y<u%Oz0Qy>z_
zx}SlC&d`gx`<YB3$DD1>E*?aa`-PktR}dYA>(xq`;z2bO+<1%@pGVED`*l6!8QSJE
z?9_h}>FC?$BOhb`WqoyUZ456(!u$sgC7l?ejnllRL7WReU5|KOg+)*@l-AI!5DC)E
zTn`h_q-xrMQ<zi5NCN{JsU-}fSM=DRt9KIOzFZ>?tz;S{!wUi{aBBpWkJ-(;{{ff{
zcnJ{Xf;Zu~Qrn|F%*aZ&F+Iwofj?G>2C$kg8>=O_!@0gN1Y<N_G}MrFNYfYc%Q6+j
zbUvR4lRXTMp-u-o5$R|p3lPP$1lh~=2$}v%(ZJY$j*vk(3Swkv#6NH7=P@!6>3`N{
zC`zW|(qy!GLzGN?Optxv(4ezxb(Z64Xw5-Y{uT(gmQF;>jK@kW{HIun9QZ<h9xIUv
z)0tXgu$z(;D0INqH1d#J82N+yp#k<z*0x)$_HXW(?d=%ZgrI{}?&W9lJ7z$1D`_wV
z{)klFu*{L&m?z~NM3jNaYi)o~33MrhFK}7M6nKbK$t<oC+a|Rm9-$F3-@agQ(m|Ax
zd`mj49Y)WKO=JY&G-FWXBa_LNpy*mddPPBEMwhx-ykXN<bc75CK^c+ukW2T%(LlRl
zP*{M_h)sor6Pgu;5A-nBCqPt-5uNe#s1t+bZco)7Esk>#(QP<d+qAKpv8_SG34E`>
zu~lBVdG;o@2tg0hJ1DXISdmBmNN!?mroaQoz*jaQwxnnb9L?V1FS$?djzGb$Q1F@e
z3fsz$vP!54yrA9pi&RDIG<y^S{3f2NU8@x~-u$!2=C^GauQmVQgq>vlEbL^S5_aM+
zcip7)mw0<H?qm+`ug9It20f>OwNl&(!j;?|7u8^66nBz>azEMiOfq1-NTE#iA`Rdv
z(7tQG(JOaFK{jjy$JvV~UcjyUpN7}<>HW_le}4ZnU0kyJPQ|=1O9DTHQHQu;Ht3g@
z<KaK?*X*~X_K?a$s?JSFr0%>7J?U$t5Oq{^AmS5NKA3`>S5~Jv*f>^^1wvNwS#6b#
za^tMS+P+y{%wOg2{X+AM_Kqu?bGy*#-|RJ<FWjg3v_AL!ebd|f_i-OjO40R(_l12r
zwax6;e>Szv)xt`K;cdf{+YoR#Y^czS6klK-#DNmY6xj2weplE_;ZEHS?amE3%d+hb
z-^cS+_i5@+_#PG6>K_)I92)lh7U(@8=lGBW$T@>nb0`O}o0AGagQnOilFEpQksXBM
zriiD60y={cZFeaVZF8|Q!HBk>>>0kjff%eyT#dGu>_D942%3XtDa#Vf$tYAWQji<P
z1Er@SHpi_^F?A+;Os8oPnTllEe_>glJO}<r<;k>G)4z#FiyDtd`#M08FB5CXIH$y;
z1;f#tqAngHXJ~b3FsHCz&Bdw~zs<|fL#eGpnsSj*6xnS!B~gO?ZyC}%5Jf_(Mk{6T
zhkr~0m0ptpTj7J_^c^yQ>~g~@;|>}`;}3JT4L;W!Fjhenu{(x?R#QkNZ*Wr4AjMIE
zpZA9E(DghSNUGNMR(_u}-tilK7)1TV9$rh~<oa<@GBl8o^oI{N(Qb!ntBUh(ctwSH
zvRLo*2KL^CqS3ptIl3}>y+b98RZ4@KMY3cp%Ho`?6ybScDBsPle^h)h=T2;nbA6G%
z>&Ed+EIXOaLYg9>1ewo59}TXF2`n_HVH)DCwm0Z9gpryCZqA%@9aoaGR6J`-5hu2B
zuWlA$@^SdMzIaG$C*7t%0BN=R8FAQO><_OndJ5eU2#V>r;?C2H2l7g?5BlQr4*Gsr
zFzox={1d*qJkGi8+(C3N*f|8L0#7yN)H&)Db&xtncpH+J%#Dumh^h`)P*Y%Aa+J51
zW8^8)TZpR4u~^2Vs$2nHiK`05RNd#{X9wjzrn8hLw4xL^hbtvwh@v3FFfO6<Zspw_
z%5zv#v6y#YF||Due<fTF0~UtjuT~-c>UYVk15C6CEVO96sg+6t$d!gy(4Dm0!;QyZ
znbBA%{z|w!8PqhPrckMIFJDl*7!eR*oOw@JuUUC^8}<WsrO^FL;*HRyRWJ}w;uk4*
z36@*1Evb0N&7PN<$kMCVjMYX8*Ks#bv2k|<>fB`KWhyd&OdD*E``9@MX&g$Oqk@Pr
zS)ngbuA9U7biEyyS&VQ}O*CIv8;gKJt~X8@eg3OI**S^c>#Jv6VQYe>TVR5fbwISf
zLC|D4MJS@RBij*?9FZH5-9xx03?~NwG1)eaQQo^(twgL7lO={r;S8iD5c!h4OtLh|
z&V&ykig|7tbB$NcYjp%e&1NCgY%c6JjCJm{NHf<ZVpoYZX&C=c_9B<fbw~*<TDD-!
z*5i8j3L{Auiu`s&pVeQBeTS;~{}y@nfHJuh07jF{{okQyy&acy$~u!A_w&fJ4|0Rs
zOo;Apb_FBPXg2<7hMYBbKkP7FjIBQVz2;vAk=^yAPBDDK#AhaZ966O>pHpHhX!a<+
zf~3aKx30>%@hHWK-ie;aPb1I{SWK2&6#@paJ69$u4n|iK=_C}~#yDs%f_E|Qh6p#~
zwFtL<1hr6v8#(-bvQvIN!Yv-lNfy;#Vkzxu?9aBH8(n^1e1L-=*zLy3*;7nU0Yb!W
zLrnGa70W#jbido__^`9P^GsuBXL<Kv=TgtZ-H&u{>XyW+fdV&UyPLNRoOMN4Wn4&g
zX<hvb=3da|u~l;`GKPyQ-21C4(#6P%1LD4~lizC=jae<{!YZckKOip0^SrZr@yswh
zOJwJ!9GZ6|<zyOm(~R@8MAc0hM{*C%Y0o_oHJ`1@aNrSp)BJ<8j?6z9P7ls&W=_ot
zL$fG4Bl&RN8`InKPHd?%oZIq{#==(7n@NY?cvm%ZYNl%T#3SDxN<8xIN%hLH>f=Ml
z#h+Gn4#geWhj`V^;;KAjtK^r4?_TiKd#1pljupA3c}ugU3le5~7$MhSs~rXV9g-j3
zyN-ePT<@vUb+8YrGISofliiMUSunn^*LHZ?-AQT3#s+^*(Qwgu#%e??zR=9ph(7;N
ze2R8PNlx^e_V3D?4-G}l(atQ%iNIZX^T{FI97AeJjvjYH^9w_eJ(cJzzVz=F-hq#d
z+eXkh=|~*K0odw>pg;RH;=2bEJ?hk_;CWK>`$a$~snD%TO+u`<1nwnw%h<z7LId&y
zVQ-5bCK6q0Nw$7P@tOQr*cJI-8h8%R!cye}758Z^!8c~SF@Fh1FC;gIy1eQ*ws0C5
z#?^u-AQkM4;TH3u`rJjOdXG-n{tYR#cAt)~&*eOH7Xz7-Y_s{tsUCHju|<2vsxceg
zQEiNZsO+l9HuJ0O3UxA69dwzoM!<+bsedHS2B&?uq7pkomLW9s@*w=Ue+rV>-GKKX
z9_vm(`T$`q2gCo3rVlDhzTs=SbY<)(n7gXugLUWj9b9E%s$+L-X^Q*=T-s;&v`mbA
z(eTpBWJ4eEuI(aUYH)@L4wzosxA^|xGY8~@b;!*pAT|38eSEFKnJ2{VWJdHG_qC`j
z=_Zy>H;q+Kc@xwAo#i;zbEW&Z{X52PI^K2M_2u3#wP5}Uh*Hz`2rWO_iF9>+mX@?j
z&^G(ZTEhCuTOxW@5{VSyeR}>Fmb5j2aa`2fj)`OTj}vaxotJ=-(6SJd`4HDM%^@c9
zW%=^5Wv6cM8LQTCjNO9f)T;!XP53RWvBAmx6(*NKlmZ1$E*2l**9XzGS{#N5o3idm
zYmWWf&gQX49uUf#9b+4DMAl;AImXgI=+e2?9PVEbd7(9v{hB!tbwNKXNLuRZ&;7>p
zokM<0=a9j&?9JBsUwqeph|@my?RW2evtaN&s5aHd{i>B$#mBz;Y`^)<l@-+$ROa17
ze9iF-npq25O)gc<+zb63Y>ig*4@R1D@udHv-eH@2VGIl=>#*>l25Tn=ti6ftW~
zYriYHLarIQFk2ixH|!g$F?INTSH*BK^1BnhA@RfoGI3n#Vi1Nj2E!Oze5=^{?h|5b
z1AqTB7IkH!e^R@!@2a@#{h}e^m~k-dyGJ|wFY182EB>ldj3x;lM~8dD`{CzxmiRU%
zke~^QqcO=b2#1eRp2T2+dmyx|^gSVR+LA5}M{Ib%xO~^L?YDz~W&nW+aS34wS!u~=
zxd?gJ;a=}#6vr6_k%q*<4UL73sUqTV&yXGoCk!cJ2yb*Um8LczBH5M)Tl}+A`P?b(
zFP@bTR{N7Po;;|kt~)<<=CQr1M?j*FL|Yo(h(EIEem;*A{`4(x-!{zgfBH5CVPAE_
zdrxwFO!Y_S>(0M>g6jn#`l)qTWtWXfb%Xr6<Ce`LZJkVo<GK(Vk`bx*XHN$GzaeoR
z(vpv<4DY?wV{%`F5>g^A3h}-{|Io6On~(57s=dtyFq`~TPFf<?`4W?Hw$$zS#ibX#
z!mgcX*>+AXaUW;m<o9w(`?1ihmh`<kN8gW#!8cYnUW{BliPuYY!;@yr^ztxr74Ffl
zjUTU+f=bV!5}&*6%y>nmUJ~j>)hKS%3O;9&XZab%CY-jMh77d~7=e+tSYkjMHz8uq
zMA0fk5xo&R^vSUvc~7jz)fDS-&?IntbQ`TRQ$cz7&Kq?KniX2x(7J}maNYPU5fh?y
zCs`mAbfVa0;Qi*X&P-;0zp`fxCMjP?hMlHNOvExnF|B^uAwKIn?vG22KLWP$ZAVMg
z`KX&ZTgD#Ygr{1@Ho=W$V<oUBe~Uk&9hh+<=!c-KL!CkvNv49<ar+G+i~njFLx`tz
z1e+K4F%4An318|+7UP7H%qUNOKZQ4tfse1gUla?%R+^ii5X~RlUKqJTz%MD7eU=Z_
z{49<j#Fz;C316;#1eRBL6?`q{o_2A)i*W=2pS7(SU>}nFQ5H=fNkS?+Uy4&g!XF%v
zALZP`1CoEyeR>?sA(!?s@Mfb>eqhmh-dmEb5wMpv^HQ;2!_!p^oasgWaFl!UBg(m*
z*HM_MpwUzCLTFP9A@cX-v1P_nF+EETj#Z*N${sOruuOEQW{cuCVuSd;7}Xc~8Odtc
z8fp!_QO?L+DS}}q1^<x1UY{M;rtQ(4T0W59q>{q=^u6JqnJ-2mWGG4z&wjKUb|Tox
zy4a6pYF-Ub8uk*UgG@#2F5~tX@QQHo3hEf)5K$Q<bBBUh)XPv0l{ErSG<+8S$?<bV
z{)&T4jVkR7tVyqnU1DS(g_1;l7PTu90VZU)C3AxAGi{F^;nB=Ry+RSR!~JOIA1o9M
zJHnG^fmG#YbZs!ytp$Aij)A6%rrR<8v_er7r?v5!>_EW>8f*CnT<=6uP)?Z-sGy$Y
zA23~HFv`dpeQ&`57*={|iGH-_A25LB^2tURY1tKqbVlNOTg715@&FWPR}<}Y@@~ri
z^$d_+BGDltnhGML;!{D<Iz&!CL#k>{Y&rjnR7+!~6`!rm6B-wDpHL`_=2Py)WKr`{
z{z10ZWLdmVT^lZF5!<7}o%sN{jf(tno<x4xfyDF?SBXnF(7%A57GI#QLH>*6L&b2o
z<=Qo&7Q(ub|2%qz5bQ??9f$D?5HU!{u%4t*M|hushbF?ia$vKFkXFBhVBfVl%g^Y%
zl27M-)Mxb3u?iCQn2NjbmxI6P=x9eYi@$3UjFqW8?lXQI`-!3VK`~Q&2#TP!Vl%?=
z3@=Ujrt`uy!T8dT-*)Ves)&8*>bL!`&#Nd}u)5+yaZvP~|6KHmM=zWh{*ZG2px7-A
zoc~B1J`avj<M(l;)fHb^7QVSZd*Knk@1C;@J@YEgicNWrq6<aCm(O|@w11cT=JDZG
z6+fVX=!&r#<1q8RJ8$3D&*U8+eska$io$n1{K;8Q_8Z?ci7mbZ;#)rdx!|aZ&&>3=
z+<L2jsKpnb{E?^yTIxPchC~SW&c_jbk&ub>J>jP`i0FT6G-fp|Tji=qC%0_O0oR3L
z*O|dOiz(|j=SYtx{5PH}I%kAUOOLgVge{rt9jm5eRtWW{CN9R*kWjgCRT_*oto0_}
zb=irg7SkF{(@Qg(2*YrQWrw0L&DeaoWVV*AG*}!OL|>L&N_2;3a`=@Jy3%GME@F_Z
zsaSt}IvpQI{E1sFY5OcVzZYFCf3L66^_98xedX@3z76j1z6y6l-vfyJ6Wx)0mF}p%
z<?iTS;(=G-$O0FI9h&duRhz}6c6g_TjJ^EMiQaca`Af4Suw~ztF5?c)v{@tzfNO8O
zLQs+Eafji8lv+iuH}(k5>-h#mc{h=s>*Zj8Cmj?ufT83r#4j-AX_Zk5INm^HH2`Pv
zSsZO(Kv{H>feD9+9O>(F?X`meLGzCzqGzpViCb@D8tFJsLNbi-RSO4Kd5q_le2tK*
zy_)o*wqks?ReX*w!hX&tuk<W!it-r{;Li0fr$y<}Vo{h;W3_-E97^Wzd>Q-zrw0ng
zjRwKDNq8Gu6U#HB_wHqDCs~-$y8xpda87c)3zcS6XvQ?Es&-#d)dcM;CA?{LOMXT>
z1PNbwb(uILd9gXoi`a@YjI_C%Y$<7|$yjy0dZ3sFj-tsp9ulXVgS%qK>D^IoIV+i8
zX%)?1<iC>t#p340A1b!E>J)y9d4gw4u4DT*1uZ~1d%|IMMT@WCIO4%Srlzjg&7)d0
zW`y*vITeFwa(u+8Ii;1jK5ZYp)mNJb9W_BaP4Lw2=i?!lbdaQKwpNLTQvy=K?`c`y
zz#)@|=4!9+l-42#6v;FoSNO-=Cz?;`AkR!Cws<CDi-plw$D@nGagb-)_(7f|ep=hK
z)-?mg{jLUK^tX-Z_7I?QekZ(i#4@o>5j5;^r5a&ETdPR1;^EcdJ7e4951Y^7>P6OO
z@Wi$Xo%N#moFhE6+c#*OD>`uaoX&s%^MjizjY|V0qv(T@@$)l;WX!$6vojPDMx#A@
z%k@$Ho1bg2{mWl#a8z^upFh_S@~;Lp<JqmV;k@4J3L1ul(MMe>Ny3q1c~o+ZZPZyz
zUglC|1C~>&MAX96wyll3eMbMfp(NPtR%EXn=otA!135xjTOn9<VRl%mL%0;S@=;&o
zsCK2%_th2c3O&yTjELkr^Zisj*?oE1ir*;ay$v=}n2iW+GG`a!KlqgRU+^3RodF=T
z%Vb#P-hvGZKZ=B|KF}#csZk>oW+OtJ=zU`j&U4`;4!y$xB8T!S^kNKpKet|M(XQ87
zIg4(i#>xtXVsO(SzF3DCtIFI?@qPa@Vl))47ZyBrRy~V{hIHO9zZVRO;MSkFP>so+
zzq(stJiZ%#G&*CUPBu6Gw8DHe;o6TyO~Mn$m~F7&=xVIZuT?nh9K#P5bl^^nJJpJC
zer2u7vdXH()3@<79#1(mVQwruuM$jy9Y-5{tl&Bt>>!Pd1`^edh1sV9>*kV$(R-h!
zx8ZH(Ml(Wv#-QvlR(%S7uVNny`9bAKHVxjl<*qGMh$@r$&ghMWrXM?=$Kg888_eTz
z9q$e1h{rfR!5hpIaGl^uz!Av=L?tG86EUmhr>p*s!=^YsxA%V|atVgf3jDSikNXiA
zP0d)Q{4+RrN0!ug@q(<W?Wm9oSoIa6V*!g%F%Ix^RDJ`6A4B^38(!|fJxRL|AYh^7
zq}wpENKa*FBy9FCx#<K>aMMzLN&#Y-Fv{X5JK~j}Qn-qrQXrao6zu{}9122&cBqg^
zo~@kW!6~}l)Wevlz4iFb4}(u0Wt89jFku7H_KtgbJf^l6P8Ui4*$vFzYw%A?ozhl+
zI#GhRwR=*V9FR{>LRj0FeXOX(|I>Ym7Dkf0qr5o0)kkM&RXC;Rh(n_jYG9Wcx@y<+
zy!S!;I2;a;cSkEf3U`AQT5$={5)mh})T!kGtoK%MwslA!H0qS4n~m%H_Uf+1{~B5&
zy@=x8%}REk`EznLkry971%o?MUu4JL@#s}B8allBAPm(Ee%9#nON=}=_V=-ux2YBT
zPf(1ER(`a_3`13<M+d6kildBG4bOH~c82ltXnBLwY45akiny=pv|c-J^F_T{K}<r>
zkV7s+O^(W3xA?mMX))T~;(uX2r_s#hp*TN$_N1TXA3iG|3lY_j1?H5e)N6TR4f04~
zE%I>T4&*xF6*zWYYT&HfU{t)j>*Z?%CI@uMQPNA;I~Y4YSe4=H6!ihdW<S5ftL=-D
za8$}+&mv!>UF*z%;*}*K&|#?fJX4h|ZKcVgYCtXy<_C3k(NM<uY{`E9Ddo-Y@X<#a
zUK7&>tT`+~97{H9QdBEK>_}Hjv3O&s8wF1m3u4qk5!FGk$&qT6`rJCbMZ3<Sw&)&2
z+%>POWO)s#M)t`#5zNeQ@xd4aUug0997$A05Ik+d-RrSrNfvA+!Ols(7;v~wQ92(S
z2u2lrBh`(cE$$SfXjp?1ET$XyyFfF_iHIuRUOc?k;SuO;q!o{biiTGy1QjE3ijJqY
zk;^AzXxk8VOG1Q6jFhj8`W=y#tT}0C|NoDAfzq;3n(yV-39rz|g9CSjM$TlO!AFXQ
z<1!IpG88!+8toDMr~pwpFU`i`#jz{V_Fz}{B)ldT57a-U+k}ahSYq57b;@05Ih%^V
z>#WAM;aJeh%asmUupuMf;$FnCu+=L3GSNFCMIha??~#3Khh)xvG=~CrH|=Aq?Y@Wi
z-D@W|Gc**i$Knf-<MV^rxp4i2T!__va#$@t=2gqYOhP{oLeWUHTgEB0!hsp-z=mIe
ztWeq@=N9|p_-M~wH;Z_z<FFJt7|AfB1Fp#9L%I}GU^6xhi(AgM1N*l%X$euT{RC);
zJ+uA6qd3g>axU}zQ@LatfEfY{Q`}$*NZ4TQJ`IkHghHOCzo=H2+#nwe>I<4J!ayZ8
zZq@<JRi)T%EH43#Iz}EEr`p$^4brSKl4}GtHQlKE%2Gng()|_t`!6z>J-e?6z9;fJ
z(eEzNuP*Jr=6Ry7{olX36dDM*h8*NAqr?1J2=RXB81%X$_=UeN=yia_2=^{fIW&t^
zkC#tSKYTS#%`ltP%QUs>67E6uPEED?SDd7NgR`n{V=9pzKq^p;q5PXD|16c~H>saS
z`Bf<YH~ctTBYvE1uKI@Zam)nfFZ)Z`PiID{|MQVws<mpfy3YCLqO{3(t0Qwt)k~Np
zZCzi1wzzPycH7cw?elkJunilWfkkG6R(s#h-`v44Yo2+Ie&NlmAB$v}HQd$z_&*IP
BMYI3_
delta 4059
zcmZ`+eN>cH8ozgjVTM8AodIR|P+l0m1sN33QgSd+Q4lpT3#}J*9ARc~SIub4<(`gv
zI+bm5t}TYTi{MvihVzo;ZtgM6Jw=uu)!JfybT)T!z#IxoJ8SIkGLY^c`^R&C&ph|z
zeeQFA_j&FNe4yF#7L8xzsB&*`tXyMT|ExhnDA5pG;pP|{A>>3MPb`e$tS~4)&ueeW
zQ)lEopT|C)q}m~QUZp#4xXp*2uLjxz=mqLf%a0Wn$!Q&FD!Z80k&ZTfsAc|FTeL1$
z@0MQXU)$O6(zyCZ)0OU2HO<Q`@dZjZu^fMhICPEVrgkN9WL=Wj5@KeHAt9$Fw$o&0
zH_l2-iZZiXUrKCdn3-+*yTrDJo7wU65_>no%+7r(u{HRuV9qA!A7ZQrxCL0<BC%=F
zW;XVW#6BNmW)GZ^#<2lRs)k|d0u03B&*38}z&hX&UQBsR%3Bhff@wu>N-PVXEZ!@z
zJm4kXPb29UT&I~w-&YrExK@*VN&S~DmeMAb>YW0r4U;wW0^e<XTK8ExajfU(mPGTs
z(2b_X4Esr1GtU<+X>05!nPngUOXwAh+%f84_Js_qJ5|bCpIS9qE$yW>Rx3r!A`zpb
zxk?waL`)<OW;vcK+I@U|*vptV7#0_^FN3<rc;&88NsJV|!z1~m@M_w`cZC;4{CYfb
zgftqqlAAh2_!)j9{3M(|60t)=pHa)q2Mtu>cVbhhlPAPYrnmT`aoO}b|6QDwuHbLP
z<<r~z3hXkEj-N^^_#^R^<9>GE^=$E-=r6~9g3jlAb?2#@)Fk>NYfFAGujQxX%ag_@
zt4epDYekn;{Y|&UrTE=lN$SS#B()C0{7QEzFC1H$lKz#%=0FI}eMId4z-BJO4p|IQ
z)Z=5%Q2I50C1Fy?*I5m%TJ+bcA0<2!tiNnK+{P^Jyd-se$Yop0f#<g~%VoYPHEB_%
z!Mnw0zi99({zDjY+1At)Aeo@ap=Q!PICyiA95b`KD|IV$Uc3Ljp;3Pr9z`7Y`V{{j
z(Z~B!W2RrWwY3eCb$D)w_xDX={lB&uya-7Pb-8^(nZX^xX7St`E53VMElG={^fF(b
zo*n&tt})1hn?~Gr-yY|3=eD-D@fk2DeUtG*Zt1sTn-LRvdd7jAn5^6r%#vVha5Brb
zEaDjSSh2n%YjRmqM{|F?N9e>Mcbw=C5;`Bum`WG&shKO&{scR-teE(`bL5K2j|HxZ
z*f&CF3sCA*=4|>A4;$ZK|IrZD5^{un{}81D#QNiq-i22BWuMwiW|{E|H3vPR!(JKh
z^U5&d6+F3j0;6!?QIL3unZ-`K8v1w|k`N($Q&uaT$rH1mrK{Cl*}KJEnr@qo_61vZ
z*opMhJ;bF;5`j3y-?t_6T}6*+=|B{}Q<TV8<<8L%hk7V?n+Du3%8R5rUXhoExtsE$
zX)J#&Z$I743-e3FYWWp(Kfjcpfsy)x6q?4f3*yk06f}m`O(G8Jl5qQ)crUDVTtE44
z%>GQ`4wa(3ti_P5bc*|F_KLfCfsdV%h;^q=c_m!rFB_!dp!J1<OT2qZGHv05Q%1)Z
zUXa*s<ea;oOYF!O5a_4QNvu7^%=okiEcLSNx}79{6JnJ=ohHf229qokvuwX?k`o19
zfsKUAovc760!d(u4SmgnCOJpo&n9_-z`G_n8^~bK5(xWvfv{%+71%Qb!k#V=_OyB^
zc66i)L`RB1bR+|1*sVb2ib+lqcsbyda%tE}*b~Hf*vAQkeJoIhJzk7IW0K<perl3q
z1%6_ZV}N$pEdpV$j}{6##sFn>j24KFD4<eqk|PDqH_2v!WhU7Kw8Jh5ggrta?BPHe
z_AsC_+a!+?ILjo53M@9sMxY(`5P`581QwfS$a*L;I)VkFLkCp!COJr8uu0Ym)R|-r
z&<;Bl2s;s|!*TH52jem{M6)&eb{-*D3&_Q~2gySB6tYGkeg*cYZ?6gl$%pi4o-;MN
z*tCGkM5B?3ZMvMQ)!>Jn5H^DlI+GAGi)<!y$O$qRdMRW+v5^HtI=zSxX)%5;Aw*tE
zO#J1k)-d^mh9*K}*i8JhsaBItw@!Or^DAwmwpKe<>(=g7_0z(rVdDZqGEn?^!!kt_
z`<w|#K@*0HeKv}HwmJbteZp{?13gC#v^MBAQReGqH4%E^aGL}@Ne#4C=vFn*CPPp5
z+I_@fRqxY>EP+hGj!EnZ<i%x>>#Y*o5Qz$WNMaqMP_o-l5>VDt_DL)q6}t>I_)FB_
zHN-rNUD}PpjQaiw(2q&|DAapU-*Zv#S7C4!Fn*z#EytpLl9`!+J-|Cyd@uCdDD@fY
zxrZL5hNbVCndL#;!seW%e5XB17Z1Zs{<i($h*8kOAQI$`SK^hn3~nomGTyWC`9%+g
z+&V0=5WE;HyrIaUegAucWVAMT1NK(<F!$yr=LUVDyI{n&wQgNw&}$7&1N5^_)Z_;J
za8=%HK>$L{tfG;yl!Jt?osp|K^(J3ZJx&v|mv5|YQkOmaH>zzOu<(@P>DsFUVcc1q
zJ8?T4TlG%B$?#!EjX(oLge2gDUO3M}VS9amk8`cyS+k<3hZoJ7ZZyLf1-awpFU{&q
z8UwZLsKjJsrNW(rl|e)h#9HDzueI~q*?%?`A?g9MI&n?`9WAEZTS;QeL-fqUH<hdn
z7YDo<BJ$x&$M{bru@$Skjj9_`*DXSVr-^C=PXc_{eAvvc;oP4(Ah8GDkl5=u#^s3a
zsXd4;eEPq<;|`ig<9P49vGqvMT~QsQy~M@3qr6DecydK{*iQ#U`5;o2d+Z+*$B}m>
z)(px#1?P8yZ^cJIAz(FPCEk4C8N(%G7VQ6AJ2(jXh)oMJh**zoSneSXJ?>D|481kp
zRma~cjnV8n%Fmb9)QjWU8Web9m{ha(*=~)?gqk6AkI&#IE{{)A?H8q?KuF%f9}`^U
zyI6N~8?ABQD7!HV%i4YJ8-d^uhX-zm5Vd1n;Tpm7{XINo#PP&x$WievJb2n}{+LkX
z_UU<f*=X9XUei2D6K7(IAokS?GdloGo?>Q#`9~pMNC&?*|4C}##pN!vN6Mr5G~ISH
z_T|&KY0ZcOb;tO=1?wt)S{b^+crN6ueP@u9EE=zfSD*#2z@kI=a&?e9%NKm!ersIq
znjfOpMq-JdJ)$L!q64MZwKb*JLoy_<(h_WyJ0rYucf?R%I8V@zjUkQ^%8EU`isRS{
zxz$V5e=a(z(G0}!9ToZY;{J))ilf=qK-f2U(ufW1$L~XsHb^_{g0dqU+(*gLcKi-O
zpP>2uF%wrt9Oq$(xF#b$yx2#Eo`-`qdUcDBwa)JgO17WW@$w~M^<oWit;93RzGpff
zeYSOa#kx*cg~z1Nil9-63<pk(`_D@Kir{m)vmTs}v8J+@W?t)&d~{uSRgHI1n>Mpr
zRSxQ`)hczfldF-2iEEX2UDs;RSm`7+&EHvEb-tAy=3dV?&Hi<*y887&Rn+wa_#G_K
zxq>)upYid&s%1mLti(rPTW?b6JfM3^?}AFD%UHEUC0JfOU6iiHAR_g^NzWt0qa*%j
zw4rMLeWPhDM%K<%t6E77wbGjU67^~;ahE#g-_)kjwf2+cj$&_elQ>=6#OfKU(*J5}
zo>%rqw8T4<{)X1u&LCUEzv<%bPP*Z?^G1*C_qWLYZ7n^Mh5l_zW?vt){C9l&{lLMs
zeLWdfN`Gyu?0=-C)@RMMdF?IXzJ$yiU`~fz@87m(f@*X$_s?w2a@hT=T3>X&;`8{#
z>$}g_<NVfV%uMsz+w_^i6Li^go!U%Lutl3>MSRlSad5A;HO@;qL*e53PT8N=NnCM=
zNHAiNzMjsbh_2G5ZwzkGAw>tR6n93@X@p+01lJaPg};bM{30a?PKvZ3vZ>(GKz4vn
zf}4V?`yhgQf`fvq9ng_=H&$-clJ7?Io0ZwNUC2b2b_8gf4g4_Y9u-4=t7k>H^BPUf
TbDL1YCx{ZBSZL?&7Q=r5PE^0=
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 3/4] ath10k: Fix the wrong updation of SGI in tx_stats debugfs
From: kbuild test robot @ 2019-02-24 21:35 UTC (permalink / raw)
To: Surabhi Vishnoi; +Cc: kbuild-all, ath10k, linux-wireless, Surabhi Vishnoi
In-Reply-To: <1550820034-18603-4-git-send-email-svishnoi@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 3914 bytes --]
Hi Surabhi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on ath6kl/ath-next]
[also build test WARNING on v5.0-rc4 next-20190222]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Surabhi-Vishnoi/Fix-inconsistencies-observed-in-population-of-tx_stats-in-debugfs/20190225-041038
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: x86_64-fedora-25 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
In file included from include/linux/bitops.h:19:0,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/completion.h:12,
from drivers/net/wireless/ath/ath10k/core.h:11,
from drivers/net/wireless/ath/ath10k/htt_rx.c:8:
drivers/net/wireless/ath/ath10k/htt_rx.c: In function 'ath10k_update_per_peer_tx_stats':
>> arch/x86/include/asm/bitops.h:325:37: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
return ((1UL << (nr & (BITS_PER_LONG-1))) &
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
drivers/net/wireless/ath/ath10k/htt_rx.c:2916:16: note: 'flags' was declared here
unsigned long flags;
^~~~~
--
In file included from include/linux/bitops.h:19:0,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/completion.h:12,
from drivers/net//wireless/ath/ath10k/core.h:11,
from drivers/net//wireless/ath/ath10k/htt_rx.c:8:
drivers/net//wireless/ath/ath10k/htt_rx.c: In function 'ath10k_update_per_peer_tx_stats':
>> arch/x86/include/asm/bitops.h:325:37: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
return ((1UL << (nr & (BITS_PER_LONG-1))) &
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
drivers/net//wireless/ath/ath10k/htt_rx.c:2916:16: note: 'flags' was declared here
unsigned long flags;
^~~~~
vim +/flags +325 arch/x86/include/asm/bitops.h
1c54d770 include/asm-x86/bitops.h Jeremy Fitzhardinge 2008-01-30 321
117780ee arch/x86/include/asm/bitops.h H. Peter Anvin 2016-06-08 322 static __always_inline bool constant_test_bit(long nr, const volatile unsigned long *addr)
1c54d770 include/asm-x86/bitops.h Jeremy Fitzhardinge 2008-01-30 323 {
9b710506 arch/x86/include/asm/bitops.h H. Peter Anvin 2013-07-16 324 return ((1UL << (nr & (BITS_PER_LONG-1))) &
9b710506 arch/x86/include/asm/bitops.h H. Peter Anvin 2013-07-16 @325 (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
1c54d770 include/asm-x86/bitops.h Jeremy Fitzhardinge 2008-01-30 326 }
1c54d770 include/asm-x86/bitops.h Jeremy Fitzhardinge 2008-01-30 327
:::::: The code at line 325 was first introduced by commit
:::::: 9b710506a03b01a9fdd83962912bc9d8237b82e8 x86, bitops: Change bitops to be native operand size
:::::: TO: H. Peter Anvin <hpa@linux.intel.com>
:::::: CC: H. Peter Anvin <hpa@linux.intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49043 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] ath10k: Fix the wrong updation of SGI in tx_stats debugfs
From: kbuild test robot @ 2019-02-24 21:13 UTC (permalink / raw)
To: Surabhi Vishnoi; +Cc: kbuild-all, ath10k, linux-wireless, Surabhi Vishnoi
In-Reply-To: <1550820034-18603-4-git-send-email-svishnoi@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 3836 bytes --]
Hi Surabhi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on ath6kl/ath-next]
[also build test WARNING on v5.0-rc4 next-20190222]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Surabhi-Vishnoi/Fix-inconsistencies-observed-in-population-of-tx_stats-in-debugfs/20190225-041038
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=alpha
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
In file included from include/linux/bitops.h:19,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/completion.h:12,
from drivers/net//wireless/ath/ath10k/core.h:11,
from drivers/net//wireless/ath/ath10k/htt_rx.c:8:
drivers/net//wireless/ath/ath10k/htt_rx.c: In function 'ath10k_update_per_peer_tx_stats':
>> arch/alpha/include/asm/bitops.h:289:37: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
return (1UL & (((const int *) addr)[nr >> 5] >> (nr & 31))) != 0UL;
~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
drivers/net//wireless/ath/ath10k/htt_rx.c:2916:16: note: 'flags' was declared here
unsigned long flags;
^~~~~
--
In file included from include/linux/bitops.h:19,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/completion.h:12,
from drivers/net/wireless/ath/ath10k/core.h:11,
from drivers/net/wireless/ath/ath10k/htt_rx.c:8:
drivers/net/wireless/ath/ath10k/htt_rx.c: In function 'ath10k_update_per_peer_tx_stats':
>> arch/alpha/include/asm/bitops.h:289:37: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
return (1UL & (((const int *) addr)[nr >> 5] >> (nr & 31))) != 0UL;
~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
drivers/net/wireless/ath/ath10k/htt_rx.c:2916:16: note: 'flags' was declared here
unsigned long flags;
^~~~~
vim +/flags +289 arch/alpha/include/asm/bitops.h
^1da177e include/asm-alpha/bitops.h Linus Torvalds 2005-04-16 285
^1da177e include/asm-alpha/bitops.h Linus Torvalds 2005-04-16 286 static inline int
^1da177e include/asm-alpha/bitops.h Linus Torvalds 2005-04-16 287 test_bit(int nr, const volatile void * addr)
^1da177e include/asm-alpha/bitops.h Linus Torvalds 2005-04-16 288 {
^1da177e include/asm-alpha/bitops.h Linus Torvalds 2005-04-16 @289 return (1UL & (((const int *) addr)[nr >> 5] >> (nr & 31))) != 0UL;
^1da177e include/asm-alpha/bitops.h Linus Torvalds 2005-04-16 290 }
^1da177e include/asm-alpha/bitops.h Linus Torvalds 2005-04-16 291
:::::: The code at line 289 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:::::: TO: Linus Torvalds <torvalds@ppc970.osdl.org>
:::::: CC: Linus Torvalds <torvalds@ppc970.osdl.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 55538 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] net: dsa: fix a leaked reference by adding missing of_node_put
From: David Miller @ 2019-02-24 20:32 UTC (permalink / raw)
To: wen.yang99
Cc: linus.walleij, andrew, vivien.didelot, f.fainelli, netdev,
linux-kernel, alexandre.belloni, UNGLinuxDriver, nbd,
lorenzo.bianconi83, kvalo, matthias.bgg, linux-wireless,
linux-arm-kernel, linux-mediatek, anirudh, John.Linn,
michal.simek, wang.yi59
In-Reply-To: <1550819742-32155-5-git-send-email-wen.yang99@zte.com.cn>
From: Wen Yang <wen.yang99@zte.com.cn>
Date: Fri, 22 Feb 2019 15:15:42 +0800
> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> index 8c431e0..89823f0 100644
> --- a/net/dsa/dsa2.c
> +++ b/net/dsa/dsa2.c
> @@ -613,7 +613,7 @@ static int dsa_switch_parse_ports_of(struct dsa_switch *ds,
> struct device_node *ports, *port;
> struct dsa_port *dp;
> u32 reg;
> - int err;
> + int err = 0;
Please preserve the reverse christmas tree ordering of variables here.
Thank you.
^ permalink raw reply
* [PATCH v2] iw: allow to set wmm parameters from iw
From: Andrea Greco @ 2019-02-24 15:25 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Andrea Greco
In-Reply-To: <E1gx8bq-0000er-7g@sipsolutions.net>
From: Andrea Greco <a.greco@4sigma.it>
Allow iw modify cw_min cw_max aifs txop
Signed-off-by: Andrea Greco <a.greco@4sigma.it>
---
Changelog:
- Removed useless printf
phy.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 78 insertions(+)
diff --git a/phy.c b/phy.c
index 77df7a7..d723dde 100644
--- a/phy.c
+++ b/phy.c
@@ -843,3 +843,81 @@ static int handle_get_txq(struct nl80211_state *state,
COMMAND(get, txq, "",
NL80211_CMD_GET_WIPHY, 0, CIB_PHY, handle_get_txq,
"Get TXQ parameters.");
+
+static int handle_wmm_params(struct nl80211_state *state,
+ struct nl_msg *msg,
+ int argc, char **argv,
+ enum id_input id)
+{
+ char *end;
+ struct nlattr *txq, *params;
+ int queue, cw_min, cw_max, aifs, txop;
+
+ if (argc != 5)
+ return 1;
+
+ if (!strcmp(argv[0], "VO"))
+ queue = NL80211_TXQ_Q_VO;
+ else if (!strcmp(argv[0], "VI"))
+ queue = NL80211_TXQ_Q_VI;
+ else if (!strcmp(argv[0], "BK"))
+ queue = NL80211_TXQ_Q_BK;
+ else if (!strcmp(argv[0], "BE"))
+ queue = NL80211_TXQ_Q_BE;
+ else {
+ printf("Invalid parameter: %s\n", argv[0]);
+ return 2;
+ }
+
+ if (!*argv[1] || !*argv[2] || !*argv[3] || !*argv[4])
+ return 1;
+
+ cw_min = strtoul(argv[1], &end, 0);
+ if (*end)
+ return 1;
+
+ cw_max = strtoul(argv[2], &end, 0);
+ if (*end)
+ return 1;
+
+ aifs = strtoul(argv[3], &end, 0);
+ if (*end)
+ return 1;
+
+ txop = strtoul(argv[4], &end, 0);
+ if (*end)
+ return 1;
+
+ txq = nla_nest_start(msg, NL80211_ATTR_WIPHY_TXQ_PARAMS);
+ if (!txq) {
+ goto nla_put_failure;
+ }
+
+ params = nla_nest_start(msg, 1);
+ if (!params) {
+ goto nla_put_failure;
+ }
+
+ NLA_PUT_U8(msg, NL80211_TXQ_ATTR_QUEUE, queue);
+ NLA_PUT_U16(msg, NL80211_TXQ_ATTR_CWMIN, cw_min);
+ NLA_PUT_U16(msg, NL80211_TXQ_ATTR_CWMAX, cw_max);
+ NLA_PUT_U16(msg, NL80211_TXQ_ATTR_TXOP, txop);
+ NLA_PUT_U8(msg, NL80211_TXQ_ATTR_AIFS, aifs);
+
+ nla_nest_end(msg,params);
+ nla_nest_end(msg,txq);
+
+ return 0;
+
+ nla_put_failure:
+ return -ENOBUFS;
+}
+
+COMMAND(set, wmm_params, "<VO|VI|BE|BK> <cw_min> <cw_max> <aifs> <txop>",
+ NL80211_CMD_SET_WIPHY, 0, CIB_NETDEV, handle_wmm_params,
+ "Set WMM parameters for a queue (VO, VI, BE, or BK):\n"
+ " * cw_min/cw_max - contention window minimum/maximum\n"
+ " (a value of the form 2^n-1 in the range 1..32767)\n"
+ " * aifs - arbitration interframe spacing (0..255)\n"
+ " * txop - maximum burst time in units of 32 usecs, 0 meaning disabled\n"
+ );
--
2.17.2
^ permalink raw reply related
* [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes
From: Marc Zyngier @ 2019-02-24 14:04 UTC (permalink / raw)
To: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu
Cc: David S. Miller, devicetree, linux-arm-kernel, linux-kernel,
linux-rockchip, linux-wireless, netdev
For quite some time, I wondered why the PCI mwifiex device built in my
Chromebook was unable to use the good old legacy interrupts. But as MSIs
were working fine, I never really bothered investigating. I finally had a
look, and the result isn't very pretty.
On this machine (rk3399-based kevin), the wake-up interrupt is described as
such:
&pci_rootport {
mvl_wifi: wifi@0,0 {
compatible = "pci1b4b,2b42";
reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
0x83010000 0x0 0x00100000 0x0 0x00100000>;
interrupt-parent = <&gpio0>;
interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&wlan_host_wake_l>;
wakeup-source;
};
};
Note how the interrupt is part of the properties directly attached to the
PCI node. And yet, this interrupt has nothing to do with a PCI legacy
interrupt, as it is attached to the wake-up widget that bypasses the PCIe RC
altogether (Yay for the broken design!). This is in total violation of the
IEEE Std 1275-1994 spec[1], which clearly documents that such interrupt
specifiers describe the PCI device interrupts, and must obey the
INT-{A,B,C,D} mapping. Oops!
The net effect of the above is that Linux tries to do something vaguely
sensible, and uses the same interrupt for both the wake-up widget and the
PCI device. This doesn't work for two reasons: (1) the wake-up widget grabs
the interrupt in exclusive mode, and (2) the PCI interrupt is still routed
to the RC, leading to a screaming interrupt. This simply cannot work.
To sort out this mess, we need to lift the confusion between the two
interrupts. This is done by extending the DT binding to allow the wake-up
interrupt to be described in a 'wake-up' subnode, sidestepping the issue
completely. On my Chromebook, it now looks like this:
&pci_rootport {
mvl_wifi: wifi@0,0 {
compatible = "pci1b4b,2b42";
reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
0x83010000 0x0 0x00100000 0x0 0x00100000>;
pinctrl-names = "default";
pinctrl-0 = <&wlan_host_wake_l>;
wake-up {
interrupt-parent = <&gpio0>;
interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
wakeup-source;
};
};
};
The driver is then updated to look for this subnode first, and fallback to
the original, broken behaviour (spitting out a warning in the offending
configuration).
For good measure, there are two additional patches:
- The wake-up interrupt requesting is horribly racy, and could lead to
unpredictable behaviours. Let's fix that properly.
- A final patch implementing the above transformation for the whole
RK3399-based Chromebook range, which all use the same broken
configuration.
With all that, I finally have PCI legacy interrupts working with the mwifiex
driver on my Chromebook.
[1] http://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf
Marc Zyngier (4):
dt-bindings/marvell-8xxx: Allow wake-up interrupt to be placed in a
separate node
mwifiex: Fetch wake-up interrupt from 'wake-up' subnode when it exists
mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling
it too late
arm64: dts: rockchip: gru: Move wifi wake-up interrupt into its own
subnode
.../bindings/net/wireless/marvell-8xxx.txt | 23 ++++++++++++++++++-
.../dts/rockchip/rk3399-gru-chromebook.dtsi | 8 ++++---
drivers/net/wireless/marvell/mwifiex/main.c | 13 +++++++++--
3 files changed, 38 insertions(+), 6 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH 1/4] dt-bindings/marvell-8xxx: Allow wake-up interrupt to be placed in a separate node
From: Marc Zyngier @ 2019-02-24 14:04 UTC (permalink / raw)
To: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu
Cc: David S. Miller, devicetree, linux-arm-kernel, linux-kernel,
linux-rockchip, linux-wireless, netdev
In-Reply-To: <20190224140426.3267-1-marc.zyngier@arm.com>
The DT binding for the PCI version of the Marvell 8xxx wifi devices
is pretty broken (the fact that a PCI device requires a DT binding
is quite telling on its own).
The binding allows the description of a wake-up interrupt as a sideband
signal, allowing the wifi device to wake-up the system. So far, so good.
Until you realise that placing an interrupt in the PCI device DT node
has a specific meaning, and applies to the actual PCI function, and
not some random sideband stuff. This is of course in total violation
of the OF specification (IEEE Std 1275-1994), but hey, who cares.
Let's thus change the binding to be somewhat compatible with the spec,
by placing the wake-up interrupt in a subnode called "wake-up". This
still is an optional property, but a recommended one for PCI devices.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
.../bindings/net/wireless/marvell-8xxx.txt | 23 ++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 9bf9bbac16e2..f9340ca37047 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -33,10 +33,16 @@ Optional properties:
this interrupt number. during system suspend, the irq will be enabled
so that the wifi chip can wakeup host platform under certain condition.
during system resume, the irq will be disabled to make sure
- unnecessary interrupt is not received.
+ unnecessary interrupt is not received. For PCI devices, it
+ is recommended that this property is placed in a "wake-up"
+ sub-node in order to limit the ambiguity with PCI legacy
+ interrupts.
- vmmc-supply: a phandle of a regulator, supplying VCC to the card
- mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
for documentation of MMC power sequence bindings.
+ - wake-up: a subnode containing the interrupt specifier for a wake-up
+ interrupt. This is the recommended configuration for PCI
+ devices.
Example:
@@ -66,3 +72,18 @@ so that firmware can wakeup host using this device side pin.
marvell,wakeup-pin = <3>;
};
};
+
+&pci_rootport {
+ mvl_wifi: wifi@0,0 {
+ compatible = "pci1b4b,2b42";
+ reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
+ 0x83010000 0x0 0x00100000 0x0 0x00100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_host_wake_l>;
+ wake-up {
+ interrupt-parent = <&gpio0>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ wakeup-source;
+ };
+ };
+};
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4] mwifiex: Fetch wake-up interrupt from 'wake-up' subnode when it exists
From: Marc Zyngier @ 2019-02-24 14:04 UTC (permalink / raw)
To: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu
Cc: David S. Miller, devicetree, linux-arm-kernel, linux-kernel,
linux-rockchip, linux-wireless, netdev
In-Reply-To: <20190224140426.3267-1-marc.zyngier@arm.com>
Encoding the wake-up interrupt as part of the PCI DT node is completely
broken, as it violates the most basic rules of PCI description in OF:
the interrupts described in such node are supposed to apply to the
PCI device, and not to some non-PCI stuff on the side.
In such a configuration, both the PCI device and the wake-up widget
end-up trying to share an interrupt. Of course, this doesn't work:
The PCI device can only generate interrupts through the root port,
while the wake-up widget uses sideband signaling that bypasses PCI
altogether. Clearly, this was never tested.
So let's first try and obtain the wake-up interrupt from a 'wake-up'
subnode, and fallback to the main DT node otherwise. This ensures
that old DTs will carry on working as bad as before (with the added
warning to let the user know about the situation), and new DT will
enjoy legacy interrupts in case MSIs are unavailable.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 20cee5c397fb..2105c2b7c627 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1590,17 +1590,26 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
{
int ret;
struct device *dev = adapter->dev;
+ struct device_node *wup_node;
if (!dev->of_node)
goto err_exit;
adapter->dt_node = dev->of_node;
- adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
+ wup_node = of_get_child_by_name(adapter->dt_node, "wake-up");
+ if (!wup_node)
+ wup_node = adapter->dt_node;
+ adapter->irq_wakeup = irq_of_parse_and_map(wup_node, 0);
if (!adapter->irq_wakeup) {
dev_dbg(dev, "fail to parse irq_wakeup from device tree\n");
goto err_exit;
}
+ if (dev_is_pci(dev) && adapter->dt_node == wup_node)
+ dev_warn(dev,
+ "wake-up interrupt outside 'wake-up' subnode of %pOF\n",
+ adapter->dt_node);
+
ret = devm_request_irq(dev, adapter->irq_wakeup,
mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
"wifi_wake", adapter);
--
2.20.1
^ permalink raw reply related
* [PATCH 3/4] mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late
From: Marc Zyngier @ 2019-02-24 14:04 UTC (permalink / raw)
To: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu
Cc: David S. Miller, devicetree, linux-arm-kernel, linux-kernel,
linux-rockchip, linux-wireless, netdev
In-Reply-To: <20190224140426.3267-1-marc.zyngier@arm.com>
The mwifiex driver makes unsafe assumptions about the state of the
wake-up interrupt. It requests it and only then disable it. Of
course, the interrupt may be screaming for whatever reason at that
time, and the handler will then be called without the interrupt
having been registered with the PM/wakeup subsystem. Oops.
The right way to handle this kind of situation is to flag the
interrupt with IRQ_NOAUTOEN before requesting it. It will then
stay disabled until someone (the wake-up subsystem) enables it.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 2105c2b7c627..82cf35e50579 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1610,6 +1610,7 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
"wake-up interrupt outside 'wake-up' subnode of %pOF\n",
adapter->dt_node);
+ irq_set_status_flags(adapter->irq_wakeup, IRQ_NOAUTOEN);
ret = devm_request_irq(dev, adapter->irq_wakeup,
mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
"wifi_wake", adapter);
@@ -1619,7 +1620,6 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
goto err_exit;
}
- disable_irq(adapter->irq_wakeup);
if (device_init_wakeup(dev, true)) {
dev_err(dev, "fail to init wakeup for mwifiex\n");
goto err_exit;
--
2.20.1
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: rockchip: gru: Move wifi wake-up interrupt into its own subnode
From: Marc Zyngier @ 2019-02-24 14:04 UTC (permalink / raw)
To: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu
Cc: David S. Miller, devicetree, linux-arm-kernel, linux-kernel,
linux-rockchip, linux-wireless, netdev
In-Reply-To: <20190224140426.3267-1-marc.zyngier@arm.com>
In order to get PCIe legacy interrupts working on gru-based Chromebooks,
let's move the wake-up interrupt out of the way and into its own
subnode. This ensures that this interrupt specifier will not be
mistaken as a PCI interrupt.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
index c400be64170e..61fff688770c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -310,11 +310,13 @@ ap_i2c_tp: &i2c5 {
compatible = "pci1b4b,2b42";
reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
0x83010000 0x0 0x00100000 0x0 0x00100000>;
- interrupt-parent = <&gpio0>;
- interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&wlan_host_wake_l>;
- wakeup-source;
+ wake-up {
+ interrupt-parent = <&gpio0>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ wakeup-source;
+ };
};
};
--
2.20.1
^ permalink raw reply related
* Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
From: Alexander Wetzel @ 2019-02-24 13:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <69e6577f90d99289acaa9853fe236e6f15f9e774.camel@sipsolutions.net>
>> and I've had some time to improve my test setup and
>> hopefully have better access to a mvm card for testing.
>
> If all that's lacking is a few NICs then I'm sure we/I can help out with
> that :)
>
Thanks, but as you suspected the NICs are the smallest problem...
I've simply delayed setting up a good lab far too long. So prior to
shifting the focus to drivers I have to remedy that somehow.
Not really relevant here, but if you want to know what I plan for the
future here my thoughts on it. If not you better skip that section:-)
Current plan is, to get one (ideally two, depending on price) mini PCs
(amd64) with m.2 slots, good antennas and one or two matching Intel AC
9260 cards.
Additionally I want to get rid of the whitelist in my development
notebook by flashing coreboot, opening the path to install a minipci to
m.2 adapter mount a second/third Intel 9260 card.
The core boot flash rollout is imminent, just do not want to risk the
system by soldering wires to the mainboard till the generic support is
sorted out. If that goes wrong I could brick my main system and lose
access to my dvm card, but no risk no fun:-)
With that setup and using AC-9260 in all devices I'll have near-perfect
setup to test and observe AC-9260 and can simply swap out cards to test
and and maybe also get working after (hopefully) getting AC-9260
Extended Key ID "certified" as reference implementation.
With three stations I can then try my hand at the still open mesh
support for Extended Key ID, but that should wpa_supplicant only.
That said the initial heavy lifting is done. I'm still amazed I get that
off the ground and working end2end with comparable ease. While there is
still much work left the structures are all in place and it's now mainly
closing the gaps.
I currently plan stick to the project a bit langer getting at least some
intel cards and ath9k working, finalize the already existing Extended
Key ID and PTK0 rekey patches and also update wireshark again.
I suspect I'll need at least one year for that in the best case,
potentially much longer.
I already have three bugs/issues flagged for analysis. Nothing really
relevant for the generic support but all three itching enough I'll plan
to look into them:
1) Wrong time stamps with at least iwlwifi when using monitor in
parallel to the normal connection for outgoing MPDUs (probably mac80211
issue, )
2) Probably: Wpa_supplicant scan list is flushed too often, preventing
fast reconnects
3) Wireshark can't handle Extended Key IDs decoding (and decoding should
get at least some other generic improvements
Chances are I'll be busy with coreboot for some time and then
finding/setting up some mini PC(s). That's nothing I've had any need for
so far and suitable systems with M.2 slots with at least two external
antennas are hard to find. (So I may end up mounting external antennas
to the system myself.)
To continue I primarily need another Extended Key ID AP, ideally able to
support NATIVE and COMPAT mode. Having a second device (or maybe just
second M.2 card in the same one?) for sniffing nice.
Finding a really good sniffer able to also capture A-MPDU frames
including control frames would be awesome. All the so-called good
sniffing USB sticks I got my hands on crap even for sniffing normal
frames compared to my built-in dvm card nobody seems to suggest for
sniffing...
Full-speed sniffing to observe a rekey during load is hardly a common
use case and I suspect usb interface alone an indication the card won't
be able to handle it well. And some things like the cleartext packet
leaks only becomes visible at higher speeds. (Which btw also need a
follow up. My crypt skills are not the best, but with my current
understanding I'm quite sure a retransmit of a previously encrypted
frame in the clear text gives away the TK key for all other frames
encrypted with the same TK.)
So plenty of work and reason to get a better test environment set up:-)
I hope the newer mvm cards will be as good as my old mvm card and when
using the same card in the AP, sta and sniffer able to get basically
every frame as long as the sniffer has the best antennas.
If someone here has a suggestion what works for I would appreciate some
pointers here:-) Don't want sink too much money at it but if it's
something around 300€ or so I could simply start with one and decide
later if I really need a second one. Non-amd64 systems would also be ok,
but it must at least work with vanilla kernels and something like
Debian. I'm wasted enough time of porting my patches for each test and
keep them in sync.
If someone is willing to donate a suitable test system I would not say
no, but I'll plan to finish that with private funds also.
I probably should work on the new AP, but then I always wanted to test
coreboot and finding out my notebook is now supported is too alluring to
resist;-)
>>>> I also have tested patch for iwldvm using the Compat mode and I think
>>>> mvm cards will also work with that.
>>>
>>> No they don't, no firmware is available for that.
>>
>> So far I only looked at the dvm part of iwlwifi with only minutes spend
>> on mvm to port the NATIVE solution from dvm.
>
> :)
>
>> Are you saying that mvm cards can't seamless switch a RX/TX key to TX
>> only one? mvm seems to support SW crypto as needed and switching RX/TX
>> to TX keys is the only other requirement for COMPAT mode.
>
> No, sorry. I misread your statement. I thought you were saying "mvm
> cards will also work with iwldvm" rather than "mvm cards will also work
> with compat mode" :-)
>
> I think they all should just be made to work in native mode, the
> firmware basically supports this as you found, there must be some small
> bugs.
Agree. And with your statements that it already should work and the
option to get ucode updates I like our chances:-) With some luck it
could even work and I made some error the first time. I'll give that a
second look with what I have at hand soon. But after bombing you with
mails for what feels like most of the weekend I'll postpone that for now:-)
As mentioned above I'm currently aiming for two or three Intel AC-9260
cards for the next development round. It's seems to be the most modern
card and the price difference between the cards is irrelevant compared
to both efforts and costs to get the cards working in two or three
devices. If you thing another card would be better for development I'll
just use that one instead...
Alexander
Alexander
^ permalink raw reply
* [REGRESSION] v5.0-rc5 rtl8192cu breakage
From: Vito Caputo @ 2019-02-24 11:34 UTC (permalink / raw)
To: linux-kernel; +Cc: Jes.Sorensen, kvalo, davem, linux-wireless, netdev
Never seen this before v5.0-rc5, rc5 is the only v5.0 build I've booted
so far, if this is already fixed in a newer rc please let me know.
Just wanted to give a heads up since we're so close to v5.0:
WiFi stopped functioning abruptly, this appeared in dmesg:
[968853.940102] usb 2-1: USB disconnect, device number 2
[968853.949169] wlan3: deauthenticating from 0c:72:d9:27:17:57 by local choice (Reason: 3=DEAUTH_LEAVING)
[968853.949537] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x6954341e
[968853.949552] rtl_usb: reg 0x422, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x8531114
[968853.949564] rtl_usb: reg 0x542, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x34085e
[968853.949583] rtl_usb: reg 0x1cc, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x2e
[968854.204153] usb 2-1: new high-speed USB device number 4 using ehci-pci
[968854.335901] usb 2-1: New USB device found, idVendor=7392, idProduct=7811, bcdDevice= 2.00
[968854.335910] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[968854.335916] usb 2-1: Product: 802.11n WLAN Adapter
[968854.335921] usb 2-1: Manufacturer: Realtek
[968854.335926] usb 2-1: SerialNumber: 00e04c000001
[968854.340632] rtl8192cu: Chip version 0x10
[968854.431999] rtl8192cu: Board Type 0
[968854.432614] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[968854.432723] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[968854.433043] ieee80211 phy1: Selected rate control algorithm 'rtl_rc'
[968854.488906] rtl8192cu 2-1:1.0 wlan3: renamed from wlan0
[968854.507120] rtl8192cu: MAC auto ON okay!
[968854.548252] rtl8192cu: Tx queue select: 0x05
[968855.298268] rtl8192c_common: Polling FW ready fail! REG_MCUFWDL:0x00030006.
[968855.298274] rtl8192c_common: Firmware is not ready to run!
Unplugging the USB WiFi dongle and reinserting got everything back up and
working. Only experienced this once so far and it took ~10 days to
happen, only just started using v5.0 so not much more information at
this time.
No reproducer at this time, I wasn't doing anything in particular.
Regards,
Vito Caputo
^ permalink raw reply
* Re: [RFC PATCH v3 04/12] mac80211: Compatibility Extended Key ID support
From: Alexander Wetzel @ 2019-02-23 22:50 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <b963b4257bba8b5423b93dd58c5828604fc07df4.camel@sipsolutions.net>
> On Thu, 2019-02-21 at 21:07 +0100, Alexander Wetzel wrote:
>>>
>>>> + if (!ext_native && key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) {
>>>> + key->flags |= KEY_FLAG_RX_SW_CRYPTO;
>>>> + /* Activate Rx crypto offload after max 10s when idle */
>>>> + ieee80211_queue_delayed_work(&local->hw, &sta->ext_key_compat_wk,
>>>> + round_jiffies_relative(HZ * 10));
>>>> + }
>>>
>>> Is there much point in this?
>>>
>>>> + if (unlikely(rx->key->flags & KEY_FLAG_RX_SW_CRYPTO)) {
>>>> + rx->key->flags &= ~KEY_FLAG_RX_SW_CRYPTO;
>>>> + cancel_delayed_work(&rx->sta->ext_key_compat_wk);
>>>> + ieee80211_queue_delayed_work(&rx->local->hw,
>>>> + &rx->sta->ext_key_compat_wk, 0);
>>>> + }
>>>
>>> We'll almost certainly do it from here, so never exercise the other
>>> path?
>>
>> This is mostly to have a definite time we know the new key is used also
>> for RX. In probably 99.9% of all cases it will be triggered from the Rx
>> path.
>> Some special purpose devices may not send any packets for a long time
>> and trigger the fallback, as (wrong) firewall rules. (I've e.g. tested
>> it by dropping all outgoing packets on the remote sta.)
>>
>> The idea was to be sure that a rekey intervall >10s prevents activating
>> Rx crypt when rekeying the next key. Which now sounds kind of thin...
>
> Not sure I even understand this?
>
> You meant "Rx crypto offload"? I'm not really sure we _care_ that much?
>
> Then again, an issue may be that some firmware may want (need) the keys
> for RX so it can look at certain frames (action frames?) itself. So if
> we never install the RX key and then only get an action frame that the
> firmware should handle, we lose. Such firmware could not support COMPAT
> mode then I guess, which may mean a bunch of iwlwifi devices shouldn't
> use COMPAT mode.
We still seem to have a problem understanding each other here. That
sounds like something we have to sort out with the RFC patch series to
avoid bad surprises later... It's probably nothing, but here we go:-)
First, COMPAT drivers must not have any key installed for Rx offload in
Hw. Any active Rx key will be changed to a Tx only key with mac80211
taking over the Rx decryption in software.
That is bad, weak CPU devices asked to take over decryption will be not
able to handle the same load as with HW. (My test router can't and with
Sw crypto I'm around 20MBit/s slower. The router even become
unresponsive on a shell when stressing it in a quick test some weeks
ago, with a single client uploading.)
So we try to handle as few packets as possible with SW crypto and as
soon as we see a packet encrypted with the new key activate Rx crypto
with the new key again. Any packets send with the old key after that are
very likely mangled by the Rx crypto offload and lost and part of the
price we have to pay for being able to use extended Key ID with cards
never designed for it and at least with traffic between ath9k/iwldvm not
an issue at all.
But it's of course all that is irrelevant when we are no packets to
decrypt and the code sample above starting the discussion. That is
handling a very rare corner case I reproduced by dropping all outgoing
packets with iptables on the remote station. EAPOL packets of course
don't care about iptable rules and the key could still be rekeyed, but
EAPOL frames were the only traffic possible and since the handshake
still use the outgoing key the receiving station never got a packet
encrypted with the new key, preventing it to activate Rx offload. So 10s
after the rekey the "fallback" mechanism kicked in.
Not installing the Rx key after 10s as a fallback has no real downsides,
it only may break the assumption of someone debugging a problem that at
10s after we installed the key to mac80211 the Hw crypto will be active
again.
Without the fallback it's just something like extremely likely and may
be not true in unusual setups or for problems affecting the Rx path.
Long story short, if you don't like the fallback activating mechanism
for no Rx packets seen we can simply drop it.
As you said it's a rare case and not handling it only chances what you
assume from what you know for sure during debugging of a problem.
Management Frame crypto is not affected by COMPAT mode workarounds or
even by Extended Key ID at all, or I have a big flaw in my understanding:
Managment frames (802.11w) and for my understanding therefore also
action frames do not use the keys PTK keys (IDs 0+1) but 4+5 and never
touch the QoS MPDUs Extended Key ID is all about.
But after figuring that much out I ignored it...
Alexander
^ permalink raw reply
* Re: [RFC PATCH v3 05/12] mac80211: Mark A-MPDU keyid borders for drivers
From: Alexander Wetzel @ 2019-02-23 21:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <fbe9234012f91ba6a209f426e95a284f482554c1.camel@sipsolutions.net>
>>>> The code is assuming that the driver is not aggregating MPDUs more than
>>>> 5s apart. We probably don't have wait nearly so long but I'm not sure
>>>> what is the minimum time.
>>>
>>> OTOH, if you have a lot of BE/VI/VO traffic BK might be starved even
>>> longer than that, technically indefinitely.
>>>
>>
>> Hm, there is nothing preventing us to drop this "idle" switch as long as
>> we also drop the 10s Rx accel offload when idle fallback in the COMPAT
>> patch. (We have to drop the RX idle accel patch or get a small risk of
>> dropping packets in unlikely but possible scenarios. If that are eapol
>> packets things will become hairy, probably disconnecting the sta.)
>>
>> It just feels strange to potentially still use the old key for one
>> packet more without time limit. It could be, that the first EAPOL packet
>> we send for the next rekey would still use the previous key, the second
>> eapol packet the current.
>
> Not sure I understand this. If we have no TX going on at all, then
> surely we can switch with the next packet, before we encrypt it?
Well, yes. But how can we figure out we are indeed idle?
(Chances are there is something and I missed it, I've not even look at
many subsystems in mac80211 and probably even don't know some of them
exist...)
The driver/card must have given up on waiting for more frames to
aggregate and send out whatever it had in the queue.
You just told me above that a card may keep a partially assembled A-MPDU
in the buffer for >5s if we have higher priority traffic... That was my
idea to just handle it time-based with an insane but still ok long time.
Checking if all higher priority TIDs are idle sounds complicated and we
still must know when the driver/card gives up and send out the bufferd
frames even if the A-MPDU is not full. That does not make the idea to
handle it time-based any simpler...
I'm not even sure it makes much sense to send out packets with 5s delay
at all, tcp will already have queued retransmitts and for udp the frames
are either also considered to be lost by the application or we don't
care about them any more.
So yes, we can switch Tx to the new key immediately when we are sure the
driver/card has no A-MPDU "in aggregation" at that time. I guess we can
add a call the driver, asking it to tell us if a TID is idle, which also
sounds complicated. So I guess I just would send the "key border" signal
even when idle and accept that this can in corner cases use different
keys for even and odd EAPOL frames.
>>>> + info->flags &= ~IEEE80211_TX_CTL_AMPDU;
>>>
>>> Like you say above, I don't think this really makes a lot of sense. If
>>> we don't have any free bits I guess we should try to find some ...
>>
>> Well, all I can think of is quite invasive, so I hoped you would have a
>> better idea:
>
> I think we have free bits in enum mac80211_tx_control_flags, so that
> should be workable? They won't be preserved until TX status, but that's
> OK for this purpose, no?
Wonderful idea:-)
I'll rewrite drop you a new patch revision with all the other changes we
discussed (or are still discussing).
If nothing new pops up - either in our discussions or when rewriting the
key border signal - I would drop RFC from the next patch series all the
POC patches after this one so we can focus on the merge relevant defects.
Alexander
^ permalink raw reply
* Re: [RFC PATCH v3 03/12] mac80211: IEEE 802.11 Extended Key ID support
From: Alexander Wetzel @ 2019-02-23 21:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <767ada740d984e180d0ac799487722293a50367c.camel@sipsolutions.net>
>>>>> + key->flags &= ~KEY_FLAG_RX_ONLY;
> [snip]
>>>>> + if (key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) {
>>>>> + ret = drv_set_key(local, EXT_KEY_RX_TX, sdata,
>>>>> + &sta->sta, &key->conf);
>>>>> + if (ret) {
>>>>> + sdata_err(sdata,
>>>>> + "failed to activate key for Tx (%d, %pM)\n",
>>>>> + key->conf.keyidx, sta->sta.addr);
>>>>> + return ret;
>>>>
>>>> You've already cleared the RX_ONLY flag, which gets you inconsistent
>>>> data now.
>>>>
>>>
>>> I don't think so, it looks ok for me. But the delay_tailroom logic took
>>> a surprisingly large chunk of time and I should explain how the updated
>>> logic is intended to work. Maybe I've messed it up somehow and just do
>>> not see it:
>
> My comment wasn't related to tailroom accounting at all. I've snipped
> more code above to hopefully make it clearer.
>
> If you fail to activate the key in the driver, then the key is not
> actually enabled for TX, and thus you should not have cleared the
> KEY_FLAG_RX_ONLY? You'll be returning this error all the way to
> userspace, I assume.
>
> (Maybe, btw, the driver should be allowed to return something like
> "oops, I now want to use TX software crypto" like it can do for other
> operations?)
Yes, an error here will get passed through to the userspace.
I think I mentioned already that tailroom update really got tricky with
Rx only keys and I'll also add some comments to help understanding better:-)
Here a more verbose version to verify the logic:
An error here will abort the key install and at the end that will
disconnect the sta. But don't forget that the key at that moment was
already installed successfully to the driver as a Rx only key and in
most cases the driver is already "ready" to use Tx with that key.
Mac80211 is just not handing over any MPDUs for that key.
A "normal" key install would already have increased the tailroom needed
count at that time, we just skipped that since a Rx only key never can
have use for a tailroom and it's now time to update the count if needed
for Tx.
If that call to the driver here fails mac80211 may have a different
understanding of the key RX/TX status than the driver for cards similar
to ath10k we do not care about that. While we still may be able to
transport some packets if the driver still can handle them with the old
Tx key the userspace will have to tear down at least the encryption and
probably the complete association to start over. The connection is
basically already dead and we only care about our mac80211 housekeeping,
so in that case our delay tailroom needed count.
Allowing SW crypto fallback makes no sense, there is no way mac80211 can
rescue the situation: Only drivers like ath10k handling the key
selection with PN assignment themselves should need this call, all
others just have to return 0. So for any driver needing this call
mac80211 can't fix whatever went wrong in the driver.
Here the comments I've now add to the code for the next revision of the
pacth: (The code itself is unchanged)
+ key->flags &= ~KEY_FLAG_RX_ONLY;
+
+ /* Dropping the KEY_FLAG_RX_ONLY flag forces us to update tailroom,
+ * do that first.
+ */
+ if (!(key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) ||
+ key->conf.flags & (IEEE80211_KEY_FLAG_GENERATE_MMIC |
+ IEEE80211_KEY_FLAG_PUT_MIC_SPACE |
+ IEEE80211_KEY_FLAG_RESERVE_TAILROOM))
+ increment_tailroom_need_count(sdata);
+
+ if (key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) {
+ ret = drv_set_key(local, EXT_KEY_RX_TX, sdata,
+ &sta->sta, &key->conf);
+ if (ret) {
+ /* This is a not recoverable error, so we don't set
+ * KEY_FLAG_RX_ONLY again or fix the tailroom needed
+ * count here. By skipping both
ieee80211_remove_key()
+ * will do that for us.
+ */
+ sdata_err(sdata,
+ "failed to activate key for Tx (%d,
%pM)\n",
+ key->conf.keyidx, sta->sta.addr);
+ return ret;
+ }
+ }
Alexander
^ permalink raw reply
* Re: [RFC PATCH v3 03/12] mac80211: IEEE 802.11 Extended Key ID support
From: Alexander Wetzel @ 2019-02-23 17:26 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <171d2db4-7639-4738-2a6d-c899f0247aee@wetzel-home.de>
>>>
>>>> + sta = sta_info_get_bss(sdata, mac_addr);
>>>> +
>>>> + if (!sta)
>>>> + return -EINVAL;
>>>> +
>>>> + if (sta->ptk_idx == key_idx)
>>>> + return 0;
>>>> +
>>>> + mutex_lock(&local->key_mtx);
>>>> + key = key_mtx_dereference(local, sta->ptk[key_idx]);
>>>> +
>>>> + if (key && key->flags & KEY_FLAG_RX_ONLY)
>>>
>>> do you even need the flag? Isn't it equivalent to checking
>>> sta->ptk_idx != key->idx
>>> or so?
>>>
>>> Less data to maintain would be better.
>>
>> I have to look at that again. It will change some assumptions for sure
>> but still could work out with some slight differences. I'll have to
>> look deeper into that since I remember two moments where I was sure
>> needing the flag. That may well be outdated, but at a first glance it
>> would at least open the door to first install two key in legacy mode
>> and then switch between them. (Which should be no problem, of course)
>> I'll follow up on that separately, but that may take some time. When
>> it works you'll get a new RFC.
I gave that a closer look today and tried to get rid of
KEY_FLAG_RX_ONLY. It looks like it could work, but only with a
(pointless looking) trade off:
The problem is the initial key install. Normal and Extended Key Installs
both call ieee80211_add_key() and the function has to "mark" either the
key or the sta to be using Extended Key ID so we later know if we have
to activate Tx for the key or not.
Without that ptk_idx will still be set to INVALID_PTK_KEYIDX in either
case and therefore useless. ieee80211_key_replace() will then have no
way to figure out if it must set ptk_idx and activate the key for TX or
not.
Both checking a key Flag (for RX only) or a station flag (for Extended
Key ID being used) would solve the problem but I do not see an good way
to do it without one or the other.
Now we could of course use some other existing variable like setting
ptk_idx to INVALID_PTK_KEYIDX+1 in ieee80211_add_key(). But it still
would be some kind of flag, only stored where nobody would expect it...
Storing the information with the key simplifies the delay tailroom
handling a bit but I think I can get that operational with a station
flag for Extended Key ID also. But for me that trade off looks pointless..
I can of course go ahead if you see some benefit or other way ahead...
But I would pull the plug on the plan to get rid of RX_Only Key flag
with that.
Alexander
^ permalink raw reply
* Re: [PATCH] mac80211: Change default tx_sk_pacing_shift to 7
From: Toke Høiland-Jørgensen @ 2019-02-23 11:49 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Ben Greear, Grant Grundler, Kalle Valo, wgong,
ath10k, wgong, Kan Yan
In-Reply-To: <44add7675ef89dd61fcea9da6b55804c498a2d24.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2019-02-22 at 14:40 +0100, Toke Høiland-Jørgensen wrote:
>>
>> And send it directly to stable, or does it need to go through you?
>
> I added a Cc: stable tag. So all you really need to do is wait for the
> emails telling you it failed to apply, and handle accordingly :)
Cool, that I can do; thanks! :)
-Toke
^ permalink raw reply
* [PATCH] iwlwifi: mvm: fix unaligned read of rx_pkt_status
From: Wang Xuerui @ 2019-02-23 8:35 UTC (permalink / raw)
To: linux-wireless; +Cc: Wang Xuerui
In-Reply-To: <20190223083543.6009-1-wangxuerui@qiniu.com>
This is present since the introduction of iwlmvm.
Example stack trace on MIPS:
[<ffffffffc0789328>] iwl_mvm_rx_rx_mpdu+0xa8/0xb88 [iwlmvm]
[<ffffffffc0632b40>] iwl_pcie_rx_handle+0x420/0xc48 [iwlwifi]
Tested with a Wireless AC 7265 for ~6 months, confirmed to fix the
problem. No other unaligned accesses are spotted yet.
Signed-off-by: Wang Xuerui <wangxuerui@qiniu.com>
Tested-by: Wang Xuerui <wangxuerui@qiniu.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
index 6653a238f32e..a9f35799e532 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
@@ -57,6 +57,7 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*****************************************************************************/
+#include <asm/unaligned.h>
#include <linux/etherdevice.h>
#include <linux/skbuff.h>
#include "iwl-trans.h"
@@ -355,7 +356,7 @@ void iwl_mvm_rx_rx_mpdu(struct iwl_mvm *mvm, struct napi_struct *napi,
rx_res = (struct iwl_rx_mpdu_res_start *)pkt->data;
hdr = (struct ieee80211_hdr *)(pkt->data + sizeof(*rx_res));
len = le16_to_cpu(rx_res->byte_count);
- rx_pkt_status = le32_to_cpup((__le32 *)
+ rx_pkt_status = get_unaligned_le32((__le32 *)
(pkt->data + sizeof(*rx_res) + len));
/* Dont use dev_alloc_skb(), we'll have enough headroom once
--
2.16.1
^ permalink raw reply related
* [PATCH v2] iwlwifi: mvm: fix unaligned read of rx_pkt_status
From: Wang Xuerui @ 2019-02-23 8:35 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20190218150952.6889-1-wangxuerui@qiniu.com>
Fixed redundant calls per review.
Sorry for the delay; I inadvertently broke my test box and it took some
time to fix.
^ permalink raw reply
* [PATCH] ila: Fix uninitialised return value in ila_xlat_nl_cmd_flush
From: Herbert Xu @ 2019-02-23 5:30 UTC (permalink / raw)
To: Dan Carpenter; +Cc: kbuild, kbuild-all, linux-wireless, Johannes Berg, netdev
In-Reply-To: <20190223042747.GK1711@kadam>
On Sat, Feb 23, 2019 at 07:27:47AM +0300, Dan Carpenter wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
> head: db0342b20f32f584aedff27c9c09e0a4bbe5beff
> commit: 6c4128f658571b2dc7e01058ad09a8e947bc0159 [25/27] rhashtable: Remove obsolete rhashtable_walk_init function
>
> smatch warnings:
> net/ipv6/ila/ila_xlat.c:420 ila_xlat_nl_cmd_flush() error: uninitialized symbol 'ret'.
Thanks for catching this.
---8<---
This patch fixes an uninitialised return value error in
ila_xlat_nl_cmd_flush.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 6c4128f65857 ("rhashtable: Remove obsolete...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/ipv6/ila/ila_xlat.c b/net/ipv6/ila/ila_xlat.c
index ae6cd4cef8db..79d2e43c05c5 100644
--- a/net/ipv6/ila/ila_xlat.c
+++ b/net/ipv6/ila/ila_xlat.c
@@ -383,7 +383,7 @@ int ila_xlat_nl_cmd_flush(struct sk_buff *skb, struct genl_info *info)
struct rhashtable_iter iter;
struct ila_map *ila;
spinlock_t *lock;
- int ret;
+ int ret = 0;
rhashtable_walk_enter(&ilan->xlat.rhash_table, &iter);
rhashtable_walk_start(&iter);
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* [mac80211-next:master 25/27] net/ipv6/ila/ila_xlat.c:420 ila_xlat_nl_cmd_flush() error: uninitialized symbol 'ret'.
From: Dan Carpenter @ 2019-02-23 4:27 UTC (permalink / raw)
To: kbuild, Herbert Xu; +Cc: kbuild-all, linux-wireless, Johannes Berg
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
head: db0342b20f32f584aedff27c9c09e0a4bbe5beff
commit: 6c4128f658571b2dc7e01058ad09a8e947bc0159 [25/27] rhashtable: Remove obsolete rhashtable_walk_init function
smatch warnings:
net/ipv6/ila/ila_xlat.c:420 ila_xlat_nl_cmd_flush() error: uninitialized symbol 'ret'.
# https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/commit/?id=6c4128f658571b2dc7e01058ad09a8e947bc0159
git remote add mac80211-next https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
git remote update mac80211-next
git checkout 6c4128f658571b2dc7e01058ad09a8e947bc0159
vim +/ret +420 net/ipv6/ila/ila_xlat.c
b6e71bde Tom Herbert 2018-06-27 378
b6e71bde Tom Herbert 2018-06-27 379 int ila_xlat_nl_cmd_flush(struct sk_buff *skb, struct genl_info *info)
b6e71bde Tom Herbert 2018-06-27 380 {
b6e71bde Tom Herbert 2018-06-27 381 struct net *net = genl_info_net(info);
b6e71bde Tom Herbert 2018-06-27 382 struct ila_net *ilan = net_generic(net, ila_net_id);
b6e71bde Tom Herbert 2018-06-27 383 struct rhashtable_iter iter;
b6e71bde Tom Herbert 2018-06-27 384 struct ila_map *ila;
b6e71bde Tom Herbert 2018-06-27 385 spinlock_t *lock;
b6e71bde Tom Herbert 2018-06-27 386 int ret;
b6e71bde Tom Herbert 2018-06-27 387
6c4128f6 Herbert Xu 2019-02-14 388 rhashtable_walk_enter(&ilan->xlat.rhash_table, &iter);
b6e71bde Tom Herbert 2018-06-27 389 rhashtable_walk_start(&iter);
b6e71bde Tom Herbert 2018-06-27 390
b6e71bde Tom Herbert 2018-06-27 391 for (;;) {
b6e71bde Tom Herbert 2018-06-27 392 ila = rhashtable_walk_next(&iter);
b6e71bde Tom Herbert 2018-06-27 393
b6e71bde Tom Herbert 2018-06-27 394 if (IS_ERR(ila)) {
b6e71bde Tom Herbert 2018-06-27 395 if (PTR_ERR(ila) == -EAGAIN)
b6e71bde Tom Herbert 2018-06-27 396 continue;
b6e71bde Tom Herbert 2018-06-27 397 ret = PTR_ERR(ila);
b6e71bde Tom Herbert 2018-06-27 398 goto done;
b6e71bde Tom Herbert 2018-06-27 399 } else if (!ila) {
b6e71bde Tom Herbert 2018-06-27 400 break;
Set "ret" on this error path?
b6e71bde Tom Herbert 2018-06-27 401 }
b6e71bde Tom Herbert 2018-06-27 402
b6e71bde Tom Herbert 2018-06-27 403 lock = lock_from_ila_map(ilan, ila);
b6e71bde Tom Herbert 2018-06-27 404
b6e71bde Tom Herbert 2018-06-27 405 spin_lock(lock);
b6e71bde Tom Herbert 2018-06-27 406
b6e71bde Tom Herbert 2018-06-27 407 ret = rhashtable_remove_fast(&ilan->xlat.rhash_table,
b6e71bde Tom Herbert 2018-06-27 408 &ila->node, rht_params);
b6e71bde Tom Herbert 2018-06-27 409 if (!ret)
b6e71bde Tom Herbert 2018-06-27 410 ila_free_node(ila);
b6e71bde Tom Herbert 2018-06-27 411
b6e71bde Tom Herbert 2018-06-27 412 spin_unlock(lock);
b6e71bde Tom Herbert 2018-06-27 413
b6e71bde Tom Herbert 2018-06-27 414 if (ret)
b6e71bde Tom Herbert 2018-06-27 415 break;
b6e71bde Tom Herbert 2018-06-27 416 }
b6e71bde Tom Herbert 2018-06-27 417
b6e71bde Tom Herbert 2018-06-27 418 done:
b6e71bde Tom Herbert 2018-06-27 419 rhashtable_walk_stop(&iter);
b6e71bde Tom Herbert 2018-06-27 @420 return ret;
b6e71bde Tom Herbert 2018-06-27 421 }
b6e71bde Tom Herbert 2018-06-27 422
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ 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