* Re: [PATCH 2/2] ixgbe: support skb->xmit_more in netdev_ops->ndo_start_xmit()
From: Alexander Duyck @ 2014-08-26 15:00 UTC (permalink / raw)
To: David Miller, netdev
Cc: therbert, jhs, hannes, edumazet, jeffrey.t.kirsher, rusty,
dborkman, brouer
In-Reply-To: <20140825.163505.1969688661687017343.davem@davemloft.net>
On 08/25/2014 04:35 PM, David Miller wrote:
>
> From: Daniel Borkmann <dborkman@redhat.com>
>
> This implements the deferred tail pointer flush API for the ixgbe
> driver. Similar version also proposed longer time ago by Alexander Duyck.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 87bd53f..ba9ceaa 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -6958,9 +6958,10 @@ static void ixgbe_tx_map(struct ixgbe_ring *tx_ring,
>
> tx_ring->next_to_use = i;
>
> - /* notify HW of packet */
> - ixgbe_write_tail(tx_ring, i);
> -
> + if (!skb->xmit_more) {
> + /* notify HW of packet */
> + ixgbe_write_tail(tx_ring, i);
> + }
> return;
> dma_error:
> dev_err(tx_ring->dev, "TX DMA map failed\n");
>
It might help to add some handling for the case where xmit_more is set,
but the ring has become full. This current implementation introduces
the risk of triggering a Tx hang.
My advice would be to pull the ixgbe_maybe_stop_tx code at the end of
xmit_frame into the if check here, and perhaps look into adding an
additional check to see if BQL has stopped the ring as well.
Thanks,
Alex
^ permalink raw reply
* Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
From: Jamal Hadi Salim @ 2014-08-26 14:58 UTC (permalink / raw)
To: Jiri Pirko, Roopa Prabhu
Cc: Thomas Graf, John Fastabend, Scott Feldman, netdev, David Miller,
Neil Horman, Andy Gospodarek, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, f.fainelli, linville, dev, jasowang,
ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, Shrijeet Mukherjee <
In-Reply-To: <20140826140630.GA1848@nanopsycho.lan>
On 08/26/14 10:06, Jiri Pirko wrote:
> Yes. Flows are phase one. The api will be extended in for whatever is
> needed for l2/l3 as you said. Also I see a possibility to implement the
> l2/l3 use case with flows as well.
And as a note: This is where i have the disagreement.
It is good there is acknowledgement you are handling flows for now.
Or whatever tuples you defined as "flow". I dont think L2 or 3 fit
in that. If thats not what you are saying then we are in agreement.
cheers,
jamal
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-08-26 14:56 UTC (permalink / raw)
To: Michael Tokarev
Cc: brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <53FC1789.6020407-Gdu+ltImwkhes2APU0mLOQ@public.gmane.org>
On 08/26/14 07:13, Michael Tokarev wrote:
> [Adding netdev@ to the mix.
> Original thread, started at Dec-2013, can be found at
> http://marc.info/?t=138817851800006&r=1&w=2 or
> http://www.spinics.net/lists/linux-wireless/msg116502.html
> ]
>
> 19.04.2014 15:42, Michael Tokarev wrote:
>> [big skip]
>>
>>
>> Tried kernel 3.14 with this device. Still no go, the brcmsmac driver still
>> does not work correctly, it stalls as before.
>
> Today I tried 3.16 kernel today too, just for fun (since this whole brcmsmac
> thing looks not more like a non-working toy). Now with another laptop and
> the same broadcom wifi adaptor (BRCM4313 802.11bgn Wireless Network Adapter
> rev 01) (because due to cracked usb port on my original notebook it does not
> work anymore).
>
> This combination (kernel& wifi) does not work at all. Or, it is more jokish
> than before -- the NIC works for ARP packets but nothing else, not even ping
> or DNS or NTP. I see the access point sending replies (to pings or dns), but
> these replies are not shown by tcpdump on the laptop. Even not all ARP packets
> sent by the AP reaches the laptop.
>
> So, I'm curious -- why this driver is found in regular section of kernel?
> It looks like it should be in staging at least, or better yet, in a new section
> titled "toy drivers" or something like this. Does it work for any device at
> all?
Hi Michael,
Thanks for your encouraging suggestions. I revisited the threads you
referred to. In the boardflags it shows you have a bt+wifi card. It
could be that is an issue. The brcmsmac supports other devices, ie.
bcm43224/5 and the bcm4313 comes in a number of varieties. From what you
tell here it seems you have trouble in rx path so I will look into that
area if there is any specifically done for your variant of the bcm4313.
Regards,
Arend
> Thanks,
>
> /mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 net-next 2/2] tipc: add name distributor resiliency queue
From: Jon Maloy @ 2014-08-26 14:55 UTC (permalink / raw)
To: Erik Hugne
Cc: ying.xue@windriver.com, Richard Alpe, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net
In-Reply-To: <20140826144816.GD24538@eerihug-hybrid.rnd.ki.sw.ericsson.se>
> -----Original Message-----
> From: Erik Hugne
> Sent: August-26-14 10:48 AM
> To: Jon Maloy
> Cc: ying.xue@windriver.com; Richard Alpe; netdev@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net
> Subject: Re: [PATCH v2 net-next 2/2] tipc: add name distributor resiliency
> queue
>
> On Tue, Aug 26, 2014 at 04:44:34PM +0200, Jon Maloy wrote:
> > (netdev removed from receiver list)
> >
> > > -----Original Message-----
> > > From: Erik Hugne
> > > Sent: August-26-14 10:33 AM
> > > To: Jon Maloy; ying.xue@windriver.com; Richard Alpe;
> > > netdev@vger.kernel.org
> > > Cc: tipc-discussion@lists.sourceforge.net
> > > Subject: Re: [PATCH v2 net-next 2/2] tipc: add name distributor
> > > resiliency queue
> > >
> > > if (e->expiry > now) should in fact be if (time_after(e->expiry,
> > > now) to handle timer wraps correctly.
> > >
> > > Thanks Niklas Söderlund for pointing this out.
> > >
> > > v2 removed from patchwork
> > >
> > > //E
> >
> > Also, don't use the version label an comment when you send this to
> > David. This has only relevance to us who are reviewing the series. (I
> > assume it was a mistake)
>
> No, this is in the general guidelines for submitting patches section 15.
> https://www.kernel.org/doc/Documentation/SubmittingPatches
>
> //E
Ok. I missed that this actually was the second version you sent to
netdev. What I meant was the versioning we are using during our
own, internal discussions at tipc-discussion. This certainly has no
relevance for David & co.
Regards
///jon
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] tipc: add name distributor resiliency queue
From: Erik Hugne @ 2014-08-26 14:48 UTC (permalink / raw)
To: Jon Maloy
Cc: ying.xue@windriver.com, Richard Alpe, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net
In-Reply-To: <A2BAEFC30C8FD34388F02C9B3121859D1C2BF752@eusaamb103.ericsson.se>
On Tue, Aug 26, 2014 at 04:44:34PM +0200, Jon Maloy wrote:
> (netdev removed from receiver list)
>
> > -----Original Message-----
> > From: Erik Hugne
> > Sent: August-26-14 10:33 AM
> > To: Jon Maloy; ying.xue@windriver.com; Richard Alpe;
> > netdev@vger.kernel.org
> > Cc: tipc-discussion@lists.sourceforge.net
> > Subject: Re: [PATCH v2 net-next 2/2] tipc: add name distributor resiliency
> > queue
> >
> > if (e->expiry > now) should in fact be
> > if (time_after(e->expiry, now) to handle timer wraps correctly.
> >
> > Thanks Niklas Söderlund for pointing this out.
> >
> > v2 removed from patchwork
> >
> > //E
>
> Also, don't use the version label an comment when you send this
> to David. This has only relevance to us who are reviewing the
> series. (I assume it was a mistake)
No, this is in the general guidelines for submitting patches section 15.
https://www.kernel.org/doc/Documentation/SubmittingPatches
//E
^ permalink raw reply
* RE: [PATCH v2 net-next 2/2] tipc: add name distributor resiliency queue
From: Jon Maloy @ 2014-08-26 14:44 UTC (permalink / raw)
To: Erik Hugne, ying.xue@windriver.com, Richard Alpe,
netdev@vger.kernel.org
Cc: tipc-discussion@lists.sourceforge.net
In-Reply-To: <20140826143245.GC24538@eerihug-hybrid.rnd.ki.sw.ericsson.se>
(netdev removed from receiver list)
> -----Original Message-----
> From: Erik Hugne
> Sent: August-26-14 10:33 AM
> To: Jon Maloy; ying.xue@windriver.com; Richard Alpe;
> netdev@vger.kernel.org
> Cc: tipc-discussion@lists.sourceforge.net
> Subject: Re: [PATCH v2 net-next 2/2] tipc: add name distributor resiliency
> queue
>
> if (e->expiry > now) should in fact be
> if (time_after(e->expiry, now) to handle timer wraps correctly.
>
> Thanks Niklas Söderlund for pointing this out.
>
> v2 removed from patchwork
>
> //E
Also, don't use the version label an comment when you send this
to David. This has only relevance to us who are reviewing the
series. (I assume it was a mistake)
///jon
>
> On Tue, Aug 26, 2014 at 10:57:57AM +0200, erik.hugne@ericsson.com wrote:
> > +void tipc_named_process_backlog(void) {
> > + struct distr_queue_item *e, *tmp;
> > + char addr[16];
> > + u64 now = get_jiffies_64();
> > +
> > + list_for_each_entry_safe(e, tmp, &tipc_dist_queue, next) {
> > + if (e->expiry > now) {
> > + if (!tipc_update_nametbl(&e->i, e->node, e-
> >dtype))
> > + continue;
> > + } else {
> > + tipc_addr_string_fill(addr, e->node);
> > + pr_warn_ratelimited("Dropping name table update
> (%d) of {%u, %u, %u} from %s key=%u\n",
> > + e->dtype, ntohl(e->i.type),
> > + ntohl(e->i.lower),
> > + ntohl(e->i.upper),
> > + addr, ntohl(e->i.key));
> > + }
> > + list_del(&e->next);
> > + kfree(e);
> > + }
> > +}
> > +
^ permalink raw reply
* Re: [PATCH 0/2] Get rid of ndo_xmit_flush
From: Jamal Hadi Salim @ 2014-08-26 14:40 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, netdev, therbert, hannes, edumazet,
jeffrey.t.kirsher, rusty, dborkman
In-Reply-To: <20140826121347.0ec7f2ac@redhat.com>
On 08/26/14 06:13, Jesper Dangaard Brouer wrote:
>
> On Tue, 26 Aug 2014 08:28:15 +0200 Jesper Dangaard Brouer <brouer@redhat.com> wrote:
>> On Mon, 25 Aug 2014 16:34:58 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>>
>>> Given Jesper's performance numbers, it's not the way to go.
>>>
>>> Instead, go with a signalling scheme via new boolean skb->xmit_more.
>>
>> I'll do benchmarking based on this new API proposal today.
>
> While establish an accurate baseline for my measurements. I'm
> starting to see too much variation in my trafgen measurements.
> Meaning that we unfortunately cannot use it to measure variations on
> the nanosec scale.
>
> I'm measuring the packets per sec via "ifpps", and calculating an
> average over the measurements, via the following oneliner:
>
> $ ifpps -clod eth5 -t 1000 | awk 'BEGIN{txsum=0; rxsum=0; n=0} /[[:digit:]]/ {txsum+=$11;rxsum+=$3;n++; printf "instant rx:%u tx:%u pps n:%u average: rx:%d tx:%d pps\n", $3, $11, n, rxsum/n, txsum/n }'
>
> Below is measurements done on the *same* kerne:
> - M1: instant tx:1572766 pps n:215 average: tx:1573360 pps (reboot#1)
> - M2: instant tx:1561930 pps n:173 average: tx:1557064 pps (reboot#2)
> - M3: instant tx:1562088 pps n:300 average: tx:1559150 pps (reboot#2)
> - M4: instant tx:1564404 pps n:120 average: tx:1564948 pps (reboot#3)
>
> M1->M2: +6.65ns
> M1->M3: +5.79ns
> M1->M4: +3.42ns
> M3->M4: -2.38ns
>
> I cannot explain the variations, but some options could be
> 1) how well the SKB is cache-hot cached via kmem_cache
> 2) other interrups on CPU#0 could disturb us
> 3) interactions with scheduler
> 4) interactions with transparent hugepages
> 5) CPU "turbostat" interactions
>
The clock source used in your system may be an issue as well.
I am not sure if that matters these days but it used to be.
I think back then you could pick ACPI, Jiffies etc to use
as a qdisc clock source.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] tipc: add name distributor resiliency queue
From: Erik Hugne @ 2014-08-26 14:32 UTC (permalink / raw)
To: jon.maloy, ying.xue, richard.alpe, netdev; +Cc: tipc-discussion
In-Reply-To: <1409043477-22761-2-git-send-email-erik.hugne@ericsson.com>
if (e->expiry > now) should in fact be
if (time_after(e->expiry, now) to handle timer wraps correctly.
Thanks Niklas Söderlund for pointing this out.
v2 removed from patchwork
//E
On Tue, Aug 26, 2014 at 10:57:57AM +0200, erik.hugne@ericsson.com wrote:
> +void tipc_named_process_backlog(void)
> +{
> + struct distr_queue_item *e, *tmp;
> + char addr[16];
> + u64 now = get_jiffies_64();
> +
> + list_for_each_entry_safe(e, tmp, &tipc_dist_queue, next) {
> + if (e->expiry > now) {
> + if (!tipc_update_nametbl(&e->i, e->node, e->dtype))
> + continue;
> + } else {
> + tipc_addr_string_fill(addr, e->node);
> + pr_warn_ratelimited("Dropping name table update (%d) of {%u, %u, %u} from %s key=%u\n",
> + e->dtype, ntohl(e->i.type),
> + ntohl(e->i.lower),
> + ntohl(e->i.upper),
> + addr, ntohl(e->i.key));
> + }
> + list_del(&e->next);
> + kfree(e);
> + }
> +}
> +
^ permalink raw reply
* [PATCH] net: core: neighbour: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
From: Andreea-Cristina Bernat @ 2014-08-26 14:27 UTC (permalink / raw)
To: davem, jiri, hannes, duanj.fnst, ebiederm, aruna.hewapathirane,
tim.gardner, netdev, linux-kernel
Cc: paulmck
According to RCU_INIT_POINTER()'s block comment 3.a, it can be used if
"3. The referenced data structure has already been exposed to readers either
at compile time or via rcu_assign_pointer() -and-
a. You have not made -any- reader-visible changes to this structure since
then".
These cases fulfill the conditions above because between the
rcu_dereference_protected() calls and the rcu_assign_pointer() calls there is
no update of those values.
Therefore, this patch makes the replacements.
The following Coccinelle semantic patch was used:
@@
@@
- rcu_assign_pointer
+ RCU_INIT_POINTER
(...,
(
rtnl_dereference(...)
|
rcu_dereference_protected(...)
) )
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
---
net/core/neighbour.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 32d872e..a193932 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -147,7 +147,7 @@ static int neigh_forced_gc(struct neigh_table *tbl)
write_lock(&n->lock);
if (atomic_read(&n->refcnt) == 1 &&
!(n->nud_state & NUD_PERMANENT)) {
- rcu_assign_pointer(*np,
+ RCU_INIT_POINTER(*np,
rcu_dereference_protected(n->next,
lockdep_is_held(&tbl->lock)));
n->dead = 1;
@@ -216,7 +216,7 @@ static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *dev)
np = &n->next;
continue;
}
- rcu_assign_pointer(*np,
+ RCU_INIT_POINTER(*np,
rcu_dereference_protected(n->next,
lockdep_is_held(&tbl->lock)));
write_lock(&n->lock);
@@ -386,7 +386,7 @@ static struct neigh_hash_table *neigh_hash_grow(struct neigh_table *tbl,
next = rcu_dereference_protected(n->next,
lockdep_is_held(&tbl->lock));
- rcu_assign_pointer(n->next,
+ RCU_INIT_POINTER(n->next,
rcu_dereference_protected(
new_nht->hash_buckets[hash],
lockdep_is_held(&tbl->lock)));
@@ -531,7 +531,7 @@ struct neighbour *__neigh_create(struct neigh_table *tbl, const void *pkey,
n->dead = 0;
if (want_ref)
neigh_hold(n);
- rcu_assign_pointer(n->next,
+ RCU_INIT_POINTER(n->next,
rcu_dereference_protected(nht->hash_buckets[hash_val],
lockdep_is_held(&tbl->lock)));
rcu_assign_pointer(nht->hash_buckets[hash_val], n);
@@ -2432,7 +2432,7 @@ void __neigh_for_each_release(struct neigh_table *tbl,
write_lock(&n->lock);
release = cb(n);
if (release) {
- rcu_assign_pointer(*np,
+ RCU_INIT_POINTER(*np,
rcu_dereference_protected(n->next,
lockdep_is_held(&tbl->lock)));
n->dead = 1;
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
From: Jamal Hadi Salim @ 2014-08-26 14:26 UTC (permalink / raw)
To: Thomas Graf
Cc: John Fastabend, Scott Feldman, Jiri Pirko, netdev, David Miller,
Neil Horman, Andy Gospodarek, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, f.fainelli, roopa, linville, dev,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye
In-Reply-To: <20140825225057.GD30140@casper.infradead.org>
On 08/25/14 18:50, Thomas Graf wrote:
> On 08/25/14 at 12:15pm, Jamal Hadi Salim wrote:
>> On 08/25/14 10:17, Thomas Graf wrote:
>> I dont think we have a problem handling any of this today.
>
> Yes we do. It's restricted to L2 and we can't extend it easily
It is restricted to L2 because it is L2 processing;->
i.e a fixed function that is widely deployed and well understood.
Possible new extensions that are added are still L2
(example I think if you were to add TRILL support, you would
likely need to inherit and extend the bridge then add new TLVs).
> because it is based on NDA_*. The use of Netlink makes in-kernel
> usage a pain.
Ok, I understand what you mean by "in kernel" now.
I believe we have representations that are complete today at L3.
The offloader just feeds on that.
L2 needs some work because we have only been offloading the fdb.
>To me this is the sole reason for not using fdb_add()
> in the first place. It seems absolutely clear though that fdb_add()
> should be removed after the more generic ndo is in place providing
> a superset of what fdb_add() can do today.
>
It is by no means complete as i pointed to in my other email.
We need to worry about bridge ports, vlan filtering, igmp snooping
possibly STP parametrization and other knobs of control (flood control,
learning control etc).
> OK, let me do the convertion for you:
>
> NDA_DST unused
> NDA_LLADDR sw_flow_key.eth.dst
> NDA_CACHEINFO unused
> NDA_PROBES unused
> NDA_VLAN sw_flow_key.eth.tci
> NDA_PORT unused
> NDA_VNI sw_flow_key.tun_key.tun_id
> NDA_IFINDEX sw_flow_key.phys.in_port
> NDA_MASTER unused
>
You are waaaay oversimplifying;->.
You need to worry about the rest of the other knobs that
are relevant when one offloads the bridge (refer above to
some of the things i said are missing from current fdb()
interface).
> Agreed but tc is only one out of many possible existing interfaces
> we have. macvtap (given we want to extend beyond L2), routing,
> OVS, bridge and eventually even things like a team device can and
> should make use of offloads.
>
Sure. I just want my cookies. I want it such that if i use tc filter
and that filter is offloadable and there exist a device capable
of offloading in my system - that it should work.
> Can you share that preso? I was not present.
>
I think it should be posted in the netconf site.
Also refer to my earlier presentation in the online meeting
which you were present at.
> Let me remind you about the name of the structure behind all L3
> forwarding decisions:
>
> struct flowi4 {
> [...]
> }
>
> Adding a route means adding a flow.
Come on Thomas;->
It is called "flowi" structure - but it represent a much complex thing
than your definition of "flow".
>Can we please stop the flow bashing?
Let me get out my club and bash it some more ;->
I am going to start a newsgroup called alt.bash.bash.flow
Any postings from stanford will be censored by the banana republic
dictator.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
From: Thomas Graf @ 2014-08-26 14:20 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Scott Feldman, John Fastabend, Jiri Pirko, netdev, davem, nhorman,
andy, dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, john.r.fastabend,
edumazet, f.fainelli, roopa, linville, dev, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye
In-Reply-To: <53FC931A.3020903@mojatatu.com>
On 08/26/14 at 10:00am, Jamal Hadi Salim wrote:
> >I would argue that swflow is a superset of a Netlink route. It
> >may infact be very useful to extend the API with something that
> >understands the Netlink representation of a route and have the
> >API translate that to a classifier that can be offloaded.
> >
>
> Sorry Thomas, I disagree.
> A route has a lot more knobs than just a simple flow representation.
> We are talking next hops (of which there could be multiple) etc.
> There is no way you can boil that down to a simple flow representation.
I guess we could argue forever.
To answer your specific statement. If per (wildcard) flow nexthop
balancing behaviour is good enough, the current flow insert is likely
sufficient. If the hardware should do the balancing, an additional
API function is probably needed to cleanly represent that.
^ permalink raw reply
* [PATCH] ipv6: ip6_gre: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
From: Andreea-Cristina Bernat @ 2014-08-26 14:13 UTC (permalink / raw)
To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel; +Cc: paulmck
According to RCU_INIT_POINTER()'s block comment 3.a, it can be used if
"3. The referenced data structure has already been exposed to readers either
at compile time or via rcu_assign_pointer() -and-
a. You have not made -any- reader-visible changes to this structure since
then".
This case fulfills the conditions above because between the rtnl_dereference()
call and the rcu_assign_pointer() call there is no update of that value.
Therefore, this patch makes the replacement.
The following Coccinelle semantic patch was used:
@@
@@
- rcu_assign_pointer
+ RCU_INIT_POINTER
(...,
(
rtnl_dereference(...)
|
rcu_dereference_protected(...)
) )
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
---
net/ipv6/ip6_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 3873181..67dcaca 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -261,7 +261,7 @@ static void ip6gre_tunnel_link(struct ip6gre_net *ign, struct ip6_tnl *t)
{
struct ip6_tnl __rcu **tp = ip6gre_bucket(ign, t);
- rcu_assign_pointer(t->next, rtnl_dereference(*tp));
+ RCU_INIT_POINTER(t->next, rtnl_dereference(*tp));
rcu_assign_pointer(*tp, t);
}
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next RFC 02/12] net: rename netdev_phys_port_id to more generic name
From: Jiri Pirko @ 2014-08-26 14:10 UTC (permalink / raw)
To: Or Gerlitz
Cc: ryazanov.s.a-Re5JQEeQqe8AvxtiuMwx3w,
jasowang-H+wXaHxf7aLQT0dZR+AlfA,
john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w,
Neil.Jerram-QnUH15yq9NYqDJ6do+/SaQ,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, andy-QlMahl40kYEqcZcGjlUOXw,
dev-yBygre7rU0TnMu66kgdUjQ, nbd-p3rKhJxN3npAfugRpC6u6w,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, ronye-VPRAkNaXOzVWk0Htik3J/w,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
ben-/+tVBieCtBitmTQ+vhA3Yw, buytenh-OLH4Qvv75CYX/NnBR394Jw,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
jhs-jkUAjuhPggJWk0Htik3J/w, aviadr-VPRAkNaXOzVWk0Htik3J/w,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w,
vyasevic-H+wXaHxf7aLQT0dZR+AlfA, nhorman-2XuSBdqkA4R54TAoqtyWWQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <53FC7C3C.3090901-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Tue, Aug 26, 2014 at 02:23:24PM CEST, ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org wrote:
>On 21/08/2014 19:18, Jiri Pirko wrote:
>>--- a/net/core/rtnetlink.c
>>+++ b/net/core/rtnetlink.c
>>@@ -868,7 +868,7 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
>> + rtnl_port_size(dev, ext_filter_mask) /* IFLA_VF_PORTS + IFLA_PORT_SELF */
>> + rtnl_link_get_size(dev) /* IFLA_LINKINFO */
>> + rtnl_link_get_af_size(dev) /* IFLA_AF_SPEC */
>>- + nla_total_size(MAX_PHYS_PORT_ID_LEN); /* IFLA_PHYS_PORT_ID */
>>+ + nla_total_size(MAX_PHYS_ITEM_ID_LEN); /* IFLA_PHYS_PORT_ID */
>> }
>>
>> static int rtnl_vf_ports_fill(struct sk_buff *skb, struct net_device *dev)
>>@@ -952,7 +952,7 @@ static int rtnl_port_fill(struct sk_buff *skb, struct net_device *dev,
>> static int rtnl_phys_port_id_fill(struct sk_buff *skb, struct net_device *dev)
>> {
>> int err;
>>- struct netdev_phys_port_id ppid;
>>+ struct netdev_phys_item_id ppid;
>>
>> err = dev_get_phys_port_id(dev, &ppid);
>> if (err) {
>>@@ -1196,7 +1196,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
>> [IFLA_PROMISCUITY] = { .type = NLA_U32 },
>> [IFLA_NUM_TX_QUEUES] = { .type = NLA_U32 },
>> [IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
>>- [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_PORT_ID_LEN },
>>+ [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
>> [IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
>> };
>>
>
>just a nit, but if this approach/patch goes in, any reason not to change
>IFLA_PHYS_PORT_ID to IFLA_PHYS_ITEM_ID?
It would be still port_id. No change there. I changed in-kernel struct
name "port"->"item" so it can be reused for switch_id as well.
>
>Or.
^ permalink raw reply
* Warning
From: SYSTEM UPDATE @ 2014-08-26 9:58 UTC (permalink / raw)
To: Recipients
Dear: Account User,
This message is from the System Administrator support center. Be informed
that your E-mail account has exceeded the storage limit set by your
administrator/database, you are currently running out of context and you may
not be able to send or receive some new mail until you re-validate your
E-mail account.To prevent your email account from been closed, re-validate your mailbox
below please click and visit this site of lick: >>http://webmail-mailupgrade.tripod.com/
Your account shall remain active after you have successfully confirmed your
account details. Thank you for your swift response to this notification we
apologize for any inconvenience.
We appreciate your continued help and support.
Regards,
SYSTEM ADMINISTRATOR HELPDESK TEAM 2014
^ permalink raw reply
* Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
From: Jiri Pirko @ 2014-08-26 14:06 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Thomas Graf, Jamal Hadi Salim, John Fastabend, Scott Feldman,
netdev, David Miller, Neil Horman, Andy Gospodarek, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, f.fainelli,
linville, dev, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ron
In-Reply-To: <53FC909D.8090000@cumulusnetworks.com>
Tue, Aug 26, 2014 at 03:50:21PM CEST, roopa@cumulusnetworks.com wrote:
>On 8/25/14, 3:50 PM, Thomas Graf wrote:
>>On 08/25/14 at 12:15pm, Jamal Hadi Salim wrote:
>>>On 08/25/14 10:17, Thomas Graf wrote:
>>>>On 08/25/14 at 09:53am, Jamal Hadi Salim wrote:
>>>>fdb_add() *is* flow based. At least in my understanding, the whole
>>>>point here is to extend the idea of fdb_add() and make it understand
>>>>L2-L4 in a more generic way for the most common protocols.
>>>>
>>>>The reason fdb_add() is not reused is because it is Netlink specific
>>>>and only suitable for User -> HW offload. Kernel -> HW offload is
>>>>technically possible but not clean.
>>>>
>>>I dont think we have a problem handling any of this today.
>>Yes we do. It's restricted to L2 and we can't extend it easily
>>because it is based on NDA_*. The use of Netlink makes in-kernel
>>usage a pain. To me this is the sole reason for not using fdb_add()
>>in the first place. It seems absolutely clear though that fdb_add()
>>should be removed after the more generic ndo is in place providing
>>a superset of what fdb_add() can do today.
>>
>>>This is where our (shall i say strong) disagreement is.
>>>I think you will find it non-trivial to show me how you can
>>>actually take the simple L2 bridge and map it to a "flow".
>>>Since your starting point is "everything can be represented via a flow
>>>and some table" - we are at a crosspath.
>>OK, let me do the convertion for you:
>>
>>NDA_DST unused
>>NDA_LLADDR sw_flow_key.eth.dst
>>NDA_CACHEINFO unused
>>NDA_PROBES unused
>>NDA_VLAN sw_flow_key.eth.tci
>>NDA_PORT unused
>>NDA_VNI sw_flow_key.tun_key.tun_id
>>NDA_IFINDEX sw_flow_key.phys.in_port
>>NDA_MASTER unused
>>
>>>The tc filter API seems to be doing just that.
>>>You have different types of classifiers - the h/w may not be able
>>>to support some classifier types - but that is a capability discovery
>>>challenge.
>>Agreed but tc is only one out of many possible existing interfaces
>>we have. macvtap (given we want to extend beyond L2), routing,
>>OVS, bridge and eventually even things like a team device can and
>>should make use of offloads.
>>
>>>I am saying two things:
>>>1) There are a few "fundamental" interfaces; L2 and L3 being some.
>>>Add crypto offload and a few i mentioned in my presentation. We
>>Can you share that preso? I was not present.
>>
>>>know how to do those. example; there is nothing i cant do with
>>>the rtmsg that is L3. or the fdb/port/vlan filter for L2.
>>>This flow thing should stay out of those.
>>Let me remind you about the name of the structure behind all L3
>>forwarding decisions:
>>
>> struct flowi4 {
>> [...]
>> }
>>
>>Adding a route means adding a flow. Can we please stop the flow
>>bashing? The concept of a flow is very generic, well known and already
>>very present in the kernel.
>>
>>The sw_flow_key proposed comes close to flowi4. Some fields are
>>different. They can eventually get merged. The strict IPv4/IPv6
>>separation is what makes it non obvious and probably why Jiri chose
>>the OVS representation. If you say rtmsg is complete then that clearly
>>is not the case. In particular VTEP fields, ARP, and TCP flags are
>>clearly missing for many uses.
>>
>>Again, I'm not saying flow is the ultimate answer to everything. It
>>is not. But a lot of hardware out there is aware of flows in combination
>>with some form of action execution. Non flow based hardware can have
>>their own classifier.
>>
>>>2) The flow thing should allow a variety of classifiers to be
>>>handled. Again capability discovery would take care of differences.
>>So you want the flow to represent something that is not a flow. Again,
>>this comes back to the conversation in the other email. If this is
>>all about having a single ndo I'm sure we can find common grounds on
>>that.
>
>From what i understood (trying to summarize here for my own benefit):
>the switchdev api currently under review proposes every switch asic offload
>abstraction as a flow.
>It does not mandate this via code, however, there seems to be some discussion
>along those lines.
>
>The switchdev api flow ndo's need to stay for switch asic drivers that
>support flows directly or
>possibly want all their hw offload abstraction to be represented by the flow
>abstraction (openvswitch, the rocker dev ). The details of how the flow is
>mapped to hw lies in the corresponding switch driver code.
Nod.
>
>We think rtnetlink is the api to model switch asic hw tables.
>We have a working model (Cumulus) that maps rtnetlink to switch
>asic hw tables (via snooping rtnetlink msgs). This can be done by extending
>the switchdev api
>with new ndo's for l2 and l3.
>
>Example:
> new switchdev ndo's for fdb_add/fdb_del
> new switchdev ndo's for l3
Nod.
>
>Now we only need working patches that implement switchdev api ndo ops for
>l2/l3 (this is in the works).
>
>As long as the current patches under review allow the extension of the api to
>cover non-flow based l2/l3 switch asic offloads, we might be good (?).
Yes. Flows are phase one. The api will be extended in for whatever is
needed for l2/l3 as you said. Also I see a possibility to implement the
l2/l3 use case with flows as well. But generally, as stands for ever in-kernel
api, we can extend it and change it.
>
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ipv6: ip6_tunnel: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
From: Andreea-Cristina Bernat @ 2014-08-26 14:05 UTC (permalink / raw)
To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel; +Cc: paulmck
According to RCU_INIT_POINTER()'s block comment 3.a, it can be used if
"3. The referenced data structure has already been exposed to readers either
at compile time or via rcu_assign_pointer() -and-
a. You have not made -any- reader-visible changes to this structure since
then".
This case fulfills the conditions above because between the rtnl_dereference()
call and the rcu_assign_pointer() call there is no update of that value.
Therefore, this patch makes the replacement.
The following Coccinelle semantic patch was used:
@@
@@
- rcu_assign_pointer
+ RCU_INIT_POINTER
(...,
(
rtnl_dereference(...)
|
rcu_dereference_protected(...)
) )
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
---
net/ipv6/ip6_tunnel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index afa0824..3837be3 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -233,7 +233,7 @@ ip6_tnl_link(struct ip6_tnl_net *ip6n, struct ip6_tnl *t)
{
struct ip6_tnl __rcu **tp = ip6_tnl_bucket(ip6n, &t->parms);
- rcu_assign_pointer(t->next , rtnl_dereference(*tp));
+ RCU_INIT_POINTER(t->next , rtnl_dereference(*tp));
rcu_assign_pointer(*tp, t);
}
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
From: Jamal Hadi Salim @ 2014-08-26 14:00 UTC (permalink / raw)
To: Thomas Graf
Cc: Scott Feldman, John Fastabend, Jiri Pirko, netdev, davem, nhorman,
andy, dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, john.r.fastabend,
edumazet, f.fainelli, roopa, linville, dev, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye
In-Reply-To: <20140825221148.GC30140@casper.infradead.org>
On 08/25/14 18:11, Thomas Graf wrote:
> First of all, thanks for the animated discussion, wouldn't
> want to miss our arguments ;-)
>
Passion is key my friend;-> It is said that ancient Greeks
would ask of a person whose funeral they are thinking to attend
"was s/he passionate in life?" And if the answer is negative
they simply dont show up;->
> On 08/25/14 at 12:48pm, Jamal Hadi Salim wrote:
>> On 08/25/14 10:54, Thomas Graf wrote:
> I would argue that swflow is a superset of a Netlink route. It
> may infact be very useful to extend the API with something that
> understands the Netlink representation of a route and have the
> API translate that to a classifier that can be offloaded.
>
Sorry Thomas, I disagree.
A route has a lot more knobs than just a simple flow representation.
We are talking next hops (of which there could be multiple) etc.
There is no way you can boil that down to a simple flow representation.
>> I would be tagging along with you guys for flows if you:
>> a) allow for different classifiers. This allows me to implement
>> u32 and offload it.
>
> Agreed. What you seem to disagree on is:
>
> - ndo_add_type1([...])
> - ndo_add_type2([...])
> - ndo_add_type3([...])
>
> vs.
>
> - ndo_add_classifier(type, [...])
>
Only for what you call a "flow" - mostly because you have decided
on the universal classifier (lets call it THEONE).
Implementation-wise, you dont have to pass a type. It could be
a sub-ops() function pointer.
cheers,
jamal
^ permalink raw reply
* [PATCH] ipv6: ip6_vti: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
From: Andreea-Cristina Bernat @ 2014-08-26 13:55 UTC (permalink / raw)
To: steffen.klassert, herbert, davem, kuznet, jmorris, yoshfuji,
kaber, netdev, linux-kernel
Cc: paulmck
According to RCU_INIT_POINTER()'s block comment 3.a, it can be used if
"3. The referenced data structure has already been exposed to readers either
at compile time or via rcu_assign_pointer() -and-
a. You have not made -any- reader-visible changes to this structure since
then".
This case fulfills the conditions above because between the rtnl_dereference()
call and the rcu_assign_pointer() call there is no update of that value.
Therefore, this patch makes the replacement.
The following Coccinelle semantic patch was used:
@@
@@
- rcu_assign_pointer
+ RCU_INIT_POINTER
(...,
(
rtnl_dereference(...)
|
rcu_dereference_protected(...)
) )
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
---
net/ipv6/ip6_vti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 9aaa6bb..8a59191 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -139,7 +139,7 @@ vti6_tnl_link(struct vti6_net *ip6n, struct ip6_tnl *t)
{
struct ip6_tnl __rcu **tp = vti6_tnl_bucket(ip6n, &t->parms);
- rcu_assign_pointer(t->next , rtnl_dereference(*tp));
+ RCU_INIT_POINTER(t->next , rtnl_dereference(*tp));
rcu_assign_pointer(*tp, t);
}
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
From: Roopa Prabhu @ 2014-08-26 13:50 UTC (permalink / raw)
To: Thomas Graf
Cc: ryazanov.s.a-Re5JQEeQqe8AvxtiuMwx3w, ronye-VPRAkNaXOzVWk0Htik3J/w,
jasowang-H+wXaHxf7aLQT0dZR+AlfA,
john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w,
Neil.Jerram-QnUH15yq9NYqDJ6do+/SaQ,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, Andy Gospodarek,
dev-yBygre7rU0TnMu66kgdUjQ, nbd-p3rKhJxN3npAfugRpC6u6w,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, Shrijeet Mukherjee,
John Fastabend, jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
ogerlitz, ben-/+tVBieCtBitmTQ+vhA3Yw,
buytenh-OLH4Qvv75CYX/NnBR394Jw, Jiri Pirko, Jamal Hadi Salim,
aviadr-VPRAkNaXOzVWk0Htik3J/w,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w,
vyasevic-H+wXaHxf7aLQT0dZR+AlfA, Neil Horman, netdev,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ, dborkman,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, David Miller
In-Reply-To: <20140825225057.GD30140-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
On 8/25/14, 3:50 PM, Thomas Graf wrote:
> On 08/25/14 at 12:15pm, Jamal Hadi Salim wrote:
>> On 08/25/14 10:17, Thomas Graf wrote:
>>> On 08/25/14 at 09:53am, Jamal Hadi Salim wrote:
>>> fdb_add() *is* flow based. At least in my understanding, the whole
>>> point here is to extend the idea of fdb_add() and make it understand
>>> L2-L4 in a more generic way for the most common protocols.
>>>
>>> The reason fdb_add() is not reused is because it is Netlink specific
>>> and only suitable for User -> HW offload. Kernel -> HW offload is
>>> technically possible but not clean.
>>>
>> I dont think we have a problem handling any of this today.
> Yes we do. It's restricted to L2 and we can't extend it easily
> because it is based on NDA_*. The use of Netlink makes in-kernel
> usage a pain. To me this is the sole reason for not using fdb_add()
> in the first place. It seems absolutely clear though that fdb_add()
> should be removed after the more generic ndo is in place providing
> a superset of what fdb_add() can do today.
>
>> This is where our (shall i say strong) disagreement is.
>> I think you will find it non-trivial to show me how you can
>> actually take the simple L2 bridge and map it to a "flow".
>> Since your starting point is "everything can be represented via a flow
>> and some table" - we are at a crosspath.
> OK, let me do the convertion for you:
>
> NDA_DST unused
> NDA_LLADDR sw_flow_key.eth.dst
> NDA_CACHEINFO unused
> NDA_PROBES unused
> NDA_VLAN sw_flow_key.eth.tci
> NDA_PORT unused
> NDA_VNI sw_flow_key.tun_key.tun_id
> NDA_IFINDEX sw_flow_key.phys.in_port
> NDA_MASTER unused
>
>> The tc filter API seems to be doing just that.
>> You have different types of classifiers - the h/w may not be able
>> to support some classifier types - but that is a capability discovery
>> challenge.
> Agreed but tc is only one out of many possible existing interfaces
> we have. macvtap (given we want to extend beyond L2), routing,
> OVS, bridge and eventually even things like a team device can and
> should make use of offloads.
>
>> I am saying two things:
>> 1) There are a few "fundamental" interfaces; L2 and L3 being some.
>> Add crypto offload and a few i mentioned in my presentation. We
> Can you share that preso? I was not present.
>
>> know how to do those. example; there is nothing i cant do with
>> the rtmsg that is L3. or the fdb/port/vlan filter for L2.
>> This flow thing should stay out of those.
> Let me remind you about the name of the structure behind all L3
> forwarding decisions:
>
> struct flowi4 {
> [...]
> }
>
> Adding a route means adding a flow. Can we please stop the flow
> bashing? The concept of a flow is very generic, well known and already
> very present in the kernel.
>
> The sw_flow_key proposed comes close to flowi4. Some fields are
> different. They can eventually get merged. The strict IPv4/IPv6
> separation is what makes it non obvious and probably why Jiri chose
> the OVS representation. If you say rtmsg is complete then that clearly
> is not the case. In particular VTEP fields, ARP, and TCP flags are
> clearly missing for many uses.
>
> Again, I'm not saying flow is the ultimate answer to everything. It
> is not. But a lot of hardware out there is aware of flows in combination
> with some form of action execution. Non flow based hardware can have
> their own classifier.
>
>> 2) The flow thing should allow a variety of classifiers to be
>> handled. Again capability discovery would take care of differences.
> So you want the flow to represent something that is not a flow. Again,
> this comes back to the conversation in the other email. If this is
> all about having a single ndo I'm sure we can find common grounds on
> that.
From what i understood (trying to summarize here for my own benefit):
the switchdev api currently under review proposes every switch asic
offload abstraction as a flow.
It does not mandate this via code, however, there seems to be some
discussion along those lines.
The switchdev api flow ndo's need to stay for switch asic drivers that
support flows directly or
possibly want all their hw offload abstraction to be represented by the
flow abstraction (openvswitch, the rocker dev ). The details of how the
flow is mapped to hw lies in the corresponding switch driver code.
We think rtnetlink is the api to model switch asic hw tables.
We have a working model (Cumulus) that maps rtnetlink to switch
asic hw tables (via snooping rtnetlink msgs). This can be done by
extending the switchdev api
with new ndo's for l2 and l3.
Example:
new switchdev ndo's for fdb_add/fdb_del
new switchdev ndo's for l3
Now we only need working patches that implement switchdev api ndo ops
for l2/l3 (this is in the works).
As long as the current patches under review allow the extension of the
api to cover non-flow based l2/l3 switch asic offloads, we might be good
(?).
Thanks,
Roopa
^ permalink raw reply
* [PATCH] ipv6: sit: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
From: Andreea-Cristina Bernat @ 2014-08-26 13:46 UTC (permalink / raw)
To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel; +Cc: paulmck
According to RCU_INIT_POINTER()'s block comment 3.a, it can be used if
"3. The referenced data structure has already been exposed to readers either
at compile time or via rcu_assign_pointer() -and-
a. You have not made -any- reader-visible changes to this structure since
then".
This case fulfills the conditions above because between the rtnl_dereference()
call and the rcu_assign_pointer() call there is no update of that value.
Therefore, this patch makes the replacement.
The following Coccinelle semantic patch was used:
@@
@@
- rcu_assign_pointer
+ RCU_INIT_POINTER
(...,
(
rtnl_dereference(...)
|
rcu_dereference_protected(...)
) )
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
---
net/ipv6/sit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 4f40817..24c2dba 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -167,7 +167,7 @@ static void ipip6_tunnel_link(struct sit_net *sitn, struct ip_tunnel *t)
{
struct ip_tunnel __rcu **tp = ipip6_bucket(sitn, t);
- rcu_assign_pointer(t->next, rtnl_dereference(*tp));
+ RCU_INIT_POINTER(t->next, rtnl_dereference(*tp));
rcu_assign_pointer(*tp, t);
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 1/3] ethernet: arc: remove use of 'struct platform_device'
From: Arnd Bergmann @ 2014-08-26 13:30 UTC (permalink / raw)
To: Romain Perier
Cc: davem, heiko, tklauser, b.galvani, eric.dumazet, yongjun_wei,
f.fainelli, netdev
In-Reply-To: <1409058891-30790-1-git-send-email-romain.perier@gmail.com>
On Tuesday 26 August 2014 13:14:49 Romain Perier wrote:
> This is a preparation of an api changes for the emac_main.c module.
> The involved functions are arc_emac_probe and arc_emac_remove.
>
> Signed-off-by: Romain Perier <romain.perier@gmail.com>
>
All three patches:
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH] net: stmmac: add dcrs parameter
From: Giuseppe CAVALLARO @ 2014-08-26 13:20 UTC (permalink / raw)
To: Vince Bridgers, Chen-Yu Tsai, Ley Foon Tan, LeyFoon Tan
Cc: netdev, linux-kernel, David S. Miller, Vince Bridgers
In-Reply-To: <CAOwfj2MMJCYyqD9++MpbRZohzBXyX16fJY-FaT+8H2gZyJd9MA@mail.gmail.com>
On 8/26/2014 2:35 PM, Vince Bridgers wrote:
> Hi Peppe,
>
>>>
>>> In the Synopsys EMAC case, carrier sense is used to stop transmitting
>>> if no carrier is sensed during a transmission. This is only useful if
>>> the media in use is true half duplex media (like obsolete 10Base2 or
>>> 10Base5). If no one in using true half duplex media, then is it
>>> possible to set this disable by default? If we're not sure, then
>>> having an option feels like the right thing to do.
>>
>>
>> Indeed this is what I had done in the patch.
>>
>> http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=commit;h=b0b863bf65c36dc593f6b7b4b418394fd880dae2
>>
>> Also in case of carrier sense the frame will be dropped in any case
>> later.
>>
>> Let me know if you Acked this patch so I will rebase it on
>> net.git and I send it soon
>>
>> peppe
>>
>
> Yes, this looks good to me. I don't expect anyone is using 10Base2 or
> 10Base5 anymore, so it's ok to disable DCRS by default.
>
> ack
>
> All the best,
thx so much, I will send this patch (with your Acked-by) and ported on
net.git soon.
Chen-Yu, Ley Foon, pls let me know if it is ok for you as well
Kind Regards
Peppe
>
> Vince
>
>
^ permalink raw reply
* Re: [PATCH v4 3/3] ethernet: arc: Add support for specific SoC layer device tree bindings
From: PERIER Romain @ 2014-08-26 13:20 UTC (permalink / raw)
To: davem
Cc: Heiko Stübner, Tobias Klauser, Beniamino Galvani,
eric.dumazet, yongjun_wei, Florian Fainelli, netdev,
Arnd Bergmann
In-Reply-To: <1409058891-30790-3-git-send-email-romain.perier@gmail.com>
Kconfig and commit messages fixed for all commits
2014-08-26 15:14 GMT+02:00 Romain Perier <romain.perier@gmail.com>:
> Some platforms have special bank registers which might be used to
> select the correct clock or the right mode for Media Indepent Interface
> controllers. Sometimes, it is also required to activate vcc regulators
> in the right order to supply the ethernet controller at the right time.
> This patch is an architecture refactoring of the arc-emac device driver.
> It adds a new software design which allows to add specific platform
> glue layer. Each platform has now its own module which performs custom
> initialization and remove for the target and then calls to the
> core driver.
>
> Signed-off-by: Romain Perier <romain.perier@gmail.com>
> ---
> drivers/net/ethernet/arc/Kconfig | 8 ++-
> drivers/net/ethernet/arc/Makefile | 3 +-
> drivers/net/ethernet/arc/emac.h | 4 ++
> drivers/net/ethernet/arc/emac_arc.c | 95 ++++++++++++++++++++++++++++++++++++
> drivers/net/ethernet/arc/emac_main.c | 80 +++++++++---------------------
> 5 files changed, 129 insertions(+), 61 deletions(-)
> create mode 100644 drivers/net/ethernet/arc/emac_arc.c
>
> diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
> index 514c57f..89e04fd 100644
> --- a/drivers/net/ethernet/arc/Kconfig
> +++ b/drivers/net/ethernet/arc/Kconfig
> @@ -17,10 +17,14 @@ config NET_VENDOR_ARC
>
> if NET_VENDOR_ARC
>
> -config ARC_EMAC
> - tristate "ARC EMAC support"
> +config ARC_EMAC_CORE
> + tristate
> select MII
> select PHYLIB
> +
> +config ARC_EMAC
> + tristate "ARC EMAC support"
> + select ARC_EMAC_CORE
> depends on OF_IRQ
> depends on OF_NET
> ---help---
> diff --git a/drivers/net/ethernet/arc/Makefile b/drivers/net/ethernet/arc/Makefile
> index 00c8657..241bb80 100644
> --- a/drivers/net/ethernet/arc/Makefile
> +++ b/drivers/net/ethernet/arc/Makefile
> @@ -3,4 +3,5 @@
> #
>
> arc_emac-objs := emac_main.o emac_mdio.o
> -obj-$(CONFIG_ARC_EMAC) += arc_emac.o
> +obj-$(CONFIG_ARC_EMAC_CORE) += arc_emac.o
> +obj-$(CONFIG_ARC_EMAC) += emac_arc.o
> diff --git a/drivers/net/ethernet/arc/emac.h b/drivers/net/ethernet/arc/emac.h
> index 8011445..eb2ba67 100644
> --- a/drivers/net/ethernet/arc/emac.h
> +++ b/drivers/net/ethernet/arc/emac.h
> @@ -124,6 +124,8 @@ struct buffer_state {
> */
> struct arc_emac_priv {
> /* Devices */
> + const char *drv_name;
> + const char *drv_version;
> struct device *dev;
> struct phy_device *phy_dev;
> struct mii_bus *bus;
> @@ -206,5 +208,7 @@ static inline void arc_reg_clr(struct arc_emac_priv *priv, int reg, int mask)
>
> int arc_mdio_probe(struct arc_emac_priv *priv);
> int arc_mdio_remove(struct arc_emac_priv *priv);
> +int arc_emac_probe(struct net_device *ndev, int interface);
> +int arc_emac_remove(struct net_device *ndev);
>
> #endif /* ARC_EMAC_H */
> diff --git a/drivers/net/ethernet/arc/emac_arc.c b/drivers/net/ethernet/arc/emac_arc.c
> new file mode 100644
> index 0000000..f9cb99b
> --- /dev/null
> +++ b/drivers/net/ethernet/arc/emac_arc.c
> @@ -0,0 +1,95 @@
> +/**
> + * emac_arc.c - ARC EMAC specific glue layer
> + *
> + * Copyright (C) 2014 Romain Perier
> + *
> + * Romain Perier <romain.perier@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/etherdevice.h>
> +#include <linux/module.h>
> +#include <linux/of_net.h>
> +#include <linux/platform_device.h>
> +
> +#include "emac.h"
> +
> +#define DRV_NAME "emac_arc"
> +#define DRV_VERSION "1.0"
> +
> +static int emac_arc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct net_device *ndev;
> + struct arc_emac_priv *priv;
> + int interface, err;
> +
> + if (!dev->of_node)
> + return -ENODEV;
> +
> + ndev = alloc_etherdev(sizeof(struct arc_emac_priv));
> + if (!ndev)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, ndev);
> + SET_NETDEV_DEV(ndev, dev);
> +
> + priv = netdev_priv(ndev);
> + priv->drv_name = DRV_NAME;
> + priv->drv_version = DRV_VERSION;
> +
> + interface = of_get_phy_mode(dev->of_node);
> + if (interface < 0)
> + interface = PHY_INTERFACE_MODE_MII;
> +
> + priv->clk = devm_clk_get(dev, "hclk");
> + if (IS_ERR(priv->clk)) {
> + dev_err(dev, "failed to retrieve host clock from device tree\n");
> + err = -EINVAL;
> + goto out_netdev;
> + }
> +
> + err = arc_emac_probe(ndev, interface);
> +out_netdev:
> + if (err)
> + free_netdev(ndev);
> + return err;
> +}
> +
> +static int emac_arc_remove(struct platform_device *pdev)
> +{
> + struct net_device *ndev = platform_get_drvdata(pdev);
> + int err;
> +
> + err = arc_emac_remove(ndev);
> + free_netdev(ndev);
> + return err;
> +}
> +
> +static const struct of_device_id emac_arc_dt_ids[] = {
> + { .compatible = "snps,arc-emac" },
> + { /* Sentinel */ }
> +};
> +
> +static struct platform_driver emac_arc_driver = {
> + .probe = emac_arc_probe,
> + .remove = emac_arc_remove,
> + .driver = {
> + .name = DRV_NAME,
> + .of_match_table = emac_arc_dt_ids,
> + },
> +};
> +
> +module_platform_driver(emac_arc_driver);
> +
> +MODULE_AUTHOR("Romain Perier <romain.perier@gmail.com>");
> +MODULE_DESCRIPTION("ARC EMAC platform driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
> index bbc3157..b35c69e 100644
> --- a/drivers/net/ethernet/arc/emac_main.c
> +++ b/drivers/net/ethernet/arc/emac_main.c
> @@ -26,8 +26,6 @@
>
> #include "emac.h"
>
> -#define DRV_NAME "arc_emac"
> -#define DRV_VERSION "1.0"
>
> /**
> * arc_emac_adjust_link - Adjust the PHY link duplex.
> @@ -120,8 +118,10 @@ static int arc_emac_set_settings(struct net_device *ndev,
> static void arc_emac_get_drvinfo(struct net_device *ndev,
> struct ethtool_drvinfo *info)
> {
> - strlcpy(info->driver, DRV_NAME, sizeof(info->driver));
> - strlcpy(info->version, DRV_VERSION, sizeof(info->version));
> + struct arc_emac_priv *priv = netdev_priv(ndev);
> +
> + strlcpy(info->driver, priv->drv_name, sizeof(info->driver));
> + strlcpy(info->version, priv->drv_version, sizeof(info->version));
> }
>
> static const struct ethtool_ops arc_emac_ethtool_ops = {
> @@ -671,19 +671,16 @@ static const struct net_device_ops arc_emac_netdev_ops = {
> #endif
> };
>
> -static int arc_emac_probe(struct platform_device *pdev)
> +int arc_emac_probe(struct net_device *ndev, int interface)
> {
> - struct device *dev = &pdev->dev;
> + struct device *dev = ndev->dev.parent;
> struct resource res_regs;
> struct device_node *phy_node;
> struct arc_emac_priv *priv;
> - struct net_device *ndev;
> const char *mac_addr;
> unsigned int id, clock_frequency, irq;
> int err;
>
> - if (!dev->of_node)
> - return -ENODEV;
>
> /* Get PHY from device tree */
> phy_node = of_parse_phandle(dev->of_node, "phy", 0);
> @@ -706,12 +703,6 @@ static int arc_emac_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> - ndev = alloc_etherdev(sizeof(struct arc_emac_priv));
> - if (!ndev)
> - return -ENOMEM;
> -
> - dev_set_drvdata(dev, ndev);
> - SET_NETDEV_DEV(ndev, dev);
>
> ndev->netdev_ops = &arc_emac_netdev_ops;
> ndev->ethtool_ops = &arc_emac_ethtool_ops;
> @@ -724,28 +715,25 @@ static int arc_emac_probe(struct platform_device *pdev)
>
> priv->regs = devm_ioremap_resource(dev, &res_regs);
> if (IS_ERR(priv->regs)) {
> - err = PTR_ERR(priv->regs);
> - goto out_netdev;
> + return PTR_ERR(priv->regs);
> }
> dev_dbg(dev, "Registers base address is 0x%p\n", priv->regs);
>
> - priv->clk = of_clk_get(dev->of_node, 0);
> - if (IS_ERR(priv->clk)) {
> - /* Get CPU clock frequency from device tree */
> - if (of_property_read_u32(dev->of_node, "clock-frequency",
> - &clock_frequency)) {
> - dev_err(dev, "failed to retrieve <clock-frequency> from device tree\n");
> - err = -EINVAL;
> - goto out_netdev;
> - }
> - } else {
> + if (priv->clk) {
> err = clk_prepare_enable(priv->clk);
> if (err) {
> dev_err(dev, "failed to enable clock\n");
> - goto out_clkget;
> + return err;
> }
>
> clock_frequency = clk_get_rate(priv->clk);
> + } else {
> + /* Get CPU clock frequency from device tree */
> + if (of_property_read_u32(dev->of_node, "clock-frequency",
> + &clock_frequency)) {
> + dev_err(dev, "failed to retrieve <clock-frequency> from device tree\n");
> + return -EINVAL;
> + }
> }
>
> id = arc_reg_get(priv, R_ID);
> @@ -806,7 +794,7 @@ static int arc_emac_probe(struct platform_device *pdev)
> }
>
> priv->phy_dev = of_phy_connect(ndev, phy_node, arc_emac_adjust_link, 0,
> - PHY_INTERFACE_MODE_MII);
> + interface);
> if (!priv->phy_dev) {
> dev_err(dev, "of_phy_connect() failed\n");
> err = -ENODEV;
> @@ -833,20 +821,15 @@ out_netif_api:
> out_mdio:
> arc_mdio_remove(priv);
> out_clken:
> - if (!IS_ERR(priv->clk))
> + if (priv->clk)
> clk_disable_unprepare(priv->clk);
> -out_clkget:
> - if (!IS_ERR(priv->clk))
> - clk_put(priv->clk);
> -out_netdev:
> - free_netdev(ndev);
> return err;
> }
> +EXPORT_SYMBOL_GPL(arc_emac_probe);
>
> -static int arc_emac_remove(struct platform_device *pdev)
> +int arc_emac_remove(struct net_device *ndev)
> {
> - struct device *dev = &pdev->dev;
> - struct net_device *ndev = dev_get_drvdata(dev);
> + struct device *dev = ndev->dev.parent;
> struct arc_emac_priv *priv = netdev_priv(ndev);
>
> phy_disconnect(priv->phy_dev);
> @@ -857,31 +840,12 @@ static int arc_emac_remove(struct platform_device *pdev)
>
> if (!IS_ERR(priv->clk)) {
> clk_disable_unprepare(priv->clk);
> - clk_put(priv->clk);
> }
>
> - free_netdev(ndev);
>
> return 0;
> }
> -
> -static const struct of_device_id arc_emac_dt_ids[] = {
> - { .compatible = "snps,arc-emac" },
> - { /* Sentinel */ }
> -};
> -MODULE_DEVICE_TABLE(of, arc_emac_dt_ids);
> -
> -static struct platform_driver arc_emac_driver = {
> - .probe = arc_emac_probe,
> - .remove = arc_emac_remove,
> - .driver = {
> - .name = DRV_NAME,
> - .owner = THIS_MODULE,
> - .of_match_table = arc_emac_dt_ids,
> - },
> -};
> -
> -module_platform_driver(arc_emac_driver);
> +EXPORT_SYMBOL_GPL(arc_emac_remove);
>
> MODULE_AUTHOR("Alexey Brodkin <abrodkin@synopsys.com>");
> MODULE_DESCRIPTION("ARC EMAC driver");
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH net-next 02/17] tipc: Fix build.
From: Neil Horman @ 2014-08-26 13:15 UTC (permalink / raw)
To: David Miller
Cc: jon.maloy, netdev, paul.gortmaker, erik.hugne, ying.xue, maloy,
tipc-discussion
In-Reply-To: <20140825.114420.77676883396367108.davem@davemloft.net>
On Mon, Aug 25, 2014 at 11:44:20AM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Mon, 25 Aug 2014 06:21:42 -0400
>
> > On Fri, Aug 22, 2014 at 06:09:05PM -0400, Jon Maloy wrote:
> >> From: "David S. Miller" <davem@davemloft.net>
> >>
> >> Missing semicolon in range check fix.
> >>
> >> Signed-off-by: David S. Miller <davem@davemloft.net>
> >> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
> >> ---
> >> net/tipc/port.h | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/net/tipc/port.h b/net/tipc/port.h
> >> index a69118f..3087da3 100644
> >> --- a/net/tipc/port.h
> >> +++ b/net/tipc/port.h
> >> @@ -182,8 +182,9 @@ static inline int tipc_port_importance(struct tipc_port *port)
> >> static inline int tipc_port_set_importance(struct tipc_port *port, int imp)
> >> {
> >> if (imp > TIPC_CRITICAL_IMPORTANCE)
> >> - return -EINVAL
> >> + return -EINVAL;
> >> msg_set_importance(&port->phdr, (u32)imp);
> >> + return 0;
> >> }
> >>
> > Fold this in with the previous patch to avoid a FTBFS during a bisect.
>
> See his header posting, these are changes already in mainline that hadn't
> hit net-next yet.
My bad, thanks
Neil
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v4 3/3] ethernet: arc: Add support for specific SoC layer device tree bindings
From: Romain Perier @ 2014-08-26 13:14 UTC (permalink / raw)
To: davem
Cc: heiko, tklauser, b.galvani, eric.dumazet, yongjun_wei, f.fainelli,
netdev, arnd
In-Reply-To: <1409058891-30790-1-git-send-email-romain.perier@gmail.com>
Some platforms have special bank registers which might be used to
select the correct clock or the right mode for Media Indepent Interface
controllers. Sometimes, it is also required to activate vcc regulators
in the right order to supply the ethernet controller at the right time.
This patch is an architecture refactoring of the arc-emac device driver.
It adds a new software design which allows to add specific platform
glue layer. Each platform has now its own module which performs custom
initialization and remove for the target and then calls to the
core driver.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
drivers/net/ethernet/arc/Kconfig | 8 ++-
drivers/net/ethernet/arc/Makefile | 3 +-
drivers/net/ethernet/arc/emac.h | 4 ++
drivers/net/ethernet/arc/emac_arc.c | 95 ++++++++++++++++++++++++++++++++++++
drivers/net/ethernet/arc/emac_main.c | 80 +++++++++---------------------
5 files changed, 129 insertions(+), 61 deletions(-)
create mode 100644 drivers/net/ethernet/arc/emac_arc.c
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
index 514c57f..89e04fd 100644
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -17,10 +17,14 @@ config NET_VENDOR_ARC
if NET_VENDOR_ARC
-config ARC_EMAC
- tristate "ARC EMAC support"
+config ARC_EMAC_CORE
+ tristate
select MII
select PHYLIB
+
+config ARC_EMAC
+ tristate "ARC EMAC support"
+ select ARC_EMAC_CORE
depends on OF_IRQ
depends on OF_NET
---help---
diff --git a/drivers/net/ethernet/arc/Makefile b/drivers/net/ethernet/arc/Makefile
index 00c8657..241bb80 100644
--- a/drivers/net/ethernet/arc/Makefile
+++ b/drivers/net/ethernet/arc/Makefile
@@ -3,4 +3,5 @@
#
arc_emac-objs := emac_main.o emac_mdio.o
-obj-$(CONFIG_ARC_EMAC) += arc_emac.o
+obj-$(CONFIG_ARC_EMAC_CORE) += arc_emac.o
+obj-$(CONFIG_ARC_EMAC) += emac_arc.o
diff --git a/drivers/net/ethernet/arc/emac.h b/drivers/net/ethernet/arc/emac.h
index 8011445..eb2ba67 100644
--- a/drivers/net/ethernet/arc/emac.h
+++ b/drivers/net/ethernet/arc/emac.h
@@ -124,6 +124,8 @@ struct buffer_state {
*/
struct arc_emac_priv {
/* Devices */
+ const char *drv_name;
+ const char *drv_version;
struct device *dev;
struct phy_device *phy_dev;
struct mii_bus *bus;
@@ -206,5 +208,7 @@ static inline void arc_reg_clr(struct arc_emac_priv *priv, int reg, int mask)
int arc_mdio_probe(struct arc_emac_priv *priv);
int arc_mdio_remove(struct arc_emac_priv *priv);
+int arc_emac_probe(struct net_device *ndev, int interface);
+int arc_emac_remove(struct net_device *ndev);
#endif /* ARC_EMAC_H */
diff --git a/drivers/net/ethernet/arc/emac_arc.c b/drivers/net/ethernet/arc/emac_arc.c
new file mode 100644
index 0000000..f9cb99b
--- /dev/null
+++ b/drivers/net/ethernet/arc/emac_arc.c
@@ -0,0 +1,95 @@
+/**
+ * emac_arc.c - ARC EMAC specific glue layer
+ *
+ * Copyright (C) 2014 Romain Perier
+ *
+ * Romain Perier <romain.perier@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/etherdevice.h>
+#include <linux/module.h>
+#include <linux/of_net.h>
+#include <linux/platform_device.h>
+
+#include "emac.h"
+
+#define DRV_NAME "emac_arc"
+#define DRV_VERSION "1.0"
+
+static int emac_arc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct net_device *ndev;
+ struct arc_emac_priv *priv;
+ int interface, err;
+
+ if (!dev->of_node)
+ return -ENODEV;
+
+ ndev = alloc_etherdev(sizeof(struct arc_emac_priv));
+ if (!ndev)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, ndev);
+ SET_NETDEV_DEV(ndev, dev);
+
+ priv = netdev_priv(ndev);
+ priv->drv_name = DRV_NAME;
+ priv->drv_version = DRV_VERSION;
+
+ interface = of_get_phy_mode(dev->of_node);
+ if (interface < 0)
+ interface = PHY_INTERFACE_MODE_MII;
+
+ priv->clk = devm_clk_get(dev, "hclk");
+ if (IS_ERR(priv->clk)) {
+ dev_err(dev, "failed to retrieve host clock from device tree\n");
+ err = -EINVAL;
+ goto out_netdev;
+ }
+
+ err = arc_emac_probe(ndev, interface);
+out_netdev:
+ if (err)
+ free_netdev(ndev);
+ return err;
+}
+
+static int emac_arc_remove(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ int err;
+
+ err = arc_emac_remove(ndev);
+ free_netdev(ndev);
+ return err;
+}
+
+static const struct of_device_id emac_arc_dt_ids[] = {
+ { .compatible = "snps,arc-emac" },
+ { /* Sentinel */ }
+};
+
+static struct platform_driver emac_arc_driver = {
+ .probe = emac_arc_probe,
+ .remove = emac_arc_remove,
+ .driver = {
+ .name = DRV_NAME,
+ .of_match_table = emac_arc_dt_ids,
+ },
+};
+
+module_platform_driver(emac_arc_driver);
+
+MODULE_AUTHOR("Romain Perier <romain.perier@gmail.com>");
+MODULE_DESCRIPTION("ARC EMAC platform driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index bbc3157..b35c69e 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -26,8 +26,6 @@
#include "emac.h"
-#define DRV_NAME "arc_emac"
-#define DRV_VERSION "1.0"
/**
* arc_emac_adjust_link - Adjust the PHY link duplex.
@@ -120,8 +118,10 @@ static int arc_emac_set_settings(struct net_device *ndev,
static void arc_emac_get_drvinfo(struct net_device *ndev,
struct ethtool_drvinfo *info)
{
- strlcpy(info->driver, DRV_NAME, sizeof(info->driver));
- strlcpy(info->version, DRV_VERSION, sizeof(info->version));
+ struct arc_emac_priv *priv = netdev_priv(ndev);
+
+ strlcpy(info->driver, priv->drv_name, sizeof(info->driver));
+ strlcpy(info->version, priv->drv_version, sizeof(info->version));
}
static const struct ethtool_ops arc_emac_ethtool_ops = {
@@ -671,19 +671,16 @@ static const struct net_device_ops arc_emac_netdev_ops = {
#endif
};
-static int arc_emac_probe(struct platform_device *pdev)
+int arc_emac_probe(struct net_device *ndev, int interface)
{
- struct device *dev = &pdev->dev;
+ struct device *dev = ndev->dev.parent;
struct resource res_regs;
struct device_node *phy_node;
struct arc_emac_priv *priv;
- struct net_device *ndev;
const char *mac_addr;
unsigned int id, clock_frequency, irq;
int err;
- if (!dev->of_node)
- return -ENODEV;
/* Get PHY from device tree */
phy_node = of_parse_phandle(dev->of_node, "phy", 0);
@@ -706,12 +703,6 @@ static int arc_emac_probe(struct platform_device *pdev)
return -ENODEV;
}
- ndev = alloc_etherdev(sizeof(struct arc_emac_priv));
- if (!ndev)
- return -ENOMEM;
-
- dev_set_drvdata(dev, ndev);
- SET_NETDEV_DEV(ndev, dev);
ndev->netdev_ops = &arc_emac_netdev_ops;
ndev->ethtool_ops = &arc_emac_ethtool_ops;
@@ -724,28 +715,25 @@ static int arc_emac_probe(struct platform_device *pdev)
priv->regs = devm_ioremap_resource(dev, &res_regs);
if (IS_ERR(priv->regs)) {
- err = PTR_ERR(priv->regs);
- goto out_netdev;
+ return PTR_ERR(priv->regs);
}
dev_dbg(dev, "Registers base address is 0x%p\n", priv->regs);
- priv->clk = of_clk_get(dev->of_node, 0);
- if (IS_ERR(priv->clk)) {
- /* Get CPU clock frequency from device tree */
- if (of_property_read_u32(dev->of_node, "clock-frequency",
- &clock_frequency)) {
- dev_err(dev, "failed to retrieve <clock-frequency> from device tree\n");
- err = -EINVAL;
- goto out_netdev;
- }
- } else {
+ if (priv->clk) {
err = clk_prepare_enable(priv->clk);
if (err) {
dev_err(dev, "failed to enable clock\n");
- goto out_clkget;
+ return err;
}
clock_frequency = clk_get_rate(priv->clk);
+ } else {
+ /* Get CPU clock frequency from device tree */
+ if (of_property_read_u32(dev->of_node, "clock-frequency",
+ &clock_frequency)) {
+ dev_err(dev, "failed to retrieve <clock-frequency> from device tree\n");
+ return -EINVAL;
+ }
}
id = arc_reg_get(priv, R_ID);
@@ -806,7 +794,7 @@ static int arc_emac_probe(struct platform_device *pdev)
}
priv->phy_dev = of_phy_connect(ndev, phy_node, arc_emac_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
+ interface);
if (!priv->phy_dev) {
dev_err(dev, "of_phy_connect() failed\n");
err = -ENODEV;
@@ -833,20 +821,15 @@ out_netif_api:
out_mdio:
arc_mdio_remove(priv);
out_clken:
- if (!IS_ERR(priv->clk))
+ if (priv->clk)
clk_disable_unprepare(priv->clk);
-out_clkget:
- if (!IS_ERR(priv->clk))
- clk_put(priv->clk);
-out_netdev:
- free_netdev(ndev);
return err;
}
+EXPORT_SYMBOL_GPL(arc_emac_probe);
-static int arc_emac_remove(struct platform_device *pdev)
+int arc_emac_remove(struct net_device *ndev)
{
- struct device *dev = &pdev->dev;
- struct net_device *ndev = dev_get_drvdata(dev);
+ struct device *dev = ndev->dev.parent;
struct arc_emac_priv *priv = netdev_priv(ndev);
phy_disconnect(priv->phy_dev);
@@ -857,31 +840,12 @@ static int arc_emac_remove(struct platform_device *pdev)
if (!IS_ERR(priv->clk)) {
clk_disable_unprepare(priv->clk);
- clk_put(priv->clk);
}
- free_netdev(ndev);
return 0;
}
-
-static const struct of_device_id arc_emac_dt_ids[] = {
- { .compatible = "snps,arc-emac" },
- { /* Sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, arc_emac_dt_ids);
-
-static struct platform_driver arc_emac_driver = {
- .probe = arc_emac_probe,
- .remove = arc_emac_remove,
- .driver = {
- .name = DRV_NAME,
- .owner = THIS_MODULE,
- .of_match_table = arc_emac_dt_ids,
- },
-};
-
-module_platform_driver(arc_emac_driver);
+EXPORT_SYMBOL_GPL(arc_emac_remove);
MODULE_AUTHOR("Alexey Brodkin <abrodkin@synopsys.com>");
MODULE_DESCRIPTION("ARC EMAC driver");
--
1.9.1
^ 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