* Re: [patch net-next 0/5] bridge: implement rtnl_link options for getting and setting bridge options
From: David Miller @ 2014-09-09 18:30 UTC (permalink / raw)
To: jiri; +Cc: netdev, stephen, sfeldma, arvid.brodin, sucheta.chakraborty
In-Reply-To: <1409925092-17808-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 5 Sep 2014 15:51:27 +0200
> So far, only sysfs is complete interface for getting and setting bridge
> options. This patchset follows-up on the similar bonding code and
> allows userspace to get/set bridge master/port options using Netlink
> IFLA_INFO_DATA/IFLA_INFO_SLAVE_DATA attr.
Series applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: John W. Linville @ 2014-09-09 18:27 UTC (permalink / raw)
To: Sergey Ryazanov
Cc: Paul Bolle, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
Oleksij Rempel, Richard Weinberger, Jonathan Bither,
Hauke Mehrtens, ath5k-devel, open,
list@hauke-m.de:NETWORKING DRIVERS, antonynpavlov@gmail.com,
OpenWrt Development List, linux-wireless@vger.kernel.org,
list@hauke-m.de:NETWORKING DRIVERS, open list
In-Reply-To: <CAHNKnsQ1gt=DRBTd9Q9yos1idqmXMepEPvhm8a7unP-whzNAgg@mail.gmail.com>
On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote:
> 2014-09-05 15:33 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>:
> > Hi Sergey,
> >
> > On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote:
> >> 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>:
> >> > On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote:
> >> >> Having this conversation every rc1 is getting a bit silly. Could Jiri
> >> >> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be
> >> >> submitted?
> >> >
> >> > I waited until rc3. Have you seen any activity on this front? If not,
> >> > should I resend the patch that removes the code in mainline that depends
> >> > on ATHEROS_AR231X (ie, AHB bus support)?
> >> >
> >> Recent activity always could be found in [1]. Now I finish another one
> >> round of cleanups and have a plan to fix several things (you can
> >> always find something that you really want to improve). But if you
> >> insist I could immediately switch to "send upstream" mode. And seems
> >> that this would be better approach.
> >>
> >> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros
> >
> > And where can the related PULL requests or patch submissions be found?
> >
> I have not sent patches yet, since I thought that it would be easier
> to cleanup them in openwrt tree and then send them upstream.
That excuse has worn a bit thin. Perhaps Paul should repost his
removal and you can add a revert to the start of your patch series?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] net/ipv4: bind ip_nonlocal_bind to current netns
From: David Miller @ 2014-09-09 18:27 UTC (permalink / raw)
To: vincent
Cc: kuznet, jmorris, yoshfuji, kaber, vyasevich, nhorman, netdev,
linux-sctp
In-Reply-To: <1409922543-708-1-git-send-email-vincent@bernat.im>
From: Vincent Bernat <vincent@bernat.im>
Date: Fri, 5 Sep 2014 15:09:03 +0200
> net.ipv4.ip_nonlocal_bind sysctl was global to all network
> namespaces. This patch allows to set a different value for each
> network namespace.
>
> Signed-off-by: Vincent Bernat <vincent@bernat.im>
Applied to net-next, thanks.
^ permalink raw reply
* [PATCH 3/3] sit: Add gro callbacks to sit_offload
From: Tom Herbert @ 2014-09-09 18:23 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1410286996-302-1-git-send-email-therbert@google.com>
Add ipv6_gro_receive and ipv6_gro_complete to sit_offload to
support GRO.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv6/ip6_offload.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 929bbbcd..9952f3f 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -317,6 +317,8 @@ static const struct net_offload sit_offload = {
.callbacks = {
.gso_send_check = ipv6_gso_send_check,
.gso_segment = ipv6_gso_segment,
+ .gro_receive = ipv6_gro_receive,
+ .gro_complete = ipv6_gro_complete,
},
};
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH 2/3] ipip: Add gro callbacks to ipip offload
From: Tom Herbert @ 2014-09-09 18:23 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1410286996-302-1-git-send-email-therbert@google.com>
Add inet_gro_receive and inet_gro_complete to ipip_offload to
support GRO.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/af_inet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index d156b3c..6d6348d 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1670,6 +1670,8 @@ static const struct net_offload ipip_offload = {
.callbacks = {
.gso_send_check = inet_gso_send_check,
.gso_segment = inet_gso_segment,
+ .gro_receive = inet_gro_receive,
+ .gro_complete = inet_gro_complete,
},
};
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 1/3] ipv6: Clear flush_id to make GRO work
From: Tom Herbert @ 2014-09-09 18:23 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1410286996-302-1-git-send-email-therbert@google.com>
In TCP gro we check flush_id which is derived from the IP identifier.
In IPv4 gro path the flush_id is set with the expectation that every
matched packet increments IP identifier. In IPv6, the flush_id is
never set and thus is uinitialized. What's worse is that in IPv6
over IPv4 encapsulation, the IP identifier is taken from the outer
header which is currently not incremented on every packet for Linux
stack, so GRO in this case never matches packets (identifier is
not increasing).
This patch clears flush_id for every time for a matched packet in
IPv6 gro_receive. We need to do this each time to overwrite the
setting that would be done in IPv4 gro_receive per the outer
header in IPv6 over Ipv4 encapsulation.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv6/ip6_offload.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 5bcda33..929bbbcd 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -261,6 +261,9 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
/* flush if Traffic Class fields are different */
NAPI_GRO_CB(p)->flush |= !!(first_word & htonl(0x0FF00000));
NAPI_GRO_CB(p)->flush |= flush;
+
+ /* Clear flush_id, there's really no concept of ID in IPv6. */
+ NAPI_GRO_CB(p)->flush_id = 0;
}
NAPI_GRO_CB(skb)->flush |= flush;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 0/3] net: enable GRO for IPIP and SIT
From: Tom Herbert @ 2014-09-09 18:23 UTC (permalink / raw)
To: davem, netdev
This patch sets populates the IPIP and SIT offload structures with
gro_receive and gro_complete functions. This enables use of GRO
for these. Also, fixed a problem in IPv6 where we were not properly
initializing flush_id.
Peformance results are below. Note that these tests were done on bnx2x
which doesn't provide RX checksum offload of IPIP or SIT (i.e. does
not give CHEKCSUM_COMPLETE). Also, we don't get 4-tuple hash for RSS
only 2-tuple in this case so all the packets between two hosts are
winding up on the same queue. Net result is the interrupting CPU is
the bottleneck in GRO (checksumming every packet there).
Testing:
netperf TCP_STREAM between two hosts using bnx2x.
* Before fix
IPIP
1 connection
6.53% CPU utilization
6544.71 Mbps
20 connections
13.79% CPU utilization
9284.54 Mbps
SIT
1 connection
6.68% CPU utilization
5653.36 Mbps
20 connections
18.88% CPU utilization
9154.61 Mbps
* After fix
IPIP
1 connection
5.73% CPU utilization
9279.53 Mbps
20 connections
7.14% CPU utilization
7279.35 Mbps
SIT
1 connection
2.95% CPU utilization
9143.36 Mbps
20 connections
7.09% CPU utilization
6255.3 Mbps
Tom Herbert (3):
ipv6: Clear flush_id to make GRO work
ipip: Add gro callbacks to ipip offload
sit: Add gro callbacks to sit_offload
net/ipv4/af_inet.c | 2 ++
net/ipv6/ip6_offload.c | 5 +++++
2 files changed, 7 insertions(+)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply
* Re: [net-next PATCH v3 09/15] net: sched: make cls_u32 lockless
From: Cong Wang @ 2014-09-09 18:02 UTC (permalink / raw)
To: John Fastabend
Cc: Cong Wang, David Miller, Eric Dumazet, Jamal Hadi Salim, netdev,
Paul McKenney, Jesper Dangaard Brouer
In-Reply-To: <20140909055815.2071.39668.stgit@nitbit.x32>
On Mon, Sep 8, 2014 at 10:58 PM, John Fastabend
<john.fastabend@gmail.com> wrote:
>
> +void __u32_delete_key(struct rcu_head *rcu)
> +{
> + struct tc_u_knode *key = container_of(rcu, struct tc_u_knode, rcu);
> +
> + u32_destroy_key(key->tp, key);
> +}
This can become static?
^ permalink raw reply
* Re: [PATCH v2 3/8] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Mark Rutland @ 2014-09-09 17:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Antoine Tenart,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
zmxu-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
jszhang-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org,
sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <2897714.QyEFFDa5hL@wuerfel>
On Tue, Sep 09, 2014 at 06:47:35PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 September 2014 18:01:36 Antoine Tenart wrote:
> >
> > On Tue, Sep 09, 2014 at 05:58:12PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 09 September 2014 16:44:03 Antoine Tenart wrote:
> > > > +- clocks: pointer to the clock for the device.
> > > > +- clock-names: should be "MFUCLK".
> > >
> > > Clock names are normally not capitalized. Are you able to change
> > > that name when providing a binding or make it an anoymous clock?
> > > What does MFU stand for anyway?
> >
> > Sure. I could have make it an anonymous clock but the name "MFUCLK" was
> > already used by the pxa168 Ethernet driver so I didn't wanted to change
> > that.
>
> I believe you can just ask for an anonymous clock anyway and get the
> first one even if it has a name, but I didn't check.
>
> In any case, we should not just take a clock name in a DT binding
> because it happened to be used by platform code. It's easy fix the
> platform code when someone makes a mistake there, but very hard to
> fix DT strings once there are users relying on a particular convention.
At least with names it's easy to add/remove abitrary sets of clocks. We
can be stuck with bad names but I don't think that's as big a concern.
So if there is an actual name for the clock input line (from the pov of
the consumer), I'd recommend using it. Note that this does not have to
be the current "MFUCLK" as used by platform data.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/8] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Arnd Bergmann @ 2014-09-09 17:47 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Antoine Tenart, thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
zmxu-eYqpPyKDWXRBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jszhang-eYqpPyKDWXRBDgjK7y7TUQ,
sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20140909160136.GA26051@kwain>
On Tuesday 09 September 2014 18:01:36 Antoine Tenart wrote:
>
> On Tue, Sep 09, 2014 at 05:58:12PM +0200, Arnd Bergmann wrote:
> > On Tuesday 09 September 2014 16:44:03 Antoine Tenart wrote:
> > > +- clocks: pointer to the clock for the device.
> > > +- clock-names: should be "MFUCLK".
> >
> > Clock names are normally not capitalized. Are you able to change
> > that name when providing a binding or make it an anoymous clock?
> > What does MFU stand for anyway?
>
> Sure. I could have make it an anonymous clock but the name "MFUCLK" was
> already used by the pxa168 Ethernet driver so I didn't wanted to change
> that.
I believe you can just ask for an anonymous clock anyway and get the
first one even if it has a name, but I didn't check.
In any case, we should not just take a clock name in a DT binding
because it happened to be used by platform code. It's easy fix the
platform code when someone makes a mistake there, but very hard to
fix DT strings once there are users relying on a particular convention.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] kbuild: remove unnecessary "obj- := dummy.o" trick
From: Mike Turquette @ 2014-09-09 17:43 UTC (permalink / raw)
To: Masahiro Yamada, linux-kbuild
Cc: Masahiro Yamada, Ben Dooks, Kukjin Kim, Russell King,
Laurent Pinchart, Simon Horman, Geert Uytterhoeven, Wolfram Sang,
Takashi Yoshii, Ulrich Hecht, linux-arm-kernel, linux-samsung-soc,
linux-kernel, netdev
In-Reply-To: <1410258381-7088-2-git-send-email-yamada.m@jp.panasonic.com>
Quoting Masahiro Yamada (2014-09-09 03:26:19)
> In these Makefiles, at least one of "obj-y" and "obj-" is non-empty,
> hence built-in.o is always created without such a trick.
>
> Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
> ---
>
> arch/arm/plat-samsung/Makefile | 1 -
> drivers/clk/shmobile/Makefile | 2 --
> drivers/net/wimax/Makefile | 4 ----
> 3 files changed, 7 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
> index 5fe1750..a402262 100644
> --- a/arch/arm/plat-samsung/Makefile
> +++ b/arch/arm/plat-samsung/Makefile
> @@ -8,7 +8,6 @@ ccflags-$(CONFIG_ARCH_MULTI_V7) += -I$(srctree)/$(src)/include
>
> obj-y :=
> obj-m :=
> -obj-n := dummy.o
> obj- :=
>
> # Objects we always build independent of SoC choice
> diff --git a/drivers/clk/shmobile/Makefile b/drivers/clk/shmobile/Makefile
> index e002923..9aab51c8 100644
> --- a/drivers/clk/shmobile/Makefile
> +++ b/drivers/clk/shmobile/Makefile
> @@ -6,5 +6,3 @@ obj-$(CONFIG_ARCH_R8A7790) += clk-rcar-gen2.o
> obj-$(CONFIG_ARCH_R8A7791) += clk-rcar-gen2.o
> obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += clk-div6.o
> obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += clk-mstp.o
> -# for emply built-in.o
> -obj-n := dummy
> diff --git a/drivers/net/wimax/Makefile b/drivers/net/wimax/Makefile
> index 992bc02..692184d 100644
> --- a/drivers/net/wimax/Makefile
> +++ b/drivers/net/wimax/Makefile
> @@ -1,5 +1 @@
> -
> obj-$(CONFIG_WIMAX_I2400M) += i2400m/
> -
> -# (from Sam Ravnborg) force kbuild to create built-in.o
> -obj- := dummy.o
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH v10 net-next 0/2] load imm64 insn and uapi/linux/bpf.h
From: David Miller @ 2014-09-09 17:30 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A,
torvalds-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
luto-kltTT9wpgjJwATOyAt5JVQ, rostedt-nx8X9YLhiw1AfugRpC6u6w,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
chema-hpIqsD4AKlfQT0dZR+AlfA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw, hpa-YMNOUZJC4hwAvxtiuMwx3w,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
keescook-F7+t8E8rja9g9hUCZPvPmw, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1409894238-9055-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Thu, 4 Sep 2014 22:17:16 -0700
> V9->V10
> - no changes, added Daniel's ack
>
> Note they're on top of Hannes's patch in the same area [1]
>
> V8 thread with 'why' reasoning and end goal [2]
>
> Original set [3] of ~28 patches I'm planning to present in 4 stages:
>
> I. this 2 patches to fork off llvm upstreaming
> II. bpf syscall with manpage and map implementation
> III. bpf program load/unload with verifier testsuite (1st user of
> instruction macros from bpf.h and 1st user of load imm64 insn)
> IV. tracing, etc
>
> [1] http://patchwork.ozlabs.org/patch/385266/
> [2] https://lkml.org/lkml/2014/8/27/628
> [3] https://lkml.org/lkml/2014/8/26/859
Begrudgingly, I've applied this series.
Although I really wish you had included the mechanism for userland to
use the eBPF instructions alongside exporting them to userspace.
You kept saying "LLVM is the user" but that's a bullshit argument
because you aren't including the patches necessary to actually
propagate native eBPF programs into the kernel.
That's what, 1 or 2 patches, right? Which is not an unreasonable
request.
Anyways, I'm just extremely frustrated with how you operate and work,
you push things way too hard. I hate to say this, but you are the
kind of submitter who gets his way by being persistent rather than
making well formed pleasant submissions that are easy to integrate.
^ permalink raw reply
* Re: [net-next PATCH v3 10/15] net: sched: rcu'ify cls_rsvp
From: John Fastabend @ 2014-09-09 16:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: xiyou.wangcong, davem, jhs, netdev, paulmck, brouer
In-Reply-To: <1410269221.11872.179.camel@edumazet-glaptop2.roam.corp.google.com>
On 09/09/2014 06:27 AM, Eric Dumazet wrote:
> On Mon, 2014-09-08 at 22:58 -0700, John Fastabend wrote:
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>> net/sched/cls_rsvp.h | 155 +++++++++++++++++++++++++++++---------------------
>> 1 file changed, 89 insertions(+), 66 deletions(-)
>>
>> diff --git a/net/sched/cls_rsvp.h b/net/sched/cls_rsvp.h
>> index 1020e23..8a35bdc 100644
[...]
>> @@ -521,12 +535,17 @@ insert:
>>
>> tcf_exts_change(tp, &f->exts, &e);
>>
>> - for (fp = &s->ht[h2]; *fp; fp = &(*fp)->next)
>> - if (((*fp)->spi.mask & f->spi.mask) != f->spi.mask)
>> + fp = &s->ht[h2];
>> + for (nfp = rtnl_dereference(*fp); nfp;
>> + fp = &nfp->next, nfp = rtnl_dereference(*fp)) {
>> + __u32 mask = nfp->spi.mask & f->spi.mask;
>> +
>> + if (mask != f->spi.mask)
>> break;
>> - f->next = *fp;
>> + }
>> + rcu_assign_pointer(f->next, nfp);
>
> RCU_INIT_POINTER()
>
>> wmb();
>
> Are you sure we need to keep this wmb() ? I dont think so.
Agreed, I'll remove it.
>
>> - *fp = f;
>> + rcu_assign_pointer(*fp, f);
>>
>> *arg = (unsigned long)f;
>> return 0;
>> @@ -546,13 +565,15 @@ insert:
>> s->protocol = pinfo->protocol;
>> s->tunnelid = pinfo->tunnelid;
>> }
>> - for (sp = &data->ht[h1]; *sp; sp = &(*sp)->next) {
>> - if (((*sp)->dpi.mask&s->dpi.mask) != s->dpi.mask)
>> + sp = &data->ht[h1];
>> + for (nsp = rtnl_dereference(*sp); nsp;
>> + sp = &nsp->next, nsp = rtnl_dereference(*sp)) {
>> + if ((nsp->dpi.mask & s->dpi.mask) != s->dpi.mask)
>> break;
>> }
>> - s->next = *sp;
>> + rcu_assign_pointer(s->next, nsp);
>
> RCU_INIT_POINTER()
>
>> wmb();
>
> This wmb() can be removed.
>
yep, same here I'll remove it.
Thanks,
John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: 3.17-rc1 oops during network interface configuration
From: Chuck Lever @ 2014-09-09 16:41 UTC (permalink / raw)
To: Steve Wise; +Cc: Bart Van Assche, netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma
In-Reply-To: <007401cfcc4a$7b32b280$71981780$@opengridcomputing.com>
On Sep 9, 2014, at 12:24 PM, Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> wrote:
>
>
>> -----Original Message-----
>> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-owner@vger.kernel.org] On Behalf Of Chuck Lever
>> Sent: Tuesday, August 19, 2014 9:56 AM
>> To: Bart Van Assche
>> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-rdma
>> Subject: Re: 3.17-rc1 oops during network interface configuration
>>
>>
>> On Aug 18, 2014, at 8:18 AM, Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org> wrote:
>>
>>> Hello,
>>>
>>> Has anyone else already tried to boot kernel 3.17-rc1 on an IB system ?
>>
>> After updating to 3.17-rc1 this morning, I hit the same issue.
>>
>
> I still see this with 3.17-rc4. Perhaps somebody should fix it. :)
I’m working on it right now.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/8] net: pxa168_eth: get and set the mac address on the Ethernet controller
From: Antoine Tenart @ 2014-09-09 16:36 UTC (permalink / raw)
To: Jason Cooper
Cc: thomas.petazzoni, zmxu, devicetree, netdev, Antoine Tenart,
linux-kernel, alexandre.belloni, jszhang, linux-arm-kernel,
sebastian.hesselbarth
In-Reply-To: <20140909162958.GS30828@titan.lakedaemon.net>
Jason,
On Tue, Sep 09, 2014 at 12:29:58PM -0400, Jason Cooper wrote:
> On Tue, Sep 09, 2014 at 04:44:05PM +0200, Antoine Tenart wrote:
> > When changing the MAC address, in addition to updating the dev_addr in
> > the net_device structure, this patch also update the MAC address
> > registers (high and low) of the Ethernet controller with the new MAC.
> > The address stored in these registers is used for IEEE 802.3x Ethernet
> > flow control, which is already enabled.
> >
> > This patch also tries reading the MAC address stored in these registers
> > when probing the driver, to use the MAC address set by the bootloader
> > and avoid using a random one.
>
> Hmm, the wording here seems odd. I think the preference should be:
>
> 1) bootloader-supplied addr via DT
> 2) addr read from device
> 3) randomly generated one.
I agree. I'll update that.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [net-next PATCH v3 09/15] net: sched: make cls_u32 lockless
From: John Fastabend @ 2014-09-09 16:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: xiyou.wangcong, davem, jhs, netdev, paulmck, brouer
In-Reply-To: <1410268807.11872.177.camel@edumazet-glaptop2.roam.corp.google.com>
On 09/09/2014 06:20 AM, Eric Dumazet wrote:
> On Mon, 2014-09-08 at 22:58 -0700, John Fastabend wrote:
>> Make cls_u32 classifier safe to run without holding lock. This patch
>> converts statistics that are kept in read section u32_classify into
>> per cpu counters.
>>
>> This patch was tested with a tight u32 filter add/delete loop while
>> generating traffic with pktgen. By running pktgen on vlan devices
>> created on top of a physical device we can hit the qdisc layer
>> correctly. For ingress qdisc's a loopback cable was used.
>>
>> for i in {1..100}; do
>> q=`echo $i%8|bc`;
>> echo -n "u32 tos: iteration $i on queue $q";
>> tc filter add dev p3p2 parent $p prio $i u32 match ip tos 0x10 0xff \
>> action skbedit queue_mapping $q;
>> sleep 1;
>> tc filter del dev p3p2 prio $i;
>>
>> echo -n "u32 tos hash table: iteration $i on queue $q";
>> tc filter add dev p3p2 parent $p protocol ip prio $i handle 628: u32 divisor 1
>> tc filter add dev p3p2 parent $p protocol ip prio $i u32 \
>> match ip protocol 17 0xff link 628: offset at 0 mask 0xf00 shift 6 plus 0
>> tc filter add dev p3p2 parent $p protocol ip prio $i u32 \
>> ht 628:0 match ip tos 0x10 0xff action skbedit queue_mapping $q
>> sleep 2;
>> tc filter del dev p3p2 prio $i
>> sleep 1;
>> done
>>
>
>
> Note it might be easier to split this patch in 2 parts.
>
> (The percpu stuff could be done in a first step, then rcu conversion)
Sure, I'll split it up.
>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
[...]
>>
>> static inline unsigned int u32_hash_fold(__be32 key,
>> @@ -96,7 +103,7 @@ static int u32_classify(struct sk_buff *skb, const struct tcf_proto *tp, struct
>> unsigned int off;
>> } stack[TC_U32_MAXDEPTH];
>>
>> - struct tc_u_hnode *ht = tp->root;
>> + struct tc_u_hnode *ht = rcu_dereference_bh(tp->root);
>> unsigned int off = skb_network_offset(skb);
>> struct tc_u_knode *n;
>> int sdepth = 0;
>> @@ -108,23 +115,23 @@ static int u32_classify(struct sk_buff *skb, const struct tcf_proto *tp, struct
>> int i, r;
>>
>> next_ht:
>> - n = ht->ht[sel];
>> + n = rcu_dereference_bh(ht->ht[sel]);
>>
>> next_knode:
>> if (n) {
>> struct tc_u32_key *key = n->sel.keys;
>>
>> #ifdef CONFIG_CLS_U32_PERF
>> - n->pf->rcnt += 1;
>> + this_cpu_inc(n->pf->rcnt);
>
> As we run in BH, we are not preemptable, we can use instead :
> __this_cpu_inc() (on all occurrences)
>
> Using a macro would also reduce the #ifdef mess of this file
>
I'll go ahead and do the macro conversion.
>> j = 0;
>> #endif
>>
>> #ifdef CONFIG_CLS_U32_MARK
>> - if ((skb->mark & n->mark.mask) != n->mark.val) {
>> - n = n->next;
>> + if ((skb->mark & n->mask) != n->val) {
>> + n = rcu_dereference_bh(n->next);
>> goto next_knode;
>> } else {
>> - n->mark.success++;
>> + this_cpu_inc(*n->pcpu_success);
>> }
>> #endif
>>
[...]
>> @@ -326,11 +342,11 @@ static int u32_init(struct tcf_proto *tp)
>> }
>>
>> tp_c->refcnt++;
>> - root_ht->next = tp_c->hlist;
>> - tp_c->hlist = root_ht;
>> + rcu_assign_pointer(root_ht->next, tp_c->hlist);
>
> RCU_INIT_POINTER() or root_ht->next = tp_c->hlist;
>
I'll fix all these as well.
>> + rcu_assign_pointer(tp_c->hlist, root_ht);
>> root_ht->tp_c = tp_c;
>>
>> - tp->root = root_ht;
>> + rcu_assign_pointer(tp->root, root_ht);
>> tp->data = tp_c;
>> return 0;
>> }
>> @@ -342,25 +358,33 @@ static int u32_destroy_key(struct tcf_proto *tp, struct tc_u_knode *n)
>> if (n->ht_down)
>> n->ht_down->refcnt--;
>> #ifdef CONFIG_CLS_U32_PERF
>> - kfree(n->pf);
>> + free_percpu(n->pf);
>> #endif
>> kfree(n);
>> return 0;
>> }
>>
>> +void __u32_delete_key(struct rcu_head *rcu)
>
> Can we consistently use _rcu, as in u32_delete_key_rcu() ?
Yes, I'll rename these calls.
Thanks,
John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH v2 5/8] net: pxa168_eth: get and set the mac address on the Ethernet controller
From: Jason Cooper @ 2014-09-09 16:29 UTC (permalink / raw)
To: Antoine Tenart
Cc: sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
zmxu-eYqpPyKDWXRBDgjK7y7TUQ, jszhang-eYqpPyKDWXRBDgjK7y7TUQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1410273848-24663-6-git-send-email-antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Sep 09, 2014 at 04:44:05PM +0200, Antoine Tenart wrote:
> When changing the MAC address, in addition to updating the dev_addr in
> the net_device structure, this patch also update the MAC address
> registers (high and low) of the Ethernet controller with the new MAC.
> The address stored in these registers is used for IEEE 802.3x Ethernet
> flow control, which is already enabled.
>
> This patch also tries reading the MAC address stored in these registers
> when probing the driver, to use the MAC address set by the bootloader
> and avoid using a random one.
Hmm, the wording here seems odd. I think the preference should be:
1) bootloader-supplied addr via DT
2) addr read from device
3) randomly generated one.
>
> Signed-off-by: Antoine Tenart <antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> drivers/net/ethernet/marvell/pxa168_eth.c | 36 +++++++++++++++++++++++++++++--
> 1 file changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
> index 10422f2df6cc..0ecbb3903b71 100644
> --- a/drivers/net/ethernet/marvell/pxa168_eth.c
> +++ b/drivers/net/ethernet/marvell/pxa168_eth.c
> @@ -60,6 +60,8 @@
> #define PORT_COMMAND 0x0410
> #define PORT_STATUS 0x0418
> #define HTPR 0x0428
> +#define MAC_ADDR_LOW 0x0430
> +#define MAC_ADDR_HIGH 0x0438
> #define SDMA_CONFIG 0x0440
> #define SDMA_CMD 0x0448
> #define INT_CAUSE 0x0450
> @@ -604,16 +606,42 @@ static void pxa168_eth_set_rx_mode(struct net_device *dev)
> update_hash_table_mac_address(pep, NULL, ha->addr);
> }
>
> +static void pxa168_eth_get_mac_address(struct net_device *dev,
> + unsigned char *addr)
> +{
> + struct pxa168_eth_private *pep = netdev_priv(dev);
> + unsigned int mac_h = rdl(pep, MAC_ADDR_HIGH);
> + unsigned int mac_l = rdl(pep, MAC_ADDR_LOW);
> +
> + addr[0] = (mac_h >> 24) & 0xff;
> + addr[1] = (mac_h >> 16) & 0xff;
> + addr[2] = (mac_h >> 8) & 0xff;
> + addr[3] = mac_h & 0xff;
> + addr[4] = (mac_l >> 8) & 0xff;
> + addr[5] = mac_l & 0xff;
> +}
> +
> static int pxa168_eth_set_mac_address(struct net_device *dev, void *addr)
> {
> struct sockaddr *sa = addr;
> struct pxa168_eth_private *pep = netdev_priv(dev);
> unsigned char oldMac[ETH_ALEN];
> + u32 mac_h, mac_l;
>
> if (!is_valid_ether_addr(sa->sa_data))
> return -EADDRNOTAVAIL;
> memcpy(oldMac, dev->dev_addr, ETH_ALEN);
> memcpy(dev->dev_addr, sa->sa_data, ETH_ALEN);
> +
> + mac_h = sa->sa_data[0] << 24;
> + mac_h |= sa->sa_data[1] << 16;
> + mac_h |= sa->sa_data[2] << 8;
> + mac_h |= sa->sa_data[3];
> + mac_l = sa->sa_data[4] << 8;
> + mac_l |= sa->sa_data[5];
> + wrl(pep, MAC_ADDR_HIGH, mac_h);
> + wrl(pep, MAC_ADDR_LOW, mac_l);
> +
> netif_addr_lock_bh(dev);
> update_hash_table_mac_address(pep, oldMac, dev->dev_addr);
> netif_addr_unlock_bh(dev);
> @@ -1494,8 +1522,12 @@ static int pxa168_eth_probe(struct platform_device *pdev)
>
> INIT_WORK(&pep->tx_timeout_task, pxa168_eth_tx_timeout_task);
>
> - dev_info(&pdev->dev, "Using random mac address\n");
> - eth_hw_addr_random(dev);
> + /* try reading the mac address, if set by the bootloader */
> + pxa168_eth_get_mac_address(dev, dev->dev_addr);
> + if (!is_valid_ether_addr(dev->dev_addr)) {
> + dev_info(&pdev->dev, "Using random mac address\n");
> + eth_hw_addr_random(dev);
> + }
I would do the above iff there was no valid addr supplied by the DT.
thx,
Jason.
>
> pep->rx_ring_size = NUM_RX_DESCS;
> pep->tx_ring_size = NUM_TX_DESCS;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next PATCH v3 07/15] net: sched: RCU cls_route
From: John Fastabend @ 2014-09-09 16:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: xiyou.wangcong, davem, jhs, netdev, paulmck, brouer
In-Reply-To: <1410267553.11872.167.camel@edumazet-glaptop2.roam.corp.google.com>
On 09/09/2014 05:59 AM, Eric Dumazet wrote:
> On Mon, 2014-09-08 at 22:57 -0700, John Fastabend wrote:
>> RCUify the route classifier. For now however spinlock's are used to
>> protect fastmap cache.
>>
>> The issue here is the fastmap may be read by one CPU while the
>> cache is being updated by another. An array of pointers could be
>> one possible solution.
>
> Yep, this doesnt seem like an urgent issue anyway.
>
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
[...]
>> @@ -296,27 +324,35 @@ static int route4_delete(struct tcf_proto *tp, unsigned long arg)
>> h = f->handle;
>> b = f->bkt;
>>
>> - for (fp = &b->ht[from_hash(h >> 16)]; *fp; fp = &(*fp)->next) {
>> - if (*fp == f) {
>> - tcf_tree_lock(tp);
>> + fp = &b->ht[from_hash(h >> 16)];
>> + for (nf = rtnl_dereference(*fp); nf;
>> + fp = &nf->next, nf = rtnl_dereference(*fp)) {
>> + if (nf == f) {
>> + /* unlink it */
>> *fp = f->next;
>
> Strange you left this without annotations, while rest of your patches
> always use rcu_assign_pointer(*fp, rtnl_dereference(f->next)
>
> Note that it is absolutely fine to use *fp = f->next;
>
> ;)
>
I was just trying to be explicit in the other cases although I
chose rcu_assign_pointer in many cases instead of INIT_POINTER. So for
consistency I'll make this,
RCU_INIT_POINTER(*fp, rtnl_dereference(f->next))
I also thought that sparse would warn about not wrapping f->next in
rtnl_dereference, but apparently that is not the case.
>> - tcf_tree_unlock(tp);
>>
>
>
>
--
John Fastabend Intel Corporation
^ permalink raw reply
* RE: 3.17-rc1 oops during network interface configuration
From: Steve Wise @ 2014-09-09 16:24 UTC (permalink / raw)
To: 'Chuck Lever', 'Bart Van Assche'
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, 'linux-rdma'
In-Reply-To: <BA3DEE00-C035-41B9-8ECD-614F04483395-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> -----Original Message-----
> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Chuck Lever
> Sent: Tuesday, August 19, 2014 9:56 AM
> To: Bart Van Assche
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-rdma
> Subject: Re: 3.17-rc1 oops during network interface configuration
>
>
> On Aug 18, 2014, at 8:18 AM, Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org> wrote:
>
> > Hello,
> >
> > Has anyone else already tried to boot kernel 3.17-rc1 on an IB system ?
>
> After updating to 3.17-rc1 this morning, I hit the same issue.
>
I still see this with 3.17-rc4. Perhaps somebody should fix it. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] kbuild: remove unnecessary "obj- := dummy.o" trick
From: Peter Foley @ 2014-09-09 16:21 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kbuild, Ben Dooks, Kukjin Kim, Russell King, Mike Turquette,
Laurent Pinchart, Simon Horman, Geert Uytterhoeven, Wolfram Sang,
Takashi Yoshii, Ulrich Hecht, linux-arm-kernel, linux-samsung-soc,
LKML, netdev
In-Reply-To: <1410258381-7088-2-git-send-email-yamada.m@jp.panasonic.com>
On Tue, Sep 9, 2014 at 6:26 AM, Masahiro Yamada
<yamada.m@jp.panasonic.com> wrote:
> In these Makefiles, at least one of "obj-y" and "obj-" is non-empty,
> hence built-in.o is always created without such a trick.
>
> Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Peter Foley <pefoley2@pefoley.com>
^ permalink raw reply
* Re: [net-next PATCH v3 05/15] net: sched: cls_flow use RCU
From: Eric Dumazet @ 2014-09-09 16:20 UTC (permalink / raw)
To: John Fastabend; +Cc: xiyou.wangcong, davem, jhs, netdev, paulmck, brouer
In-Reply-To: <540F2640.2080904@gmail.com>
On Tue, 2014-09-09 at 09:09 -0700, John Fastabend wrote:
> On 09/09/2014 05:41 AM, Eric Dumazet wrote:
> >> struct flow_filter {
> >> struct list_head list;
> >> + struct rcu_head rcu;
> >
> > Please move these 2 new fields at the end of structure, they are only
> > used at dismantle phase.
> >
> > Patch looks fine otherwise, thanks !
> >
> >
>
> 2 new fields? The first rcu struct is already at end of
> structure. I assume you just mean the rcu struct in flow_filter.
Yes, I was referring to these fields.
^ permalink raw reply
* Re: [net-next PATCH v3 05/15] net: sched: cls_flow use RCU
From: John Fastabend @ 2014-09-09 16:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: xiyou.wangcong, davem, jhs, netdev, paulmck, brouer
In-Reply-To: <1410266481.11872.158.camel@edumazet-glaptop2.roam.corp.google.com>
On 09/09/2014 05:41 AM, Eric Dumazet wrote:
> On Mon, 2014-09-08 at 22:56 -0700, John Fastabend wrote:
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>> net/sched/cls_flow.c | 145 +++++++++++++++++++++++++++++---------------------
>> 1 file changed, 84 insertions(+), 61 deletions(-)
>>
>> diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
>> index 35be16f..e33560b 100644
>> --- a/net/sched/cls_flow.c
>> +++ b/net/sched/cls_flow.c
>> @@ -34,12 +34,15 @@
>>
>> struct flow_head {
>> struct list_head filters;
>> + struct rcu_head rcu;
>> };
>>
>> struct flow_filter {
>> struct list_head list;
>> + struct rcu_head rcu;
>
> Please move these 2 new fields at the end of structure, they are only
> used at dismantle phase.
>
> Patch looks fine otherwise, thanks !
>
>
2 new fields? The first rcu struct is already at end of
structure. I assume you just mean the rcu struct in flow_filter.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH v2 3/8] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Antoine Tenart @ 2014-09-09 16:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Antoine Tenart, sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
zmxu-eYqpPyKDWXRBDgjK7y7TUQ, jszhang-eYqpPyKDWXRBDgjK7y7TUQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3827594.chb831jyvc@wuerfel>
Arnd,
On Tue, Sep 09, 2014 at 05:58:12PM +0200, Arnd Bergmann wrote:
> On Tuesday 09 September 2014 16:44:03 Antoine Tenart wrote:
> > +- clocks: pointer to the clock for the device.
> > +- clock-names: should be "MFUCLK".
>
> Clock names are normally not capitalized. Are you able to change
> that name when providing a binding or make it an anoymous clock?
> What does MFU stand for anyway?
Sure. I could have make it an anonymous clock but the name "MFUCLK" was
already used by the pxa168 Ethernet driver so I didn't wanted to change
that.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/8] net: pxa168_eth: get and set the mac address on the Ethernet controller
From: Arnd Bergmann @ 2014-09-09 15:59 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Antoine Tenart, sebastian.hesselbarth, thomas.petazzoni, zmxu,
devicetree, netdev, linux-kernel, alexandre.belloni, jszhang
In-Reply-To: <1410273848-24663-6-git-send-email-antoine.tenart@free-electrons.com>
On Tuesday 09 September 2014 16:44:05 Antoine Tenart wrote:
> When changing the MAC address, in addition to updating the dev_addr in
> the net_device structure, this patch also update the MAC address
> registers (high and low) of the Ethernet controller with the new MAC.
> The address stored in these registers is used for IEEE 802.3x Ethernet
> flow control, which is already enabled.
>
> This patch also tries reading the MAC address stored in these registers
> when probing the driver, to use the MAC address set by the bootloader
> and avoid using a random one.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
>
I think it would be good to allow overriding the address using a
'mac-address' property from DT. It's very easy to call
of_get_mac_address().
Arnd
^ permalink raw reply
* Re: [PATCH v2 3/8] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Arnd Bergmann @ 2014-09-09 15:58 UTC (permalink / raw)
To: Antoine Tenart
Cc: sebastian.hesselbarth, alexandre.belloni, thomas.petazzoni, zmxu,
jszhang, netdev, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1410273848-24663-4-git-send-email-antoine.tenart@free-electrons.com>
On Tuesday 09 September 2014 16:44:03 Antoine Tenart wrote:
> +- clocks: pointer to the clock for the device.
> +- clock-names: should be "MFUCLK".
Clock names are normally not capitalized. Are you able to change
that name when providing a binding or make it an anoymous clock?
What does MFU stand for anyway?
Arnd
^ 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