* Re: [PATCH net-next 1/2] vxlan: don't flush static fdb entries on admin down
From: Jiri Benc @ 2017-01-23 8:55 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: davem, netdev, ramanb, stephen, pshelar
In-Reply-To: <1484984599-16712-2-git-send-email-roopa@cumulusnetworks.com>
On Fri, 20 Jan 2017 23:43:18 -0800, Roopa Prabhu wrote:
> This patch skips flushing static fdb entries in
> ndo_stop, but flushes all fdb entries during vxlan
> device delete. This is consistent with the bridge
> driver fdb
This makes sense but isn't this a uAPI change? Do you know whether
there are users relying on the current behavior?
Jiri
^ permalink raw reply
* [PATCH net] net/sched: matchall: Fix configuration race
From: Yotam Gigi @ 2017-01-23 8:54 UTC (permalink / raw)
To: mlxsw, jiri, eladr, daniel, jhs, davem, netdev; +Cc: Yotam Gigi
In the current version, the matchall internal state is split into two
structs: cls_matchall_head and cls_matchall_filter. This makes little
sense, as matchall instance supports only one filter, and there is no
situation where one exists and the other does not. In addition, that led
to some races when filter was deleted while packet was processed.
Unify that two structs into one, thus simplifying the process of matchall
creation and deletion. As a result, the new, delete and get callbacks have
a dummy implementation where all the work is done in destroy and change
callbacks, as was done in cls_cgroup.
Fixes: bf3994d2ed31 ("net/sched: introduce Match-all classifier")
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_matchall.c | 129 +++++++++++++++++------------------------------
1 file changed, 46 insertions(+), 83 deletions(-)
diff --git a/net/sched/cls_matchall.c b/net/sched/cls_matchall.c
index fcecf5a..f2141cb 100644
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@ -16,16 +16,11 @@
#include <net/sch_generic.h>
#include <net/pkt_cls.h>
-struct cls_mall_filter {
+struct cls_mall_head {
struct tcf_exts exts;
struct tcf_result res;
u32 handle;
- struct rcu_head rcu;
u32 flags;
-};
-
-struct cls_mall_head {
- struct cls_mall_filter *filter;
struct rcu_head rcu;
};
@@ -33,38 +28,29 @@ static int mall_classify(struct sk_buff *skb, const struct tcf_proto *tp,
struct tcf_result *res)
{
struct cls_mall_head *head = rcu_dereference_bh(tp->root);
- struct cls_mall_filter *f = head->filter;
- if (tc_skip_sw(f->flags))
+ if (tc_skip_sw(head->flags))
return -1;
- return tcf_exts_exec(skb, &f->exts, res);
+ return tcf_exts_exec(skb, &head->exts, res);
}
static int mall_init(struct tcf_proto *tp)
{
- struct cls_mall_head *head;
-
- head = kzalloc(sizeof(*head), GFP_KERNEL);
- if (!head)
- return -ENOBUFS;
-
- rcu_assign_pointer(tp->root, head);
-
return 0;
}
-static void mall_destroy_filter(struct rcu_head *head)
+static void mall_destroy_rcu(struct rcu_head *rcu)
{
- struct cls_mall_filter *f = container_of(head, struct cls_mall_filter, rcu);
+ struct cls_mall_head *head = container_of(rcu, struct cls_mall_head,
+ rcu);
- tcf_exts_destroy(&f->exts);
-
- kfree(f);
+ tcf_exts_destroy(&head->exts);
+ kfree(head);
}
static int mall_replace_hw_filter(struct tcf_proto *tp,
- struct cls_mall_filter *f,
+ struct cls_mall_head *head,
unsigned long cookie)
{
struct net_device *dev = tp->q->dev_queue->dev;
@@ -74,7 +60,7 @@ static int mall_replace_hw_filter(struct tcf_proto *tp,
offload.type = TC_SETUP_MATCHALL;
offload.cls_mall = &mall_offload;
offload.cls_mall->command = TC_CLSMATCHALL_REPLACE;
- offload.cls_mall->exts = &f->exts;
+ offload.cls_mall->exts = &head->exts;
offload.cls_mall->cookie = cookie;
return dev->netdev_ops->ndo_setup_tc(dev, tp->q->handle, tp->protocol,
@@ -82,7 +68,7 @@ static int mall_replace_hw_filter(struct tcf_proto *tp,
}
static void mall_destroy_hw_filter(struct tcf_proto *tp,
- struct cls_mall_filter *f,
+ struct cls_mall_head *head,
unsigned long cookie)
{
struct net_device *dev = tp->q->dev_queue->dev;
@@ -103,29 +89,20 @@ static bool mall_destroy(struct tcf_proto *tp, bool force)
{
struct cls_mall_head *head = rtnl_dereference(tp->root);
struct net_device *dev = tp->q->dev_queue->dev;
- struct cls_mall_filter *f = head->filter;
- if (!force && f)
- return false;
+ if (!head)
+ return true;
- if (f) {
- if (tc_should_offload(dev, tp, f->flags))
- mall_destroy_hw_filter(tp, f, (unsigned long) f);
+ if (tc_should_offload(dev, tp, head->flags))
+ mall_destroy_hw_filter(tp, head, (unsigned long) head);
- call_rcu(&f->rcu, mall_destroy_filter);
- }
- kfree_rcu(head, rcu);
+ call_rcu(&head->rcu, mall_destroy_rcu);
return true;
}
static unsigned long mall_get(struct tcf_proto *tp, u32 handle)
{
- struct cls_mall_head *head = rtnl_dereference(tp->root);
- struct cls_mall_filter *f = head->filter;
-
- if (f && f->handle == handle)
- return (unsigned long) f;
- return 0;
+ return 0UL;
}
static const struct nla_policy mall_policy[TCA_MATCHALL_MAX + 1] = {
@@ -134,7 +111,7 @@ static const struct nla_policy mall_policy[TCA_MATCHALL_MAX + 1] = {
};
static int mall_set_parms(struct net *net, struct tcf_proto *tp,
- struct cls_mall_filter *f,
+ struct cls_mall_head *head,
unsigned long base, struct nlattr **tb,
struct nlattr *est, bool ovr)
{
@@ -149,11 +126,11 @@ static int mall_set_parms(struct net *net, struct tcf_proto *tp,
goto errout;
if (tb[TCA_MATCHALL_CLASSID]) {
- f->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
- tcf_bind_filter(tp, &f->res, base);
+ head->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
+ tcf_bind_filter(tp, &head->res, base);
}
- tcf_exts_change(tp, &f->exts, &e);
+ tcf_exts_change(tp, &head->exts, &e);
return 0;
errout:
@@ -167,21 +144,17 @@ static int mall_change(struct net *net, struct sk_buff *in_skb,
unsigned long *arg, bool ovr)
{
struct cls_mall_head *head = rtnl_dereference(tp->root);
- struct cls_mall_filter *fold = (struct cls_mall_filter *) *arg;
struct net_device *dev = tp->q->dev_queue->dev;
- struct cls_mall_filter *f;
struct nlattr *tb[TCA_MATCHALL_MAX + 1];
+ struct cls_mall_head *new;
u32 flags = 0;
int err;
if (!tca[TCA_OPTIONS])
return -EINVAL;
- if (head->filter)
- return -EBUSY;
-
- if (fold)
- return -EINVAL;
+ if (head)
+ return -EEXIST;
err = nla_parse_nested(tb, TCA_MATCHALL_MAX,
tca[TCA_OPTIONS], mall_policy);
@@ -194,25 +167,25 @@ static int mall_change(struct net *net, struct sk_buff *in_skb,
return -EINVAL;
}
- f = kzalloc(sizeof(*f), GFP_KERNEL);
- if (!f)
+ new = kzalloc(sizeof(*new), GFP_KERNEL);
+ if (!new)
return -ENOBUFS;
- err = tcf_exts_init(&f->exts, TCA_MATCHALL_ACT, 0);
+ err = tcf_exts_init(&new->exts, TCA_MATCHALL_ACT, 0);
if (err)
goto err_exts_init;
if (!handle)
handle = 1;
- f->handle = handle;
- f->flags = flags;
+ new->handle = handle;
+ new->flags = flags;
- err = mall_set_parms(net, tp, f, base, tb, tca[TCA_RATE], ovr);
+ err = mall_set_parms(net, tp, new, base, tb, tca[TCA_RATE], ovr);
if (err)
goto err_set_parms;
if (tc_should_offload(dev, tp, flags)) {
- err = mall_replace_hw_filter(tp, f, (unsigned long) f);
+ err = mall_replace_hw_filter(tp, new, (unsigned long) new);
if (err) {
if (tc_skip_sw(flags))
goto err_replace_hw_filter;
@@ -221,42 +194,32 @@ static int mall_change(struct net *net, struct sk_buff *in_skb,
}
}
- *arg = (unsigned long) f;
- rcu_assign_pointer(head->filter, f);
-
+ *arg = (unsigned long) head;
+ rcu_assign_pointer(tp->root, new);
+ if (head)
+ call_rcu(&head->rcu, mall_destroy_rcu);
return 0;
err_replace_hw_filter:
err_set_parms:
- tcf_exts_destroy(&f->exts);
+ tcf_exts_destroy(&new->exts);
err_exts_init:
- kfree(f);
+ kfree(new);
return err;
}
static int mall_delete(struct tcf_proto *tp, unsigned long arg)
{
- struct cls_mall_head *head = rtnl_dereference(tp->root);
- struct cls_mall_filter *f = (struct cls_mall_filter *) arg;
- struct net_device *dev = tp->q->dev_queue->dev;
-
- if (tc_should_offload(dev, tp, f->flags))
- mall_destroy_hw_filter(tp, f, (unsigned long) f);
-
- RCU_INIT_POINTER(head->filter, NULL);
- tcf_unbind_filter(tp, &f->res);
- call_rcu(&f->rcu, mall_destroy_filter);
- return 0;
+ return -EOPNOTSUPP;
}
static void mall_walk(struct tcf_proto *tp, struct tcf_walker *arg)
{
struct cls_mall_head *head = rtnl_dereference(tp->root);
- struct cls_mall_filter *f = head->filter;
if (arg->count < arg->skip)
goto skip;
- if (arg->fn(tp, (unsigned long) f, arg) < 0)
+ if (arg->fn(tp, (unsigned long) head, arg) < 0)
arg->stop = 1;
skip:
arg->count++;
@@ -265,28 +228,28 @@ static void mall_walk(struct tcf_proto *tp, struct tcf_walker *arg)
static int mall_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
struct sk_buff *skb, struct tcmsg *t)
{
- struct cls_mall_filter *f = (struct cls_mall_filter *) fh;
+ struct cls_mall_head *head = (struct cls_mall_head *) fh;
struct nlattr *nest;
- if (!f)
+ if (!head)
return skb->len;
- t->tcm_handle = f->handle;
+ t->tcm_handle = head->handle;
nest = nla_nest_start(skb, TCA_OPTIONS);
if (!nest)
goto nla_put_failure;
- if (f->res.classid &&
- nla_put_u32(skb, TCA_MATCHALL_CLASSID, f->res.classid))
+ if (head->res.classid &&
+ nla_put_u32(skb, TCA_MATCHALL_CLASSID, head->res.classid))
goto nla_put_failure;
- if (tcf_exts_dump(skb, &f->exts))
+ if (tcf_exts_dump(skb, &head->exts))
goto nla_put_failure;
nla_nest_end(skb, nest);
- if (tcf_exts_dump_stats(skb, &f->exts) < 0)
+ if (tcf_exts_dump_stats(skb, &head->exts) < 0)
goto nla_put_failure;
return skb->len;
--
2.4.11
^ permalink raw reply related
* Re: [RFC PATCH net-next 0/5] bridge: per vlan lwt and dst_metadata support
From: Jiri Benc @ 2017-01-23 8:51 UTC (permalink / raw)
To: Jiri Pirko
Cc: Roopa Prabhu, netdev, davem, stephen, nikolay, tgraf, hannes,
pshelar, dsa, hadi
In-Reply-To: <20170123080805.GB1831@nanopsycho.orion>
On Mon, 23 Jan 2017 09:08:05 +0100, Jiri Pirko wrote:
> Sat, Jan 21, 2017 at 06:46:51AM CET, roopa@cumulusnetworks.com wrote:
> >Other approaches tried and vetoed:
> >- tc vlan push/pop and tunnel metadata dst:
> > - posses a tc rule scalability problem (2 rules per vni)
>
> Why it is a problem?
Wanted to ask exactly the same question.
> > - cannot handle the case where a packet needs to be replicated to
> > multiple vxlan remote tunnel end-points.. which the vxlan driver
> > can do today by having multiple remote destinations per fdb.
>
> Can't you just extend the tc to support this?
+1
> To me, looks like the tc is the correct place to hangle this. Then, the
> user can use it for multiple cases of forwarding, including bridge,
> tc-mirred, ovs and others. Putting this in bridge somehow seems wrong in
> this light. Also, the bridge code is polluted enough as it is. I this we
> should be super-picky to add another code there.
Completely agreed.
Jiri
^ permalink raw reply
* Re: ieee802154: atusb: fix driver to work with older firmware versions
From: Geert Uytterhoeven @ 2017-01-23 8:42 UTC (permalink / raw)
To: Stefan Schmidt, Marcel Holtmann
Cc: Linux Kernel Mailing List, linux-wpan, netdev@vger.kernel.org
In-Reply-To: <20170117181132.05BEF660FF6@gitolite.kernel.org>
On Tue, Jan 17, 2017 at 7:11 PM, Linux Kernel Mailing List
<linux-kernel@vger.kernel.org> wrote:
> Web: https://git.kernel.org/torvalds/c/8e38b7d4d71479b23b77f01cf0e5071610b8f357
> Commit: 8e38b7d4d71479b23b77f01cf0e5071610b8f357
> Parent: f301606934b240fb54d8edf3618a0483e36046fc
> Refname: refs/heads/master
> Author: Stefan Schmidt <stefan@osg.samsung.com>
> AuthorDate: Mon Jan 2 16:58:13 2017 +0100
> Committer: Marcel Holtmann <marcel@holtmann.org>
> CommitDate: Thu Jan 12 22:12:43 2017 +0100
>
> ieee802154: atusb: fix driver to work with older firmware versions
>
> After the addition of the frame_retries callback we could run into cases where
> a ATUSB device with an older firmware version would now longer be able to bring
> the interface up.
>
> We keep this functionality disabled now if the minimum firmware version for this
> feature is not available.
>
> Fixes: 5d82288b93db3bc ("ieee802154: atusb: implement .set_frame_retries
> ops callback")
> Reported-by: Alexander Aring <aar@pengutronix.de>
> Acked-by: Alexander Aring <aar@pengutronix.de>
> Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> drivers/net/ieee802154/atusb.c | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> index 63cb679..ef68851 100644
> --- a/drivers/net/ieee802154/atusb.c
> +++ b/drivers/net/ieee802154/atusb.c
> @@ -562,13 +562,6 @@ static int
> atusb_set_frame_retries(struct ieee802154_hw *hw, s8 retries)
> {
> struct atusb *atusb = hw->priv;
> - struct device *dev = &atusb->usb_dev->dev;
> -
> - if (atusb->fw_ver_maj == 0 && atusb->fw_ver_min < 3) {
> - dev_info(dev, "Automatic frame retransmission is only available from "
> - "firmware version 0.3. Please update if you want this feature.");
> - return -EINVAL;
> - }
>
> return atusb_write_subreg(atusb, SR_MAX_FRAME_RETRIES, retries);
> }
> @@ -802,8 +795,7 @@ static int atusb_probe(struct usb_interface *interface,
>
> hw->parent = &usb_dev->dev;
> hw->flags = IEEE802154_HW_TX_OMIT_CKSUM | IEEE802154_HW_AFILT |
> - IEEE802154_HW_PROMISCUOUS | IEEE802154_HW_CSMA_PARAMS |
> - IEEE802154_HW_FRAME_RETRIES;
> + IEEE802154_HW_PROMISCUOUS | IEEE802154_HW_CSMA_PARAMS;
>
> hw->phy->flags = WPAN_PHY_FLAG_TXPOWER | WPAN_PHY_FLAG_CCA_ED_LEVEL |
> WPAN_PHY_FLAG_CCA_MODE;
> @@ -832,6 +824,9 @@ static int atusb_probe(struct usb_interface *interface,
> atusb_get_and_show_build(atusb);
> atusb_set_extended_addr(atusb);
>
> + if (atusb->fw_ver_maj >= 0 && atusb->fw_ver_min >= 3)
As fw_ver_maj is unsigned char, gcc 4.1.2 complains:
warning: comparison is always true due to limited range of data type
> + hw->flags |= IEEE802154_HW_FRAME_RETRIES;
> +
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net] net/mlx5e: Do not recycle pages from emergency reserve
From: Jesper Dangaard Brouer @ 2017-01-23 8:39 UTC (permalink / raw)
To: Saeed Mahameed
Cc: brouer, Tom Herbert, Saeed Mahameed, netdev, Tariq Toukan, Davem,
Eric Dumazet
In-Reply-To: <CALzJLG9JEorLwV48H3m0vQ1+VDnpYbKhiBoUw+WW-JFouJoj1g@mail.gmail.com>
On Sat, 21 Jan 2017 22:31:26 +0200 Saeed Mahameed <saeedm@dev.mellanox.co.il> wrote:
> > My previous measurements show approx 20℅ speedup on a UDP test with delivery
> > to remote CPU.
> >
> > Removing the cache would of cause be a good usecase for speeding up the page
> > allocator (PCP). Which Mel Gorman and me are working on. AFAIK current page
> > order0 cost 240 cycles. Mel have reduced til to 180, and without NUMA 150
> > cycles. And with bulking this can be amortized to 80 cycles.
> >
>
> Are you trying to say that we won't need the cache if you manage to
> deliver those optimizations ?
These page alloc optimization are good, but not fast-enough to replace
your cache. Maybe I can improve it further, but it will be very hard
to compete with a recycle cache (it can skip many checks the page alloc
need, as it knows the page state).
Said in another way, the gap will be significantly smaller, and you
will not see a big boost from using this cache.
BUT there are other advantages of using a guaranteed recycle pool
facility (like the page_pool). Namely, (1) DMA-overhead: keeping page
DMA mapped to counter DMA+IOMMU overhead, (2) RX-zero-copy: opens up
for a software memory model solution for pre-VMA-mapping pages to
userspace (See: [1] for argument how this avoids leaking kernel mem,
but only expose/leak packet-data mem)
> can you compare those optimizations with the page_frag_cache from
> dev_alloc_skb ?
IHMO the page_frag_cache is indirectly a bulk page allocator facility,
which is limiting the number of times the page allocator is called, and
thus amortize the cost of talking to the page allocator. Performance
wise, it is likely comparable to your page cache, and likely faster
than the 80 cycles order0-bulking.
BUT we generally worry about using these 32K pages, as it opens a
window for attackers pinning down memory.
[1] https://prototype-kernel.readthedocs.io/en/latest/vm/page_pool/design/memory_model_nic.html
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* RE: [PATCH v2] net: broadcom: bnx2x: use new api ethtool_{get|set}_link_ksettings
From: Mintz, Yuval @ 2017-01-23 8:16 UTC (permalink / raw)
To: Philippe Reynes, davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Elior, Ariel
In-Reply-To: <1485006196-6472-1-git-send-email-tremyfr@gmail.com>
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if someone may test this
> patch.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
>From the little testing I've did, things look fine. Thanks.
Acked-by: Yuval Mintz <Yuval.Mintz@cavium.com>
^ permalink raw reply
* Re: [RFC PATCH net-next 0/5] bridge: per vlan lwt and dst_metadata support
From: Jiri Pirko @ 2017-01-23 8:08 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, davem, stephen, nikolay, tgraf, hannes, jbenc, pshelar,
dsa, hadi
In-Reply-To: <1484977616-1541-1-git-send-email-roopa@cumulusnetworks.com>
Sat, Jan 21, 2017 at 06:46:51AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>High level summary:
>lwt and dst_metadata/collect_metadata have enabled vxlan l3 deployments
>to use a single vxlan netdev for multiple vnis eliminating the scalability
>problem with using a single vxlan netdev per vni. This series tries to
>do the same for vxlan netdevs in pure l2 bridged networks.
>Use-case/deployment and details are below.
>
>Deployment scerario details:
>As we know VXLAN is used to build layer 2 virtual networks across the
>underlay layer3 infrastructure. A VXLAN tunnel endpoint (VTEP)
>originates and terminates VXLAN tunnels. And a VTEP can be a TOR switch
>or a vswitch in the hypervisor. This patch series mainly
>focuses on the TOR switch configured as a Vtep. Vxlan segment ID (vni)
>along with vlan id is used to identify layer 2 segments in a vxlan
>overlay network. Vxlan bridging is the function provided by Vteps to terminate
>vxlan tunnels and map the vxlan vni to traditional end host vlan. This is
>covered in the "VXLAN Deployment Scenarios" in sections 6 and 6.1 in RFC 7348.
>To provide vxlan bridging function, a vtep has to map vlan to a vni. The rfc
>says that the ingress VTEP device shall remove the IEEE 802.1Q VLAN tag in
>the original Layer 2 packet if there is one before encapsulating the packet
>into the VXLAN format to transmit it through the underlay network. The remote
>VTEP devices have information about the VLAN in which the packet will be
>placed based on their own VLAN-to-VXLAN VNI mapping configurations.
>
>Existing solution:
>Without this patch series one can deploy such a vtep configuration by
>by adding the local ports and vxlan netdevs into a vlan filtering bridge.
>The local ports are configured as trunk ports carrying all vlans.
>A vxlan netdev per vni is added to the bridge. Vlan mapping to vni is
>achieved by configuring the vlan as pvid on the corresponding vxlan netdev.
>The vxlan netdev only receives traffic corresponding to the vlan it is mapped
>to. This configuration maps traffic belonging to a vlan to the corresponding
>vxlan segment.
>
> -----------------------------------
> | bridge |
> | |
> -----------------------------------
> |100,200 |100 (pvid) |200 (pvid)
> | | |
> swp1 vxlan1000 vxlan2000
>
>This provides the required vxlan bridging function but poses a
>scalability problem with using a single vxlan netdev for each vni.
>
>Solution in this patch series:
>The Goal is to use a single vxlan device to carry all vnis similar
>to the vxlan collect metadata mode but vxlan driver still carrying all
>the forwarding information.
>- vxlan driver changes:
> - enable collect metadata mode device to be used with learning,
> replication, fdb
> - A single fdb table hashed by (mac, vni)
> - rx path already has the vni
> - tx path expects a vni in the packet with dst_metadata and vxlan
> driver has all the forwarding information for the vni in the
> dst_metadata.
>
>- Bridge driver changes: per vlan LWT and dst_metadata support:
> - Our use case is vxlan and 1-1 mapping between vlan and vni, but I have
> kept the api generic for any tunnel info
> - Uapi to configure/unconfigure/dump per vlan tunnel data
> - new bridge port flag to turn this feature on/off. off by default
> - ingress hook:
> - if port is a lwt tunnel port, use tunnel info in
> attached dst_metadata to map it to a local vlan
> - egress hook:
> - if port is a lwt tunnel port, use tunnel info attached to vlan
> to set dst_metadata on the skb
>
>Other approaches tried and vetoed:
>- tc vlan push/pop and tunnel metadata dst:
> - posses a tc rule scalability problem (2 rules per vni)
Why it is a problem?
> - cannot handle the case where a packet needs to be replicated to
> multiple vxlan remote tunnel end-points.. which the vxlan driver
> can do today by having multiple remote destinations per fdb.
Can't you just extend the tc to support this?
To me, looks like the tc is the correct place to hangle this. Then, the
user can use it for multiple cases of forwarding, including bridge,
tc-mirred, ovs and others. Putting this in bridge somehow seems wrong in
this light. Also, the bridge code is polluted enough as it is. I this we
should be super-picky to add another code there.
Can you please elaborate more why can't have this as a re-usable TC solution?
Thanks.
^ permalink raw reply
* Re: [PATCH 3/3] sh_eth: stop using bare numbers for EESIPR values
From: Geert Uytterhoeven @ 2017-01-23 8:00 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <4605565.M0SEEbnHAH@wasted.cogentembedded.com>
Hi Sergei,
On Sun, Jan 22, 2017 at 8:19 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Now that we have almost all EESIPR bits declared (and those that are
> still not are most probably reserved anyway) we can at last replace the
> bare numbers used for 'sh_eth_cpu_data::eesipr_value' initializers with
> the bit names ORed together...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> drivers/net/ethernet/renesas/sh_eth.c | 89 +++++++++++++++++++++++++++++-----
> 1 file changed, 78 insertions(+), 11 deletions(-)
>
> Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
> ===================================================================
> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
> +++ net-next/drivers/net/ethernet/renesas/sh_eth.c
> @@ -800,7 +843,12 @@ static struct sh_eth_cpu_data sh7734_dat
>
> .ecsr_value = ECSR_ICD | ECSR_MPD,
> .ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
> - .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP | 0x003f07ff,
> + .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
> + EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
> + EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
Missing:
EESIPR_DLCIP | EESIPR_CDIP | EESIPR_TROIP |
> + EESIPR_RMAFIP | EESIPR_CEEFIP | EESIPR_CELFIP |
> + EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
> + EESIPR_PREIP | EESIPR_CERFIP,
>
> .tx_check = EESR_TC1 | EESR_FTC,
> .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
> @@ -830,7 +878,12 @@ static struct sh_eth_cpu_data sh7763_dat
>
> .ecsr_value = ECSR_ICD | ECSR_MPD,
> .ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
> - .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP | 0x003f07ff,
> + .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
> + EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
> + EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
Likewise
> + EESIPR_RMAFIP | EESIPR_CEEFIP | EESIPR_CELFIP |
> + EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
> + EESIPR_PREIP | EESIPR_CERFIP,
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v1] net: phy: micrel: add KSZ8795 ethernet switch
From: Sean Nyekjaer @ 2017-01-23 7:58 UTC (permalink / raw)
To: netdev; +Cc: Sean Nyekjaer, andrew
This is add support for the PHYs in the KSZ8795 5port managed switch.
It will allow to detect the link between the switch and the soc
and uses the same read_status functions as the KSZ8873MLL switch.
This ethernet switch have unfortunately the same phy id as KSZ8051.
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
---
drivers/net/phy/micrel.c | 14 ++++++++++++++
include/linux/micrel_phy.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index ea92d524d5a8..fa158ae5115b 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -1014,6 +1014,20 @@ static struct phy_driver ksphy_driver[] = {
.get_stats = kszphy_get_stats,
.suspend = genphy_suspend,
.resume = genphy_resume,
+}, {
+ .phy_id = PHY_ID_KSZ8795,
+ .phy_id_mask = MICREL_PHY_ID_MASK,
+ .name = "Micrel KSZ8795 Switch",
+ .features = (SUPPORTED_Pause | SUPPORTED_Asym_Pause),
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = kszphy_config_init,
+ .config_aneg = ksz8873mll_config_aneg,
+ .read_status = ksz8873mll_read_status,
+ .get_sset_count = kszphy_get_sset_count,
+ .get_strings = kszphy_get_strings,
+ .get_stats = kszphy_get_stats,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
} };
module_phy_driver(ksphy_driver);
diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
index 257173e0095e..f541da68d1e7 100644
--- a/include/linux/micrel_phy.h
+++ b/include/linux/micrel_phy.h
@@ -35,6 +35,8 @@
#define PHY_ID_KSZ886X 0x00221430
#define PHY_ID_KSZ8863 0x00221435
+#define PHY_ID_KSZ8795 0x00221550
+
/* struct phy_device dev_flags definitions */
#define MICREL_PHY_50MHZ_CLK 0x00000001
#define MICREL_PHY_FXEN 0x00000002
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next v6 1/1] net sched actions: Add support for user cookies
From: Jiri Pirko @ 2017-01-23 7:48 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: davem, netdev, jiri, paulb, john.fastabend, simon.horman, mrv,
hadarh, ogerlitz, roid, xiyou.wangcong, daniel
In-Reply-To: <1485116750-31198-1-git-send-email-jhs@emojatatu.com>
Sun, Jan 22, 2017 at 09:25:50PM CET, jhs@mojatatu.com wrote:
>From: Jamal Hadi Salim <jhs@mojatatu.com>
>
>Introduce optional 128-bit action cookie.
>Like all other cookie schemes in the networking world (eg in protocols
>like http or existing kernel fib protocol field, etc) the idea is to save
>user state that when retrieved serves as a correlator. The kernel
>_should not_ intepret it. The user can store whatever they wish in the
>128 bits.
>
>Sample exercise(showing variable length use of cookie)
>
>.. create an accept action with cookie a1b2c3d4
>sudo $TC actions add action ok index 1 cookie a1b2c3d4
>
>.. dump all gact actions..
>sudo $TC -s actions ls action gact
>
> action order 0: gact action pass
> random type none pass val 0
> index 1 ref 1 bind 0 installed 5 sec used 5 sec
> Action statistics:
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> cookie a1b2c3d4
>
>.. bind the accept action to a filter..
>sudo $TC filter add dev lo parent ffff: protocol ip prio 1 \
>u32 match ip dst 127.0.0.1/32 flowid 1:1 action gact index 1
>
>... send some traffic..
>$ ping 127.0.0.1 -c 3
>PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
>64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.020 ms
>64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.027 ms
>64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.038 ms
>
>--- 127.0.0.1 ping statistics ---
>3 packets transmitted, 3 received, 0% packet loss, time 2109ms
>rtt min/avg/max/mdev = 0.020/0.028/0.038/0.008 ms 1
>
>... show some stats
>$ sudo $TC -s actions get action gact index 1
>
> action order 1: gact action pass
> random type none pass val 0
> index 1 ref 2 bind 1 installed 204 sec used 5 sec
> Action statistics:
> Sent 12168 bytes 164 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> cookie a1b2c3d4
>
>.. try longer cookie...
>$ sudo $TC actions replace action ok index 1 cookie 1234567890abcdef
>.. dump..
>$ sudo $TC -s actions ls action gact
>
> action order 1: gact action pass
> random type none pass val 0
> index 1 ref 2 bind 1 installed 204 sec used 5 sec
> Action statistics:
> Sent 12168 bytes 164 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> cookie 1234567890abcdef
>
>Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH 2/3] sh_eth: add missing EESIPR bits
From: Geert Uytterhoeven @ 2017-01-23 7:41 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <3805935.iR4tgtFiHm@wasted.cogentembedded.com>
On Sun, Jan 22, 2017 at 8:18 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Renesas SH77{34|63} manuals describe more EESIPR bits than the current
> driver. Declare the new bits with the end goal of using the bit names
> instead of the bare numbers for the 'sh_eth_cpu_data::eesipr_value'
> initializers...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/net/ethernet/renesas/sh_eth.h | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
> ===================================================================
> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
> +++ net-next/drivers/net/ethernet/renesas/sh_eth.h
> @@ -269,13 +269,17 @@ enum EESR_BIT {
>
> /* EESIPR */
> enum EESIPR_BIT {
> - EESIPR_TWBIP = 0x40000000,
> + EESIPR_TWB1IP = 0x80000000,
> + EESIPR_TWBIP = 0x40000000, /* same as TWB0IP */
Ah, your adding it here ;-)
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH 1/3] sh_eth: rename EESIPR bits
From: Geert Uytterhoeven @ 2017-01-23 7:39 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <6851530.HAKW22qnWH@wasted.cogentembedded.com>
Hi Sergei,
On Sun, Jan 22, 2017 at 8:18 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Since the commit b0ca2a21f769 ("sh_eth: Add support of SH7763 to sh_eth")
> the *enum* declaring the EESIPR bits (interrupt mask) went out of sync with
> the *enum* declaring the EESR bits (interrupt status) WRT bit naming and
> formatting. I'd like to restore the consistency by using EESIPR as the bit
> name prefix, renaming the *enum* to EESIPR_BIT, and (finally) renaming the
> bits according to the available Renesas SH77{34|63} manuals...
Which versions of the SH77{34|63} manuals did you use?
Several registers are called slightly different in mine, and also in my
r8a7740 manual.
> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
> +++ net-next/drivers/net/ethernet/renesas/sh_eth.h
> @@ -268,19 +268,29 @@ enum EESR_BIT {
> EESR_TFE | EESR_TDE)
>
> /* EESIPR */
> -enum DMAC_IM_BIT {
> - DMAC_M_TWB = 0x40000000, DMAC_M_TABT = 0x04000000,
> - DMAC_M_RABT = 0x02000000,
> - DMAC_M_RFRMER = 0x01000000, DMAC_M_ADF = 0x00800000,
> - DMAC_M_ECI = 0x00400000, DMAC_M_FTC = 0x00200000,
> - DMAC_M_TDE = 0x00100000, DMAC_M_TFE = 0x00080000,
> - DMAC_M_FRC = 0x00040000, DMAC_M_RDE = 0x00020000,
> - DMAC_M_RFE = 0x00010000, DMAC_M_TINT4 = 0x00000800,
> - DMAC_M_TINT3 = 0x00000400, DMAC_M_TINT2 = 0x00000200,
> - DMAC_M_TINT1 = 0x00000100, DMAC_M_RINT8 = 0x00000080,
> - DMAC_M_RINT5 = 0x00000010, DMAC_M_RINT4 = 0x00000008,
> - DMAC_M_RINT3 = 0x00000004, DMAC_M_RINT2 = 0x00000002,
> - DMAC_M_RINT1 = 0x00000001,
> +enum EESIPR_BIT {
> + EESIPR_TWBIP = 0x40000000,
TWBIP is actually two bits in my manual: TWB1IP and TWB0IP
> + EESIPR_ADEIP = 0x00800000,
Nonexistent bit in my manual.
> + EESIPR_CNDIP = 0x00000800,
Nonexistent bit in my manual.
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: add KSZ8795 ethernet switch
From: Sean Nyekjær @ 2017-01-23 7:22 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20170120141728.GA13115@lunn.ch>
On 2017-01-20 15:17, Andrew Lunn wrote:
> On Fri, Jan 20, 2017 at 01:50:49PM +0100, Sean Nyekjaer wrote:
>> This ethernet switch have unfortunately the same phy id as KSZ8051.
> Hi Sean
>
> Please could you explain some more. You are adding PHY support here,
> not switch support. So is this to enable the PHY driver for the PHYs
> embedded in the switch?
>
> Andrew
Yes of couse :-)
The KSZ8051 is a 5 port managed ethernet switch with integrated PHY with
MII/RMII interface on one port.
Through the MDIO interface is possible to control the PHY on port 1-5.
I have just seen an issue with the reported speed and duplex, so i'm
gonna submit a new version with a better description
/Sean
^ permalink raw reply
* [PATCH v4 net-next] net: mvneta: implement .set_wol and .get_wol
From: Jisheng Zhang @ 2017-01-23 6:55 UTC (permalink / raw)
To: thomas.petazzoni, davem; +Cc: netdev, linux-kernel, Jingju Hou, Jisheng Zhang
From: Jingju Hou <houjingj@marvell.com>
From: Jingju Hou <houjingj@marvell.com>
The mvneta itself does not support WOL, but the PHY might.
So pass the calls to the PHY
Signed-off-by: Jingju Hou <houjingj@marvell.com>
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
since v3:
- really fix the build error
since v2,v1:
- using phy_dev member in struct net_device
- add commit msg
drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 6dcc951af0ff..02611fa1c3b8 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3929,6 +3929,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
return 0;
}
+static void mvneta_ethtool_get_wol(struct net_device *dev,
+ struct ethtool_wolinfo *wol)
+{
+ wol->supported = 0;
+ wol->wolopts = 0;
+
+ if (dev->phydev)
+ return phy_ethtool_get_wol(dev->phydev, wol);
+}
+
+static int mvneta_ethtool_set_wol(struct net_device *dev,
+ struct ethtool_wolinfo *wol)
+{
+ if (!dev->phydev)
+ return -EOPNOTSUPP;
+
+ return phy_ethtool_set_wol(dev->phydev, wol);
+}
+
static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open = mvneta_open,
.ndo_stop = mvneta_stop,
@@ -3958,6 +3977,8 @@ const struct ethtool_ops mvneta_eth_tool_ops = {
.set_rxfh = mvneta_ethtool_set_rxfh,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = mvneta_ethtool_set_link_ksettings,
+ .get_wol = mvneta_ethtool_get_wol,
+ .set_wol = mvneta_ethtool_set_wol,
};
/* Initialize hw */
--
2.11.0
^ permalink raw reply related
* [PATCH net] r8152: don't execute runtime suspend if the tx is not empty
From: Hayes Wang @ 2017-01-23 6:18 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Runtime suspend shouldn't be executed if the tx queue is not empty,
because the device is not idle.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0e99af0..e1466b4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -32,7 +32,7 @@
#define NETNEXT_VERSION "08"
/* Information for net */
-#define NET_VERSION "6"
+#define NET_VERSION "7"
#define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
#define DRIVER_AUTHOR "Realtek linux nic maintainers <nic_swsd@realtek.com>"
@@ -3574,6 +3574,8 @@ static bool delay_autosuspend(struct r8152 *tp)
*/
if (!sw_linking && tp->rtl_ops.in_nway(tp))
return true;
+ else if (!skb_queue_empty(&tp->tx_queue))
+ return true;
else
return false;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: stmicro: fix LS field mask in EEE configuration
From: Rayagond Kokatanur @ 2017-01-23 5:31 UTC (permalink / raw)
To: Joao Pinto; +Cc: David Miller, netdev
In-Reply-To: <ed690f703a3c82193737f1a9813dff8b1ff403dd.1484927665.git.jpinto@synopsys.com>
Acked-by:Rayagond Kokatanur <rayagond@vayavyalabs.com>
On Fri, Jan 20, 2017 at 9:30 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
> This patch fixes the LS mask when setting EEE timer.
> LS field is 10 bits long and not 11 as currently.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> Reported-By: Rayagond Kokatanur <rayagond@vayavyalabs.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> index 834f40f..202216c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> @@ -184,7 +184,7 @@ static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
> static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
> {
> void __iomem *ioaddr = hw->pcsr;
> - int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
> + int value = ((tw & 0xffff)) | ((ls & 0x3ff) << 16);
>
> /* Program the timers in the LPI timer control register:
> * LS: minimum time (ms) for which the link
> --
> 2.9.3
>
--
wwr
Rayagond
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: Fix inverted test for multiple CPU interface
From: Florian Fainelli @ 2017-01-23 5:26 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: Vivien Didelot, netdev
In-Reply-To: <1485119805-30338-1-git-send-email-andrew@lunn.ch>
On 01/22/2017 01:16 PM, Andrew Lunn wrote:
> Remove the wrong !, otherwise we get false positives about having
> multiple CPU interfaces.
>
> Fixes: b22de490869d ("net: dsa: store CPU switch structure in the tree")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH net-next 2/2] net: dsa: b53: Utilize mdio_module_driver
From: Florian Fainelli @ 2017-01-23 5:17 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
In-Reply-To: <20170123051733.10316-1-f.fainelli@gmail.com>
Eliminate a bit of boilerplate code.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_mdio.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_mdio.c b/drivers/net/dsa/b53/b53_mdio.c
index 477a16b5660a..fa7556f5d4fb 100644
--- a/drivers/net/dsa/b53/b53_mdio.c
+++ b/drivers/net/dsa/b53/b53_mdio.c
@@ -375,18 +375,7 @@ static struct mdio_driver b53_mdio_driver = {
.of_match_table = b53_of_match,
},
};
-
-static int __init b53_mdio_driver_register(void)
-{
- return mdio_driver_register(&b53_mdio_driver);
-}
-module_init(b53_mdio_driver_register);
-
-static void __exit b53_mdio_driver_unregister(void)
-{
- mdio_driver_unregister(&b53_mdio_driver);
-}
-module_exit(b53_mdio_driver_unregister);
+mdio_module_driver(b53_mdio_driver);
MODULE_DESCRIPTION("B53 MDIO access driver");
MODULE_LICENSE("Dual BSD/GPL");
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 1/2] net: phy: Fix typo for MDIO module boilerplate comment
From: Florian Fainelli @ 2017-01-23 5:17 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
In-Reply-To: <20170123051733.10316-1-f.fainelli@gmail.com>
The module boilerplate macro is named mdio_module_driver and not
module_mdio_driver, fix that.
Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
include/linux/mdio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index b6587a4b32e7..55a80d73cfc1 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -265,7 +265,7 @@ bool mdiobus_is_registered_device(struct mii_bus *bus, int addr);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr);
/**
- * module_mdio_driver() - Helper macro for registering mdio drivers
+ * mdio_module_driver() - Helper macro for registering mdio drivers
*
* Helper macro for MDIO drivers which do not do anything special in module
* init/exit. Each module may only use this macro once, and calling it
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 0/2] net: couple mdio_module_driver changes
From: Florian Fainelli @ 2017-01-23 5:17 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
Hi David,
Small patch series fixing a comment for mdio_module_driver and
finally utilizing it in b53_mdio.
Thanks!
Florian Fainelli (2):
net: phy: Fix typo for MDIO module boilerplate comment
net: dsa: b53: Utilize mdio_module_driver
drivers/net/dsa/b53/b53_mdio.c | 13 +------------
include/linux/mdio.h | 2 +-
2 files changed, 2 insertions(+), 13 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: ignore null_entry on route dumps
From: David Miller @ 2017-01-23 4:58 UTC (permalink / raw)
To: dsa; +Cc: netdev, xiaolong.ye
In-Reply-To: <1485147377-11922-1-git-send-email-dsa@cumulusnetworks.com>
David, please slow down.
How is the NULL entry getting selected to be dumped and passed
down here in the first place?
The problem seems to be higher up in the chain here, don't
just special case check for this in rt6_dump_route().
Thanks.
^ permalink raw reply
* [PATCH net-next] net: ipv6: ignore null_entry on route dumps
From: David Ahern @ 2017-01-23 4:56 UTC (permalink / raw)
To: netdev; +Cc: xiaolong.ye, David Ahern
lkp-robot reported a BUG:
[ 10.151226] BUG: unable to handle kernel NULL pointer dereference at 00000198
[ 10.152525] IP: rt6_fill_node+0x164/0x4b8
[ 10.153307] *pdpt = 0000000012ee5001 *pde = 0000000000000000
[ 10.153309]
[ 10.154492] Oops: 0000 [#1]
[ 10.154987] CPU: 0 PID: 909 Comm: netifd Not tainted 4.10.0-rc4-00722-g41e8c70ee162-dirty #10
[ 10.156482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 10.158254] task: d0deb000 task.stack: d0e0c000
[ 10.159059] EIP: rt6_fill_node+0x164/0x4b8
[ 10.159780] EFLAGS: 00010296 CPU: 0
[ 10.160404] EAX: 00000000 EBX: d10c2358 ECX: c1f7c6cc EDX: c1f6ff44
[ 10.161469] ESI: 00000000 EDI: c2059900 EBP: d0e0dc4c ESP: d0e0dbe4
[ 10.162534] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[ 10.163482] CR0: 80050033 CR2: 00000198 CR3: 10d94660 CR4: 000006b0
[ 10.164535] Call Trace:
[ 10.164993] ? paravirt_sched_clock+0x9/0xd
[ 10.165727] ? sched_clock+0x9/0xc
[ 10.166329] ? sched_clock_cpu+0x19/0xe9
[ 10.166991] ? lock_release+0x13e/0x36c
[ 10.167652] rt6_dump_route+0x4c/0x56
[ 10.168276] fib6_dump_node+0x1d/0x3d
[ 10.168913] fib6_walk_continue+0xab/0x167
[ 10.169611] fib6_walk+0x2a/0x40
[ 10.170182] inet6_dump_fib+0xfb/0x1e0
[ 10.170855] netlink_dump+0xcd/0x21f
This happens when the loopback device is set down and a ipv6 fib route
dump is requested.
The ipv6 route dump code passes ip6_null_entry to rt6_fill_node. This
route uses the loopback device but does not have idev set. When the
loopback is set down, the netif_running check added by a1a22c1206 fails
and the fill_node descends to checking rt->rt6i_idev for
ignore_routes_with_linkdown. Since idev is null for the ip6_null_entry
route it triggers the BUG.
The null_entry route should not be processed in a dump request. Catch
and ignore.
Fixes: a1a22c1206("net: ipv6: Keep nexthop of multipath route on admin down")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/ipv6/route.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 4b1f0f98a0e9..47499ed429da 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3320,6 +3320,10 @@ static int rt6_fill_node(struct net *net,
int rt6_dump_route(struct rt6_info *rt, void *p_arg)
{
struct rt6_rtnl_dump_arg *arg = (struct rt6_rtnl_dump_arg *) p_arg;
+ struct net *net = arg->net;
+
+ if (rt == net->ipv6.ip6_null_entry)
+ return 0;
if (nlmsg_len(arg->cb->nlh) >= sizeof(struct rtmsg)) {
struct rtmsg *rtm = nlmsg_data(arg->cb->nlh);
@@ -3332,7 +3336,7 @@ int rt6_dump_route(struct rt6_info *rt, void *p_arg)
}
}
- return rt6_fill_node(arg->net,
+ return rt6_fill_node(net,
arg->skb, rt, NULL, NULL, 0, RTM_NEWROUTE,
NETLINK_CB(arg->cb->skb).portid, arg->cb->nlh->nlmsg_seq,
NLM_F_MULTI);
--
2.1.4
^ permalink raw reply related
* RE: [PATCH v3 net-next] net: mvneta: implement .set_wol and .get_wol
From: YUAN Linyu @ 2017-01-23 4:55 UTC (permalink / raw)
To: Jingju Hou, davem@davemloft.net
Cc: jszhang@marvell.com, thomas.petazzoni@free-electrons.com,
netdev@vger.kernel.org
In-Reply-To: <1485144678-11777-1-git-send-email-houjingj@marvell.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Jingju Hou
> Sent: Monday, January 23, 2017 12:11 PM
> To: davem@davemloft.net
> Cc: jszhang@marvell.com; thomas.petazzoni@free-electrons.com;
> netdev@vger.kernel.org; Jingju Hou
> Subject: [PATCH v3 net-next] net: mvneta: implement .set_wol and .get_wol
>
> The mvneta itself does not support WOL, but the PHY might.
> So pass the calls to the PHY
>
> Signed-off-by: Jingju Hou <houjingj@marvell.com>
> ---
> Since v2:
> - it should be phydev member not phy_dev
>
> drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c
> b/drivers/net/ethernet/marvell/mvneta.c
> index e05e227..fea4968 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3908,6 +3908,25 @@ static int mvneta_ethtool_get_rxfh(struct
> net_device *dev, u32 *indir, u8 *key,
> return 0;
> }
>
> +static void
> +mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo
> *wol)
> +{
> + wol->supported = 0;
> + wol->wolopts = 0;
> +
> + if (dev->phy_dev)
Not changed,
> + return phy_ethtool_get_wol(dev->phydev, wol);
> +}
> +
> +static int
> +mvneta_ethtool_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> +{
> + if (!dev->phydev)
> + return -EOPNOTSUPP;
> +
> + return phy_ethtool_set_wol(dev->phydev, wol);
> +}
> +
> static const struct net_device_ops mvneta_netdev_ops = {
> .ndo_open = mvneta_open,
> .ndo_stop = mvneta_stop,
> @@ -3937,6 +3956,8 @@ static int mvneta_ethtool_get_rxfh(struct
> net_device *dev, u32 *indir, u8 *key,
> .set_rxfh = mvneta_ethtool_set_rxfh,
> .get_link_ksettings = phy_ethtool_get_link_ksettings,
> .set_link_ksettings = mvneta_ethtool_set_link_ksettings,
> + .get_wol = mvneta_ethtool_get_wol,
> + .set_wol = mvneta_ethtool_set_wol,
> };
>
> /* Initialize hw */
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Check that idev is non-NULL in rt6_fill_node
From: David Ahern @ 2017-01-23 4:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, xiaolong.ye
In-Reply-To: <20170122.233239.720617884825007357.davem@davemloft.net>
On 1/22/17 9:32 PM, David Miller wrote:
> From: David Ahern <dsa@cumulusnetworks.com>
> Date: Sun, 22 Jan 2017 20:08:00 -0800
>
>> The ipv6 route dump code passes ip6_null_entry to rt6_fill_node.
>
> Doesn't this fact cause you to take a pause?
yes, it did.
>
> I can't see a legitimate reason to dump the null entry, it's
> a marker rather than a real entry.
>
neither do I. I was rather surprised to see it hit rt6_fill_node and that the rc is 0.
I can send a v2 that drops null_entry.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Check that idev is non-NULL in rt6_fill_node
From: David Miller @ 2017-01-23 4:32 UTC (permalink / raw)
To: dsa; +Cc: netdev, xiaolong.ye
In-Reply-To: <1485144480-4460-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Sun, 22 Jan 2017 20:08:00 -0800
> The ipv6 route dump code passes ip6_null_entry to rt6_fill_node.
Doesn't this fact cause you to take a pause?
I can't see a legitimate reason to dump the null entry, it's
a marker rather than a real entry.
^ 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