* [linux-firmware v2 1/2] rtl_nic: update firmware for RTL8111E-VL
From: Hayes Wang @ 2011-08-10 12:22 UTC (permalink / raw)
To: dwmw2; +Cc: romieu, netdev, Hayes Wang
Updated firmware with stability fixes.
Version: rtl8168e-3_0.0.1.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 2 +-
rtl_nic/rtl8168e-3.fw | Bin 2804 -> 3264 bytes
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/WHENCE b/WHENCE
index 4b88f1f..a463417 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1626,7 +1626,7 @@ File: rtl_nic/rtl8168d-2.fw
File: rtl_nic/rtl8105e-1.fw
File: rtl_nic/rtl8168e-1.fw
File: rtl_nic/rtl8168e-2.fw
-File: rtl_nic/rtl8168e-3.fw
+File: rtl_nic/rtl8168e-3.fw (Version: rtl8168e-3_0.0.1)
Licence:
* Copyright © 2011, Realtek Semiconductor Corporation
diff --git a/rtl_nic/rtl8168e-3.fw b/rtl_nic/rtl8168e-3.fw
index cb494071d0273c7b3102b97552f4bc7b756c0e17..43d1b8641fb09d2f8dd91998ed78c1deb7c71a7a 100644
GIT binary patch
literal 3264
zcmaKvYiyKd7RR4XJEv1F2Cx-|%P_rAM4+9iSgT*G$Qn#^V@Nhxb+hmRKA3FcMoAX$
zr$R?<l^E|avDV%FqB0d(q94pMd@!2qCYvonBD=bIr?%kknwf+^%cW)foq68TS3{iS
z&3T^loXh{*p7$N+oO^Kh@A|U6eY-YZzdh5H>B^=vz1=-M-PtT>_Pd*BdA)N<x9!f}
zo@{3G_HDP`wf(jScJA7q&1QPDnRIs3%{_fLXEW{v=T@s*=G3_sS1G$R^r+kFv=M%{
zOTl-)uX8SNZlwvO)x}14I@611YPu%d{v+9?4xO|^wmFoIBQsrzt2(LLHhHPPMjLtF
zcP+Z3KdA?yZckD_F#1GN4?zz;nAE@6{>h{sw*5m%t*dL%xJzn1v>qCV&SjD+(3v-r
z+6euWJ+V}MIDEt`&hXjMy0nU+9}Ep{nI3OirVjs;MiWUrYqXNohIyXfY;-|VJB-5L
zZFCyB<^H^31r)tzqjSg^#oi{P=xqu4FB?U#iX(!-fx&pu962RdG0~Z=q5(OZsfg;R
z=oq}%v}jA6Xq~OwL`OAT-y(VseAA2lRrFu*hXc{#GosH9Ba>oZ6ip4mLvA?Ad(QKo
zkMj0o8@bP%=*MHC1II-tkBPpB%<z=x_)DUNdeQbl(HrqO-p(G{8SYE$6FJcmGV_e?
z5M5*xdy7MQ1T3XS^o%|v`U=!+JcAGSt>`;R(HB^kE(rbObuAa;myyHH@~CgHt_t@J
z_zupC4xyXQqu1=$F?8NoO&kI7c8ac@WL+W#){|4Bvuj1qH~75epBHUTv*z5f9zti&
zy`m$;6KfLvcU<%-%k`t8*&fk`S?_ay=yQ4%Hqp2JfXV$v^zZ9MH`;og=wa+M*!mUG
zzjcZ3v-M}957hkc7oFcK+Dg5L!5L$}iL({R1>bnPZNxSWj>$H^w|eK1OAvp1L~ms_
zjES>&hiFH57O*#bYif4Z{KO7<>5SMpw=rUeT&<0qJ!0{YgA3%nd=ZTIi#{FZ;@B=<
zum5(7_JTi!UV+%oh5H5UQ;R+Ce3ZAu^DaesS9{)T)X{8Jb*Zn}OAkhP*MI@ubM#aU
z*|rgCc#8bc>&@gNL(FA-{u&!23*gg-iC*~BxZy44WgNXRY7gx$us%ahZxnsCEILR3
z)nfezv0A(riMNg!Is7ZIaK0hLa)8+8Un@FjHmLhFKCV5$EZ>3LPSJG{x%-fF|MY!z
zU<b7Vf1AmIvG7aLPpEJ1i0Com{eoUN$$T{OB){bOia95S^0T79#cqZ5u7&h7eV1~g
zU*0bI6|#qTj!%FUUJaAQwTf5+Y!^NuKRM!K){|fGoJ1E}rfa^=9s(nA+WZ-IoBhl5
zo8{$G;<ntx>4S+2qW=SL@U`f@|EEsaNYNvw(joseXYglDrik90pS=LR0s5wsxP#?>
z-D+!M9<+Y4^;Le|ZtH~avkumlr&5pT%1J2sSp}VdJ{IB#9vAHk{pD|Bmbyf5q7TN&
zQ=v}u1o^gjV#IUoDe6W}`a-)g5nZxZbT8*~)+5ANq}R{VU)8xAAns1;#re#i!9^`C
zj#li);@oA}TsITSlD9Z{Xg1mRki9O9CzL(CM09;k_Gx50yx*A*MW;4+pSAm@nk&;I
zw^QJ+VQFG*ch-TkqV@P{$5-%rm_y`)CU3`bYr2=1tEw*8n!x(KZX0o%E<JAZ+!4{W
z{G0B_d#{|21o_wthCIC#TSMP73pIT6z_*XH>3O_o)^bjc*456zkN~q`$bZ8bve!k=
zz-M+wkum@4YiHytL9TLk24*|kz}e80=-cEW;ru+e+AN;%^K5y{mEa@){oRk9RK!jk
zJ*)fJ1a{9+kGgPwhW&i@oZ0<7MqiHN)A5+yi}c6+%!Qqmh(E?$mC?QYsy{Dr-UQFy
zOZV;byhZe!Gn_y3*t^Z%t+}G;YU((G&Bel=ILFvq@0+h#_!iSeX3B6BF5v_I!>k=O
zu{ln)!3W>B-M;q=?V@Ms1-n}plDm6;0p``r|7-aCT=XSoatU|MAD4>$2ixU}k7qWV
z-<q!yz6`?&a-qbMBj;t4e;9w*ypq2>{$lh(Wsi?-1-<buF_gQw>+tW;T|WYr0s7c#
z*yC$hy{n07!6MOv-02I+eF54%82L5<Lv3&0CWg)Ki>tvj{3p@R4-=RAxbjzs%kCw+
zf9zcuY~{XV?uUxpErtu*H-Kx%`iR<ADSYeS;t{YQo0|~*8hrNcW4X;+9@Ad7KGgXL
zooX*4SEa<Tn0`3b;=i48r@;)b#GM!YmYTzV^*)0Bp<lEgTmd!eX%oGhb#XU2-NH9v
z0H1noJBkfkp9JrnqMM6xi^0Cz7eSBq|72hLK6T;$fl9?W6w>y8p!SV#{{uGL|A2P?
OJ^RD|0{iy%zwZF4*F!x3
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)
--
1.7.3.2
^ permalink raw reply related
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Ben Hutchings @ 2011-08-10 12:48 UTC (permalink / raw)
To: Michael Guntsche
Cc: Jiri Pirko, shemminger, sebastian.belden, netdev, linux-kernel,
davem
In-Reply-To: <CAMvAeqOZ9OoV5KxTbn0+sPxJ=AkSrb__31GShVshDkX6NUXgNw@mail.gmail.com>
On Wed, 2011-08-10 at 13:51 +0200, Michael Guntsche wrote:
[...]
> Jiri, there seems to be another bug lingering in the bridge code,
> which might cause this problem in the first place but I am not really
> sure. I looked at the ethtool output some more and I noticed that some
> features were enabled on the Bridge which should be off.
[...]
That's an intentional change. There are software fallbacks for TX
checksumming and VLAN tag insertion. Bridge devices (and some other
software devices) now always advertise them so that the fallback is not
used until and unless it is known that the real output device doesn't
support the feature.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/6] Security: define security_sk_getsecid.
From: Stephen Smalley @ 2011-08-10 12:49 UTC (permalink / raw)
To: Rongqing Li; +Cc: Casey Schaufler, netdev, selinux, linux-security-module
In-Reply-To: <4E41DDEB.9040904@windriver.com>
On Wed, 2011-08-10 at 09:24 +0800, Rongqing Li wrote:
> On 08/10/2011 08:57 AM, Casey Schaufler wrote:
> > On 8/9/2011 5:43 PM, Rongqing Li wrote:
> >> On 08/10/2011 12:13 AM, Casey Schaufler wrote:
> >>> On 8/9/2011 12:28 AM, rongqing.li@windriver.com wrote:
> >>>> From: Roy.Li<rongqing.li@windriver.com>
> >>>>
> >>>> Define security_sk_getsecid to get the security id of a sock.
> >>>
> >>> Why are you requesting the secid when you're just going to
> >>> use it to get the secctx? Why not ask for that directly?
> >>> Is there ever a case where you only want the secid?
> >>>
> >> Hi:
> >>
> >> As I know, we have not method to get secctx directly.
> >
> > You are defining the method! Ask for what you want!
> >
> > The whole notion of secids is a holdover from the bad old
> > days when SELinux was a user space based enforcement mechanism.
> > The audit system was implemented when SELinux was the lone LSM
> > and unfortunately and unnecessarily propagated the use of secids.
> > If an object has a secid it must also have a secctx. The
> > interfaces that use secids could just as well use the secctx.
> > It is wasteful to create a new interface that fetches a secid
> > just to turn around and ask for the secctx in all cases.
> >
>
> Do you means I should write a method like below
> security_sk_getsecctx(struct sock *sk, char *secctx, int *len)?
>
> But secctx only is used to user. secid is used to source code to
> compute and compare the access permission.
>
> And I do not see the same method like
> security_task_getsecctx(). but security_task_getsecid() has been
> implemented in kernel source code.
Unlike Casey, I don't think secids are a bad idea or just a holdover -
we find them to be quite useful and efficient in SELinux. But in this
instance, he is correct that there is no reason to first fetch a secid
only to convert it into a context. There are other cases where you do
in fact want to avoid generating and managing the life cycle of a
security context string until you truly need it, and thus a secid makes
sense. So if you want to add a security_sk_getsecctx() hook, feel free.
There are some existing examples, e.g. security_inode_getsecctx() for
inodes, security_getprocattr() for tasks. Note that they use a slightly
different interface than what you describe above.
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: [linux-firmware v2 1/2] rtl_nic: update firmware for RTL8111E-VL
From: Ben Hutchings @ 2011-08-10 12:54 UTC (permalink / raw)
To: Hayes Wang; +Cc: dwmw2, romieu, netdev
In-Reply-To: <1312978979-1808-1-git-send-email-hayeswang@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On Wed, 2011-08-10 at 20:22 +0800, Hayes Wang wrote:
> Updated firmware with stability fixes.
> Version: rtl8168e-3_0.0.1.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> WHENCE | 2 +-
> rtl_nic/rtl8168e-3.fw | Bin 2804 -> 3264 bytes
> 2 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/WHENCE b/WHENCE
> index 4b88f1f..a463417 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -1626,7 +1626,7 @@ File: rtl_nic/rtl8168d-2.fw
> File: rtl_nic/rtl8105e-1.fw
> File: rtl_nic/rtl8168e-1.fw
> File: rtl_nic/rtl8168e-2.fw
> -File: rtl_nic/rtl8168e-3.fw
> +File: rtl_nic/rtl8168e-3.fw (Version: rtl8168e-3_0.0.1)
[...]
Please don't write the version in yet another way. It should be:
File: rtl_nic/rtl8168e-3.fw
Version: 0.0.1
Or, if you insist on duplicating the name in the version:
File: rtl_nic/rtl8168e-3.fw
Version: rtl8168e-3_0.0.1
Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Fwd: [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: Sebastian Pöhn @ 2011-08-10 13:11 UTC (permalink / raw)
To: Linux Netdev, wangshaoyan.pt
I was annoyed by the compiler warning for quite a long time ...
Patch seems to work. Please put version information in your email header on future patches.
Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
Reviewed-and-tested-by: Sebastian Pöhn <sebastian.poehn@belden.com>
---
drivers/net/gianfar_ethtool.c | 26 +++++++++++++++++++++-----
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 6e35069..25a8c2a 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -686,10 +686,21 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
{
unsigned int last_rule_idx = priv->cur_filer_idx;
unsigned int cmp_rqfpr;
- unsigned int local_rqfpr[MAX_FILER_IDX + 1];
- unsigned int local_rqfcr[MAX_FILER_IDX + 1];
+ unsigned int *local_rqfpr;
+ unsigned int *local_rqfcr;
int i = 0x0, k = 0x0;
int j = MAX_FILER_IDX, l = 0x0;
+ int ret = 1;
+
+ local_rqfpr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ local_rqfcr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ if (!local_rqfpr || !local_rqfcr) {
+ pr_err("Out of memory\n");
+ ret = 0;
+ goto err;
+ }
switch (class) {
case TCP_V4_FLOW:
@@ -706,7 +717,8 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
break;
default:
pr_err("Right now this class is not supported\n");
- return 0;
+ ret = 0;
+ goto err;
}
for (i = 0; i < MAX_FILER_IDX + 1; i++) {
@@ -721,7 +733,8 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
if (i == MAX_FILER_IDX + 1) {
pr_err("No parse rule found, can't create hash rules\n");
- return 0;
+ ret = 0;
+ goto err;
}
/* If a match was found, then it begins the starting of a cluster rule
@@ -765,7 +778,10 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
priv->cur_filer_idx = priv->cur_filer_idx - 1;
}
- return 1;
+err:
+ kfree(local_rqfcr);
+ kfree(local_rqfpr);
+ return ret;
}
static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc *cmd)
^ permalink raw reply related
* Use of 802.3ad bonding for increasing link throughput
From: Tom Brown @ 2011-08-10 12:07 UTC (permalink / raw)
To: netdev
[couldn't thread with '802.3ad bonding brain damaged', as I've just
signed up]
So, under what circumstances would a user actually use 802.3ad mode to
"increase" link throughput, rather than just for redundancy? Are there
any circumstances in which a single file, for example, could be
transferred at multiple-NIC speed? The 3 hashing options are:
- layer 2: presumably this always puts traffic on the same NIC, even in
a LAG with multiple NICs? Should layer 2 ever be used?
- layer2+3: can't be used for a single file, since it still hashes to
the same NIC, and can't be used for load-balancing, since different IP
endpoints go unintelligently to different NICs
- layer3+4: seems to have exactly the same issue as layer2+3, as well as
being non-compliant
I guess my problem is in understanding whether the 802.3/802.1AX spec
has any use at all beyond redundancy. Given the requirement to maintain
frame order at the distributor, I can't immediately see how having a
bonded group of, say, 3 NICs is any better than having 3 separate NICs.
Have I missed something obvious?
And, having said that, the redundancy features seem limited. For hot
standby, when the main link fails, you have to wait for both ends to
timeout, and re-negotiate via LACP, and hopefully pick up the same
lower-priority NIC, and then rely on a higher layer to request
retransmission of the missing frame. Do any of you have any experience
of using 802.1AX for anything useful and non-trivial?
So, to get multiple-NIC speed, are we stuck with balance-rr? But
presumably this only works if the other end of the link is also running
the bonding driver?
Thanks -
Tom
^ permalink raw reply
* Re: Use of 802.3ad bonding for increasing link throughput
From: Chris Adams @ 2011-08-10 13:23 UTC (permalink / raw)
To: netdev
In-Reply-To: <4E427499.8060108@cyconix.com>
Once upon a time, Tom Brown <sa212+glibc@cyconix.com> said:
> So, under what circumstances would a user actually use 802.3ad mode to
> "increase" link throughput, rather than just for redundancy? Are there
> any circumstances in which a single file, for example, could be
> transferred at multiple-NIC speed? The 3 hashing options are:
It isn't going to increase the rate for a single stream. However, few
setups have only a single TCP stream going across a segment, so this is
still quite useful for real-world setups to increase the total
throughput.
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
^ permalink raw reply
* Re: [PATCH v2] pch ieee1588 driver for Intel EG20T PCH
From: Joe Perches @ 2011-08-10 13:40 UTC (permalink / raw)
To: Toshiharu Okada
Cc: richard.cochran, netdev, linux-kernel, qi.wang, yong.y.wang,
joel.clark, kok.howg.ewe, tomoya-linux
In-Reply-To: <1312956783-11460-1-git-send-email-toshiharu-linux@dsn.okisemi.com>
On Wed, 2011-08-10 at 15:13 +0900, Toshiharu Okada wrote:
> This patch is for IEEE1588 driver of Intel EG20T PCH.
> EG20T PCH is the platform controller hub that is used in Intel's
> general embedded platform.
> This driver adds support for using the EG20T PCH as a PTP clock.
> Would you review this patch, although this driver has not been tested yet?
Just trivia...
> diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
[]
> +/**
> + * struct ch_1588_params_ - 1588 module paramter
parameter
> + */
> +struct pch_params_ {
> + u8 station[STATION_ADDR_LEN];
> +};
names for struct types ending in _ are pretty unusual.
[]
> +/**
> + * get_decimal() - Returns the decimal value of the passed hexadecimal value
> + * @ch: The hexadecimal value that has to be converted.
> + */
> +static s32 get_decimal(u8 ch)
> +{
> + s32 ret;
> +
> + if ((ch >= '0') && (ch <= '9'))
> + ret = ch - '0';
> + else if ((ch >= 'A') && (ch <= 'F'))
> + ret = 10 + ch - 'A';
> + else if ((ch >= 'a') && (ch <= 'f'))
> + ret = 10 + ch - 'a';
> + else
> + return -1;
> +
> + return ret;
> +}
hex_to_bin
> +pch_probe(struct pci_dev *pdev, const struct pci_device_id *id)
[]
> + if (ret != 0) {
> + dev_err(&pdev->dev,
> + "%s:could not enable the pci device\n", __func__);
> + goto err_pci_en;
> + }
It seems all of the dev_<level> logging messages include __func__.
I think these __func__ uses are not particularly valuable and could
be removed.
> + /* retreive the available length of the IO memory space */
retrieve
> + if (!request_mem_region(chip->mem_base, chip->mem_size, "1588_regs")) {
> + dev_err(&pdev->dev, "%s: could not allocate register memory "
> + "space\n", __func__);
Please don't split format strings.
dev_err(&pdev->dev, "could not allocate register memory space\n");
or if you must
dev_err(&pdev->dev, "%s: could not allocate register memory space\n",
__func__);
[]
> + if (strcmp(pch_param.station, "00:00:00:00:00:00") != 0) {
> + if (pch_set_station_address(pch_param.station, pdev) != 0) {
> + dev_err(&pdev->dev,
> + "%s: Invalid station address parameter\n"
> + "Module loaded; But, station address not set "
> + "correctly\n", __func__);
dev_err(&pdev->dev,
"%s: Invalid station address parameter\n"
"Module loaded but station address not set correctly\n",
__func__);
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Wolfgang Grandegger @ 2011-08-10 13:47 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
Scott Wood, PPC list
In-Reply-To: <1312945564-6626-6-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Hi Robin,
On 08/10/2011 05:06 AM, Robin Holt wrote:
> In working with the socketcan developers, we have come to the conclusion
> the Documentation...fsl-flexcan.txt device tree documentation needs to
> be cleaned up. The driver does not depend upon any properties other
Your first sentence could be misleading. Please just describe what the
patch does and why, something like:
"This patch cleans up the documentation of the device-tree binding for
the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
properties are not needed as the frequency of the source clock is
fixed..." and so on.
> than the required properties so we are removing the file. Additionally,
> the p1010*dts* files are not following the standard for node naming in
> that they have a trailing -v1.0.
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
> arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> 3 files changed, 4 insertions(+), 73 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>
> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> deleted file mode 100644
> index 1a729f0..0000000
> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -CAN Device Tree Bindings
> -------------------------
> -2011 Freescale Semiconductor, Inc.
> -
> -fsl,flexcan-v1.0 nodes
> ------------------------
> -In addition to the required compatible-, reg- and interrupt-properties, you can
> -also specify which clock source shall be used for the controller.
> -
> -CPI Clock- Can Protocol Interface Clock
> - This CLK_SRC bit of CTRL(control register) selects the clock source to
> - the CAN Protocol Interface(CPI) to be either the peripheral clock
> - (driven by the PLL) or the crystal oscillator clock. The selected clock
> - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> - The PRESDIV field of CTRL(control register) controls a prescaler that
> - generates the Serial Clock (Sclock), whose period defines the
> - time quantum used to compose the CAN waveform.
> -
> -Can Engine Clock Source
> - There are two sources for CAN clock
> - - Platform Clock It represents the bus clock
> - - Oscillator Clock
> -
> - Peripheral Clock (PLL)
> - --------------
> - |
> - --------- -------------
> - | |CPI Clock | Prescaler | Sclock
> - | |---------------->| (1.. 256) |------------>
> - --------- -------------
> - | |
> - -------------- ---------------------CLK_SRC
> - Oscillator Clock
> -
> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> - the peripheral clock. PLL clock is fed to the
> - prescaler to generate the Serial Clock (Sclock).
> - Valid values are "oscillator" and "platform"
> - "oscillator": CAN engine clock source is oscillator clock.
> - "platform" The CAN engine clock source is the bus clock
> - (platform clock).
> -
> -- fsl,flexcan-clock-divider : for the reference and system clock, an additional
> - clock divider can be specified.
> -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> -
> -Note:
> - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> - - P1010 does not have oscillator as the Clock Source.So the default
> - Clock Source is platform clock.
> -Examples:
> -
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> - reg = <0x1c000 0x1000>;
> - interrupts = <48 0x2>;
> - interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-source = "platform";
> - fsl,flexcan-clock-divqider = <2>;
> - clock-frequency = <fixed by u-boot>;
> - };
Do we really want to drop the documentation for that binding. I think
something like the following text would be still useful:
------------------------
Flexcan CAN contoller on Freescale's ARM and PowerPC processors
Required properties:
- compatible : Should be "fsl,flexcan" and optionally
"fsl,flexcan-<processor>"
- reg : Offset and length of the register set for this device
- interrupts : Interrupt tuple for this device
Example:
can@1c000 {
compatible = "fsl,p1010-flexcan", "fsl,flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
};
-------------------------
What do you think?
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> index 6b33b73..d6a0bb2 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dts
> +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> @@ -169,14 +169,6 @@
> };
> };
>
> - can0@1c000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> - can1@1d000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> usb@22000 {
> phy_type = "utmi";
> };
> diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
> index 7f51104..20c396d 100644
> --- a/arch/powerpc/boot/dts/p1010si.dtsi
> +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> @@ -141,19 +141,19 @@
> };
>
> can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> + compatible = "fsl,p1010-flexcan",
> + "fsl,flexcan";
Does fit on one line.
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> can1@1d000 {
> - compatible = "fsl,flexcan-v1.0";
> + compatible = "fsl,p1010-flexcan",
> + "fsl,flexcan";
Ditto
> reg = <0x1d000 0x1000>;
> interrupts = <61 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> L2: l2-cache-controller@20000 {
Please also correct the node names (not using the number suffix).
Wolfgang.
^ permalink raw reply
* Re: Use of 802.3ad bonding for increasing link throughput
From: Simon Farnsworth @ 2011-08-10 13:50 UTC (permalink / raw)
To: netdev
In-Reply-To: <4E427499.8060108@cyconix.com>
Tom Brown wrote:
> [couldn't thread with '802.3ad bonding brain damaged', as I've just
> signed up]
>
> So, under what circumstances would a user actually use 802.3ad mode to
> "increase" link throughput, rather than just for redundancy? Are there
> any circumstances in which a single file, for example, could be
> transferred at multiple-NIC speed? The 3 hashing options are:
>
As an example, from my server room here; I have an install server (TFTP, FTP
and HTTP) connected by a 2x1G LACP bond to the switch. When I have multiple
clients installing simultaneously, the layer2 hash distributes the load
nicely across both NICs - I can reach saturation on both NICs together.
If I had routers between my clients and the install server, I'd need
layer2+3 hashing to spread the clients over the links, but I'd still be able
to push over a gigabit per second to the clients, despite being limited to
1GBit/s to each individual client by the packet distribution.
I'm sure that you can think of lots of other situations in which you have
multiple conversations sharing a link - those are the situations that gain
speed from 802.3ad.
--
Simon Farnsworth
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-10 14:15 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
Scott Wood, PPC list
In-Reply-To: <4E428BFF.7060402-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
> Hi Robin,
>
> On 08/10/2011 05:06 AM, Robin Holt wrote:
> > In working with the socketcan developers, we have come to the conclusion
> > the Documentation...fsl-flexcan.txt device tree documentation needs to
> > be cleaned up. The driver does not depend upon any properties other
>
> Your first sentence could be misleading. Please just describe what the
> patch does and why, something like:
>
> "This patch cleans up the documentation of the device-tree binding for
> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> properties are not needed as the frequency of the source clock is
> fixed..." and so on.
I borrowed heavily from your message. ;)
> > than the required properties so we are removing the file. Additionally,
> > the p1010*dts* files are not following the standard for node naming in
> > that they have a trailing -v1.0.
>
> > Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> > To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> > To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> > To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> > Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> > Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> > Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> > ---
> > .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
> > arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> > arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> > 3 files changed, 4 insertions(+), 73 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > deleted file mode 100644
> > index 1a729f0..0000000
> > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > +++ /dev/null
> > @@ -1,61 +0,0 @@
> > -CAN Device Tree Bindings
> > -------------------------
> > -2011 Freescale Semiconductor, Inc.
> > -
> > -fsl,flexcan-v1.0 nodes
> > ------------------------
> > -In addition to the required compatible-, reg- and interrupt-properties, you can
> > -also specify which clock source shall be used for the controller.
> > -
> > -CPI Clock- Can Protocol Interface Clock
> > - This CLK_SRC bit of CTRL(control register) selects the clock source to
> > - the CAN Protocol Interface(CPI) to be either the peripheral clock
> > - (driven by the PLL) or the crystal oscillator clock. The selected clock
> > - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> > - The PRESDIV field of CTRL(control register) controls a prescaler that
> > - generates the Serial Clock (Sclock), whose period defines the
> > - time quantum used to compose the CAN waveform.
> > -
> > -Can Engine Clock Source
> > - There are two sources for CAN clock
> > - - Platform Clock It represents the bus clock
> > - - Oscillator Clock
> > -
> > - Peripheral Clock (PLL)
> > - --------------
> > - |
> > - --------- -------------
> > - | |CPI Clock | Prescaler | Sclock
> > - | |---------------->| (1.. 256) |------------>
> > - --------- -------------
> > - | |
> > - -------------- ---------------------CLK_SRC
> > - Oscillator Clock
> > -
> > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> > - the peripheral clock. PLL clock is fed to the
> > - prescaler to generate the Serial Clock (Sclock).
> > - Valid values are "oscillator" and "platform"
> > - "oscillator": CAN engine clock source is oscillator clock.
> > - "platform" The CAN engine clock source is the bus clock
> > - (platform clock).
> > -
> > -- fsl,flexcan-clock-divider : for the reference and system clock, an additional
> > - clock divider can be specified.
> > -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> > -
> > -Note:
> > - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> > - - P1010 does not have oscillator as the Clock Source.So the default
> > - Clock Source is platform clock.
> > -Examples:
> > -
> > - can0@1c000 {
> > - compatible = "fsl,flexcan-v1.0";
> > - reg = <0x1c000 0x1000>;
> > - interrupts = <48 0x2>;
> > - interrupt-parent = <&mpic>;
> > - fsl,flexcan-clock-source = "platform";
> > - fsl,flexcan-clock-divqider = <2>;
> > - clock-frequency = <fixed by u-boot>;
> > - };
>
> Do we really want to drop the documentation for that binding. I think
> something like the following text would be still useful:
>
> ------------------------
> Flexcan CAN contoller on Freescale's ARM and PowerPC processors
>
> Required properties:
>
> - compatible : Should be "fsl,flexcan" and optionally
> "fsl,flexcan-<processor>"
> - reg : Offset and length of the register set for this device
> - interrupts : Interrupt tuple for this device
>
> Example:
>
> can@1c000 {
> compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> };
> -------------------------
Done, except the
> compatible = "fsl,p1010-flexcan", "fsl,flexcan";
line is
compatible = "fsl,flexcan", "fsl,flexcan-p1010";
>
> What do you think?
>
> > diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> > index 6b33b73..d6a0bb2 100644
> > --- a/arch/powerpc/boot/dts/p1010rdb.dts
> > +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> > @@ -169,14 +169,6 @@
> > };
> > };
> >
> > - can0@1c000 {
> > - fsl,flexcan-clock-source = "platform";
> > - };
> > -
> > - can1@1d000 {
> > - fsl,flexcan-clock-source = "platform";
> > - };
> > -
> > usb@22000 {
> > phy_type = "utmi";
> > };
> > diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
> > index 7f51104..20c396d 100644
> > --- a/arch/powerpc/boot/dts/p1010si.dtsi
> > +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> > @@ -141,19 +141,19 @@
> > };
> >
> > can0@1c000 {
> > - compatible = "fsl,flexcan-v1.0";
> > + compatible = "fsl,p1010-flexcan",
> > + "fsl,flexcan";
>
> Does fit on one line.
>
> > reg = <0x1c000 0x1000>;
> > interrupts = <48 0x2>;
> > interrupt-parent = <&mpic>;
> > - fsl,flexcan-clock-divider = <2>;
> > };
> >
> > can1@1d000 {
> > - compatible = "fsl,flexcan-v1.0";
> > + compatible = "fsl,p1010-flexcan",
> > + "fsl,flexcan";
>
> Ditto
>
> > reg = <0x1d000 0x1000>;
> > interrupts = <61 0x2>;
> > interrupt-parent = <&mpic>;
> > - fsl,flexcan-clock-divider = <2>;
> > };
> >
> > L2: l2-cache-controller@20000 {
>
> Please also correct the node names (not using the number suffix).
So the node names should be
can@1c000 {
can@1d000 {
correct?
Robin
^ permalink raw reply
* Re: [PATCH v10 3/5] [flexcan] Add of_match to platform_device definition.
From: Robin Holt @ 2011-08-10 14:33 UTC (permalink / raw)
To: Robin Holt, Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Marc Kleine-Budde, PPC list,
U Bhaskar-B22300
In-Reply-To: <1312945564-6626-4-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
On Tue, Aug 09, 2011 at 10:06:02PM -0500, Robin Holt wrote:
> On powerpc, the OpenFirmware devices are not matched without specifying
> an of_match array. Introduce that array as that is used for matching
> on the Freescale P1010 processor.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> ---
> drivers/net/can/flexcan.c | 13 ++++++++++++-
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> index 68cbe52..662f832 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
> @@ -1027,8 +1027,19 @@ static int __devexit flexcan_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static struct of_device_id flexcan_of_match[] = {
> + {
> + .compatible = "fsl,flexcan",
Let me make sure I have this correct. At this point, we would want it
to be fsl,flexcan here. If, at some point, we find the i.MX-wonderful
has diverged from the -p1010, we would, at that point in the code, use
of_device_is_compatible to differentiate the two, correct? That would
mean we should make no change to this patch for the fsl,flexcan-p1010,
right?
Robin
^ permalink raw reply
* Re: [PATCH] slip: fix NOHZ local_softirq_pending 08 warning
From: Oliver Hartkopp @ 2011-08-10 14:33 UTC (permalink / raw)
To: Alan Cox, matvejchikov; +Cc: netdev
In-Reply-To: <20110810102824.4c4eaefe@lxorguk.ukuu.org.uk>
On 10.08.2011 11:28, Alan Cox wrote:
>> 2) From tty_flip_buffer_push() which schedules the flush_to_ldisc to
>> work or calls it directly if the tty->low_latency set.
>>
>> So the only thing we must take into account that with tty->low_latency
>> set we can be in IRQ context when doing with netif_rx_ni(). But if we
>
> A driver is not permitted to directly call into flush_to_ldisc from an
> interrupt so that case doesn't happen.
>
Thanks to both of you for the explanation!
I'll send a patch for slcan.c then.
Best regards,
Oliver
^ permalink raw reply
* RE: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: U Bhaskar-B22300 @ 2011-08-10 14:36 UTC (permalink / raw)
To: Robin Holt, Wolfgang Grandegger
Cc: Marc Kleine-Budde, Wood Scott-B07421, netdev@vger.kernel.org,
Kumar Gala, socketcan-core@lists.berlios.de, PPC list
In-Reply-To: <20110810141550.GQ4926@sgi.com>
> -----Original Message-----
> From: Robin Holt [mailto:holt@sgi.com]
> Sent: Wednesday, August 10, 2011 7:46 PM
> To: Wolfgang Grandegger
> Cc: Robin Holt; Marc Kleine-Budde; U Bhaskar-B22300; Wood Scott-B07421;
> netdev@vger.kernel.org; Kumar Gala; socketcan-core@lists.berlios.de; PPC
> list
> Subject: Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree
> binding.
>
> On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
> > Hi Robin,
> >
> > On 08/10/2011 05:06 AM, Robin Holt wrote:
> > > In working with the socketcan developers, we have come to the
> > > conclusion the Documentation...fsl-flexcan.txt device tree
> > > documentation needs to be cleaned up. The driver does not depend
> > > upon any properties other
> >
> > Your first sentence could be misleading. Please just describe what the
> > patch does and why, something like:
> >
> > "This patch cleans up the documentation of the device-tree binding for
> > the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> > properties are not needed as the frequency of the source clock is
> > fixed..." and so on.
>
> I borrowed heavily from your message. ;)
>
> > > than the required properties so we are removing the file.
> > > Additionally, the p1010*dts* files are not following the standard
> > > for node naming in that they have a trailing -v1.0.
> >
> > > Signed-off-by: Robin Holt <holt@sgi.com>
> > > To: Marc Kleine-Budde <mkl@pengutronix.de>,
> > > To: Wolfgang Grandegger <wg@grandegger.com>,
> > > To: U Bhaskar-B22300 <B22300@freescale.com>
> > > To: Scott Wood <scottwood@freescale.com>
> > > Cc: socketcan-core@lists.berlios.de,
> > > Cc: netdev@vger.kernel.org,
> > > Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
> > > Cc: Kumar Gala <galak@kernel.crashing.org>
> > > ---
> > > .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 ----------
> ----------
> > > arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> > > arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> > > 3 files changed, 4 insertions(+), 73 deletions(-) delete mode
> > > 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > deleted file mode 100644
> > > index 1a729f0..0000000
> > > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > +++ /dev/null
> > > @@ -1,61 +0,0 @@
> > > -CAN Device Tree Bindings
> > > -------------------------
> > > -2011 Freescale Semiconductor, Inc.
> > > -
> > > -fsl,flexcan-v1.0 nodes
> > > ------------------------
> > > -In addition to the required compatible-, reg- and
> > > interrupt-properties, you can -also specify which clock source shall
> be used for the controller.
> > > -
> > > -CPI Clock- Can Protocol Interface Clock
> > > - This CLK_SRC bit of CTRL(control register) selects the clock source
> to
> > > - the CAN Protocol Interface(CPI) to be either the peripheral clock
> > > - (driven by the PLL) or the crystal oscillator clock. The selected
> clock
> > > - is the one fed to the prescaler to generate the Serial Clock
> (Sclock).
> > > - The PRESDIV field of CTRL(control register) controls a prescaler
> that
> > > - generates the Serial Clock (Sclock), whose period defines the
> > > - time quantum used to compose the CAN waveform.
> > > -
> > > -Can Engine Clock Source
> > > - There are two sources for CAN clock
> > > - - Platform Clock It represents the bus clock
> > > - - Oscillator Clock
> > > -
> > > - Peripheral Clock (PLL)
> > > - --------------
> > > - |
> > > - --------- -------------
> > > - | |CPI Clock | Prescaler | Sclock
> > > - | |---------------->| (1.. 256) |------------>
> > > - --------- -------------
> > > - | |
> > > - -------------- ---------------------CLK_SRC
> > > - Oscillator Clock
> > > -
> > > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property
> selects
> > > - the peripheral clock. PLL clock is fed to the
> > > - prescaler to generate the Serial Clock (Sclock).
> > > - Valid values are "oscillator" and "platform"
> > > - "oscillator": CAN engine clock source is
> oscillator clock.
> > > - "platform" The CAN engine clock source is the bus
> clock
> > > - (platform clock).
> > > -
> > > -- fsl,flexcan-clock-divider : for the reference and system clock, an
> additional
> > > - clock divider can be specified.
> > > -- clock-frequency: frequency required to calculate the bitrate for
> FlexCAN.
> > > -
> > > -Note:
> > > - - v1.0 of flexcan-v1.0 represent the IP block version for P1010
> SOC.
> > > - - P1010 does not have oscillator as the Clock Source.So the default
> > > - Clock Source is platform clock.
> > > -Examples:
> > > -
> > > - can0@1c000 {
> > > - compatible = "fsl,flexcan-v1.0";
> > > - reg = <0x1c000 0x1000>;
> > > - interrupts = <48 0x2>;
> > > - interrupt-parent = <&mpic>;
> > > - fsl,flexcan-clock-source = "platform";
> > > - fsl,flexcan-clock-divqider = <2>;
> > > - clock-frequency = <fixed by u-boot>;
> > > - };
> >
> > Do we really want to drop the documentation for that binding. I think
> > something like the following text would be still useful:
> >
> > ------------------------
> > Flexcan CAN contoller on Freescale's ARM and PowerPC processors
> >
> > Required properties:
> >
> > - compatible : Should be "fsl,flexcan" and optionally
> > "fsl,flexcan-<processor>"
> > - reg : Offset and length of the register set for this device
> > - interrupts : Interrupt tuple for this device
> >
> > Example:
> >
> > can@1c000 {
> > compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> > reg = <0x1c000 0x1000>;
> > interrupts = <48 0x2>;
> > interrupt-parent = <&mpic>;
> > };
> > -------------------------
>
> Done, except the
> > compatible = "fsl,p1010-flexcan", "fsl,flexcan";
>
> line is
> compatible = "fsl,flexcan", "fsl,flexcan-p1010";
>
> >
> > What do you think?
> >
> > > diff --git a/arch/powerpc/boot/dts/p1010rdb.dts
> > > b/arch/powerpc/boot/dts/p1010rdb.dts
> > > index 6b33b73..d6a0bb2 100644
> > > --- a/arch/powerpc/boot/dts/p1010rdb.dts
> > > +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> > > @@ -169,14 +169,6 @@
> > > };
> > > };
> > >
> > > - can0@1c000 {
> > > - fsl,flexcan-clock-source = "platform";
> > > - };
> > > -
> > > - can1@1d000 {
> > > - fsl,flexcan-clock-source = "platform";
> > > - };
> > > -
> > > usb@22000 {
> > > phy_type = "utmi";
> > > };
> > > diff --git a/arch/powerpc/boot/dts/p1010si.dtsi
> > > b/arch/powerpc/boot/dts/p1010si.dtsi
> > > index 7f51104..20c396d 100644
> > > --- a/arch/powerpc/boot/dts/p1010si.dtsi
> > > +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> > > @@ -141,19 +141,19 @@
> > > };
> > >
> > > can0@1c000 {
> > > - compatible = "fsl,flexcan-v1.0";
> > > + compatible = "fsl,p1010-flexcan",
> > > + "fsl,flexcan";
> >
> > Does fit on one line.
> >
> > > reg = <0x1c000 0x1000>;
> > > interrupts = <48 0x2>;
> > > interrupt-parent = <&mpic>;
> > > - fsl,flexcan-clock-divider = <2>;
> > > };
> > >
> > > can1@1d000 {
> > > - compatible = "fsl,flexcan-v1.0";
> > > + compatible = "fsl,p1010-flexcan",
> > > + "fsl,flexcan";
> >
> > Ditto
> >
> > > reg = <0x1d000 0x1000>;
> > > interrupts = <61 0x2>;
> > > interrupt-parent = <&mpic>;
> > > - fsl,flexcan-clock-divider = <2>;
> > > };
> > >
> > > L2: l2-cache-controller@20000 {
> >
> > Please also correct the node names (not using the number suffix).
>
> So the node names should be
> can@1c000 {
> can@1d000 {
> correct?
>
[Bhaskar] As there are two CAN controllers on P1010,So won't it be better
to distinguish it by can0 and can1 instead by simple "can" ?
> Robin
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Wolfgang Grandegger @ 2011-08-10 14:41 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
Scott Wood, PPC list
In-Reply-To: <20110810141550.GQ4926-sJ/iWh9BUns@public.gmane.org>
On 08/10/2011 04:15 PM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
...
> Done, except the
>> compatible = "fsl,p1010-flexcan", "fsl,flexcan";
>
> line is
> compatible = "fsl,flexcan", "fsl,flexcan-p1010";
IIRC, there order is more to less specific, e.g. for I2C:
compatible = "fsl,mpc5200-i2c", "fsl-i2c"
...
>> Please also correct the node names (not using the number suffix).
>
> So the node names should be
> can@1c000 {
> can@1d000 {
> correct?
Yes, just have a look how other node names are constructed, e.g. for
sata, serial, rtc, etc.:
$ grep serial@ *.dts
...
pdm360ng.dts: serial@11000 {
pdm360ng.dts: serial@11100 {
pdm360ng.dts: serial@11200 {
pdm360ng.dts: serial@11300 {
pdm360ng.dts: serial@11400 {
pdm360ng.dts: serial@11600 {
pdm360ng.dts: serial@11800 {
pdm360ng.dts: serial@11B00 {
...
Wolfgang.
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Kumar Gala @ 2011-08-10 14:45 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <20110810141550.GQ4926-sJ/iWh9BUns@public.gmane.org>
On Aug 10, 2011, at 9:15 AM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
>> Hi Robin,
>>
>> On 08/10/2011 05:06 AM, Robin Holt wrote:
>>> In working with the socketcan developers, we have come to the conclusion
>>> the Documentation...fsl-flexcan.txt device tree documentation needs to
>>> be cleaned up. The driver does not depend upon any properties other
>>
>> Your first sentence could be misleading. Please just describe what the
>> patch does and why, something like:
>>
>> "This patch cleans up the documentation of the device-tree binding for
>> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
>> properties are not needed as the frequency of the source clock is
>> fixed..." and so on.
>
> I borrowed heavily from your message. ;)
>
>>> than the required properties so we are removing the file. Additionally,
>>> the p1010*dts* files are not following the standard for node naming in
>>> that they have a trailing -v1.0.
>>
>>> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
>>> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
>>> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
>>> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>>> To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>>> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
>>> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
>>> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
>>> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
>>> arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
>>> arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
>>> 3 files changed, 4 insertions(+), 73 deletions(-)
>>> delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
I don't understand how we can do this? What binding spec covers the P1010 CAN support if you remove this?
- k
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Kumar Gala @ 2011-08-10 14:46 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
Scott Wood, PPC list
In-Reply-To: <4E42987F.9040304-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Aug 10, 2011, at 9:41 AM, Wolfgang Grandegger wrote:
> On 08/10/2011 04:15 PM, Robin Holt wrote:
>> On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
> ...
>> Done, except the
>>> compatible = "fsl,p1010-flexcan", "fsl,flexcan";
>>
>> line is
>> compatible = "fsl,flexcan", "fsl,flexcan-p1010";
>
> IIRC, there order is more to less specific, e.g. for I2C:
>
> compatible = "fsl,mpc5200-i2c", "fsl-i2c"
>
> ...
>
>>> Please also correct the node names (not using the number suffix).
>>
>> So the node names should be
>> can@1c000 {
>> can@1d000 {
>> correct?
>
> Yes, just have a look how other node names are constructed, e.g. for
> sata, serial, rtc, etc.:
>
> $ grep serial@ *.dts
> ...
> pdm360ng.dts: serial@11000 {
> pdm360ng.dts: serial@11100 {
> pdm360ng.dts: serial@11200 {
> pdm360ng.dts: serial@11300 {
> pdm360ng.dts: serial@11400 {
> pdm360ng.dts: serial@11600 {
> pdm360ng.dts: serial@11800 {
> pdm360ng.dts: serial@11B00 {
> ...
>
> Wolfgang.
Agree w/Wolfgang here, can@1c000, can@1d000 is what we should use.
- k
^ permalink raw reply
* Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Kumar Gala @ 2011-08-10 14:52 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
U Bhaskar-B22300, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Marc Kleine-Budde, Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <20110809205900.GC4926-sJ/iWh9BUns@public.gmane.org>
On Aug 9, 2011, at 3:59 PM, Robin Holt wrote:
> I guess my poor wording may have gotten me in trouble. I am getting
> ready to repost this patch, but I want to ensure I am getting it as
> right as possible.
>
> I think I should reword the commit message to indicate we are removing
> the Documentation/.../fsl-flexcan.txt file which has essentially become
> empty and change the p1010si.dtsi file's can nodes to "fsl,p1010-flexcan",
> "fsl,flexcan". Is that correct?
>
> Thanks,
> Robin
This is wrong. Again, what binding covers "fsl,flexcan" if you remove fsl-flexcan.txt:
[galak@right powerpc]$ git grep flexcan Documentation/devicetree/bindings
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt:fsl,flexcan-v1.0 nodes
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt:- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt:- fsl,flexcan-clock-divider : for the reference and system clock, an additional
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: compatible = "fsl,flexcan-v1.0";
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: fsl,flexcan-clock-source = "platform";
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: fsl,flexcan-clock-divider = <2>;
Not seeing anything that covers it.
I think the issue should be resolved by patching fsl-flexcan.txt to remove wording or update it.
- k
^ permalink raw reply
* Re: [PATCH v2] net: add Documentation/networking/scaling.txt
From: David Miller @ 2011-08-10 14:57 UTC (permalink / raw)
To: willemb; +Cc: rdunlap, linux-doc, netdev, therbert
In-Reply-To: <1312899648.5889.14.camel@gopher.nyc.corp.google.com>
From: Willem de Bruijn <willemb@google.com>
Date: Tue, 09 Aug 2011 10:20:48 -0400
> Describes RSS, RPS, RFS, accelerated RFS, and XPS.
>
> This version incorporates comments by Randy Dunlap and Rick Jones.
> Besides text cleanup, it adds an explicit "Suggested Configuration"
> heading to each section.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks.
^ permalink raw reply
* Re: GRO support in the bridge
From: Stephen Hemminger @ 2011-08-10 15:08 UTC (permalink / raw)
To: Sedat Cakir; +Cc: netdev@vger.kernel.org
In-Reply-To: <1312979355.53304.YahooMailNeo@web110404.mail.gq1.yahoo.com>
On Wed, 10 Aug 2011 05:29:15 -0700 (PDT)
Sedat Cakir <cakir_sedat@yahoo.com> wrote:
> Hi,
>
>
>
> I am trying to understand why GRO is NOT enabled on the bridge. Is there a special reason for it? Reading the code in net/core/dev.c:2817 (__netif_receieve_skb) which is what I think the bridge is calling because that is what is passed in at br_input.c:br_pass_frame_up():24. I am wondering if this can be modified to use one of the _gro_ receive functions and if so if that will positively impact performance? Do you have any idea?
>
> Appreciate your help.Thanks,
> Sedat
The reason is that GRO is related to NAPI.
GRO works by coalescing frames received in one NAPI interval
of work. The bridge itself has no receive irq or NAPI and is upcalled
from the device receive handler. There is no expectation or
requirement that devices in a bridge use NAPI. Therefore it
is not possible or safe for bridge pseudo-device to use GRO.
^ permalink raw reply
* [PATCH] slcan: ldisc generated skbs are received in softirq context
From: Oliver Hartkopp @ 2011-08-10 15:18 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, Matvejchikov Ilya, Alan Cox
As this discussion pointed out
http://marc.info/?l=linux-netdev&m=131257225602375
netdevices that are based on serial line disciplines should use netif_rx_ni()
when pushing received socketbuffers into the netdev rx queue.
Following commit 614851601c121b1320a35757ab88292d6272f906 ("slip: fix NOHZ
local_softirq_pending 08 warning") this patch updates the slcan driver
accordingly.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
CC: Matvejchikov Ilya <matvejchikov@gmail.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
---
diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c
index f523f1c..4b70b7e 100644
--- a/drivers/net/can/slcan.c
+++ b/drivers/net/can/slcan.c
@@ -197,7 +197,7 @@ static void slc_bump(struct slcan *sl)
skb->ip_summed = CHECKSUM_UNNECESSARY;
memcpy(skb_put(skb, sizeof(struct can_frame)),
&cf, sizeof(struct can_frame));
- netif_rx(skb);
+ netif_rx_ni(skb);
sl->dev->stats.rx_packets++;
sl->dev->stats.rx_bytes += cf.can_dlc;
^ permalink raw reply related
* [PATCH] PCnet: Fix section mismatch
From: Ralf Baechle @ 2011-08-10 15:23 UTC (permalink / raw)
To: David S. Miller, Don Fry, netdev; +Cc: Thomas Bogendoerfer, linux-mips
Building MIPS mtx1_defconfig results in:
MODPOST 735 modules
WARNING: drivers/net/pcnet32.o(.devinit.text+0x11ec): Section mismatch in reference from the function pcnet32_probe_vlbus.constprop.22() to the variable .init.data:pcnet32_portlist
The function __devinit pcnet32_probe_vlbus.constprop.22() references
a variable __initdata pcnet32_portlist.
If pcnet32_portlist is only used by pcnet32_probe_vlbus.constprop.22 then
annotate pcnet32_portlist with a matching annotation.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
---
As recently discussed in the discussion of submission of a fix for a
similar bug in another driver remove __initdata rather than replace it
with __devinitdata.
drivers/net/pcnet32.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/pcnet32.c b/drivers/net/pcnet32.c
index 8b3090d..80b6f36 100644
--- a/drivers/net/pcnet32.c
+++ b/drivers/net/pcnet32.c
@@ -82,7 +82,7 @@ static int cards_found;
/*
* VLB I/O addresses
*/
-static unsigned int pcnet32_portlist[] __initdata =
+static unsigned int pcnet32_portlist[] =
{ 0x300, 0x320, 0x340, 0x360, 0 };
static int pcnet32_debug;
^ permalink raw reply related
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-10 15:35 UTC (permalink / raw)
To: Kumar Gala
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Scott Wood, PPC list
In-Reply-To: <8ED8063F-7227-402A-89D5-7CE69241AF9C-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Wed, Aug 10, 2011 at 09:45:17AM -0500, Kumar Gala wrote:
>
> On Aug 10, 2011, at 9:15 AM, Robin Holt wrote:
>
> > On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
> >> Hi Robin,
> >>
> >> On 08/10/2011 05:06 AM, Robin Holt wrote:
> >>> In working with the socketcan developers, we have come to the conclusion
> >>> the Documentation...fsl-flexcan.txt device tree documentation needs to
> >>> be cleaned up. The driver does not depend upon any properties other
> >>
> >> Your first sentence could be misleading. Please just describe what the
> >> patch does and why, something like:
> >>
> >> "This patch cleans up the documentation of the device-tree binding for
> >> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> >> properties are not needed as the frequency of the source clock is
> >> fixed..." and so on.
> >
> > I borrowed heavily from your message. ;)
> >
> >>> than the required properties so we are removing the file. Additionally,
> >>> the p1010*dts* files are not following the standard for node naming in
> >>> that they have a trailing -v1.0.
> >>
> >>> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> >>> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> >>> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> >>> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> >>> To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> >>> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> >>> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> >>> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> >>> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> >>> ---
> >>> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
> >>> arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> >>> arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> >>> 3 files changed, 4 insertions(+), 73 deletions(-)
> >>> delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>
> I don't understand how we can do this? What binding spec covers the P1010 CAN support if you remove this?
We have added it back in based upon an earlier comment from Wolfgang.
I will post a new version shortly.
Robin
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-10 16:00 UTC (permalink / raw)
To: U Bhaskar-B22300
Cc: Wood Scott-B07421, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Marc Kleine-Budde, PPC list, Wolfgang Grandegger
In-Reply-To: <9C64B7751C3BCA41B64A68E23005A7BE1C6A21-TcFNo7jSaXPiTqIcKZ1S2K4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>
On Wed, Aug 10, 2011 at 02:36:20PM +0000, U Bhaskar-B22300 wrote:
>
>
> > -----Original Message-----
> > From: Robin Holt [mailto:holt-sJ/iWh9BUns@public.gmane.org]
> > Sent: Wednesday, August 10, 2011 7:46 PM
> > To: Wolfgang Grandegger
> > Cc: Robin Holt; Marc Kleine-Budde; U Bhaskar-B22300; Wood Scott-B07421;
> > netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Kumar Gala; socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; PPC
> > list
> > Subject: Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree
> > binding.
> >
> > On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
> > > Hi Robin,
> > >
> > > On 08/10/2011 05:06 AM, Robin Holt wrote:
> > > > In working with the socketcan developers, we have come to the
> > > > conclusion the Documentation...fsl-flexcan.txt device tree
> > > > documentation needs to be cleaned up. The driver does not depend
> > > > upon any properties other
> > >
> > > Your first sentence could be misleading. Please just describe what the
> > > patch does and why, something like:
> > >
> > > "This patch cleans up the documentation of the device-tree binding for
> > > the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> > > properties are not needed as the frequency of the source clock is
> > > fixed..." and so on.
> >
> > I borrowed heavily from your message. ;)
> >
> > > > than the required properties so we are removing the file.
> > > > Additionally, the p1010*dts* files are not following the standard
> > > > for node naming in that they have a trailing -v1.0.
> > >
> > > > Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> > > > To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> > > > To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> > > > To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> > > > Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> > > > Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> > > > Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> > > > ---
> > > > .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 ----------
> > ----------
> > > > arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> > > > arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> > > > 3 files changed, 4 insertions(+), 73 deletions(-) delete mode
> > > > 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > > deleted file mode 100644
> > > > index 1a729f0..0000000
> > > > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > > +++ /dev/null
> > > > @@ -1,61 +0,0 @@
> > > > -CAN Device Tree Bindings
> > > > -------------------------
> > > > -2011 Freescale Semiconductor, Inc.
> > > > -
> > > > -fsl,flexcan-v1.0 nodes
> > > > ------------------------
> > > > -In addition to the required compatible-, reg- and
> > > > interrupt-properties, you can -also specify which clock source shall
> > be used for the controller.
> > > > -
> > > > -CPI Clock- Can Protocol Interface Clock
> > > > - This CLK_SRC bit of CTRL(control register) selects the clock source
> > to
> > > > - the CAN Protocol Interface(CPI) to be either the peripheral clock
> > > > - (driven by the PLL) or the crystal oscillator clock. The selected
> > clock
> > > > - is the one fed to the prescaler to generate the Serial Clock
> > (Sclock).
> > > > - The PRESDIV field of CTRL(control register) controls a prescaler
> > that
> > > > - generates the Serial Clock (Sclock), whose period defines the
> > > > - time quantum used to compose the CAN waveform.
> > > > -
> > > > -Can Engine Clock Source
> > > > - There are two sources for CAN clock
> > > > - - Platform Clock It represents the bus clock
> > > > - - Oscillator Clock
> > > > -
> > > > - Peripheral Clock (PLL)
> > > > - --------------
> > > > - |
> > > > - --------- -------------
> > > > - | |CPI Clock | Prescaler | Sclock
> > > > - | |---------------->| (1.. 256) |------------>
> > > > - --------- -------------
> > > > - | |
> > > > - -------------- ---------------------CLK_SRC
> > > > - Oscillator Clock
> > > > -
> > > > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property
> > selects
> > > > - the peripheral clock. PLL clock is fed to the
> > > > - prescaler to generate the Serial Clock (Sclock).
> > > > - Valid values are "oscillator" and "platform"
> > > > - "oscillator": CAN engine clock source is
> > oscillator clock.
> > > > - "platform" The CAN engine clock source is the bus
> > clock
> > > > - (platform clock).
> > > > -
> > > > -- fsl,flexcan-clock-divider : for the reference and system clock, an
> > additional
> > > > - clock divider can be specified.
> > > > -- clock-frequency: frequency required to calculate the bitrate for
> > FlexCAN.
> > > > -
> > > > -Note:
> > > > - - v1.0 of flexcan-v1.0 represent the IP block version for P1010
> > SOC.
> > > > - - P1010 does not have oscillator as the Clock Source.So the default
> > > > - Clock Source is platform clock.
> > > > -Examples:
> > > > -
> > > > - can0@1c000 {
> > > > - compatible = "fsl,flexcan-v1.0";
> > > > - reg = <0x1c000 0x1000>;
> > > > - interrupts = <48 0x2>;
> > > > - interrupt-parent = <&mpic>;
> > > > - fsl,flexcan-clock-source = "platform";
> > > > - fsl,flexcan-clock-divqider = <2>;
> > > > - clock-frequency = <fixed by u-boot>;
> > > > - };
> > >
> > > Do we really want to drop the documentation for that binding. I think
> > > something like the following text would be still useful:
> > >
> > > ------------------------
> > > Flexcan CAN contoller on Freescale's ARM and PowerPC processors
> > >
> > > Required properties:
> > >
> > > - compatible : Should be "fsl,flexcan" and optionally
> > > "fsl,flexcan-<processor>"
> > > - reg : Offset and length of the register set for this device
> > > - interrupts : Interrupt tuple for this device
> > >
> > > Example:
> > >
> > > can@1c000 {
> > > compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> > > reg = <0x1c000 0x1000>;
> > > interrupts = <48 0x2>;
> > > interrupt-parent = <&mpic>;
> > > };
> > > -------------------------
> >
> > Done, except the
> > > compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> >
> > line is
> > compatible = "fsl,flexcan", "fsl,flexcan-p1010";
> >
> > >
> > > What do you think?
> > >
> > > > diff --git a/arch/powerpc/boot/dts/p1010rdb.dts
> > > > b/arch/powerpc/boot/dts/p1010rdb.dts
> > > > index 6b33b73..d6a0bb2 100644
> > > > --- a/arch/powerpc/boot/dts/p1010rdb.dts
> > > > +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> > > > @@ -169,14 +169,6 @@
> > > > };
> > > > };
> > > >
> > > > - can0@1c000 {
> > > > - fsl,flexcan-clock-source = "platform";
> > > > - };
> > > > -
> > > > - can1@1d000 {
> > > > - fsl,flexcan-clock-source = "platform";
> > > > - };
> > > > -
> > > > usb@22000 {
> > > > phy_type = "utmi";
> > > > };
> > > > diff --git a/arch/powerpc/boot/dts/p1010si.dtsi
> > > > b/arch/powerpc/boot/dts/p1010si.dtsi
> > > > index 7f51104..20c396d 100644
> > > > --- a/arch/powerpc/boot/dts/p1010si.dtsi
> > > > +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> > > > @@ -141,19 +141,19 @@
> > > > };
> > > >
> > > > can0@1c000 {
> > > > - compatible = "fsl,flexcan-v1.0";
> > > > + compatible = "fsl,p1010-flexcan",
> > > > + "fsl,flexcan";
> > >
> > > Does fit on one line.
> > >
> > > > reg = <0x1c000 0x1000>;
> > > > interrupts = <48 0x2>;
> > > > interrupt-parent = <&mpic>;
> > > > - fsl,flexcan-clock-divider = <2>;
> > > > };
> > > >
> > > > can1@1d000 {
> > > > - compatible = "fsl,flexcan-v1.0";
> > > > + compatible = "fsl,p1010-flexcan",
> > > > + "fsl,flexcan";
> > >
> > > Ditto
> > >
> > > > reg = <0x1d000 0x1000>;
> > > > interrupts = <61 0x2>;
> > > > interrupt-parent = <&mpic>;
> > > > - fsl,flexcan-clock-divider = <2>;
> > > > };
> > > >
> > > > L2: l2-cache-controller@20000 {
> > >
> > > Please also correct the node names (not using the number suffix).
> >
> > So the node names should be
> > can@1c000 {
> > can@1d000 {
> > correct?
> >
> [Bhaskar] As there are two CAN controllers on P1010,So won't it be better
> to distinguish it by can0 and can1 instead by simple "can" ?
It looks like the way to do that is to assign a label to those devices
and then associate the label with an alias. I have no idea how that
works under the hood, but it is the way other files are set up. Take a
look at arch/powerpc/boot/dts/bamboo.dts for how they define the serial
interfaces.
Grant or Wolfgang, is that the right way to handle the concern about
names or does it have no practical effect with the Linux kernel?
Thanks,
Robin
^ permalink raw reply
* [patch net-next-2.6 1/2] bonding: implement get_tx_queues rtnk_link_op
From: Jiri Pirko @ 2011-08-10 16:09 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, fubar, andy, tgraf, ebiederm
In-Reply-To: <1312992585-1201-1-git-send-email-jpirko@redhat.com>
If vonding device is created via rtnl, it is created with default number
of rx/tx queues. This patch implements callback in bonding so the
correct value (previously specified by bonding module param) is used.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/bonding/bond_main.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 38a83ac..854aa8d 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4828,11 +4828,20 @@ static int bond_validate(struct nlattr *tb[], struct nlattr *data[])
return 0;
}
+static int bond_get_tx_queues(struct net *net, struct nlattr *tb[],
+ unsigned int *num_queues,
+ unsigned int *real_num_queues)
+{
+ *num_queues = tx_queues;
+ return 0;
+}
+
static struct rtnl_link_ops bond_link_ops __read_mostly = {
.kind = "bond",
.priv_size = sizeof(struct bonding),
.setup = bond_setup,
.validate = bond_validate,
+ .get_tx_queues = bond_get_tx_queues,
};
/* Create a new bond based on the specified name and bonding parameters.
--
1.7.6
^ permalink raw reply related
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