* Re: Please revert "iwlagn: Support new 5000 microcode." from 2.6.32 and 2.6.33
From: Herton Ronaldo Krzesinski @ 2011-06-15 1:14 UTC (permalink / raw)
To: Greg KH
Cc: ak, sgruszka, stable, netdev, linux-wireless, linville,
donald.h.fry, linux-kernel, ilw, wey-yi.w.guy, reinette.chatre
In-Reply-To: <20110614230344.GA2065@kroah.com>
On Tue, Jun 14, 2011 at 04:03:44PM -0700, Greg KH wrote:
> On Mon, Jun 13, 2011 at 03:13:18PM -0300, Herton Ronaldo Krzesinski wrote:
> > The patch ("iwlagn: Support new 5000 microcode") shoudn't have been
> > applied on 2.6.32 and 2.6.33 stable trees, it doesn't support new
> > firmware file format, thus if the new firmware is on the disk, loading
> > fails, as reported on:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336
> >
> > Support for the iwlagn new firmware file format was only added beginning
> > with 2.6.35 (commit "iwlagn: implement loading a new firmware file
> > type"), so iwlagn works with new firmware only with 2.6.35 or later.
>
> Can I get an ack from the developer of the patch and the people involved
> with it first? It was asked to be backported for a reason, so I would
> at least like to get the people who asked for the backport to have a
> chance to respond please.
>
> It's only nice, why would you exclude them?
I didn't intend to exclude anyone and I'm just reporting it, it didn't
came to my mind CC'ing people while sending to stable, and hopefully
everyone related are CC'ed now.
Also note that this revert request is for 2.6.32 and 2.6.33 *only*
And seems the right thing to do for them.
The other stable release where this was applied (2.6.35) looks fine
but these two are too old to support the new firmware (don't work, need
extra patches backported which weren't, like the commit I mentioned --
commit "iwlagn: implement loading a new firmware file type"), as yourself
can check reading the code/bug report, and what I wrote.
>
> greg k-h
>
--
[]'s
Herton
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply
* [PATCH net-next-2.6] net: rfs: enable RFS before first data packet is received
From: Eric Dumazet @ 2011-06-15 2:15 UTC (permalink / raw)
To: Tom Herbert, David Miller; +Cc: netdev, Ben Hutchings, jamal
First packet received on a passive tcp flow is not correctly RFS
steered.
One sock_rps_record_flow() call is missing in inet_accept()
But before that, we also must record rxhash when child socket is setup.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Tom Herbert <therbert@google.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
CC: Jamal Hadi Salim <hadi@cyberus.ca>
---
Netconf2011 workshop ;)
net/ipv4/af_inet.c | 1 +
net/ipv4/tcp_ipv4.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 83673d2..0600f0f 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -676,6 +676,7 @@ int inet_accept(struct socket *sock, struct socket *newsock, int flags)
lock_sock(sk2);
+ sock_rps_record_flow(sk2);
WARN_ON(!((1 << sk2->sk_state) &
(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_CLOSE)));
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 617dee3..955b8e6 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1594,6 +1594,7 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
goto discard;
if (nsk != sk) {
+ sock_rps_save_rxhash(nsk, skb->rxhash);
if (tcp_child_process(sk, nsk, skb)) {
rsk = nsk;
goto reset;
^ permalink raw reply related
* RE: [PATCH] linux-firmware: Replace the old firmware
From: hayeswang @ 2011-06-15 2:38 UTC (permalink / raw)
To: dwmw2; +Cc: romieu, netdev
In-Reply-To: <1307956516-1203-1-git-send-email-hayeswang@realtek.com>
Hi David Woodhouse,
Please give up this patch. Thanks.
Best Regards,
Hayes
-----Original Message-----
From: Hayeswang [mailto:hayeswang@realtek.com]
Sent: Monday, June 13, 2011 5:15 PM
To: dwmw2@infradead.org
Cc: romieu@fr.zoreil.com; netdev@vger.kernel.org; Hayeswang
Subject: [PATCH] linux-firmware: Replace the old firmware
Replace the old firmware with the new one which is embedded more
information. The old firmware needs the old method of parsing, and
the new firmware needs the new one. They are not compatible.
rtl8168d-3.fw replace rtl8168d-1.fw.
rtl8168d-4.fw replace rtl8168d-2.fw.
rtl8168e-3.fw replace rtl8168e-1.fw.
rtl8168e-4.fw replace rtl8168e-2.fw.
rtl8105e-2.fw replace rtl8105e-1.fw.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 4 ++++
rtl_nic/rtl8105e-2.fw | Bin 0 -> 2144 bytes
rtl_nic/rtl8168d-3.fw | Bin 0 -> 1584 bytes
rtl_nic/rtl8168d-4.fw | Bin 0 -> 1408 bytes
rtl_nic/rtl8168e-3.fw | Bin 2804 -> 5568 bytes
rtl_nic/rtl8168e-4.fw | Bin 0 -> 3984 bytes
6 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 rtl_nic/rtl8105e-2.fw
create mode 100644 rtl_nic/rtl8168d-3.fw
create mode 100644 rtl_nic/rtl8168d-4.fw
create mode 100644 rtl_nic/rtl8168e-4.fw
diff --git a/WHENCE b/WHENCE
index d2abe41..8eba04a 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1613,10 +1613,14 @@ Driver: r8169 - RealTek 8169/8168/8101 ethernet driver.
File: rtl_nic/rtl8168d-1.fw
File: rtl_nic/rtl8168d-2.fw
+File: rtl_nic/rtl8168d-3.fw
+File: rtl_nic/rtl8168d-4.fw
File: rtl_nic/rtl8105e-1.fw
+File: rtl_nic/rtl8105e-2.fw
File: rtl_nic/rtl8168e-1.fw
File: rtl_nic/rtl8168e-2.fw
File: rtl_nic/rtl8168e-3.fw
+File: rtl_nic/rtl8168e-4.fw
Licence:
* Copyright C 2011, Realtek Semiconductor Corporation
diff --git a/rtl_nic/rtl8105e-2.fw b/rtl_nic/rtl8105e-2.fw
new file mode 100644
index
0000000000000000000000000000000000000000..c19d8288e4bfdb0549a88e0fdc5ae1c3e79e32
db
GIT binary patch
literal 2144
zcma);Z-`W76vp4ZGp@U}<VuDX9(Ra^mI$0t+ZI2~LdFtpMH#xRFhj1XX|-rbAFNKb
zK~S3%T1YL8x&$SXv{6Yx`>BWs?T?XcA13HS`=ty;qBghRGxuJaZdeVxoO|E*oaa2}
z&wK7XxcT9omC?<+M|VF^=_?g)tgOGIGO}y?o-Mm7#lBT*LOF!c8ijBu6nj^eR<A6T
z3Z>q)YkJp~`oj1~cgTk>*BTwY+C%Gd4=<aCM_Jnwxy}6GfO*$m-fxR#3o^KQ{qcBj
zVHtTdt4Xi(Zr-ab?0dH&L%g~+nEzfe&%J5BaoBuC(R>6s_qzGacjimbd*h7xmB<}m
zm@h_N@ea?Y%sY5)ecQZ6TsE5LB{!L01BUimlD#~8!W}G`pJj<>0nYiVxp=K^;;FdW
z6wgyExQ6>!_|fV(Vg403vab&&{=mq_B+Sbby((Baa0*-g!pXg5eie2@=qyFn$w3EP
zpJUB|eS~~mm*LbYPGjap_!Y4ED08kFv>(G4=Q-j{IsZ*klN-=E`HguL%+Grqi(^|5
zE_N$2xDjWU{SREl9F3E6e4KxRx+QrIgXXI;n2Mzhf9i+#Ce5d)@5T9;O9B1x80%j1
zbx97(?3ELJ;dkB@*Q|k&V5K#4a#z2{{Gn;{1;i-qKfsoK8Gou>6+Gp93A`FT1BPTC
z8J_(297e~`fx|5LIq<*b{bP7Ol5m{{yV%s<6Q|-_U!-T{+c}T6fzi}gX)bnV@}!#P
z4xpRlLwDr^;!E$!EIxHtj(%=FOpN2mA><BX-hiy(dq(oJnCn?Lzkp49Qky#XMecU7
zsW<D&^ZI|*O!*bhHgc%D5hZtFA9#wZMqD-Z@sRo9iuoiym49(kp62kaUTo+pu6L;;
zc%9XFhIHXmy+4I*Za<4N_3;Acg7d8Vt@+Rc_w-${U+SI+Tm99Y$!S_+@tB53W44XN
zzLncc={IU{|9_lQSLIjO;db+M4mM^VXU%hO5xJUIti(4=Y@3K{D>5Q>_5Km^HbK6g
zM!tenO%EbxU*bH$lAi*8eqb;EY*L>)!91GWFP>Y_-P6>MduNz|^I(AWJ@#enZyGRP
zMo)jzA9L59?u+_B^H6=5%1`%E=P%7~#Xk3<d4J7(4DQ0JV)rUoJ-5U-dhelk^`7Eo
zXZ4TxOtDjW93TD6_3Oc&NP4vfRs@#_o&&7?_(}C8b8t*+w~*(b!JTKlkmzYodP|X-
zqrW~M$9n)@r-@_HA^PfT@<v>K+WZ7LiVmB<kN?JOz^9(a&^gDM<S$5lQ&fjK{L&bo
zLH8uS)3a&L&Sm(v!=r6o%%K|&%gE`q_?|?*2JV>z*Rf6KXIh8F*!JK<{>s!S`>j(>
rrzXvR0we8}^gEF4yWh}J-(C1H{$}aBCEofE5TfN?)c*iIC%-=d;3S|Q
literal 0
HcmV?d00001
diff --git a/rtl_nic/rtl8168d-3.fw b/rtl_nic/rtl8168d-3.fw
new file mode 100644
index
0000000000000000000000000000000000000000..17309e299a23991bc8ea7aa64d371ba381cda7
70
GIT binary patch
literal 1584
zcmb7_&ud&&6vyvOW{#;*GqpmA5fh{<p>$^2skEy>LTzo*v|=T(n-*030|ZlO;oFQG
zTMKSPagn5`AR{EGD_wMUZmm&5#gx8IlL{@&xY9|QPW+si_h@w2f$+WOo*(ynzvsN0
z*GBi}OQn~Gi~0P4-TBh)Vj=wJSH?P<3gOF;-@m7@cTb@(T-bN8R6JPP7cRfGD`dlv
z218aMSO~TEzIFTW&8!qmL0PS}OwDyuW72e&b%XtTU<956TenP;=ZWbz9Y~pG(yWbj
z&NSOg{EPp~BPPk4AaABjEV<P~rdprr<7w0Mk}3U}X`I+?^Vl`h680Rvl-D0OwLdX!
zJmCDSX?+cB!1r#9_rSX8_BqpeIBx&S^z?R9dC@fDwMR@lsWpdPb-UWN`#EcbSoe>y
zuKF6^E6!noyX-I>t8_IObA<P3jN|eCi5OpX+%z2pBQOtE&}yP!T4|dux^}DhE}4q4
zZ*s4xPED`9>j~3eZ^HX|;#N$nADJ$b<2)jG_<1X6>{y9RQ^(Moo<xs#_i}Tb4}a$y
zp`&AV%Jlin!}ysDK5DqH2VehIA35_`(*itN7fcs8ci{`uGV4T(!{qrq907eE{O-=l
zF*QNoXX(i`lYTM1GZgoP9{K#VxZAMb?GAT~_tL-8*YCS=O?r2#NDtNRVGrCknU^Qg
z@;Pchdy>As&AePeGxD5E<+f??i0PX*m=R|04%pfM)0AUB;gLa``VS9tn)vF}@}6~S
z9HsYO<Ed_q&OSBj?0au2aE?a1>p(5n$aV2P<i<eyH4h4XeI2n*H16A~G5!XB?u(e~
zN0|dZ>sH=WAUE|cnsLtRMbjm;eTjLkH0UWa(TR(>rUp$J&c9MMeI3VSJcigXj&8n3
z-6__yJ#c%b%WaW4SSp)dNAqcTF7CvhBj?Ai-NsJ7#g_9rZ8`&wbiymPJHErr3%-7O
znD+iV?|9E=#p~BjnT~U>Lrv4bvgz6lVpGfm->mzi_f4m%;cw5x8D@@mpkuGX1A7fk
z@AGEWelnGbt6b$<KaNh+7<|n1^M|HhzWqOVC%zkCuI`&2w5dnlR*t<1|CrxDaNf!{
zv%w70+jKC!fR2tgu~W?G4Q$7C&Tmq`c9s~{1J~jFJNkaW-Zs-!zmvZ~aP{}@Q|{a*
zFH7xBbWOo4fPVk$m8?z(?LmJFe**({ZaA&5+`}6_#IxO}<PG0|PiK$+0m<)QUJh0t
literal 0
HcmV?d00001
diff --git a/rtl_nic/rtl8168d-4.fw b/rtl_nic/rtl8168d-4.fw
new file mode 100644
index
0000000000000000000000000000000000000000..b35fb1b70eae2bdadad668b79462c9b94c0b00
8f
GIT binary patch
literal 1408
zcmb7^OGuPa6vyw3^PSAB86$`?bO>n|%}kAzD;Lts$COl<Z4xTlv<wmwj@l+oXcx55
zX(5HdM7gR(L5sGTffyx?IvNy=t;%Q9?|MH=mwlUa&*Pr+KmT*S+uTqcOD5~0iCFCD
z{#bH<B5pQ(wP>k;G3_Q+eIS1DKs+9eAF4?vYLZ7x-{mUfnMy4;o*E;@44-;t^`8Y#
z)rcDPbYWgJzbN|6N^IYeQ^;G$`DxL?4$-nQ(b4UqW3{4nb)ua?^tb3~(V-!yXV3@3
z&Y!_Q*yw!r{Pei!n@-X0JT;q~4CA+YxWTule0j#n!YN<YBeSBDG0}Lp=<gPA<wR$C
zM0>%w>Pv_o#23DRJ|$X8?$#>NiXWmmaNo7P%z&fM$3eb`tw)|LvWdIqrfA84%a_JB
z7~u@QfW=GvO=Q1E`~w#sB0kc;&R2vl?0f-y9=_5H+&rc3BhhC1Up@D(<Kl#?VNSX{
z5!*YMT95+)(UEVW?~Q1sGLx%rMs_Bx-|3B>W~081-acR(hU=-{Zgz<|QN8G9*v||*
zz*i`cd#mWVJ)&23i#}woAMQ~T&Zfa~5+2T%ixxjYa=&|4^s8@w4<8ms8XPY|8}D4P
zu{H-YtM_wk8(Npcx7(OmX4627<uuK?)Hq(U@Y0AqM;$9eaF?T=J^$su2#&Y><3D8i
z&x;0`&HwB{mOY5sypy8W;?#lb9{997k^x8lu&a@!-YQn&%E8)C+z`EI9uo7|#pKab
z<jT-T7T)Z+i23iZy9725Y_+3sJ_gRSqHjCt8~vr#xnuPeX67w(9}Jf)j!AH}fh*|i
z;L4((@O>@pOGViES8e!5u-SYiUDSOoI(J(1^D)thUF`6PXcxJHC8GQA&u96cE{V30
zZ>0sDotyFX5I7bWz_o;(Jg;g+Pt#K%ExIWndWZcOeaAadEV}EH=+blkN%ktV;_$Cw
zyat{eF>ClN=G?D;`Z9VW+?gmmg3atjM;5-IQ>QRNedH2vQ#<=*v5XV*k$!H2dGi20
zVH>+HdZP<`+?`8t@4o0VeD3rduASrv81myE@8%s;?jTd#i9~~HJ{R#eR`MKf(Y3d6
J*~VKN-yhTU5+48n
literal 0
HcmV?d00001
diff --git a/rtl_nic/rtl8168e-3.fw b/rtl_nic/rtl8168e-3.fw
index
cb494071d0273c7b3102b97552f4bc7b756c0e17..d3497e897c447bce05859be45cd7ca3f9ad7a2
a3 100644
GIT binary patch
literal 5568
zcmZvgdvKK16~OQACN~j+1Pmk}mShtWo<R}_P=Y!eO#my8fWZcw5uL^gj<x(j$7;16
zUKN5^RFEo)!SPWw!D)R=eE>lsrU+^TU$n(dNO)?3iUDF^`#ZaL1v_Q<=J%a*&pogE
z$TvG{>bSx&g;&j+RWfbf)xWK}WnN)n!I;AFCjKwP%Z-V~tTzSYMiq`3Rah7-EGiyb
zP&}s4tggysG)qi|kt8_CWJ<a(J^G%{yD7g^bUdM?KQs${#)Ko0OcM#1V2bhAq#3iu
zn8boa_3`6)k_j69e||g?iR*gQXq-*zJ2jm-Ji&Ash5W;Y42k(kLZ20V?~Ejh7%P#8
zG51B(r>XZd7KtP~Ik{eK<GI^Fe@WuG*z}Vg#*<W-3^Sl_iYK0Oz9$3VreAxK1r6gt
z$85(O$3c#{j(KoXl_!JYv5+T2V4%#Cp*sGQC&OUjbDj)`>FYfi0rLwy$%lU8kA(Xx
zJ-H0_V*V(&qSTWDXf}FM2pfOp$!NHkIAc^#enpOB9mhG2cl^2I1jk~>iSP*iE?4<p
zPp*Lb=6G@?JdHjCwVo1qfILfKZ}KdIhCWS#LZ2qX)O$Rc0yV#Dbez0?;drg%RL5zK
z(;a6(?N>R}e$9lt=))|i{;q?c!wOhKyxCCudA*Xn?top7d+eKjQi}W%3^KnKCfw*r
z9ZY%Mlb4~c``_Uk*u4Rh>F=AcCw09A4fb!tdE~PNPGNj23?grX^O5VJ{|QgF!y4ke
z0~7JT1MaQ&qyZix&b#od{hsWEUC8gjGf#Tb2=69-Utd4TroWfKWcrr|Pf%w+7$9DM
zm_fXBXg07<;mz24uo(_eJ$}ofFn^{Sp9OXPbudIfE1>pkwvzbQs~-DbLXBSub^aW<
z33)C&M}C=p*0sWuJZRt*upGbZVDjzs2M&6c{=i+MJ=q0cp^xuF?bmJ{N8STd$>Rf9
zOrJi4jqJBi;c4pn9Cj}E<O>+aPZ$<4uNi8b7O4IX!d&#ND&wzB$I%~xHz6N}3DkE4
zHeh!YYJZNwQsm=M<DP)0p77)wxb{m=zJ-45zJsarJvj-}$n$$RqQR3+xR3Eua5nO3
z_z3bD*#595UGVD;Pkw-X$FQz}e)8HitSi)Wm8P7=x<d7z31@`3UtnV?_lwG(dXfzf
z<2MKDei#G;OFYSiQ<$Fzhv0uO3?UDJpEYv7zyR}x!65U7E2nb5z^@t4hbI{y317kA
zWpH2<_Y3?R`U047fcpjNeK;DnKg9h4ClId~R)x3^pyeJaftue{Q1iPQYJR0~682?K
z^P2=U&Sdx)ey70nx40jme=+w1oQD0iF#l;!ro#2e)8MznpAIwL@ni-(!TfSJJ`?J?
zR>8!#J-HQjZ}Mb5yp#D0;41dfZBXs*gzK;M<o7Ux{@(?Ykne`IAy57Q%UFkd;B@4B
z;myc@gcm*G$$fA?=TcyZbFdixh51Y1P4r<YH1vBJOh&&P>V5SmxSD+Khq}Hippef>
zm_pyGVNdd21;1n8J^<HYzZ$CjgYXRYe}?Jxo~(h1$PdAuoQsEHfccL=Jtu3S-Y@H%
z{3z6ZJ_dE)J)?T^eHQAvJ*P73^gMh4yT3x+r!T-R&gF~nb@Xq+>qFd&@F;!R0&hg#
z3Qr?%gPLzW98Z4Rm0P$M;aU2(15Vh<y$Jg-{w@sQe<$>j&wEPx*Qk2-*FT}|<6TPh
z@57Va@4I1N^n2he^dG>5#Q)IgKY}6jO>i4|e+nm)=Vx#McAvu$oXaoZUC8_4Mfm#{
z)PDRM>OTGt{F3<xpzh-@q1G3M>Ez$6q`nrYbsU76Z>y5{ZSeaQ+)Hq11NRctb9DrM
zOC3j{)^QAK9mk>8@s-nm4YiJTxSu>aR1fw0#puH~&0X2C@30WxMrAfbObhqBa*Zd6
zz2H{v8|7Z^4dppc#wzJYnesmDm8qWGq9niHDe1#<C$Cd3WWOkTd-9sn$NDL$`x7O8
z+LU4LOC|T<C;cJ$v?*WmBw-jNZkiJNTqS;rltJzdCGjhilQ`GPZci3D{W4`a`&-HW
zenuJb<W(hp8<hCnr^HXI62B*%oG={u5b>4F%T;1mq{MHjlD|I{O8itQYl*K+=3Fbu
zXRR_!eB~nID?`LrYJ4SiwJM2oQc0YI5s>vwQ{pFAsqvM}FI7@kg_3zyPQOTr-(^bd
z*Shg%ocyX1e+^E*&*@v0_&upyN&I}cl=#Xp@s;>1Qc`EBk~%AtUBp*5Q@@h<J_Ffv
zhCQd>;PLP76{`}_+n+wdH~Bs*t=p|UzRJp~HY@ELtSseyTZxqw(0pa(1<%SF-rLVu
z{6YMjf?=Levz2C^Q`mQo!q-rz!<Xv(*rxcQJ_D^3#NR{2<6Ts~-O6%74&!Tum6gQu
zWg_D@vl^X`_X~9o#B{4K)IDgW2D|r&w_`K8owlOm!8-CyjlF9wsh3#E(wI+@SC*9_
zymwz?<#a+UejR>#2AS81+=?CY#Y?SRie25UR{G>v$+=+c*%4NTtG`?;J0<pBcLKXS
zD|r{#4PIg;LG1!ocGJ%hym#L~Zp76*6Ukk3*52ombGVc^VMq_^23eVyW2G9oW-GSF
z%24KSK7f2xY;IKk2DuoSvBf%04mG2Zi8)N=$B~C46EiB)r<xq(L??fSJOJ4``5gK6
zwNlR-=$dbL-08R#ZbskDqy5u9gy~T{?_T6xiLV;s>-vu*p09>Eyw{AhGL3mHVb&7*
zTF%$~4t}d!@zuauy7%^Xt!TV3zO+Yqx~|k3&4K*GMOHpwJU|TXQ}c&b)K4O7Tiu52
ze8uIsKR<I{AI^H$k|VWlSR8wAPx=4#c9Z)@)T(=_4%^;yc%Q)9zDNxp@lJdL&tTKi
zW#wb)YB`9!m-8@}_d`|=e{5wh`Y_MIeELGZH*mHx;h_R6`7nGKTY9uRK7S9fm|uRI
z^Re5?9`%83^W|2qfK?sHXWbn3O(k>Y_Qo&!vDNSN^x`b~=sXuYObuD=#Y;GI;Z`ec
zaXr4G`KvGTpL+^l$uVD1J-#~7pPNMe*q&kkc2IM8!TCK<$sW+&-@%%ta^5O8#?DpU
z9oXb>{%Wn%&ZcjJtqh=dwu!yI4f##_PyI=8dCULE^)b1CIf1y%j+oBG<(=o{CF*lm
zOzs^YcQJf%*~R!#b}=5MuV*<63Eix1+}6eF!&>WEp7R5>2dp&t*xQC!JU{wzdGukf
z-bZ>L*7d<A+e+UQD;MV0NIk6!8KWOfOE_2T&v;MIwXpWAMO}nm(VONl&vYv@(2b;z
zojJ@ShlxA^*2?lM)4EHoWMkh4-#?i{F56ho8OxYYPMze_VOh^dW3_g%o(rgbDP#UJ
zD^D+V`$lUc_7LVbW#Pj|Oy?uKof;X7-dp&)I2h|$G>?g~{zuoB7@CvzwwvDS{n5o4
z(0KZHpzeMvQ*|z9Mem48L*Iy#NiJd4qf4zMmhM>{AIBJV>sb8$(Y>c<N_AE2KR>zV
z=>9u||0*kKqpcKCLkDY7iQkRPuS>F$JeE6;vzG8wYz?Dlnzf78aAmB93-^TX`!MUj
z+}%szobx%fki$65;UMQ{yp>)J#By~UB(KBORtohD+(g`BD_8QqnYDkJdvrWK9Z!DY
zo2?wdt~E8r>Sq2P9VK66y-S;BvIfRV3HG{<?b~B^dN<cy%{tMW=$+V3t@v3)kE8N2
zE5}v7)XHV_r8UjUF=V|jJB|}~5x!K`c+A;2nRva?c`-Zvo1pVGPA&SB39)`f`&1I^
zQ#CQo5q!||$YIu+d%`5p_ZHT5H{Te{HN59NZ>0xu+Xiy~^>FXMu`)3J{xfRheKvMg
z?ptOp+_Oac&bLiab4`?gu!cvVp1(-MXMDz_8sn?i-yLJ`re42~e)>D7F?<*W#hm}0
hGyXedfA<^eP`=&uH%Qf&@a|9UC(E;A-}lD-`!C;a@LK=?
literal 2804
zcmaKuS!|S56vyvuXDEwdX=z8WolZ+xrAP=!Vq#-Nc`(M9m<Srf13vJiQ4@-BIfa&`
zMS>d`6R?UeXp0DaGtxc~Ow<@#AOWSxH%JAQw21-A(sulv@B5~F;_~q2-gE9*{^x(s
zJu}W#sjG16T$w8jxh!jsTkSNBzTQ=$cQ3}A^PHP)Mp<?7_Vv!~b}qHVg}!E6^Ecaa
zhfmgFTN>J?u(?)9sXFmvo4q7vYMSp0SElP4GJ2TRHD>fnTi?j&5!S;mW%Q`YZ)UX1
z<d-uVi<N20Wi-K>U`?@(F3G5{4)4oon)L)SwfH$4IpT&j{MJ>M`xqL)kaQJVo32nd
zmeFOlj%KvBf^`JhR%G8V;^Xi!U9={r)D{;VUM=cT<8VP#+eHtdi(eBhi;2c;pA)Sw
z?jICg!`}SjJ4FwwXqzXR-!8hN4f{&uyl7=BI_%n_I_ypNR#dl3v>n|y<p1iBXwxat
z3;RXi!KQ6MwD(=n?u6*u&7v#F*;|9m`d%mxB1?<tAT|?NyVr?s$Jbp3TSjy@`@tK+
zJ+hL+YU~}uj{Wv%Ov4(=Nn(1}1Dx4T{7QqpakQ4Y5{;rIU`!bYKZ`!FS#&A;k^4li
zCyC>Uc2d{fS<x&!wq3vud0vy~Li71fbpE}>v3-~5`}i!j{kNhoMEoaJi&jVcmvJ@=
zJMWU{F6zpG?OF=Ha)DgTI|2MP5x?2sDxRfkMQg(|4@?$kPBG4$JL1%d)<xo61@m~E
zxuSC;XRpG4azyk7ybaw1;|9@f#5Vr=o)7r`tzL9F_$%@2rnal0JQ=xiTA;fg)lCm{
zx1zckfo^YA5X<-Fek|Uu=7?@47|`wHzT(*CxUbe<xfgn{6h4-KYlxgrgJ=I_^lAEM
zIr_EK@ezI8iy!^ySnIpl{|TonME4Adj?zEHT7RHctM?}L#^~Lyr@+Gbhar|uYI}5^
zXtTxG%YBh!UWe$9&mhxJ)tmW{JGe)CXOEN9!}i#5aBd|}pJ?U`-&xUfVC<)-(|kL2
zh^_}q`Z>`l1<_~W*uniHmDrx+>lZzL1Ra>VW1@S(WAEn>y>aXw(c|>!R`T@0-I=85
z*)VR=_XxR8UBMrWMeJ7p5Vei%;X6UUk8<DO_Rfp`^1J9C#7x6q0zR|g@ZkGmsP{O_
z(;uU(N%I4%^-@O@@1*YbzLY!j^(~@zWpD4Tr+xi4c&g>S!PA97V$BX$YVvWsCi*&Y
z{e1U}u4KQMyY8F?Pb-6at+u;39o*+;<AfR0F$o>^LR{0uPx98b1U1^5Zp{-DKAPz1
zI^xBt`_mkEIUL~Xq>dEWYw#UDi0ypQmazZL_H%e%P_(7C6!lCu+l$yP4Bkp@7<VIi
z7h&5vKz?$L&lGYb;Hnxwk2AwkjgMC%dWAmE(ns-x=m*3$t~$w60*9^aJBX72-wgA;
z6=180_~t_2o4h&S7oJPtdEA$nTksu$-+$x7n?Nst+n*(tgPtG9H&JwAb1*Mb?Ysdy
zkMLu@m%wke_-6|u_&Cc_XQJpA;mZ6RH5ShX76m-GkD2kD*^EC;&DQrL;2-23%|40V
z=DW=&<J_ZHP4CEIcXfa|uF?mwP(F%02{|6hUn3`wE$@g6_^=re-@u#UtYr{i^foI-
zcrV76=^SsW*|5;FzRu%K2ycemu_}6Rzvuun$>b#Qi*bsx#&X;uM+^NsM4Y}&<Redx
zFHQ~qoVpzJ^$hEAW|qyHRZ~Q()-VIWbF!cJ1~>im{8Vz-`~JVLoPJ1tB3k(VpR;cq
z549yM4sWVk$qW8X<XXk|Uzp~?dm}aE3&HPpjQ6?tvjF3!v&>}THF4M7;BBXOiog9s
zF>vEIZ8AI_W~DZNKJ5$Yws{?ujYFHW#^(WkJG!`Y<!z7G1&-)U&tto>L9`)HUyyrg
zPV@=(`B&iJVbPyF^k9Cnhkmj>Slwfy59L$Fqy2}R%G%R#hg|&c<--4_g@POZZ(97n
VdHX+Uxf?6kf6?+D|9>1#e*sYqwB!H)
diff --git a/rtl_nic/rtl8168e-4.fw b/rtl_nic/rtl8168e-4.fw
new file mode 100644
index
0000000000000000000000000000000000000000..1ded93185fff12bd206ebf0762471b5b1434d6
cd
GIT binary patch
literal 3984
zcmZ9PYiv~45y#K&ddJ2XFvJfoZtS&r6N9~&r%O^(AR!GTh6D<z3P}r;sOm!zA6f~-
z@C=0nrBa%zN+5P68iimJ^+VN^rgoa7=}W30X;tMzwQFoc44CvGFvRipH}{?eQfaUL
zGjry3=FFVCckQYL>8A9u%`3jYW9!r3S+;rY($$-neRs>&&FOSwQ+lCman5~^aBiP#
zT+oniYDlM3>3Plb=QcMjcF%2@!fK7WiB1c_$*x)}W0fIY5A9m3)Yc1@R)Fq%G3PS5
zT(!$3T&l#y+sd4K-nnFB(tO-nFLWtqzuW7%TwYe(W^vlhcWEUyJgG`;fdBNRi5mGS
zL|zlp*K$c!Cz{JSw>xJ(U3Z+dT&~FTMct;G&s`D~TF5ijm20sJv=l4?CxWq+fd+=#
z1Dyo6Zws^rbgZX5)_Sb-IN9SAk5j?+ErCu02U-H14klIvI>Xjq33Miy{&}FYz{;Nl
zdJkCN7-&5hC;n{kqYZ)10moq903KQ%Xd~#32bu=|@Qpy{f_sS5WODMG=W)Kr1s)fA
zT;y@F$7YXT1TW%miSfGvy%+p&W1#neL&#e|+s{()pX9k597mojKu4YK2bDTK0G93y
zbR}r{J!tFX^%ai~d0gdjwa14&J_1_3T0yJV8t_llVJ&F>9tHmaJ_fcCZyjj$TyIET
z?cj3obufk9DX`%2Ks&&aUj}*_wDbN2_$GR9f<@Hz*WhUOa|U$i{|4Ml9&dpwS^q7V
zg6{&i!*_%6mjitpY$ML^z$E_P0YB&t^j)x@IPZa%KMM5s;7$1V!5hZ{oe(S6TIzWh
zSVX<bz)#p$IhY_$1vrs7m7sfxz675{KLE4fB$MN>6;$lk`1Q4***^-lP`}4OtIs+^
z;;uJ2`d<Yt{sz$OH-hc(o4^t3av>i1pP2wz-wT@ETj1mP|D%_m_h|Fvcx*27v*?tW
zjEi1hDVkw6ujfRyO|%nP{F<l(Z9V?1=oCYH=85jk%YP<%Mn#WgM6-uPe|SVRRt=vO
ztv-w_27RXtKPG$bPT5h>He~M;|4gUo;X&f|N0@*%{#REcjDL(j_|$<2W6y~0`B1bs
zE&2jJkMxOl{aEx6w7V?&S|Iv7^xzF)&mb{uj~Sj8a?J8vU&>koK4y3sJ_?X!hNAtX
zI<OlP(Q)jr>=mtvQwMY=U{f$0>Drz`-O^}(rhDuz@-yAPivF}lbUO6#fap*Gxn@K=
zj*6D0u%p&TdeMV-dqk_u=D(sZ*L(Y?MVIUsts|Ff<H@y7^eFM_P49lu_hyOCG#Xz&
zx<_<sUT<oom$0=>qRqseWb{VzK+kf&$v&T=z8Uh#I?fNAj{RBk?TU$BB5ngVnO5>-
zEt4hhTG6p7ay=`$zYBktL|duhy+$t<ePfR3i})NKfhXpC_B50fy?PV-r$k43M0?Cn
zj(lbl7r)tuMIS*n`xJYu!!9AZfG2TXRCvNTe~WyN@BBX-^6e_ZH@VIs*K2POONjGg
zw8tClF(3OG>SpJ3ZWa2DJ&;Rm1My0b)4NuO4aloG$4rVG;1jIp*Rtd`8Ck~54nx<_
zug8ho&sslyKNtTUWuoJml{j@U`@-YY0r@8Ke5ITEQkTvch+UTx{g<!vRqAYc4}TW*
z$xV9KdgT-~96RkcT~zC7W*|OA^jp*<Gsu4EuMjztOpoaKoua$2AAdr$oZfljoanZ{
zW3x^4Mj^8Yf71Aq5x<vwI@gJwSdJb#b{CvjgbwRQ56%@Gz~3PGUjlnXbSIcO&$CN(
zk<pxE2YpaGNAyeVIl~;3_0qS<x0i$Jd1fsRzizMSX!5_0vk&hceC|eOxs1GayB2n@
zWbnC%Gn|IsI6d_r>M(=;2<K^!XcE2-yX!;f&J?xtp5k?T@j1(Mi93v+TXTqAVjB5k
zm*LFJf34*`ihhDlk(c%3L;HLjYCejZhv$Ny1TptvJKX4fW<Q^2hBH5Rz|W<{;NG|u
zqgb@~ATxK3+}r3~TfZZ3v%PXS>RDUsn-%5c+M}Gt6WiuEyf?3SynM&r$hDbV!}%VF
z&TNQ&j4`_z&ZN)F!gb#(?rYpP%x1L{{le?sc9rOA&h~9=Lp#rhc7x0pYfGN;Yo5>F
zjrlXkOrUSjv;Nq~T=c%<dCp@H-u5{hyPdoBd~#}3+fH(_GpK+!zxkQINz8-zY%3Q2
z6Gn7)v}hCOR$7HFb7#FRove{p484A6d!KbO?`_O!88MCTq6fasV|U0PcgSeY#oifq
zKBtk*-;b|0WNY#3*OH*!Bc^NpS;c%D=k7RJ;OFJf(VD#v>>LjEFq5pA-B$J-^1}T9
zzn*-@lIwbt_lsWea?|Oj7mLsd_X=HzKif}&{p>qUUSH>~$A7r5Y3yqyJxsk!KT8jd
z!ZwEg66%p8MyPiTy9<$BkFQSw{>-nVhUT{ozvbi``aw3&*ENZs1b$3skiM}Rbtcg-
z!6#UVzsYgd$ko<H$k*NppN-r;zs#qi2k>X_t4tkpORm-%J(Ht**Y1=}3q{Ag%bm;_
zRpak`in<&YO`qaUe1e)Z`+I{upZ+HI>3-3L=I=?-i|F-o7KVrIY(9?8#_pK2YodF1
z5Pf^U4Yo#lo#ffEjCovu4f$lL#Z~NgkbB4vFhj;u%Q@7bm;M<r|9$9PBJK`+8E^5h
zIsO238HX&0^sJxE-r}4>Ucx<TvlzbLh-L55aF#EE{d_NRKK3qnl{4t0_wO#Ip2X^_
zr&sgz-OQ<{U!Bd_aevS2p^k?{|3Vyl$K`S{7jv%ExmdS-gGIFK4!;@sPxyn{N{xX#
z{#_b=gMHb)>&EfllBZ|~{~gChbj)Ne6&iy#I&S<66&i;(I>BT533#Imj7Pr!-smKc
z=_lch7M?^=g$lgUZVV6qal>3bDdj(OjXp?jpZ_j(j)fF|P;Y&==D!;&_~yOyJ2IE6
kbgsqrUD=&tPq|!`*}_+KFNL?fXN2;=oFWgpqnbGPKZs`*OaK4?
literal 0
HcmV?d00001
--
1.7.3.2
^ permalink raw reply related
* kernel 2.6.32-27 crash in tcp
From: Vishal Study @ 2011-06-15 2:43 UTC (permalink / raw)
To: netdev; +Cc: vishal.study
Hello,
I'm using kernel 2.6.32-27 on a MIPS platform and get following kernel crash.
I'm running open-source IET iSCSI Stack and get this error during
heavy load test. Any ideas on what could be happening or if this is
known issue?
Thanks,
Vishal.
------------[ cut here ]------------
WARNING: at net/ipv4/tcp.c:1457 tcp_recvmsg+0x7c0/0x990()
recvmsg bug 2: copied 8D07C2AD seq 1EAA6653 rcvnxt 8D083A71 fl 4000
Modules linked in: iscsi_trgt test_ethernet ipv6
Call Trace:
[<ffffffff801127d0>] dump_stack+0x8/0x34
[<ffffffff8024a8e8>] warn_slowpath_common+0x70/0xb0
[<ffffffff8024a97c>] warn_slowpath_fmt+0x34/0x40
[<ffffffff805c0130>] tcp_recvmsg+0x7c0/0x990
[<ffffffff8057bd8c>] sock_common_recvmsg+0x34/0x58
[<ffffffff8057a050>] sock_recvmsg+0x100/0x140
[<ffffffffc0081800>] do_recv+0x120/0x238 [iscsi_trgt]
[<ffffffffc0081ef8>] istd+0x5e0/0x1408 [iscsi_trgt]
[<ffffffff80264820>] kthread+0x88/0x90
[<ffffffff80221ea8>] kernel_thread_helper+0x10/0x18
^ permalink raw reply
* Re: [ipv6] valid_lft and active connections
From: YOSHIFUJI Hideaki @ 2011-06-15 3:37 UTC (permalink / raw)
To: Stefan (metze) Metzmacher; +Cc: netdev, yoshfuji
In-Reply-To: <4DF753C6.1000700@samba.org>
Stefan (metze) Metzmacher wrote:
> Am 14.06.2011 13:41, schrieb YOSHIFUJI Hideaki:
> > Hello.
> >
> > Stefan (metze) Metzmacher wrote:
> >> If I use ipv6 addresses with valid_lft != forever, the ipv6 addresses
> >> are removed from the interface if the valid_lft expires, even if there're
> >> established connection which use with address.
> >>
> >> Would it be possible keep the address until the last active connection
> >> is closed? Otherwise the usable of the privacy extensions will make
> >> very long living tcp connections impossible.
> >>
> >
> > I cannot imagine why you do not hear RAs before the address expires.
>
> They do not reset the valid lifetime counter for temporary addresses.
>
> And I think that valid_lft and preferred_lft should work with a manual
> configured setup in a similar way.
This is because of RFC3041 Section 3.3:
| 1) Process the Prefix Information Option as defined in [ADDRCONF],
| either creating a public address or adjusting the lifetimes of
| existing addresses, both public and temporary. When adjusting the
| lifetimes of an existing temporary address, only lower the
| lifetimes. Implementations must not increase the lifetimes of an
| existing temporary address when processing a Prefix Information
| Option.
It would be make sense to allow extending valid lifetime of non-deprecated
addresses, but not sure.
> > And well, I don't think it is a good idea because it is not what
> > "valid lifetime" means.
> >
> > We have 3 states:
> >
> > 1) time <= preferred lifetime
> > 2) preferred lifetime < time <= valid lifetime
> > 3) valid lifetime < lifetime
> >
> > You can make new connection during the period of 1 and you can continue
> > using that connection during the period of 1 and 2.
>
> But it means tcp connection can not last longer than the valid lifetime of
> a temporary address, which is very ugly as the application layer will
> run into
> timeouts instead of getting an immediate error when the kernel drops the
> related ip.
>
Valid lifetime represents administrative "hard" lifetime. If it
expired, all address must be gone.
> > Ask network administrator to advertise longer "valid" lifetime, if
> > needed, and you may want to make net.ipv6.conf.*.max_addresses larger.
>
> My aim is to have a preferred lifetime of say 4 hours, in order to have
> no limit
> on the lifetime of tcp connections, I'd have to set valid lifetime to
> forever,
> which means that I'll have about 180 addresses on an interface after
> a month (8760 after a year) which are mostly all unused.
This is how it works.
How can you determine if one address is not unused at all?
For UDP, applications only know, for example.
In fact, RFC3041 Section 3.4 says:
| As an optional optimization, an implementation may wish to remove a
| deprecated temporary address that is not in use by applications or
| upper-layers. For TCP connections, such information is available in
| control blocks. For UDP-based applications, it may be the case that
| only the applications have knowledge about what addresses are
| actually in use. Consequently, one may need to use heuristics in
| deciding when an address is no longer in use (e.g., the default
| TEMP_VALID_LIFETIME suggested above).
Of course, we could have some sysctl (but default must be off
(or moderate; do it if the number addresses exceeds some limit).
> Do you know a better solution?
Ask your administrator to advertise larger valid lifetime.
Otherwise, other implementation will have similar issues, anyway.
We could have above "optimization" with sysctl.
And, please note that if you want to change address preference in
an application, consider using IPV6_ADDR_PREFERENCES socket
option.
--yoshfuji
^ permalink raw reply
* [PATCH v2] net/r8169: update the new parser for the new firmware
From: Hayes Wang @ 2011-06-15 3:45 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Update the parser for the new firmware which is embedded some information.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 96 +++++++++++++++++++++++++++++++++++++--------------
1 files changed, 70 insertions(+), 26 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index ef1ce2e..bd9e78f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -594,6 +594,14 @@ struct ring_info {
u8 __pad[sizeof(void *) - sizeof(u32)];
};
+struct fw_info {
+ u32 magic;
+ char version[32];
+ u32 fw_start;
+ u32 fw_len;
+ u8 chksum;
+};
+
enum features {
RTL_FEATURE_WOL = (1 << 0),
RTL_FEATURE_MSI = (1 << 1),
@@ -1740,21 +1748,57 @@ static void rtl_writephy_batch(struct rtl8169_private *tp,
#define PHY_DELAY_MS 0xe0000000
#define PHY_WRITE_ERI_WORD 0xf0000000
+static int is_firmware_valid(const struct firmware *fw)
+{
+ struct fw_info *f_info = (struct fw_info *)fw->data;
+
+ if (f_info->magic == 0) {
+ size_t i, fw_size;
+ u8 checksum = 0;
+
+ for (i = 0; i < fw->size; i++) {
+ checksum += fw->data[i];
+ }
+
+ if (checksum != 0)
+ return 0;
+
+ fw_size = (fw->size - le32_to_cpu(f_info->fw_start)) / 4;
+ if (fw_size < le32_to_cpu(f_info->fw_len))
+ return 0;
+ } else if (fw->size % 4) {
+ return 0;
+ }
+
+ return 1;
+}
+
static void
rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
{
- __le32 *phytable = (__le32 *)fw->data;
+ struct fw_info *f_info = (struct fw_info *)fw->data;
struct net_device *dev = tp->dev;
- size_t index, fw_size = fw->size / sizeof(*phytable);
+ __le32 *phytable;
+ size_t i, fw_size;
u32 predata, count;
- if (fw->size % sizeof(*phytable)) {
- netif_err(tp, probe, dev, "odd sized firmware %zd\n", fw->size);
+ if (!is_firmware_valid(fw)) {
+ netif_err(tp, probe, dev, "Invalid firwmare\n");
return;
}
- for (index = 0; index < fw_size; index++) {
- u32 action = le32_to_cpu(phytable[index]);
+ if (f_info->magic == 0) {
+ netif_info(tp, probe, dev, "firmware: %s\n", f_info->version);
+
+ phytable = (__le32 *)(fw->data + le32_to_cpu(f_info->fw_start));
+ fw_size = le32_to_cpu(f_info->fw_len);
+ } else {
+ phytable = (__le32 *)fw->data;
+ fw_size = fw->size / sizeof(*phytable);
+ }
+
+ for (i = 0; i < fw_size; i++) {
+ u32 action = le32_to_cpu(phytable[i]);
u32 regno = (action & 0x0fff0000) >> 16;
switch(action & 0xf0000000) {
@@ -1769,14 +1813,14 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
break;
case PHY_BJMPN:
- if (regno > index) {
+ if (regno > i) {
netif_err(tp, probe, tp->dev,
"Out of range of firmware\n");
return;
}
break;
case PHY_READCOUNT_EQ_SKIP:
- if (index + 2 >= fw_size) {
+ if (i + 2 >= fw_size) {
netif_err(tp, probe, tp->dev,
"Out of range of firmware\n");
return;
@@ -1785,7 +1829,7 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
case PHY_COMP_EQ_SKIPN:
case PHY_COMP_NEQ_SKIPN:
case PHY_SKIPN:
- if (index + 1 + regno >= fw_size) {
+ if (i + 1 + regno >= fw_size) {
netif_err(tp, probe, tp->dev,
"Out of range of firmware\n");
return;
@@ -1805,8 +1849,8 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
predata = 0;
count = 0;
- for (index = 0; index < fw_size; ) {
- u32 action = le32_to_cpu(phytable[index]);
+ for (i = 0; i < fw_size; ) {
+ u32 action = le32_to_cpu(phytable[i]);
u32 data = action & 0x0000ffff;
u32 regno = (action & 0x0fff0000) >> 16;
@@ -1817,54 +1861,54 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
case PHY_READ:
predata = rtl_readphy(tp, regno);
count++;
- index++;
+ i++;
break;
case PHY_DATA_OR:
predata |= data;
- index++;
+ i++;
break;
case PHY_DATA_AND:
predata &= data;
- index++;
+ i++;
break;
case PHY_BJMPN:
- index -= regno;
+ i -= regno;
break;
case PHY_READ_EFUSE:
predata = rtl8168d_efuse_read(tp->mmio_addr, regno);
- index++;
+ i++;
break;
case PHY_CLEAR_READCOUNT:
count = 0;
- index++;
+ i++;
break;
case PHY_WRITE:
rtl_writephy(tp, regno, data);
- index++;
+ i++;
break;
case PHY_READCOUNT_EQ_SKIP:
- index += (count == data) ? 2 : 1;
+ i += (count == data) ? 2 : 1;
break;
case PHY_COMP_EQ_SKIPN:
if (predata == data)
- index += regno;
- index++;
+ i += regno;
+ i++;
break;
case PHY_COMP_NEQ_SKIPN:
if (predata != data)
- index += regno;
- index++;
+ i += regno;
+ i++;
break;
case PHY_WRITE_PREVIOUS:
rtl_writephy(tp, regno, predata);
- index++;
+ i++;
break;
case PHY_SKIPN:
- index += regno + 1;
+ i += regno + 1;
break;
case PHY_DELAY_MS:
mdelay(data);
- index++;
+ i++;
break;
case PHY_READ_MAC_BYTE:
--
1.7.3.2
^ permalink raw reply related
* Re: IGMP snooping: set mrouters_only flag for IPv4 traffic properly
From: Fernando Luis Vázquez Cao @ 2011-06-15 5:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Herbert Xu, netdev, Hayato Kakuta
In-Reply-To: <20110614132212.2ac83c6c@s6510.ftrdhcpuser.net>
On Tue, 2011-06-14 at 13:22 -0400, Stephen Hemminger wrote:
> On Mon, 13 Jun 2011 12:02:43 +0900
> Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> wrote:
>
> > Upon reception of a IGMP/IGMPv2 membership report the kernel sets the
> > mrouters_only flag in a skb that may be a clone of the original skb, which
> > means that sometimes the bridge loses track of membership report packets (cb
> > buffers are tied to a specifici skb and not shared) and it ends up forwading
> > join requests to the bridge interface.
> >
> > This can cause unexpected membership timeouts and intermitent/permanent loss of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
> >
> > A snooping switch should forward IGMP Membership Reports only to
> > those ports where multicast routers are attached.
> > [...]
> > Sending membership reports to other hosts can result, for IGMPv1
> > and IGMPv2, in unintentionally preventing a host from joining a
> > specific multicast group.
> >
> >
> > Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> > Tested-by: Hayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
> > ---
> >
> > diff -urNp linux-3.0-rc2-orig/net/bridge/br_multicast.c linux-3.0-rc2/net/bridge/br_multicast.c
> > --- linux-3.0-rc2-orig/net/bridge/br_multicast.c 2011-06-09 13:34:04.164261031 +0900
> > +++ linux-3.0-rc2/net/bridge/br_multicast.c 2011-06-09 20:04:23.473930447 +0900
> > @@ -1424,7 +1424,7 @@ static int br_multicast_ipv4_rcv(struct
> > switch (ih->type) {
> > case IGMP_HOST_MEMBERSHIP_REPORT:
> > case IGMPV2_HOST_MEMBERSHIP_REPORT:
> > - BR_INPUT_SKB_CB(skb2)->mrouters_only = 1;
> > + BR_INPUT_SKB_CB(skb)->mrouters_only = 1;
> > err = br_ip4_multicast_add_group(br, port, ih->group);
> > break;
> > case IGMPV3_HOST_MEMBERSHIP_REPORT:
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Can I take that as an acked-by for the IPv6 patch too?
Thanks,
Fernando
^ permalink raw reply
* Re: [PATCH 2/2] batman-adv: compare_eth() should take const pointer arguments
From: Sven Eckelmann @ 2011-06-15 5:56 UTC (permalink / raw)
To: David Howells; +Cc: Marek Lindner, Simon Wunderlich, b.a.t.m.a.n, netdev
In-Reply-To: <20110614235142.3724.92963.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: Text/Plain, Size: 1825 bytes --]
David Howells wrote:
> compare_eth() should take const pointer arguments so that it can be passed
> const pointers without the need for a cast, leading to:
>
> net/batman-adv/vis.c: In function 'vis_data_insert_interface':
> net/batman-adv/vis.c:146: warning: passing argument 2 of 'compare_eth'
> discards qualifiers from pointer target type
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Marek Lindner <lindner_marek@yahoo.de>
> cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
> cc: Sven Eckelmann <sven@narfation.org>
> cc: b.a.t.m.a.n@lists.open-mesh.org
> cc: netdev@vger.kernel.org
> ---
>
> net/batman-adv/main.h | 2 +-
> net/batman-adv/vis.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
> index 148b49e..e6fc798 100644
> --- a/net/batman-adv/main.h
> +++ b/net/batman-adv/main.h
> @@ -172,7 +172,7 @@ static inline void bat_dbg(char type __always_unused,
> *
> * note: can't use compare_ether_addr() as it requires aligned memory
> */
> -static inline int compare_eth(void *data1, void *data2)
> +static inline int compare_eth(const void *data1, const void *data2)
> {
> return (memcmp(data1, data2, ETH_ALEN) == 0 ? 1 : 0);
> }
> diff --git a/net/batman-adv/vis.c b/net/batman-adv/vis.c
> index c39f20c..34053ac 100644
> --- a/net/batman-adv/vis.c
> +++ b/net/batman-adv/vis.c
> @@ -143,7 +143,7 @@ static void vis_data_insert_interface(const uint8_t
> *interface, struct hlist_node *pos;
>
> hlist_for_each_entry(entry, pos, if_list, list) {
> - if (compare_eth(entry->addr, (void *)interface))
> + if (compare_eth(entry->addr, interface))
> return;
> }
Sry, but this patch doesn't apply here (net-next-2.6/linux-next)
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [stable] Please revert "iwlagn: Support new 5000 microcode." from 2.6.32 and 2.6.33
From: Stanislaw Gruszka @ 2011-06-15 5:57 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski
Cc: Greg KH, stable, donald.h.fry, reinette.chatre, wey-yi.w.guy, ilw,
linville, ak, linux-wireless, netdev, linux-kernel
In-Reply-To: <20110615011443.GA13680@herton-IdeaPad-Y430>
On Tue, Jun 14, 2011 at 10:14:44PM -0300, Herton Ronaldo Krzesinski wrote:
> On Tue, Jun 14, 2011 at 04:03:44PM -0700, Greg KH wrote:
> > On Mon, Jun 13, 2011 at 03:13:18PM -0300, Herton Ronaldo Krzesinski wrote:
> > > The patch ("iwlagn: Support new 5000 microcode") shoudn't have been
> > > applied on 2.6.32 and 2.6.33 stable trees, it doesn't support new
> > > firmware file format, thus if the new firmware is on the disk, loading
> > > fails, as reported on:
> > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336
> > >
> > > Support for the iwlagn new firmware file format was only added beginning
> > > with 2.6.35 (commit "iwlagn: implement loading a new firmware file
> > > type"), so iwlagn works with new firmware only with 2.6.35 or later.
> >
> > Can I get an ack from the developer of the patch and the people involved
> > with it first? It was asked to be backported for a reason, so I would
> > at least like to get the people who asked for the backport to have a
> > chance to respond please.
> >
> > It's only nice, why would you exclude them?
>
> I didn't intend to exclude anyone and I'm just reporting it, it didn't
> came to my mind CC'ing people while sending to stable, and hopefully
> everyone related are CC'ed now.
>
> Also note that this revert request is for 2.6.32 and 2.6.33 *only*
>
> And seems the right thing to do for them.
>
> The other stable release where this was applied (2.6.35) looks fine
> but these two are too old to support the new firmware (don't work, need
> extra patches backported which weren't, like the commit I mentioned --
> commit "iwlagn: implement loading a new firmware file type"), as yourself
> can check reading the code/bug report, and what I wrote.
ACK for revert. I could be wrong, but I think some more patches, except mentioned
new format patch, are needed to make driver work reliably with the new firmware.
Stanislaw
^ permalink raw reply
* Re: [PATCH 1/2] batman-adv: count_real_packets() in batman-adv assumes char is signed
From: Sven Eckelmann @ 2011-06-15 5:59 UTC (permalink / raw)
To: David Howells
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, Marek Lindner,
Simon Wunderlich
In-Reply-To: <20110614235132.3724.57632.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 738 bytes --]
David Howells wrote:
> count_real_packets() in batman-adv assumes char is signed, and returns -1
> through it:
>
> net/batman-adv/routing.c: In function 'receive_bat_packet':
> net/batman-adv/routing.c:739: warning: comparison is always false due to
> limited range of data type
>
> Use int instead.
>
[...]
> -static char count_real_packets(struct ethhdr *ethhdr,
> - struct batman_packet *batman_packet,
> - struct hard_iface *if_incoming)
> +static int count_real_packets(struct ethhdr *ethhdr,
> + struct batman_packet *batman_packet,
> + struct hard_iface *if_incoming)
> {
This one doesn't apply on linux-next/net-next-2.6, but I will fix it by hand.
Thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] batman-adv: count_real_packets() in batman-adv assumes char is signed
From: Sven Eckelmann @ 2011-06-15 6:58 UTC (permalink / raw)
To: David Howells; +Cc: Marek Lindner, Simon Wunderlich, b.a.t.m.a.n, netdev
In-Reply-To: <20110614235132.3724.57632.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: Text/Plain, Size: 1087 bytes --]
On Wednesday 15 June 2011 01:51:32 David Howells wrote:
> count_real_packets() in batman-adv assumes char is signed, and returns -1
> through it:
>
> net/batman-adv/routing.c: In function 'receive_bat_packet':
> net/batman-adv/routing.c:739: warning: comparison is always false due to
> limited range of data type
>
> Use int instead.
>
> This is also looks a bit weird as (presumably signed) is_duplicate is
> constructed by OR'ding together the unsigned results of get_bit_status()
> (though the latter only returns 0 or 1).
Sry, had to catch the train and had no time to explain it further.
It is correct that is_duplicate will only have 0 and 1 stored, but the
window_protected function (called before the loop) may detect that the packet
has to be dropped and we return in that case -1.
I don't know who started to use char in those places, but thanks for reminding
me how much I hate it and that I wanted to check the rest of the code. :)
I will submit the corrected patch in a pull request later this week to David
S. Miller.
Thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: Vlad Zolotarov @ 2011-06-15 7:11 UTC (permalink / raw)
To: David Woodhouse; +Cc: Dave Miller, Eilon Greenstein, netdev@vger.kernel.org
> - Add a separate directory for the bnx2x FW.
> - Post a new FW version: 7.0.20.0
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> ---
> WHENCE | 3 +++
> bnx2x/bnx2x-e1-7.0.20.0.fw | Bin 0 -> 161144 bytes
> bnx2x/bnx2x-e1h-7.0.20.0.fw | Bin 0 -> 168552 bytes
> bnx2x/bnx2x-e2-7.0.20.0.fw | Bin 0 -> 290952 bytes
> 4 files changed, 3 insertions(+), 0 deletions(-)
> create mode 100644 bnx2x/bnx2x-e1-7.0.20.0.fw
> create mode 100644 bnx2x/bnx2x-e1h-7.0.20.0.fw
> create mode 100644 bnx2x/bnx2x-e2-7.0.20.0.fw
David, did u have a chance to apply it? Pls., let me know if u want me to
resend it to u.
thanks,
vlad
^ permalink raw reply
* [PATCH] ppp: use PPP_TRANS instead of the magic number 0x20
From: Changli Gao @ 2011-06-15 7:58 UTC (permalink / raw)
To: David S. Miller; +Cc: Paul Mackerras, linux-ppp, netdev, Changli Gao
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
drivers/net/ppp_async.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index 6436ba9..c6ba643 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -524,7 +524,7 @@ static void ppp_async_process(unsigned long arg)
#define PUT_BYTE(ap, buf, c, islcp) do { \
if ((islcp && c < 0x20) || (ap->xaccm[c >> 5] & (1 << (c & 0x1f)))) {\
*buf++ = PPP_ESCAPE; \
- *buf++ = c ^ 0x20; \
+ *buf++ = c ^ PPP_TRANS; \
} else \
*buf++ = c; \
} while (0)
@@ -897,7 +897,7 @@ ppp_async_input(struct asyncppp *ap, const unsigned char *buf,
sp = skb_put(skb, n);
memcpy(sp, buf, n);
if (ap->state & SC_ESCAPE) {
- sp[0] ^= 0x20;
+ sp[0] ^= PPP_TRANS;
ap->state &= ~SC_ESCAPE;
}
}
^ permalink raw reply related
* [PATCH] phylib: Allow BCM63XX PHY to be selected only on BCM63XX.
From: Ralf Baechle @ 2011-06-15 8:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-mips, Florian Fainelli
This PHY is available integrated into BCM63xx series SOCs only.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
drivers/net/phy/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 392a6c4..a702443 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -58,6 +58,7 @@ config BROADCOM_PHY
config BCM63XX_PHY
tristate "Drivers for Broadcom 63xx SOCs internal PHY"
+ depends on BCM63XX
---help---
Currently supports the 6348 and 6358 PHYs.
^ permalink raw reply related
* tc match MAC destination
From: Andrei Popa @ 2011-06-15 8:12 UTC (permalink / raw)
To: linux-kernel; +Cc: pdoru.kernel, netdev
Hello,
I want to shape PVSTP+ traffic (traffic that has MAC destination
01:00:0c:cc:cc:cd) and it doesn't work.
I've tried
filter parent 1: protocol 802_3 pref 2 u32 fh 802::11 order 17 key ht
802 bkt 0 flowid 1:3
match 01000ccc/ffffffff at 0
but it doesn't work.
With
filter parent 1: protocol arp pref 1 u32
filter parent 1: protocol arp pref 1 u32 fh 801: ht divisor 1
filter parent 1: protocol arp pref 1 u32 fh 801::7 order 7 key ht 801
bkt 0 flowid 1:3
match 00000000/00000000 at 0
filter parent 1: protocol 802_3 pref 2 u32
filter parent 1: protocol 802_3 pref 2 u32 fh 802: ht divisor 1
filter parent 1: protocol 802_3 pref 2 u32 fh 802::3 order 3 key ht 802
bkt 0 flowid 1:3
match 00000000/00000000 at 0
action order 1: mirred (Egress Mirror to device ifb1) pipe
index 1923 ref 1 bind 1
I see arp trafic with tcpdump on ifb1, but no STP traffic or any kind of
traffic except arp, because I've matched all MAC addreses.
Can somebody verify that this match works ?
I use kernel 2.6.39.1.
Thank you,
--
Andrei Popa
0760 683 280
^ permalink raw reply
* Re: [PATCH] phylib: Allow BCM63XX PHY to be selected only on BCM63XX.
From: Florian Fainelli @ 2011-06-15 8:20 UTC (permalink / raw)
To: Ralf Baechle; +Cc: David S. Miller, netdev, linux-mips
In-Reply-To: <20110615080758.GA3226@linux-mips.org>
On Wednesday 15 June 2011 10:07:58 Ralf Baechle wrote:
> This PHY is available integrated into BCM63xx series SOCs only.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Florian Fainelli <ffainelli@freebox.fr>
>
> drivers/net/phy/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 392a6c4..a702443 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -58,6 +58,7 @@ config BROADCOM_PHY
>
> config BCM63XX_PHY
> tristate "Drivers for Broadcom 63xx SOCs internal PHY"
> + depends on BCM63XX
> ---help---
> Currently supports the 6348 and 6358 PHYs.
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 2/9] xen: convert to 64 bit stats interface
From: Ian Campbell @ 2011-06-15 8:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ben Hutchings, Stephen Hemminger, xen-devel@lists.xensource.com,
netdev@vger.kernel.org, Jeremy Fitzhardinge, David S. Miller
In-Reply-To: <20110614210756.GA22304@dumpdata.com>
On Tue, 2011-06-14 at 22:07 +0100, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 09, 2011 at 02:56:45AM +0100, Ben Hutchings wrote:
> > On Wed, 2011-06-08 at 17:53 -0700, Stephen Hemminger wrote:
> > > Convert xen driver to 64 bit statistics interface.
> > > This driver was already counting packet per queue in a 64 bit value so not
> > > a huge change.
> > [...]
> >
> > I think this driver will need to use u64_stats_sync.
>
> Ian?
I'll defer to Ben on this, but the case for needing u64_stats_sync for
64 bit values seems reasonable to me.
Ian.
^ permalink raw reply
* RE: [PATCH] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: David Woodhouse @ 2011-06-15 8:43 UTC (permalink / raw)
To: Vlad Zolotarov; +Cc: Dave Miller, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <201106151011.34758.vladz@broadcom.com>
On Wed, 2011-06-15 at 10:11 +0300, Vlad Zolotarov wrote:
> > - Add a separate directory for the bnx2x FW.
> > - Post a new FW version: 7.0.20.0
> >
> > Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> > Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> > ---
> > WHENCE | 3 +++
> > bnx2x/bnx2x-e1-7.0.20.0.fw | Bin 0 -> 161144 bytes
> > bnx2x/bnx2x-e1h-7.0.20.0.fw | Bin 0 -> 168552 bytes
> > bnx2x/bnx2x-e2-7.0.20.0.fw | Bin 0 -> 290952 bytes
> > 4 files changed, 3 insertions(+), 0 deletions(-)
> > create mode 100644 bnx2x/bnx2x-e1-7.0.20.0.fw
> > create mode 100644 bnx2x/bnx2x-e1h-7.0.20.0.fw
> > create mode 100644 bnx2x/bnx2x-e2-7.0.20.0.fw
>
> David, did u have a chance to apply it? Pls., let me know if u want me to
> resend it to u.
Hm, I don't think I did receive that. Last message I have from you in
that thread is Tue, 14 Jun 2011 13:53:34 +0300
Please resend.
--
dwmw2
^ permalink raw reply
* Hi Dear
From: monicagirl4god8g @ 2011-06-15 9:16 UTC (permalink / raw)
To: monicagirl4god8g
Hello
My name is Miss Monica.a 23 yrs old girl .I am average in height and fair in complexion ,am a loving and caring angel.I fine your mail contact today truly is quiet interesting to me then , i decide to contact you.i really want to have a good relationship with you. Beside i have a special something i want to discuses with you,so you can reach me through this my(monicagirl4god8g@yahoo.com)Hope to hear from you soon.i will send my beautiful pictures to you and also tell you more about my self. I know age will not be a barer to our relationship, what i need is just your love and caring. I will give you my best,
bye for now. care from
Miss Monica
^ permalink raw reply
* Re: tc match MAC destination
From: Eric Dumazet @ 2011-06-15 9:43 UTC (permalink / raw)
To: ierdnah; +Cc: linux-kernel, pdoru.kernel, netdev
In-Reply-To: <1308125523.30324.64.camel@ierdnac-hp>
Le mercredi 15 juin 2011 à 11:12 +0300, Andrei Popa a écrit :
> Hello,
>
> I want to shape PVSTP+ traffic (traffic that has MAC destination
> 01:00:0c:cc:cc:cd) and it doesn't work.
> I've tried
> filter parent 1: protocol 802_3 pref 2 u32 fh 802::11 order 17 key ht
> 802 bkt 0 flowid 1:3
> match 01000ccc/ffffffff at 0
> but it doesn't work.
>
> With
> filter parent 1: protocol arp pref 1 u32
> filter parent 1: protocol arp pref 1 u32 fh 801: ht divisor 1
> filter parent 1: protocol arp pref 1 u32 fh 801::7 order 7 key ht 801
> bkt 0 flowid 1:3
> match 00000000/00000000 at 0
> filter parent 1: protocol 802_3 pref 2 u32
> filter parent 1: protocol 802_3 pref 2 u32 fh 802: ht divisor 1
> filter parent 1: protocol 802_3 pref 2 u32 fh 802::3 order 3 key ht 802
> bkt 0 flowid 1:3
> match 00000000/00000000 at 0
> action order 1: mirred (Egress Mirror to device ifb1) pipe
> index 1923 ref 1 bind 1
>
> I see arp trafic with tcpdump on ifb1, but no STP traffic or any kind of
> traffic except arp, because I've matched all MAC addreses.
> Can somebody verify that this match works ?
>
> I use kernel 2.6.39.1.
>
> Thank you,
Hi Andrei
Since you refer to a very complex network setup, it would really help if
you provide a self contained script so that we can take a look.
We netdev guys saw your first mail days ago but are a bit busy, so the
7th point listed in "REPORTING-BUGS" would be nice :
[7.] A small shell script or example program which triggers the problem
^ permalink raw reply
* [PATCH for 3.0-rc4 0/2] dp83640: bug fixes
From: Richard Cochran @ 2011-06-15 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, David Miller, John Stultz, Thomas Gleixner
This series fixes two status frame related bugs in the driver for the
dp83640 phy. I am not sure whether you would call this a timer fix or
a networking fix, so I put both groups on CC.
Thanks,
Richard
Richard Cochran (2):
dp83640: fix phy status frame event parsing
dp83640: drop PHY status frames in the driver.
drivers/net/phy/dp83640.c | 24 +++++++++++++++++-------
1 files changed, 17 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH for 3.0-rc4 2/2] dp83640: drop PHY status frames in the driver.
From: Richard Cochran @ 2011-06-15 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, David Miller, John Stultz, Thomas Gleixner
In-Reply-To: <cover.1308129342.git.richard.cochran@omicron.at>
The dp83640 PHY provides time stamp and other information via special
PHY status frames. Previously, the driver decoded the frames and then
let the network stack drop them. This works fine when the PTP messages
come over UDP.
However, when receiving PTP messages via L2 packets, this creates a
problem. The status frames use the official PTP destination MAC address,
and so they are delivered to user space along with the "real" frames,
causing confusion for applications.
This commit fixes the issue by simply dropping the PHY status frames
in the driver.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/phy/dp83640.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index ead323e..2cd8dc5 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -1044,8 +1044,8 @@ static bool dp83640_rxtstamp(struct phy_device *phydev,
if (is_status_frame(skb, type)) {
decode_status_frame(dp83640, skb);
- /* Let the stack drop this frame. */
- return false;
+ kfree_skb(skb);
+ return true;
}
SKB_PTP_TYPE(skb) = type;
--
1.7.0.4
^ permalink raw reply related
* [PATCH for 3.0-rc4 1/2] dp83640: fix phy status frame event parsing
From: Richard Cochran @ 2011-06-15 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, David Miller, John Stultz, Thomas Gleixner
In-Reply-To: <cover.1308129342.git.richard.cochran@omicron.at>
If two eternal time stamp events occur at nearly the same time, the
phyter will add an extra word into the status frame. This commit fixes
the parsing code to recognize and skip over the extra word.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/phy/dp83640.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index b0c9522..ead323e 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -543,11 +543,20 @@ static void recalibrate(struct dp83640_clock *clock)
/* time stamping methods */
-static void decode_evnt(struct dp83640_private *dp83640,
- struct phy_txts *phy_txts, u16 ests)
+static int decode_evnt(struct dp83640_private *dp83640,
+ void *data, u16 ests)
{
+ struct phy_txts *phy_txts;
struct ptp_clock_event event;
int words = (ests >> EVNT_TS_LEN_SHIFT) & EVNT_TS_LEN_MASK;
+ u16 ext_status = 0;
+
+ if (ests & MULT_EVNT) {
+ ext_status = *(u16 *) data;
+ data += sizeof(ext_status);
+ }
+
+ phy_txts = data;
switch (words) { /* fall through in every case */
case 3:
@@ -565,6 +574,9 @@ static void decode_evnt(struct dp83640_private *dp83640,
event.timestamp = phy2txts(&dp83640->edata);
ptp_clock_event(dp83640->clock->ptp_clock, &event);
+
+ words = ext_status ? words + 2 : words + 1;
+ return words * sizeof(u16);
}
static void decode_rxts(struct dp83640_private *dp83640,
@@ -643,9 +655,7 @@ static void decode_status_frame(struct dp83640_private *dp83640,
} else if (PSF_EVNT == type && len >= sizeof(*phy_txts)) {
- phy_txts = (struct phy_txts *) ptr;
- decode_evnt(dp83640, phy_txts, ests);
- size = sizeof(*phy_txts);
+ size = decode_evnt(dp83640, ptr, ests);
} else {
size = 0;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: Vlad Zolotarov @ 2011-06-15 10:08 UTC (permalink / raw)
To: David Woodhouse; +Cc: Dave Miller, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <1308127394.3450.103.camel@i7.infradead.org>
>
> Hm, I don't think I did receive that. Last message I have from you in
> that thread is Tue, 14 Jun 2011 13:53:34 +0300
>
> Please resend.
I've sent it to u once again a minute ago.
If for any reason u don't get it, the patch is avaliable at
http://linux.broadcom.com/eilong/FW-7.0.20.0/
thanks,
vlad
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: Lennert Buytenhek @ 2011-06-15 10:21 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: Mika Westerberg, ynezz@true.cz, netdev@vger.kernel.org,
ryan@bluewatersys.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <ADE657CA350FB648AAC2C43247A983F001F381FC56CE@AUSP01VMBX24.collaborationhost.net>
On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
> Lennert,
Hi,
> You are listed as the maintainer for these EP93xx related pieces:
>
> ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
> CIRRUS LOGIC EP93XX ETHERNET DRIVER
> CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER
>
> I can take over the edb9315a with no problem. It actually falls under
> arch/arm/mach-ep93xx, so the entry could just be removed from MAINTAINERS.
If you have the hardware, that's fine with me.
> For the OHCI driver, I'm in the same boat as the Ethernet. If you are
> no longer maintaining this driver I'm willing to handle it but would
> like someone to step up as a co-maintainer. Hopefully someone that
> has some grasp of that subsystem.
Same here.
> Your also listed in the source as the maintainer of these ep93xx boards:
>
> ADSSPHERE adssphere.c
> EDB9302A edb93xx.c
> EDB9315 edb93xx.c
> EDB9315A edb93xx.c
> GESBC9312 gesbc9312.c
> TS72XX ts72xx.c
>
> I'm willing to handle those also since they are under arch/arm/mach-ep93xx.
Do you have all these boards, though?
thanks,
Lennert
^ 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