* Re: [PATCH] net: bcm63xx_enet: make bcm_enetsw_ethtool_ops const
From: David Miller @ 2017-08-30 22:20 UTC (permalink / raw)
To: bhumirks
Cc: julia.lawall, f.fainelli, bcm-kernel-feedback-list, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <1504085108-23495-1-git-send-email-bhumirks@gmail.com>
From: Bhumika Goyal <bhumirks@gmail.com>
Date: Wed, 30 Aug 2017 14:55:08 +0530
> Make this const as it is never modified.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH v2] ipv6: sr: fix get_srh() to comply with IPv6 standard "RFC 8200"
From: David Miller @ 2017-08-30 22:19 UTC (permalink / raw)
To: amsalam20; +Cc: netdev, david.lebrun
In-Reply-To: <1504083037-1605-1-git-send-email-amsalam20@gmail.com>
From: Ahmed Abdelsalam <amsalam20@gmail.com>
Date: Wed, 30 Aug 2017 10:50:37 +0200
> IPv6 packet may carry more than one extension header, and IPv6 nodes must
> accept and attempt to process extension headers in any order and occurring
> any number of times in the same packet. Hence, there should be no
> assumption that Segment Routing extension header is to appear immediately
> after the IPv6 header.
>
> Moreover, section 4.1 of RFC 8200 gives a recommendation on the order of
> appearance of those extension headers within an IPv6 packet. According to
> this recommendation, Segment Routing extension header should appear after
> Hop-by-Hop and Destination Options headers (if they present).
>
> This patch fixes the get_srh(), so it gets the segment routing header
> regardless of its position in the chain of the extension headers in IPv6
> packet, and makes sure that the IPv6 routing extension header is of Type 4.
>
> Signed-off-by: Ahmed Abdelsalam <amsalam20@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v4 00/13] net: mvpp2: comphy configuration
From: David Miller @ 2017-08-30 22:18 UTC (permalink / raw)
To: antoine.tenart
Cc: kishon, andrew, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170830082924.3180-1-antoine.tenart@free-electrons.com>
From: Antoine Tenart <antoine.tenart@free-electrons.com>
Date: Wed, 30 Aug 2017 10:29:11 +0200
> This series, following up the one one the GoP/MAC configuration, aims at
> stopping to depend on the firmware/bootloader configuration when using
> the PPv2 engine. With this series the PPv2 driver does not need to rely
> on a previous configuration, and dynamic reconfiguration while the
> kernel is running can be done (i.e. switch one port from SGMII to 10G,
> or the opposite). A port can now be configured in a different mode than
> what's done in the firmware/bootloader as well.
>
> The series first contain patches in the generic PHY framework to support
> what is called the comphy (common PHYs), which is an h/w block providing
> PHYs that can be configured in various modes ranging from SGMII, 10G
> to SATA and others. As of now only the SGMII and 10G modes are
> supported by the comphy driver.
>
> Then patches are modifying the PPv2 driver to first add the comphy
> initialization sequence (i.e. calls to the generic PHY framework) and to
> then take advantage of this to allow dynamic reconfiguration (i.e.
> configuring the mode of a port given what's connected, between sgmii and
> 10G). Note the use of the comphy in the PPv2 driver is kept optional
> (i.e. if not described in dt the driver still as before an relies on the
> firmware/bootloader configuration).
>
> Finally there are dt/defconfig patches to describe and take advantage of
> this.
>
> This was tested on a range of devices: 8040-db, 8040-mcbin and 7040-db.
>
> @Dave: the dt patches should go through the mvebu tree (patches 9-13).
Ok, patches 1-8 applied to net-next, thanks!
^ permalink raw reply
* Re: DSA mv88e6xxx RX frame errors and TCP/IP RX failure
From: Andrew Lunn @ 2017-08-30 22:06 UTC (permalink / raw)
To: Tim Harvey; +Cc: netdev, Vivien Didelot, linux-kernel@vger.kernel.org
In-Reply-To: <CAJ+vNU0VzgDkH-ksHgaA0cn3nbCOfcUs_BU90v6xw_QappssgA@mail.gmail.com>
On Wed, Aug 30, 2017 at 12:53:56PM -0700, Tim Harvey wrote:
> Greetings,
>
> I'm seeing RX frame errors when using the mv88e6xxx DSA driver on
> 4.13-rc7. The board I'm using is a GW5904 [1] which has an IMX6 FEC
> MAC (eth0) connected via RGMII to a MV88E6176 with its downstream
> P0/P1/P2/P3 to front panel RJ45's (lan1-lan4).
Hi Tim
Can you confirm the counter is this one:
/* Report late collisions as a frame error. */
if (status & (BD_ENET_RX_NO | BD_ENET_RX_CL))
ndev->stats.rx_frame_errors++;
I don't see anywhere else frame errors are counted, but it would be
good to prove we are looking in the right place.
Andrew
^ permalink raw reply
* Re: [Patch net-next] net_sched: add reverse binding for tc class
From: Cong Wang @ 2017-08-30 22:01 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Linux Kernel Network Developers, Jamal Hadi Salim
In-Reply-To: <59A732B8.6020405@iogearbox.net>
On Wed, Aug 30, 2017 at 2:48 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 08/30/2017 11:30 PM, Cong Wang wrote:
> [...]
>>
>> Note, we still can NOT totally get rid of those class lookup in
>> ->enqueue() because cgroup and flow filters have no way to determine
>> the classid at setup time, they still have to go through dynamic lookup.
>
> [...]
>>
>> ---
>> include/net/sch_generic.h | 1 +
>> net/sched/cls_basic.c | 9 +++++++
>> net/sched/cls_bpf.c | 9 +++++++
>
>
> Same is for cls_bpf as well, so bind_class wouldn't work there
> either as we could return dynamic classids. bind_class cannot
> be added here, too.
I think you are probably right, but the following code is
misleading there:
if (tb[TCA_BPF_CLASSID]) {
prog->res.classid = nla_get_u32(tb[TCA_BPF_CLASSID]);
tcf_bind_filter(tp, &prog->res, base);
}
If the classid is dynamic, why this tb[TCA_BPF_CLASSID]?
^ permalink raw reply
* Re: [PATCH] DSA support for Micrel KSZ8895
From: Andrew Lunn @ 2017-08-30 22:00 UTC (permalink / raw)
To: Tristram.Ha
Cc: pavel, Woojung.Huh, nathan.leigh.conrad, vivien.didelot,
f.fainelli, netdev, linux-kernel
In-Reply-To: <93AF473E2DA327428DE3D46B72B1E9FD4111FA48@CHN-SV-EXMX02.mchp-main.com>
> The KSZ8795 driver will be submitted after Labor Day (9/4) if
> testing reveals no problem. The KSZ8895 driver will be submitted
> right after that. You should have no problem using the driver right
> away.
Hi Tristram
Release early, release often. It stops people wasting time....
Also, we are likely to give you feedback, asking you to make
changes. Testing is important, but you are probably going to have to
do it a number of times. So it is not everything passes now, don't
worry, you will have time to fix things up as you go through review
cycles.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] dp83640: don't hold spinlock while calling netif_rx_ni
From: David Miller @ 2017-08-30 21:50 UTC (permalink / raw)
To: stefan.sorensen; +Cc: richardcochran, netdev
In-Reply-To: <20170830065847.2444-1-stefan.sorensen@spectralink.com>
From: Stefan Sørensen <stefan.sorensen@spectralink.com>
Date: Wed, 30 Aug 2017 08:58:47 +0200
> We should not hold a spinlock while pushing the skb into the networking
> stack, so move the call to netif_rx_ni out of the critical region to where
> we have dropped the spinlock.
>
> Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [Patch net-next] net_sched: add reverse binding for tc class
From: Daniel Borkmann @ 2017-08-30 21:48 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: Jamal Hadi Salim
In-Reply-To: <20170830213036.24250-1-xiyou.wangcong@gmail.com>
On 08/30/2017 11:30 PM, Cong Wang wrote:
[...]
> Note, we still can NOT totally get rid of those class lookup in
> ->enqueue() because cgroup and flow filters have no way to determine
> the classid at setup time, they still have to go through dynamic lookup.
[...]
> ---
> include/net/sch_generic.h | 1 +
> net/sched/cls_basic.c | 9 +++++++
> net/sched/cls_bpf.c | 9 +++++++
Same is for cls_bpf as well, so bind_class wouldn't work there
either as we could return dynamic classids. bind_class cannot
be added here, too.
> net/sched/cls_flower.c | 9 +++++++
> net/sched/cls_fw.c | 9 +++++++
> net/sched/cls_matchall.c | 9 +++++++
> net/sched/cls_route.c | 9 +++++++
> net/sched/cls_rsvp.h | 9 +++++++
> net/sched/cls_tcindex.c | 9 +++++++
> net/sched/cls_u32.c | 9 +++++++
> net/sched/sch_api.c | 68 +++++++++++++++++++++++++++++++++++++++++++++--
> 11 files changed, 148 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] net: cpsw: Don't handle SIOC[GS]HWTSTAMP when CPTS is disabled
From: David Miller @ 2017-08-30 21:47 UTC (permalink / raw)
To: stefan.sorensen; +Cc: grygorii.strashko, netdev, linux-omap
In-Reply-To: <20170830065055.419-1-stefan.sorensen@spectralink.com>
From: Stefan Sørensen <stefan.sorensen@spectralink.com>
Date: Wed, 30 Aug 2017 08:50:55 +0200
> There is no reason to handle SIOC[GS]HWTSTAMP and return -EOPNOTSUPP when
> CPTS is disabled, so just pass them on to the phy. This will allow PTP
> timestamping on a capable phy by disabling CPTS.
>
> Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
It should not be required to disable a Kconfig option just to get PHY
timestamping to work properly.
Rather, if the CPTS code returns -EOPNOTSUPP we should try to
fallthrough to the PHY library based methods.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/3 v11] drivers: net: ethernet: qualcomm: rmnet: Initial implementation
From: Subash Abhinov Kasiviswanathan @ 2017-08-30 21:40 UTC (permalink / raw)
To: David Miller
Cc: dcbw, netdev, fengguang.wu, jiri, stephen, David.Laight, marcel,
andrew
In-Reply-To: <20170830.142744.324884406082731585.davem@davemloft.net>
> Subash, keep in mind that since I applied your v11 patches already you
> will need to send me relative fixes and changes at this point, rather
> than resubmit the series.
>
> Thank you.
Thanks for the heads up David. Will do.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [patch net-next v2 0/3] net/sched: Improve getting objects by indexes
From: David Miller @ 2017-08-30 21:39 UTC (permalink / raw)
To: chrism; +Cc: netdev, jhs, xiyou.wangcong, jiri, mawilcox
In-Reply-To: <1504074719-15147-1-git-send-email-chrism@mellanox.com>
From: Chris Mi <chrism@mellanox.com>
Date: Wed, 30 Aug 2017 02:31:56 -0400
> Using current TC code, it is very slow to insert a lot of rules.
>
> In order to improve the rules update rate in TC,
> we introduced the following two changes:
> 1) changed cls_flower to use IDR to manage the filters.
> 2) changed all act_xxx modules to use IDR instead of
> a small hash table
>
> But IDR has a limitation that it uses int. TC handle uses u32.
> To make sure there is no regression, we add several new IDR APIs
> to support unsigned long.
>
> v2
> ==
>
> Addressed Hannes's comment:
> express idr_alloc in terms of idr_alloc_ext and most of the other functions
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 9/9] sch_tbf: fix two null pointer dereferences on init failure
From: Nikolay Aleksandrov @ 2017-08-30 21:39 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Eric Dumazet, Jamal Hadi Salim,
Jiri Pirko, Roopa Prabhu
In-Reply-To: <CAM_iQpWn_q4CaOKhw7nxFR40V2JaVwr_5kx-ZUpdFxPa4hxKyA@mail.gmail.com>
On 30/08/17 20:37, Cong Wang wrote:
> On Wed, Aug 30, 2017 at 2:49 AM, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>> Reproduce:
>> $ sysctl net.core.default_qdisc=tbf
>> $ ip l set ethX up
>
> I once upon a time had a patch to disallow those qdisc's
> to be default. Probably I should resend it.
>
That sounds good. A lot of them can't be default anyway, they need
some options to be set, so it's definitely worth looking into.
^ permalink raw reply
* Re: [PATCH net 6/9] sch_fq_codel: avoid double free on init failure
From: Nikolay Aleksandrov @ 2017-08-30 21:37 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Eric Dumazet, Jamal Hadi Salim,
Jiri Pirko, Roopa Prabhu
In-Reply-To: <CAM_iQpUZoQYPnq6z3ofFQ_j4O1f+sSChCkYgv5=_cEXRutZeag@mail.gmail.com>
On 30/08/17 20:36, Cong Wang wrote:
> On Wed, Aug 30, 2017 at 2:49 AM, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>> It is very unlikely to happen but the backlogs memory allocation
>> could fail and will free q->flows, but then ->destroy() will free
>> q->flows too. For correctness remove the first free and let ->destroy
>> clean up.
>>
>> Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
>> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>> ---
>> net/sched/sch_fq_codel.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
>> index 337f2d6d81e4..2c0c05f2cc34 100644
>> --- a/net/sched/sch_fq_codel.c
>> +++ b/net/sched/sch_fq_codel.c
>> @@ -491,10 +491,8 @@ static int fq_codel_init(struct Qdisc *sch, struct nlattr *opt)
>> if (!q->flows)
>> return -ENOMEM;
>> q->backlogs = kvzalloc(q->flows_cnt * sizeof(u32), GFP_KERNEL);
>> - if (!q->backlogs) {
>> - kvfree(q->flows);
>> + if (!q->backlogs)
>> return -ENOMEM;
>> - }
>
> This is fine. Or we can NULL it after kvfree().
>
> I have no preference here. The only difference here is if we still
> expect ->init() to cleanup its own failure.
>
We don't, that's the point of the changes that lead to these fixes,
the way ->destroy() is used by both the default qdisc infra and the
normal qdisc add suggest that it should clean up after ->init failure,
thus the change.
^ permalink raw reply
* Re: [PATCH net 0/9] net/sched: init failure fixes
From: Nikolay Aleksandrov @ 2017-08-30 21:35 UTC (permalink / raw)
To: Jamal Hadi Salim, netdev
Cc: edumazet, xiyou.wangcong, jiri, roopa, Lucas Bates
In-Reply-To: <58c39495-8667-d983-94ba-b1a242f56945@mojatatu.com>
On 30/08/17 15:15, Jamal Hadi Salim wrote:
> On 17-08-30 05:48 AM, Nikolay Aleksandrov wrote:
>> Hi all,
>> I went over all qdiscs' init, destroy and reset callbacks and found the
>> issues fixed in each patch. Mostly they are null pointer dereferences due
>> to uninitialized timer (qdisc watchdog) or double frees due to ->destroy
>> cleaning up a second time. There's more information in each patch.
>> I've tested these by either sending wrong attributes from user-spaces, no
>> attributes or by simulating memory alloc failure where applicable. Also
>> tried all of the qdiscs as a default qdisc.
>>
>> Most of these bugs were present before commit 87b60cfacf9f, I've tried to
>> include proper fixes tags in each patch.
>>
>> I haven't included individual patch acks in the set, I'd appreciate it if
>> you take another look and resend them.
>>
>
>
> Hi Nik,
>
> For all patches:
>
> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>
> Would you please consider adding all the the tests
> you used to create the oopses in selftests? It will ensure this
> embarassing bugs get caught should they ever happen again.
> If you need help ping Lucas on Cc.
>
> cheers,
> jamal
Hi,
Sure, I'll make the tests and send patches for tc selftests, using the infra at
tools/testing/selftests/tc-testing.
Thanks!
^ permalink raw reply
* RE: [PATCH] DSA support for Micrel KSZ8895
From: Tristram.Ha @ 2017-08-30 21:32 UTC (permalink / raw)
To: pavel
Cc: Woojung.Huh, nathan.leigh.conrad, vivien.didelot, f.fainelli,
netdev, linux-kernel, andrew
In-Reply-To: <20170829074547.GB31303@amd>
> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
> > > I may be confused here, but AFAICT:
> > >
> > > 1) Yes, it has standard layout when accessed over MDIO.
> >
> >
> > Section 4.8 of the datasheet says:
> >
> > All the registers defined in this section can be also accessed
> > via the SPI interface.
> >
> > Meaning all PHY registers can be access via the SPI interface. So you
> > should be able to make a standard Linux MDIO bus driver which performs
> > SPI reads.
>
> As far as I can tell (and their driver confirms) -- yes, all those registers can be
> accessed over the SPI, they are just shuffled around... hence MDIO
> emulation code. I copied it from their code (see the copyrights) so no, I don't
> believe there's nicer solution.
>
> Best regards,
>
> Pavel
Can you hold on your developing work on KSZ8895 driver? I am afraid your effort may be in vain. We at Microchip are planning to release DSA drivers for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
The driver files all follow the structures of the current KSZ9477 DSA driver, and the file tag_ksz.c will be updated to handle the tail tag of different chips, which requires including the ksz_priv.h header. That is required nevertheless to support using the offload_fwd_mark indication.
The KSZ8795 driver will be submitted after Labor Day (9/4) if testing reveals no problem. The KSZ8895 driver will be submitted right after that. You should have no problem using the driver right away.
Tristram Ha
Principal Software Engineer
Microchip Technology Inc.
^ permalink raw reply
* [Patch net-next] net_sched: add reverse binding for tc class
From: Cong Wang @ 2017-08-30 21:30 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Jamal Hadi Salim
TC filters when used as classifiers are bound to TC classes.
However, there is a hidden difference when adding them in different
orders:
1. If we add tc classes before its filters, everything is fine.
Logically, the classes exist before we specify their ID's in
filters, it is easy to bind them together, just as in the current
code base.
2. If we add tc filters before the tc classes they bind, we have to
do dynamic lookup in fast path. What's worse, this happens all
the time not just once, because on fast path tcf_result is passed
on stack, there is no way to propagate back to the one in tc filters.
This hidden difference hurts performance silently if we have many tc
classes in hierarchy.
This patch intends to close this gap by doing the reverse binding when
we create a new class, in this case we can actually search all the
filters in its parent, match and fixup by classid. And because
tcf_result is specific to each type of tc filter, we have to introduce
a new ops for each filter to tell how to bind the class.
Note, we still can NOT totally get rid of those class lookup in
->enqueue() because cgroup and flow filters have no way to determine
the classid at setup time, they still have to go through dynamic lookup.
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
include/net/sch_generic.h | 1 +
net/sched/cls_basic.c | 9 +++++++
net/sched/cls_bpf.c | 9 +++++++
net/sched/cls_flower.c | 9 +++++++
net/sched/cls_fw.c | 9 +++++++
net/sched/cls_matchall.c | 9 +++++++
net/sched/cls_route.c | 9 +++++++
net/sched/cls_rsvp.h | 9 +++++++
net/sched/cls_tcindex.c | 9 +++++++
net/sched/cls_u32.c | 9 +++++++
net/sched/sch_api.c | 68 +++++++++++++++++++++++++++++++++++++++++++++--
11 files changed, 148 insertions(+), 2 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index c30b634c5f82..d6247a3c40df 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -217,6 +217,7 @@ struct tcf_proto_ops {
void **, bool);
int (*delete)(struct tcf_proto*, void *, bool*);
void (*walk)(struct tcf_proto*, struct tcf_walker *arg);
+ void (*bind_class)(void *, u32, unsigned long);
/* rtnetlink specific */
int (*dump)(struct net*, struct tcf_proto*, void *,
diff --git a/net/sched/cls_basic.c b/net/sched/cls_basic.c
index 73cc7f167a38..d89ebafd2239 100644
--- a/net/sched/cls_basic.c
+++ b/net/sched/cls_basic.c
@@ -235,6 +235,14 @@ static void basic_walk(struct tcf_proto *tp, struct tcf_walker *arg)
}
}
+static void basic_bind_class(void *fh, u32 classid, unsigned long cl)
+{
+ struct basic_filter *f = fh;
+
+ if (f && f->res.classid == classid)
+ f->res.class = cl;
+}
+
static int basic_dump(struct net *net, struct tcf_proto *tp, void *fh,
struct sk_buff *skb, struct tcmsg *t)
{
@@ -280,6 +288,7 @@ static struct tcf_proto_ops cls_basic_ops __read_mostly = {
.delete = basic_delete,
.walk = basic_walk,
.dump = basic_dump,
+ .bind_class = basic_bind_class,
.owner = THIS_MODULE,
};
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index 6f2dffe30f25..520c5027646a 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -607,6 +607,14 @@ static int cls_bpf_dump(struct net *net, struct tcf_proto *tp, void *fh,
return -1;
}
+static void cls_bpf_bind_class(void *fh, u32 classid, unsigned long cl)
+{
+ struct cls_bpf_prog *prog = fh;
+
+ if (prog && prog->res.classid == classid)
+ prog->res.class = cl;
+}
+
static void cls_bpf_walk(struct tcf_proto *tp, struct tcf_walker *arg)
{
struct cls_bpf_head *head = rtnl_dereference(tp->root);
@@ -635,6 +643,7 @@ static struct tcf_proto_ops cls_bpf_ops __read_mostly = {
.delete = cls_bpf_delete,
.walk = cls_bpf_walk,
.dump = cls_bpf_dump,
+ .bind_class = cls_bpf_bind_class,
};
static int __init cls_bpf_init_mod(void)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index bd9dab41f8af..23832d8862c0 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -1360,6 +1360,14 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, void *fh,
return -1;
}
+static void fl_bind_class(void *fh, u32 classid, unsigned long cl)
+{
+ struct cls_fl_filter *f = fh;
+
+ if (f && f->res.classid == classid)
+ f->res.class = cl;
+}
+
static struct tcf_proto_ops cls_fl_ops __read_mostly = {
.kind = "flower",
.classify = fl_classify,
@@ -1370,6 +1378,7 @@ static struct tcf_proto_ops cls_fl_ops __read_mostly = {
.delete = fl_delete,
.walk = fl_walk,
.dump = fl_dump,
+ .bind_class = fl_bind_class,
.owner = THIS_MODULE,
};
diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c
index 192255ec50bd..941245ad07fd 100644
--- a/net/sched/cls_fw.c
+++ b/net/sched/cls_fw.c
@@ -412,6 +412,14 @@ static int fw_dump(struct net *net, struct tcf_proto *tp, void *fh,
return -1;
}
+static void fw_bind_class(void *fh, u32 classid, unsigned long cl)
+{
+ struct fw_filter *f = fh;
+
+ if (f && f->res.classid == classid)
+ f->res.class = cl;
+}
+
static struct tcf_proto_ops cls_fw_ops __read_mostly = {
.kind = "fw",
.classify = fw_classify,
@@ -422,6 +430,7 @@ static struct tcf_proto_ops cls_fw_ops __read_mostly = {
.delete = fw_delete,
.walk = fw_walk,
.dump = fw_dump,
+ .bind_class = fw_bind_class,
.owner = THIS_MODULE,
};
diff --git a/net/sched/cls_matchall.c b/net/sched/cls_matchall.c
index d4dc387f7a56..21cc45caf842 100644
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@ -251,6 +251,14 @@ static int mall_dump(struct net *net, struct tcf_proto *tp, void *fh,
return -1;
}
+static void mall_bind_class(void *fh, u32 classid, unsigned long cl)
+{
+ struct cls_mall_head *head = fh;
+
+ if (head && head->res.classid == classid)
+ head->res.class = cl;
+}
+
static struct tcf_proto_ops cls_mall_ops __read_mostly = {
.kind = "matchall",
.classify = mall_classify,
@@ -261,6 +269,7 @@ static struct tcf_proto_ops cls_mall_ops __read_mostly = {
.delete = mall_delete,
.walk = mall_walk,
.dump = mall_dump,
+ .bind_class = mall_bind_class,
.owner = THIS_MODULE,
};
diff --git a/net/sched/cls_route.c b/net/sched/cls_route.c
index 3b70982394ce..9ddde65915d2 100644
--- a/net/sched/cls_route.c
+++ b/net/sched/cls_route.c
@@ -624,6 +624,14 @@ static int route4_dump(struct net *net, struct tcf_proto *tp, void *fh,
return -1;
}
+static void route4_bind_class(void *fh, u32 classid, unsigned long cl)
+{
+ struct route4_filter *f = fh;
+
+ if (f && f->res.classid == classid)
+ f->res.class = cl;
+}
+
static struct tcf_proto_ops cls_route4_ops __read_mostly = {
.kind = "route",
.classify = route4_classify,
@@ -634,6 +642,7 @@ static struct tcf_proto_ops cls_route4_ops __read_mostly = {
.delete = route4_delete,
.walk = route4_walk,
.dump = route4_dump,
+ .bind_class = route4_bind_class,
.owner = THIS_MODULE,
};
diff --git a/net/sched/cls_rsvp.h b/net/sched/cls_rsvp.h
index 26203ff817f3..98c05db85bcb 100644
--- a/net/sched/cls_rsvp.h
+++ b/net/sched/cls_rsvp.h
@@ -723,6 +723,14 @@ static int rsvp_dump(struct net *net, struct tcf_proto *tp, void *fh,
return -1;
}
+static void rsvp_bind_class(void *fh, u32 classid, unsigned long cl)
+{
+ struct rsvp_filter *f = fh;
+
+ if (f && f->res.classid == classid)
+ f->res.class = cl;
+}
+
static struct tcf_proto_ops RSVP_OPS __read_mostly = {
.kind = RSVP_ID,
.classify = rsvp_classify,
@@ -733,6 +741,7 @@ static struct tcf_proto_ops RSVP_OPS __read_mostly = {
.delete = rsvp_delete,
.walk = rsvp_walk,
.dump = rsvp_dump,
+ .bind_class = rsvp_bind_class,
.owner = THIS_MODULE,
};
diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index fb281b9b2c52..14a7e08b2fa9 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -606,6 +606,14 @@ static int tcindex_dump(struct net *net, struct tcf_proto *tp, void *fh,
return -1;
}
+static void tcindex_bind_class(void *fh, u32 classid, unsigned long cl)
+{
+ struct tcindex_filter_result *r = fh;
+
+ if (r && r->res.classid == classid)
+ r->res.class = cl;
+}
+
static struct tcf_proto_ops cls_tcindex_ops __read_mostly = {
.kind = "tcindex",
.classify = tcindex_classify,
@@ -616,6 +624,7 @@ static struct tcf_proto_ops cls_tcindex_ops __read_mostly = {
.delete = tcindex_delete,
.walk = tcindex_walk,
.dump = tcindex_dump,
+ .bind_class = tcindex_bind_class,
.owner = THIS_MODULE,
};
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index 99ea4c74dd5b..10b8d851fc6b 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -1112,6 +1112,14 @@ static void u32_walk(struct tcf_proto *tp, struct tcf_walker *arg)
}
}
+static void u32_bind_class(void *fh, u32 classid, unsigned long cl)
+{
+ struct tc_u_knode *n = fh;
+
+ if (n && n->res.classid == classid)
+ n->res.class = cl;
+}
+
static int u32_dump(struct net *net, struct tcf_proto *tp, void *fh,
struct sk_buff *skb, struct tcmsg *t)
{
@@ -1242,6 +1250,7 @@ static struct tcf_proto_ops cls_u32_ops __read_mostly = {
.delete = u32_delete,
.walk = u32_walk,
.dump = u32_dump,
+ .bind_class = u32_bind_class,
.owner = THIS_MODULE,
};
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index e7f8e4bfd4ec..929b024f41ba 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -35,6 +35,7 @@
#include <net/sock.h>
#include <net/netlink.h>
#include <net/pkt_sched.h>
+#include <net/pkt_cls.h>
/*
@@ -1648,6 +1649,64 @@ static int tclass_del_notify(struct net *net,
n->nlmsg_flags & NLM_F_ECHO);
}
+#ifdef CONFIG_NET_CLS
+
+struct tcf_bind_args {
+ struct tcf_walker w;
+ u32 classid;
+ unsigned long cl;
+};
+
+static int tcf_node_bind(struct tcf_proto *tp, void *n, struct tcf_walker *arg)
+{
+ struct tcf_bind_args *a = (void *)arg;
+
+ if (tp->ops->bind_class) {
+ tcf_tree_lock(tp);
+ tp->ops->bind_class(n, a->classid, a->cl);
+ tcf_tree_unlock(tp);
+ }
+ return 0;
+}
+
+static void tc_bind_tclass(struct Qdisc *q, u32 portid, u32 clid,
+ unsigned long new_cl)
+{
+ const struct Qdisc_class_ops *cops = q->ops->cl_ops;
+ struct tcf_block *block;
+ struct tcf_chain *chain;
+ unsigned long cl;
+
+ cl = cops->find(q, portid);
+ if (!cl)
+ return;
+ block = cops->tcf_block(q, cl);
+ if (!block)
+ return;
+ list_for_each_entry(chain, &block->chain_list, list) {
+ struct tcf_proto *tp;
+
+ for (tp = rtnl_dereference(chain->filter_chain);
+ tp; tp = rtnl_dereference(tp->next)) {
+ struct tcf_bind_args arg = {};
+
+ arg.w.fn = tcf_node_bind;
+ arg.classid = clid;
+ arg.cl = new_cl;
+ tp->ops->walk(tp, &arg.w);
+ }
+ }
+}
+
+#else
+
+static void tc_bind_tclass(struct Qdisc *q, u32 portid, u32 clid,
+ unsigned long new_cl)
+{
+}
+
+#endif
+
static int tc_ctl_tclass(struct sk_buff *skb, struct nlmsghdr *n,
struct netlink_ext_ack *extack)
{
@@ -1753,6 +1812,8 @@ static int tc_ctl_tclass(struct sk_buff *skb, struct nlmsghdr *n,
break;
case RTM_DELTCLASS:
err = tclass_del_notify(net, cops, skb, n, q, cl);
+ /* Unbind the class with flilters with 0 */
+ tc_bind_tclass(q, portid, clid, 0);
goto out;
case RTM_GETTCLASS:
err = tclass_notify(net, skb, n, q, cl, RTM_NEWTCLASS);
@@ -1767,9 +1828,12 @@ static int tc_ctl_tclass(struct sk_buff *skb, struct nlmsghdr *n,
err = -EOPNOTSUPP;
if (cops->change)
err = cops->change(q, clid, portid, tca, &new_cl);
- if (err == 0)
+ if (err == 0) {
tclass_notify(net, skb, n, q, new_cl, RTM_NEWTCLASS);
-
+ /* We just create a new class, need to do reverse binding. */
+ if (cl != new_cl)
+ tc_bind_tclass(q, portid, clid, new_cl);
+ }
out:
return err;
}
--
2.13.0
^ permalink raw reply related
* Re: [PATCH net-next 3/3 v11] drivers: net: ethernet: qualcomm: rmnet: Initial implementation
From: David Miller @ 2017-08-30 21:27 UTC (permalink / raw)
To: subashab
Cc: dcbw, netdev, fengguang.wu, jiri, stephen, David.Laight, marcel,
andrew
In-Reply-To: <c64415aa8d1184303f5916bdd2fd6ce3@codeaurora.org>
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Wed, 30 Aug 2017 15:19:19 -0600
> Sure, I'll implement this. Let me know if you have more comments.
Subash, keep in mind that since I applied your v11 patches already you
will need to send me relative fixes and changes at this point, rather
than resubmit the series.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 3/3 v11] drivers: net: ethernet: qualcomm: rmnet: Initial implementation
From: Subash Abhinov Kasiviswanathan @ 2017-08-30 21:19 UTC (permalink / raw)
To: Dan Williams
Cc: netdev, davem, fengguang.wu, jiri, stephen, David.Laight, marcel,
andrew
In-Reply-To: <1504103947.21231.5.camel@redhat.com>
> General comment; other drivers that do similar things (macvlan, ipvlan)
> use the term "port" to refer to what I think you're calling a
> "rmnet_real_dev_info". Maybe that's a shorter or less confusing term.
> Could be renamed later too, if you wanted to do so.
>
Hi Dan
I'll rename it to rmnet_port.
> Maybe this got elided during the revisions, but now I can't find
> anywhere that sets RMNET_LOCAL_LOGICAL_ENDPOINT. Looking at the
> callchain, there are two places that LOCAL_LOGICAL_ENDPOINT matters:
>
> rmnet_get_endpoint(): only ever called by __rmnet_set_endpoint_config()
>
> __rmnet_set_endpoint_config(): only called from
> rmnet_set_endpoint_config(); which itself is only called from
> rmnet_newlink().
>
> So the only place that 'config_id' is set, and thus that it could be
> LOCAL_LOGICAL_ENDPOINT, is rmnet_newlink() via 'mux_id'. But
> IFLA_VLAN_ID is a u16, and so I don't see anywhere that
> config_id/mux_id will ever be < 0, and thus anywhere that it could be
> LOCAL_LOGICAL_ENDPOINT.
>
> I could well just not be seeing it though...
>
> This function (__rmnet_set_endpoint_config) seems to only be called
> from rmnet_set_endpoint_config(). Perhaps just combine them?
>
> But that brings up another point; can the rmnet "mode" or egress_dev
> change at runtime, after the rmnet child has been created? I forget if
> that was possible with your original patchset that used ioctls.
>
The original series with IOCTL was able to change it.
With the current netlink based configuration, we are using a fixed
config
of muxing and the egress dev is fixed for its lifetime. Practically,
these
should never change for a set of rmnet devices attached to a real dev.
I will remove LOCAL_LOGICAL_ENDPOINT since it is unused.
> Why not set the mux_id in rmnet_vnd_newlink()?
>
> Also, bigger problem. r->rmnet_devices[] is only 32 items in size.
> But mux_id (which is used as an index into rmnet_devices in a few
> places) can be up to 255 (RMNET_MAX_LOGICAL_EP).
>
> So if you try to create an rmnet for mux ID 32, you panic the kernel.
> See below my comments about rmnet_real_dev_info...
>
I'll fix this.
> I can't see anywhere that the egress/ingress data get set except for
> this function, so perhaps you could just skip these functions and
> (since you already have 'r' from above) set r-
>> [egress|ingress]_data_format directly?
>
Yes, till this is made configurable, this need not be set separately.
> This means that the first time you add an rmnet dev to a netdev, it'll
> create a structure that's quite large (at least 255 * 6, but more due
> to padding), when in most cases few of these items will be used. Most
> of the time you'd have only a couple PDNs active, but this will
> allocate memory for MAX_LOGICAL_EP of them, no?
>
> ipvlan uses a list to track the child devices attached to a physical
> device so that it doesn't have to allocate them all at once and waste
> memory; that technique could replace the 'rmnet_devices' member below.
>
> It also uses a hash to find the actual ipvlan upperdev from the
> rx_handler of the lowerdev, which is probably what would replace
> muxed_ep[] here.
>
> Is the relationship between rmnet "child"/upper devs and mux_ids 1:1?
> Or can you have multiple rmnet devs for the same mux_id?
>
> Dan
We can have multiple rmnet devices having the same mux_id. They will
need to be attached to different real_dev though. I'll look into the
creation of hash for the lookup. Once I have the hash up, I should
be able to get rid of some of the structures.
The other main functionality which I am unsure is the
bridge handling - passing on MAP data from one real_dev to another.
Is there some to achieve this using any existing netlink attributes?
Any suggestions would be appreciated.
> Please implement ndo_get_iflink as well, so that it's easy to find out
> what the "parent"/lowerdev for a given rmnet interface is.
>
> That might mean adding a "phy_dev" member to rmnet_priv, but that might
> help you clean up a lot of other stuff too
>
Sure, I'll implement this. Let me know if you have more comments.
^ permalink raw reply
* [PATCH net-next] hv_netvsc: Fix typos in the document of UDP hashing
From: Haiyang Zhang @ 2017-08-30 20:37 UTC (permalink / raw)
To: davem, netdev; +Cc: haiyangz, kys, olaf, vkuznets, linux-kernel
From: Haiyang Zhang <haiyangz@microsoft.com>
There are two typos in the document, netvsc.txt,
regarding UDP hashing level. This patch fixes them.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
Documentation/networking/netvsc.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/netvsc.txt b/Documentation/networking/netvsc.txt
index fa8d86356791..93560fb1170a 100644
--- a/Documentation/networking/netvsc.txt
+++ b/Documentation/networking/netvsc.txt
@@ -32,9 +32,9 @@ Features
hashing. Using L3 hashing is recommended in this case.
For example, for UDP over IPv4 on eth0:
- To include UDP port numbers in hasing:
+ To include UDP port numbers in hashing:
ethtool -N eth0 rx-flow-hash udp4 sdfn
- To exclude UDP port numbers in hasing:
+ To exclude UDP port numbers in hashing:
ethtool -N eth0 rx-flow-hash udp4 sd
To show UDP hash level:
ethtool -n eth0 rx-flow-hash udp4
--
2.14.1
^ permalink raw reply related
* (unknown),
From: anita.traylor @ 2017-08-30 20:26 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 61571.doc --]
[-- Type: application/msword, Size: 30930 bytes --]
^ permalink raw reply
* Re: [PATCH][net-next][V3] bpf: test_maps: fix typos, "conenct" and "listeen"
From: Daniel Borkmann @ 2017-08-30 20:24 UTC (permalink / raw)
To: shuah, Colin King, Alexei Starovoitov, netdev, linux-kselftest,
linux-kernel, Shuah Khan
In-Reply-To: <9863bea1-5325-edc8-ca46-46e2a738782c@kernel.org>
On 08/30/2017 10:13 PM, Shuah Khan wrote:
> On 08/30/2017 12:47 PM, Daniel Borkmann wrote:
>> On 08/30/2017 07:15 PM, Colin King wrote:
>>> From: Colin Ian King <colin.king@canonical.com>
>>>
>>> Trivial fix to typos in printf error messages:
>>> "conenct" -> "connect"
>>> "listeen" -> "listen"
>>>
>>> thanks to Daniel Borkmann for spotting one of these mistakes
>>>
>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>>
>> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>
> I can get this into 4.14-rc1 unless it should go through net-next
> for dependencies. In which case,
Yeah, it does depends on work sitting in net-next so easier
to go that route.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH][net-next][V3] bpf: test_maps: fix typos, "conenct" and "listeen"
From: Shuah Khan @ 2017-08-30 20:13 UTC (permalink / raw)
To: Daniel Borkmann, Colin King, Alexei Starovoitov, netdev,
linux-kselftest, linux-kernel, Shuah Khan
Cc: Shuah Khan
In-Reply-To: <59A70831.6080501@iogearbox.net>
On 08/30/2017 12:47 PM, Daniel Borkmann wrote:
> On 08/30/2017 07:15 PM, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> Trivial fix to typos in printf error messages:
>> "conenct" -> "connect"
>> "listeen" -> "listen"
>>
>> thanks to Daniel Borkmann for spotting one of these mistakes
>>
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>
>
I can get this into 4.14-rc1 unless it should go through net-next
for dependencies. In which case,
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
thanks,
-- Shuah
^ permalink raw reply
* DSA mv88e6xxx RX frame errors and TCP/IP RX failure
From: Tim Harvey @ 2017-08-30 19:53 UTC (permalink / raw)
To: netdev, Andrew Lunn, Vivien Didelot; +Cc: linux-kernel@vger.kernel.org
Greetings,
I'm seeing RX frame errors when using the mv88e6xxx DSA driver on
4.13-rc7. The board I'm using is a GW5904 [1] which has an IMX6 FEC
MAC (eth0) connected via RGMII to a MV88E6176 with its downstream
P0/P1/P2/P3 to front panel RJ45's (lan1-lan4).
What I see is the following:
- bring up eth0/lan1
- DHCP ipv4 on lan1
- iperf client to server on network connected to lan1 shows ~150mbps
TX without any errors/overruns/frame but 10 or so dropped
- iperf server with a 100mbps TCP client test shows
- iperf server will hang when connected to from iperf client on lan1
network and I see frame errors from ifconfig:
root@xenial:/# ifconfig lan1
lan1 Link encap:Ethernet HWaddr 00:D0:12:41:F3:E7
inet addr:172.24.22.125 Bcast:172.24.255.255 Mask:255.240.0.0
inet6 addr: fe80::2d0:12ff:fe41:f3e7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:148 errors:0 dropped:30 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8780 (8.5 KiB) TX bytes:1762 (1.7 KiB)
root@xenial:/# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:D0:12:41:F3:E7
inet6 addr: fe80::2d0:12ff:fe41:f3e7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:386 errors:19 dropped:39 overruns:0 frame:57
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:39484 (38.5 KiB) TX bytes:2880 (2.8 KiB)
It doesn't appear that this is a new issue as it exists on also on
older kernels.
Note that the IMX6 has an errata (ERR004512) [2] that limits the
theoretical max performance of the FEC to 470mbps (total TX+RX) and if
the TX and RK peak datarate is higher than ~400mps there is a risk of
ENET RX FIFO overrun but I don't think this is the issue here. It
would be the cause of the relatively low throughput of ~150 TX though
I would assume.
Best Regards,
Tim
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-gw5904.dtsi
[2] - http://cache.nxp.com/docs/en/errata/IMX6DQCE.pdf - ERR004512
^ permalink raw reply
* Re: [PATCH net] net: dsa: bcm_sf2: Fix number of CFP entries for BCM7278
From: Vivien Didelot @ 2017-08-30 19:45 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: davem, andrew, Florian Fainelli
In-Reply-To: <1504121973-8438-1-git-send-email-f.fainelli@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> writes:
> BCM7278 has only 128 entries while BCM7445 has the full 256 entries set,
> fix that.
>
> Fixes: 7318166cacad ("net: dsa: bcm_sf2: Add support for ethtool::rxnfc")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* [PATCH net] net: dsa: bcm_sf2: Fix number of CFP entries for BCM7278
From: Florian Fainelli @ 2017-08-30 19:39 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
BCM7278 has only 128 entries while BCM7445 has the full 256 entries set,
fix that.
Fixes: 7318166cacad ("net: dsa: bcm_sf2: Add support for ethtool::rxnfc")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 4 ++++
drivers/net/dsa/bcm_sf2.h | 1 +
drivers/net/dsa/bcm_sf2_cfp.c | 8 ++++----
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 00416e9f0196..eb220c8327b5 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1043,6 +1043,7 @@ struct bcm_sf2_of_data {
u32 type;
const u16 *reg_offsets;
unsigned int core_reg_align;
+ unsigned int num_cfp_rules;
};
/* Register offsets for the SWITCH_REG_* block */
@@ -1066,6 +1067,7 @@ struct bcm_sf2_of_data {
.type = BCM7445_DEVICE_ID,
.core_reg_align = 0,
.reg_offsets = bcm_sf2_7445_reg_offsets,
+ .num_cfp_rules = 256,
};
static const u16 bcm_sf2_7278_reg_offsets[] = {
@@ -1088,6 +1090,7 @@ struct bcm_sf2_of_data {
.type = BCM7278_DEVICE_ID,
.core_reg_align = 1,
.reg_offsets = bcm_sf2_7278_reg_offsets,
+ .num_cfp_rules = 128,
};
static const struct of_device_id bcm_sf2_of_match[] = {
@@ -1144,6 +1147,7 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
priv->type = data->type;
priv->reg_offsets = data->reg_offsets;
priv->core_reg_align = data->core_reg_align;
+ priv->num_cfp_rules = data->num_cfp_rules;
/* Auto-detection using standard registers will not work, so
* provide an indication of what kind of device we are for
diff --git a/drivers/net/dsa/bcm_sf2.h b/drivers/net/dsa/bcm_sf2.h
index d9c96b281fc0..02c499f9c56b 100644
--- a/drivers/net/dsa/bcm_sf2.h
+++ b/drivers/net/dsa/bcm_sf2.h
@@ -72,6 +72,7 @@ struct bcm_sf2_priv {
u32 type;
const u16 *reg_offsets;
unsigned int core_reg_align;
+ unsigned int num_cfp_rules;
/* spinlock protecting access to the indirect registers */
spinlock_t indir_lock;
diff --git a/drivers/net/dsa/bcm_sf2_cfp.c b/drivers/net/dsa/bcm_sf2_cfp.c
index 2fb32d67065f..8a1da7e67707 100644
--- a/drivers/net/dsa/bcm_sf2_cfp.c
+++ b/drivers/net/dsa/bcm_sf2_cfp.c
@@ -98,7 +98,7 @@ static inline void bcm_sf2_cfp_rule_addr_set(struct bcm_sf2_priv *priv,
{
u32 reg;
- WARN_ON(addr >= CFP_NUM_RULES);
+ WARN_ON(addr >= priv->num_cfp_rules);
reg = core_readl(priv, CORE_CFP_ACC);
reg &= ~(XCESS_ADDR_MASK << XCESS_ADDR_SHIFT);
@@ -109,7 +109,7 @@ static inline void bcm_sf2_cfp_rule_addr_set(struct bcm_sf2_priv *priv,
static inline unsigned int bcm_sf2_cfp_rule_size(struct bcm_sf2_priv *priv)
{
/* Entry #0 is reserved */
- return CFP_NUM_RULES - 1;
+ return priv->num_cfp_rules - 1;
}
static int bcm_sf2_cfp_rule_set(struct dsa_switch *ds, int port,
@@ -523,7 +523,7 @@ static int bcm_sf2_cfp_rule_get_all(struct bcm_sf2_priv *priv,
if (!(reg & OP_STR_DONE))
break;
- } while (index < CFP_NUM_RULES);
+ } while (index < priv->num_cfp_rules);
/* Put the TCAM size here */
nfc->data = bcm_sf2_cfp_rule_size(priv);
@@ -544,7 +544,7 @@ int bcm_sf2_get_rxnfc(struct dsa_switch *ds, int port,
case ETHTOOL_GRXCLSRLCNT:
/* Subtract the default, unusable rule */
nfc->rule_cnt = bitmap_weight(priv->cfp.used,
- CFP_NUM_RULES) - 1;
+ priv->num_cfp_rules) - 1;
/* We support specifying rule locations */
nfc->data |= RX_CLS_LOC_SPECIAL;
break;
--
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