* [PATCH v2 net-next 0/2] Fix TX Timeout and implement Safety Features
From: Jose Abreu @ 2018-03-29 9:40 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, David S. Miller, Joao Pinto, Giuseppe Cavallaro,
Alexandre Torgue, Andrew Lunn
Fix the TX Timeout handler to correctly reconfigure the whole system and
start implementing features for DWMAC5 cores, specifically the Safety
Features.
Changes since v1:
- Display error stats in ethtool
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Jose Abreu (2):
net: stmmac: Rework and fix TX Timeout code
net: stmmac: Add support for DWMAC5 and implement Safety Features
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
drivers/net/ethernet/stmicro/stmmac/common.h | 22 ++
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 4 +
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 39 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 6 +
drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 298 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac5.h | 52 ++++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 12 +
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 39 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 101 ++++++-
10 files changed, 567 insertions(+), 8 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5.c
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5.h
--
2.9.3
^ permalink raw reply
* [PATCH] net: mvneta: remove duplicate *_coal assignment
From: Jisheng Zhang @ 2018-03-29 9:29 UTC (permalink / raw)
To: Thomas Petazzoni, David Miller; +Cc: netdev, linux-kernel, linux-arm-kernel
The style of the rx/tx queue's *_coal member assignment is:
static void foo_coal_set(...)
{
set the coal in hw;
update queue's foo_coal member; [1]
}
In other place, we call foo_coal_set(pp, queue->foo_coal), so the above [1]
is duplicated and could be removed.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
drivers/net/ethernet/marvell/mvneta.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index eaa4bb80f1c9..30aab9bf77cc 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1555,7 +1555,6 @@ static void mvneta_rx_pkts_coal_set(struct mvneta_port *pp,
{
mvreg_write(pp, MVNETA_RXQ_THRESHOLD_REG(rxq->id),
value | MVNETA_RXQ_NON_OCCUPIED(0));
- rxq->pkts_coal = value;
}
/* Set the time delay in usec before RX interrupt will be generated by
@@ -1571,7 +1570,6 @@ static void mvneta_rx_time_coal_set(struct mvneta_port *pp,
val = (clk_rate / 1000000) * value;
mvreg_write(pp, MVNETA_RXQ_TIME_COAL_REG(rxq->id), val);
- rxq->time_coal = value;
}
/* Set threshold for TX_DONE pkts coalescing */
@@ -1586,8 +1584,6 @@ static void mvneta_tx_done_pkts_coal_set(struct mvneta_port *pp,
val |= MVNETA_TXQ_SENT_THRESH_MASK(value);
mvreg_write(pp, MVNETA_TXQ_SIZE_REG(txq->id), val);
-
- txq->done_pkts_coal = value;
}
/* Handle rx descriptor fill by setting buf_cookie and buf_phys_addr */
--
2.16.3
^ permalink raw reply related
* Re: RFC on writel and writel_relaxed
From: Will Deacon @ 2018-03-29 9:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nicholas Piggin, David Miller, paulmck, arnd, linux-rdma,
linuxppc-dev, linus971, alexander.duyck, okaya, jgg, David.Laight,
oohall, netdev, alexander.h.duyck, torvalds
In-Reply-To: <1522272692.21446.42.camel@kernel.crashing.org>
On Thu, Mar 29, 2018 at 08:31:32AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-29 at 02:23 +1000, Nicholas Piggin wrote:
> > This is a variation on the mandatory write barrier that causes writes to weakly
> > ordered I/O regions to be partially ordered. Its effects may go beyond the
> > CPU->Hardware interface and actually affect the hardware at some level.
> >
> > How can a driver writer possibly get that right?
> >
> > IIRC it was added for some big ia64 system that was really expensive
> > to implement the proper wmb() semantics on. So wmb() semantics were
> > quietly downgraded, then the subsequently broken drivers they cared
> > about were fixed by adding the stronger mmiowb().
> >
> > What should have happened was wmb and writel remained correct, sane, and
> > expensive, and they add an mmio_wmb() to order MMIO stores made by the
> > writel_relaxed accessors, then use that to speed up the few drivers they
> > care about.
> >
> > Now that ia64 doesn't matter too much, can we deprecate mmiowb and just
> > make wmb ordering talk about stores to the device, not to some
> > intermediate stage of the interconnect where it can be subsequently
> > reordered wrt the device? Drivers can be converted back to using wmb
> > or writel gradually.
>
> I was under the impression that mmiowb was specifically about ordering
> writel's with a subsequent spin_unlock, without it, MMIOs from
> different CPUs (within the same lock) would still arrive OO.
>
> If that's indeed the case, I would suggest ia64 switches to a similar
> per-cpu flag trick powerpc uses.
... or we could remove ia64.
/me runs for cover
Will
^ permalink raw reply
* RE: [PATCH v7 3/7] bnx2x: Replace doorbell barrier() with wmb()
From: Elior, Ariel @ 2018-03-29 9:17 UTC (permalink / raw)
To: Sinan Kaya, netdev@vger.kernel.org, timur@codeaurora.org,
sulrich@codeaurora.org
Cc: linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Dept-Eng Everest Linux L2,
linux-kernel@vger.kernel.org
In-Reply-To: <1521988761-30344-4-git-send-email-okaya@codeaurora.org>
> Subject: [PATCH v7 3/7] bnx2x: Replace doorbell barrier() with wmb()
>
> barrier() doesn't guarantee memory writes to be observed by the hardware on
> all architectures. barrier() only tells compiler not to move this code
> with respect to other read/writes.
>
> If memory write needs to be observed by the HW, wmb() is the right choice.
The wmb() is there (a couple of lines above). Your modification adds an
unnecessary fence which would hurt high pps scenarios. The memory
writes which the HW needs to observe are the buffer descriptors, not the
producer update message. The producer is written to the HW, and exists
on the stack. The barrier() is there to prevent the compiler from mixing the
order of the prod update message preparation and writing it to the host.
A possible alternative would be to move the existing wmb() to where
the barrier() is, achieving both goals, although in the existing design each
barrier has a distinct purpose. The comment location is misleading, though.
Thanks,
Ariel
^ permalink raw reply
* Re: ath: Remove unnecessary ath_bcast_mac and use eth_broadcast_addr
From: Kalle Valo @ 2018-03-29 9:11 UTC (permalink / raw)
To: Joe Perches
Cc: Luis R. Rodriguez, Jiri Slaby, Nick Kossifidis,
QCA ath9k Development, linux-wireless, netdev, linux-kernel
In-Reply-To: <3ed8112986ba6f538cb45df6ea67e0c027a3dc12.1521628278.git.joe@perches.com>
Joe Perches <joe@perches.com> wrote:
> Remove the static array and use the generic routine to set the
> Ethernet broadcast address.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
a72c92629108 ath: Remove unnecessary ath_bcast_mac and use eth_broadcast_addr
--
https://patchwork.kernel.org/patch/10299129/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH v2 net-next 2/2] Documentation: ip-sysctl.txt: clarify disable_ipv6
From: Lorenzo Bianconi @ 2018-03-29 9:02 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <cover.1522312507.git.lorenzo.bianconi@redhat.com>
Clarify that when disable_ipv6 is enabled even the ipv6 routes
are deleted for the selected interface and from now it will not
be possible to add addresses/routes to that interface
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
---
Documentation/networking/ip-sysctl.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 1d1120753ae8..33f35f049ad5 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1703,7 +1703,9 @@ disable_ipv6 - BOOLEAN
interface and start Duplicate Address Detection, if necessary.
When this value is changed from 0 to 1 (IPv6 is being disabled),
- it will dynamically delete all address on the given interface.
+ it will dynamically delete all addresses and routes on the given
+ interface. From now on it will not possible to add addresses/routes
+ to the selected interface.
accept_dad - INTEGER
Whether to accept DAD (Duplicate Address Detection).
--
2.14.3
^ permalink raw reply related
* [PATCH v2 net-next 1/2] ipv6: do not set routes if disable_ipv6 has been enabled
From: Lorenzo Bianconi @ 2018-03-29 9:02 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <cover.1522312507.git.lorenzo.bianconi@redhat.com>
Do not allow setting ipv6 routes from userspace if disable_ipv6 has been
enabled. The issue can be triggered using the following reproducer:
- sysctl net.ipv6.conf.all.disable_ipv6=1
- ip -6 route add a:b:c:d::/64 dev em1
- ip -6 route show
a:b:c:d::/64 dev em1 metric 1024 pref medium
Fix it checking disable_ipv6 value in ip6_route_info_create routine
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
---
net/ipv6/route.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index ba8d5df50ebe..e461ef1158b6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2917,6 +2917,12 @@ static struct rt6_info *ip6_route_info_create(struct fib6_config *cfg,
if (!dev)
goto out;
+ if (idev->cnf.disable_ipv6) {
+ NL_SET_ERR_MSG(extack, "IPv6 is disabled on nexthop device");
+ err = -EACCES;
+ goto out;
+ }
+
if (!(dev->flags & IFF_UP)) {
NL_SET_ERR_MSG(extack, "Nexthop device is not up");
err = -ENETDOWN;
--
2.14.3
^ permalink raw reply related
* [PATCH v2 net-next 0/2] do not allow adding routes if disable_ipv6 is enabled
From: Lorenzo Bianconi @ 2018-03-29 9:02 UTC (permalink / raw)
To: davem; +Cc: netdev
Do not allow userspace to add static ipv6 routes if disable_ipv6 is enabled.
Update disable_ipv6 documentation according to that change
Changes since v1:
- added an extack message telling the user that IPv6 is disabled on the nexthop
device
- rebased on-top of net-next
Lorenzo Bianconi (2):
ipv6: do not set routes if disable_ipv6 has been enabled
Documentation: ip-sysctl.txt: clarify disable_ipv6
Documentation/networking/ip-sysctl.txt | 4 +++-
net/ipv6/route.c | 6 ++++++
2 files changed, 9 insertions(+), 1 deletion(-)
--
2.14.3
^ permalink raw reply
* Re: [RFC PATCH ghak32 V2 01/13] audit: add container id
From: Richard Guy Briggs @ 2018-03-29 9:01 UTC (permalink / raw)
To: Jonathan Corbet
Cc: ebiederm-aS9lmoZGLiVWk0Htik3J/w, simo-H+wXaHxf7aLQT0dZR+AlfA,
jlayton-H+wXaHxf7aLQT0dZR+AlfA, carlos-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
eparis-FjpueFixGhCM4zKIHC2jIg, dhowells-H+wXaHxf7aLQT0dZR+AlfA,
madzcar-Re5JQEeQqe8AvxtiuMwx3w, Linux-Audit Mailing List,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
luto-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180328123912.49b11c98-T1hC0tSOHrs@public.gmane.org>
On 2018-03-28 12:39, Jonathan Corbet wrote:
> On Fri, 16 Mar 2018 05:00:28 -0400
> Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > Implement the proc fs write to set the audit container ID of a process,
> > emitting an AUDIT_CONTAINER record to document the event.
>
> A little detail, but still...
I am understanding that you would prefer more context (as opposed to
operational detail) in the description, laying out the use case for this
patch(set)?
> > +static int audit_set_containerid_perm(struct task_struct *task, u64 containerid)
> > +{
> > + struct task_struct *parent;
> > + u64 pcontainerid, ccontainerid;
> > +
> > + /* Don't allow to set our own containerid */
> > + if (current == task)
> > + return -EPERM;
> > + /* Don't allow the containerid to be unset */
> > + if (!cid_valid(containerid))
> > + return -EINVAL;
>
> I went looking for cid_valid(), but it turns out you don't add it until
> patch 5. That, I expect, will not be good for bisectability (or patch
> review).
Nice catch, thanks Jon. That is very likely another victim of a git
rebase to re-order afterthoughts in the right place. I'll need to be
more careful of that class of bug, rethink my workflow, or script builds
to verify each commit is compilable.
> Thanks,
>
> jon
- RGB
--
Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH 07/30] aio: add delayed cancel support
From: Christoph Hellwig @ 2018-03-29 8:53 UTC (permalink / raw)
To: Al Viro
Cc: Christoph Hellwig, Avi Kivity, linux-aio, linux-fsdevel, netdev,
linux-api, linux-kernel
In-Reply-To: <20180328163526.GV30522@ZenIV.linux.org.uk>
On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> > ret = vfs_fsync(req->file, req->datasync);
> > - fput(req->file);
> > - aio_complete(container_of(req, struct aio_kiocb, fsync), ret, 0);
> > + if (aio_complete(iocb, ret, 0, 0))
> > + fput(file);
>
> IDGI.
> 1) can aio_complete() ever return false here?
It won't. But sometimes checking the return value and sometimes not
seems like a bad pattern.
> 2) do we ever have aio_kiocb that would not have an associated
> struct file * that needs to be dropped on successful aio_complete()? AFAICS,
> rw, fsync and poll variants all have one, and I'm not sure what kind of
> async IO *could* be done without an opened file.
All have a file assoiated at least right now. As mentioned last time
finding a struct to pass that file would be rather annoying, so we'd either
have to pass it explicitly, or do something nasty like duplicating the
pointer in the aio_kiocb in addition to struct kiocb. Which might not
be that bad after all, as it would only bloat the aio_kiocb and not
struct kiocb used on stack all over.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: Allow FIB notifiers to fail add and replace
From: Ido Schimmel @ 2018-03-29 8:29 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-1-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:54PM -0700, David Ahern wrote:
> I wanted to revisit how resource overload is handled for hardware offload
> of FIB entries and rules. At the moment, the in-kernel fib notifier can
> tell a driver about a route or rule add, replace, and delete, but the
> notifier can not affect the action. Specifically, in the case of mlxsw
> if a route or rule add is going to overflow the ASIC resources the only
> recourse is to abort hardware offload. Aborting offload is akin to taking
> down the switch as the path from data plane to the control plane simply
> can not support the traffic bandwidth of the front panel ports. Further,
> the current state of FIB notifiers is inconsistent with other resources
> where a driver can affect a user request - e.g., enslavement of a port
> into a bridge or a VRF.
>
> As a result of the work done over the past 3+ years, I believe we are
> at a point where we can bring consistency to the stack and offloads,
> and reliably allow the FIB notifiers to fail a request, pushing an error
> along with a suitable error message back to the user. Rather than
> aborting offload when the switch is out of resources, userspace is simply
> prevented from adding more routes and has a clear indication of why.
Nice work, David. Ran various tests and didn't see any regressions.
I know you already know this, but for the record, we plan to add
accounting to KVD hash resources which will eventually allow us to
return errors when resources are exceeded.
^ permalink raw reply
* Re: [PATCH net-next 5/6] net/ipv6: Move call_fib6_entry_notifiers up for route adds
From: Ido Schimmel @ 2018-03-29 8:23 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-6-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:59PM -0700, David Ahern wrote:
> Move call to call_fib6_entry_notifiers for new IPv6 routes to right
> before the insertion into the FIB. At this point notifier handlers can
> decide the fate of the new route with a clean path to delete the
> potential new entry if the notifier returns non-0.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 4/6] net/ipv4: Allow notifier to fail route replace
From: Ido Schimmel @ 2018-03-29 8:23 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-5-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:58PM -0700, David Ahern wrote:
> Add checking to call to call_fib_entry_notifiers for IPv4 route replace.
> Allows a notifier handler to fail the replace.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 3/6] net/ipv4: Move call_fib_entry_notifiers up for new routes
From: Ido Schimmel @ 2018-03-29 8:22 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-4-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:57PM -0700, David Ahern wrote:
> Move call to call_fib_entry_notifiers for new IPv4 routes to right
> before the call to fib_insert_alias. At this point the only remaining
> failure path is memory allocations in fib_insert_node. Handle that
> very unlikely failure with a call to call_fib_entry_notifiers to
> tell drivers about it.
>
> At this point notifier handlers can decide the fate of the new route
> with a clean path to delete the potential new entry if the notifier
> returns non-0.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 2/6] net: Move call_fib_rule_notifiers up in fib_nl_newrule
From: Ido Schimmel @ 2018-03-29 8:22 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-3-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:56PM -0700, David Ahern wrote:
> Move call_fib_rule_notifiers up in fib_nl_newrule to the point right
> before the rule is inserted into the list. At this point there are no
> more failure paths within the core rule code, so if the notifier
> does not fail then the rule will be inserted into the list.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
BTW, this means we can now return an error from mlxsw instead of only
emitting an extack warning when an unsupported FIB rule is configured.
Will add that.
^ permalink raw reply
* Re: [PATCH net-next 2/6] net: Move call_fib_rule_notifiers up in fib_nl_newrule
From: Ido Schimmel @ 2018-03-29 8:20 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-3-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:56PM -0700, David Ahern wrote:
> Move call_fib_rule_notifiers up in fib_nl_newrule to the point right
> before the rule is inserted into the list. At this point there are no
> more failure paths within the core rule code, so if the notifier
> does not fail then the rule will be inserted into the list.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: Fix fib notifer to return errno
From: Ido Schimmel @ 2018-03-29 8:19 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-2-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:55PM -0700, David Ahern wrote:
> Notifier handlers use notifier_from_errno to convert any potential error
> to an encoded format. As a consequence the other side, call_fib_notifier{s}
> in this case, needs to use notifier_to_errno to return the error from
> the handler back to its caller.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 1/2] ipv6: do not set routes if disable_ipv6 has been enabled
From: Lorenzo Bianconi @ 2018-03-29 8:19 UTC (permalink / raw)
To: David Ahern; +Cc: davem, netdev
In-Reply-To: <d7815ad8-c1a2-9444-deb9-b3a9c8fb3b50@gmail.com>
> On 3/27/18 11:11 AM, Lorenzo Bianconi wrote:
> > Do not allow to set ipv6 routes from userspace if disable_ipv6 has been
> > enabled. The issue can be triggered using the following reproducer:
> >
> > - sysctl net.ipv6.conf.all.disable_ipv6=1
> > - ip -6 route add a:b:c:d::/64 dev em1
> > - ip -6 route show
> > a:b:c:d::/64 dev em1 metric 1024 pref medium
> >
> > Fix it checking disable_ipv6 value in ip6_route_info_create routine
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> > ---
> > net/ipv6/route.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> > index 1d0eaa69874d..672fd7fdb037 100644
> > --- a/net/ipv6/route.c
> > +++ b/net/ipv6/route.c
> > @@ -2917,6 +2917,11 @@ static struct rt6_info *ip6_route_info_create(struct fib6_config *cfg,
> > if (!dev)
> > goto out;
> >
> > + if (idev->cnf.disable_ipv6) {
> > + err = -EACCES;
>
> you need an extack message telling the user that IPv6 is disabled on the
> nexthop device.
>
Ack, will do in v2.
Regards,
Lorenzo
> > + goto out;
> > + }
> > +
> > if (!(dev->flags & IFF_UP)) {
> > NL_SET_ERR_MSG(extack, "Nexthop device is not up");
> > err = -ENETDOWN;
> >
>
^ permalink raw reply
* Re: [PATCH net V2] vhost: correctly remove wait queue during poll failure
From: Jason Wang @ 2018-03-29 8:01 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, Darren Kenny
In-Reply-To: <20180329071801-mutt-send-email-mst@kernel.org>
On 2018年03月29日 12:20, Michael S. Tsirkin wrote:
> On Tue, Mar 27, 2018 at 08:50:52PM +0800, Jason Wang wrote:
>> We tried to remove vq poll from wait queue, but do not check whether
>> or not it was in a list before. This will lead double free. Fixing
>> this by switching to use vhost_poll_stop() which zeros poll->wqh after
>> removing poll from waitqueue to make sure it won't be freed twice.
>>
>> Cc: Darren Kenny<darren.kenny@oracle.com>
>> Reported-by:syzbot+c0272972b01b872e604a@syzkaller.appspotmail.com
>> Fixes: 2b8b328b61c79 ("vhost_net: handle polling errors when setting backend")
>> Signed-off-by: Jason Wang<jasowang@redhat.com>
> OK with this the only bug we have is where get user pages returns 0
> (Reported-by:syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com)
>
>
>
Thanks for the reminder.
I post a patch to avoid this.
^ permalink raw reply
* [PATCH net] vhost: validate log when IOTLB is enabled
From: Jason Wang @ 2018-03-29 8:00 UTC (permalink / raw)
To: mst, jasowang; +Cc: netdev, linux-kernel, kvm, virtualization
Vq log_base is the userspace address of bitmap which has nothing to do
with IOTLB. So it needs to be validated unconditionally otherwise we
may try use 0 as log_base which may lead to pin pages that will lead
unexpected result (e.g trigger BUG_ON() in set_bit_to_user()).
Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
Reported-by: syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vhost.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 5d5a9d9..5320039 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1244,14 +1244,12 @@ static int vq_log_access_ok(struct vhost_virtqueue *vq,
/* Caller should have vq mutex and device mutex */
int vhost_vq_access_ok(struct vhost_virtqueue *vq)
{
- if (vq->iotlb) {
- /* When device IOTLB was used, the access validation
- * will be validated during prefetching.
- */
- return 1;
- }
- return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used) &&
- vq_log_access_ok(vq, vq->log_base);
+ int ret = vq_log_access_ok(vq, vq->log_base);
+
+ if (ret || vq->iotlb)
+ return ret;
+
+ return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used);
}
EXPORT_SYMBOL_GPL(vhost_vq_access_ok);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610
From: Kalle Valo @ 2018-03-29 7:45 UTC (permalink / raw)
To: Ramon Fried
Cc: loic.poulain, wcn36xx, linux-wireless, netdev, linux-kernel,
devicetree, bjorn.andersson
In-Reply-To: <2d978343-2057-8424-a249-83a0394da5a7@codeaurora.org>
(really adding Bjorn)
Ramon Fried <rfried@codeaurora.org> writes:
> (adding Bjorn Andersson)
>
>
> On 3/29/2018 10:15 AM, Kalle Valo wrote:
>> (adding devicetree list)
>>
>> Ramon Fried <rfried@codeaurora.org> writes:
>>
>>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>>> If wcn36xx digital block is associated with an external IRIS
>>> RF module, retrieve the id and disable 5GHz band in case of
>>> wcn3610 id.
>>>
>>> Signed-off-by: Ramon Fried <rfried@codeaurora.org>
>>> ---
>>> v2: fixed wrong assignment, which is logically introduces the
>>> same behaviour, but for correctness.
>>>
>>> drivers/net/wireless/ath/wcn36xx/main.c | 4 +++-
>>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
>>> index ab5be6d2c691..833531a68c95 100644
>>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>>> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>>> BIT(NL80211_IFTYPE_MESH_POINT);
>>>
>>> wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = &wcn_band_2ghz;
>>> - if (wcn->rf_id != RF_IRIS_WCN3620)
>>> + if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>>> wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = &wcn_band_5ghz;
>>>
>>> wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
>>> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct wcn36xx *wcn,
>>> if (iris_node) {
>>> if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>>> wcn->rf_id = RF_IRIS_WCN3620;
>>> + else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
>>> + wcn->rf_id = RF_IRIS_WCN3610;
>>> of_node_put(iris_node);
>>> }
>> Should we document qcom,wcn3610 just like wcn3620 is:
>>
>> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt:
>> "qcom,wcn3620",
>
> IMHO the mentioned bindings is related to the PIL (peripheral image
> loaded) which is just the firmware part and has
> nothing to do with wifi frontend(IRIS).
Should we then have a bindings document for wcn36xx or is it ok to use
compatible strings like this without any docs? I'm not very familiar
with the devicetree stuff.
--
Kalle Valo
^ permalink raw reply
* Re: [EXT] [PATCH net-next v2 0/2] phylink: API changes
From: Russell King - ARM Linux @ 2018-03-29 7:44 UTC (permalink / raw)
To: Yan Markman
Cc: Florian Fainelli, netdev@vger.kernel.org, Thomas Petazzoni,
Andrew Lunn, David S. Miller, open list, Antoine Tenart,
Stefan Chulski, Maxime Chevallier, Miquel Raynal, Marcin Wojtas,
Yelena Krivosheev
In-Reply-To: <98b31575864f474fa7177c39ff06f81b@IL-EXCH01.marvell.com>
On Thu, Mar 29, 2018 at 05:58:43AM +0000, Yan Markman wrote:
> Hi Florian
> Please keep CC Yelena Krivosheev <yelena@marvell.com>
> for changes with drivers/net/ethernet/marvell/mvneta.c
> Thanks
We have a way to ensure such things happen - it's the MAINTAINERS
file. Please use the established community methods rather than
sending emails asking for people to remember such quirks. Thanks.
> Yan Markman
> Tel. 05-44732819
>
>
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> Sent: Thursday, March 29, 2018 1:44 AM
> To: netdev@vger.kernel.org
> Cc: Florian Fainelli <f.fainelli@gmail.com>; Thomas Petazzoni <thomas.petazzoni@free-electrons.com>; Andrew Lunn <andrew@lunn.ch>; David S. Miller <davem@davemloft.net>; Russell King <rmk+kernel@armlinux.org.uk>; open list <linux-kernel@vger.kernel.org>; Antoine Tenart <antoine.tenart@bootlin.com>; Yan Markman <ymarkman@marvell.com>; Stefan Chulski <stefanc@marvell.com>; Maxime Chevallier <maxime.chevallier@bootlin.com>; Miquel Raynal <miquel.raynal@free-electrons.com>; Marcin Wojtas <mw@semihalf.com>
> Subject: [EXT] [PATCH net-next v2 0/2] phylink: API changes
>
> External Email
>
> ----------------------------------------------------------------------
> Hi all,
>
> This patch series contains two API changes to PHYLINK which will later be used by DSA to migrate to PHYLINK. Because these are API changes that impact other outstanding work (e.g: MVPP2) I would rather get them included sooner to minimize conflicts.
>
> Thank you!
>
> Changes in v2:
>
> - added missing documentation to mac_link_{up,down} that the interface
> must be configured in mac_config()
>
> - added Russell's, Andrew's and my tags
>
> Florian Fainelli (1):
> net: phy: phylink: Provide PHY interface to mac_link_{up,down}
>
> Russell King (1):
> sfp/phylink: move module EEPROM ethtool access into netdev core
> ethtool
>
> drivers/net/ethernet/marvell/mvneta.c | 22 +++-------------------
> drivers/net/phy/phylink.c | 32 +++-----------------------------
> drivers/net/phy/sfp-bus.c | 6 ++----
> include/linux/netdevice.h | 3 +++
> include/linux/phylink.h | 17 +++++++++++------
> net/core/ethtool.c | 7 +++++++
> 6 files changed, 29 insertions(+), 58 deletions(-)
>
> --
> 2.14.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: systemport: Fix coalescing settings handling
From: Tal Gilboa @ 2018-03-29 7:42 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: davem, jaedon.shin, pgynther, opendmb, Michael Chan, gospo,
saeedm
In-Reply-To: <20180328221538.29290-3-f.fainelli@gmail.com>
On 3/29/2018 1:15 AM, Florian Fainelli wrote:
> There were a number of issues with setting the RX coalescing parameters:
>
> - we would not be preserving values that would have been configured
> across close/open calls, instead we would always reset to no timeout
> and 1 interrupt per packet, this would also prevent DIM from setting its
> default usec/pkts values
>
> - when adaptive RX would be turned on, we woud not be fetching the
> default parameters, we would stay with no timeout/1 packet per
> interrupt until the estimator kicks in and changes that
>
> - finally disabling adaptive RX coalescing while providing parameters
> would not be honored, and we would stay with whatever DIM had
> previously determined instead of the user requested parameters
>
> Fixes: b6e0e875421e ("net: systemport: Implement adaptive interrupt coalescing")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/ethernet/broadcom/bcmsysport.c | 62 +++++++++++++++++++++---------
> drivers/net/ethernet/broadcom/bcmsysport.h | 4 +-
> 2 files changed, 46 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
> index 1e52bb7d822e..4a75b1de22e0 100644
> --- a/drivers/net/ethernet/broadcom/bcmsysport.c
> +++ b/drivers/net/ethernet/broadcom/bcmsysport.c
> @@ -574,16 +574,16 @@ static int bcm_sysport_set_wol(struct net_device *dev,
> return 0;
> }
>
> -static void bcm_sysport_set_rx_coalesce(struct bcm_sysport_priv *priv)
> +static void bcm_sysport_set_rx_coalesce(struct bcm_sysport_priv *priv,
> + u32 usecs, u32 pkts)
> {
> u32 reg;
>
> reg = rdma_readl(priv, RDMA_MBDONE_INTR);
> reg &= ~(RDMA_INTR_THRESH_MASK |
> RDMA_TIMEOUT_MASK << RDMA_TIMEOUT_SHIFT);
> - reg |= priv->dim.coal_pkts;
> - reg |= DIV_ROUND_UP(priv->dim.coal_usecs * 1000, 8192) <<
> - RDMA_TIMEOUT_SHIFT;
> + reg |= pkts;
> + reg |= DIV_ROUND_UP(usecs * 1000, 8192) << RDMA_TIMEOUT_SHIFT;
> rdma_writel(priv, reg, RDMA_MBDONE_INTR);
> }
>
> @@ -626,6 +626,8 @@ static int bcm_sysport_set_coalesce(struct net_device *dev,
> struct ethtool_coalesce *ec)
> {
> struct bcm_sysport_priv *priv = netdev_priv(dev);
> + struct net_dim_cq_moder moder;
> + u32 usecs, pkts;
> unsigned int i;
>
> /* Base system clock is 125Mhz, DMA timeout is this reference clock
> @@ -646,15 +648,21 @@ static int bcm_sysport_set_coalesce(struct net_device *dev,
> for (i = 0; i < dev->num_tx_queues; i++)
> bcm_sysport_set_tx_coalesce(&priv->tx_rings[i], ec);
>
> - priv->dim.coal_usecs = ec->rx_coalesce_usecs;
> - priv->dim.coal_pkts = ec->rx_max_coalesced_frames;
> + priv->rx_coalesce_usecs = ec->rx_coalesce_usecs;
> + priv->rx_max_coalesced_frames = ec->rx_max_coalesced_frames;
> + usecs = priv->rx_coalesce_usecs;
> + pkts = priv->rx_max_coalesced_frames;
>
> - if (!ec->use_adaptive_rx_coalesce && priv->dim.use_dim) {
> - priv->dim.coal_pkts = 1;
> - priv->dim.coal_usecs = 0;
> + if (ec->use_adaptive_rx_coalesce && !priv->dim.use_dim) {
> + moder = net_dim_get_def_profile(priv->dim.dim.mode);
> + usecs = moder.usec;
> + pkts = moder.pkts;
> }
> +
> priv->dim.use_dim = ec->use_adaptive_rx_coalesce;
> - bcm_sysport_set_rx_coalesce(priv);
> +
> + /* Apply desired coalescing parameters */
> + bcm_sysport_set_rx_coalesce(priv, usecs, pkts);
>
> return 0;
> }
> @@ -1058,10 +1066,7 @@ static void bcm_sysport_dim_work(struct work_struct *work)
> struct net_dim_cq_moder cur_profile =
> net_dim_get_profile(dim->mode, dim->profile_ix);
>
> - priv->dim.coal_usecs = cur_profile.usec;
> - priv->dim.coal_pkts = cur_profile.pkts;
> -
> - bcm_sysport_set_rx_coalesce(priv);
> + bcm_sysport_set_rx_coalesce(priv, cur_profile.usec, cur_profile.pkts);
> dim->state = NET_DIM_START_MEASURE;
> }
>
> @@ -1408,9 +1413,11 @@ static void bcm_sysport_adj_link(struct net_device *dev)
> phy_print_status(phydev);
> }
>
> -static void bcm_sysport_init_dim(struct bcm_sysport_net_dim *dim,
> +static void bcm_sysport_init_dim(struct bcm_sysport_priv *priv,
> void (*cb)(struct work_struct *work))
> {
> + struct bcm_sysport_net_dim *dim = &priv->dim;
> +
> INIT_WORK(&dim->dim.work, cb);
> dim->dim.mode = NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE;
> dim->event_ctr = 0;
> @@ -1418,6 +1425,25 @@ static void bcm_sysport_init_dim(struct bcm_sysport_net_dim *dim,
> dim->bytes = 0;
> }
>
> +static void bcm_sysport_init_rx_coalesce(struct bcm_sysport_priv *priv)
> +{
> + struct bcm_sysport_net_dim *dim = &priv->dim;
> + struct net_dim_cq_moder moder;
> + u32 usecs, pkts;
> +
> + usecs = priv->rx_coalesce_usecs;
> + pkts = priv->rx_max_coalesced_frames;
> +
> + /* If DIM was enabled, re-apply default parameters */
> + if (dim->use_dim) {
> + moder = net_dim_get_def_profile(dim->dim.mode);
> + usecs = moder.usec;
> + pkts = moder.pkts;
> + }
> +
> + bcm_sysport_set_rx_coalesce(priv, usecs, pkts);
> +}
> +
> static int bcm_sysport_init_tx_ring(struct bcm_sysport_priv *priv,
> unsigned int index)
> {
> @@ -1658,8 +1684,6 @@ static int bcm_sysport_init_rx_ring(struct bcm_sysport_priv *priv)
> rdma_writel(priv, 0, RDMA_END_ADDR_HI);
> rdma_writel(priv, priv->num_rx_desc_words - 1, RDMA_END_ADDR_LO);
>
> - rdma_writel(priv, 1, RDMA_MBDONE_INTR);
> -
> netif_dbg(priv, hw, priv->netdev,
> "RDMA cfg, num_rx_bds=%d, rx_bds=%p\n",
> priv->num_rx_bds, priv->rx_bds);
> @@ -1827,7 +1851,8 @@ static void bcm_sysport_netif_start(struct net_device *dev)
> struct bcm_sysport_priv *priv = netdev_priv(dev);
>
> /* Enable NAPI */
> - bcm_sysport_init_dim(&priv->dim, bcm_sysport_dim_work);
> + bcm_sysport_init_dim(priv, bcm_sysport_dim_work);
> + bcm_sysport_init_rx_coalesce(priv);
> napi_enable(&priv->napi);
>
> /* Enable RX interrupt and TX ring full interrupt */
> @@ -2333,6 +2358,7 @@ static int bcm_sysport_probe(struct platform_device *pdev)
> /* libphy will adjust the link state accordingly */
> netif_carrier_off(dev);
>
> + priv->rx_max_coalesced_frames = 1;
Do you still want to keep {usecs,frames}={0,1} as default static
configuration? Is the latency so important for the static case? I'm
assuming RT latency is at least 10us so you can somewhat increase the
timer and counter without causing an increase in latency. This should be
properly tested of course so maybe in a future patch.
> u64_stats_init(&priv->syncp);
>
> priv->dsa_notifier.notifier_call = bcm_sysport_dsa_notifier;
> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.h b/drivers/net/ethernet/broadcom/bcmsysport.h
> index 57e18ef8f206..d6e5d0cbf3a3 100644
> --- a/drivers/net/ethernet/broadcom/bcmsysport.h
> +++ b/drivers/net/ethernet/broadcom/bcmsysport.h
> @@ -701,8 +701,6 @@ struct bcm_sysport_net_dim {
> u16 event_ctr;
> unsigned long packets;
> unsigned long bytes;
> - u32 coal_usecs;
> - u32 coal_pkts;
> struct net_dim dim;
> };
>
> @@ -755,6 +753,8 @@ struct bcm_sysport_priv {
> unsigned int rx_c_index;
>
> struct bcm_sysport_net_dim dim;
> + u32 rx_max_coalesced_frames;
> + u32 rx_coalesce_usecs;
>
> /* PHY device */
> struct device_node *phy_dn;
>
Reviewed-by: Tal Gilboa <talgi@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: bcmgenet: Fix coalescing settings handling
From: Tal Gilboa @ 2018-03-29 7:42 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: davem, jaedon.shin, pgynther, opendmb, Michael Chan, gospo,
saeedm
In-Reply-To: <20180328221538.29290-4-f.fainelli@gmail.com>
On 3/29/2018 1:15 AM, Florian Fainelli wrote:
> There were a number of issues with setting the RX coalescing parameters:
>
> - we would not be preserving values that would have been configured
> across close/open calls, instead we would always reset to no timeout
> and 1 interrupt per packet, this would also prevent DIM from setting its
> default usec/pkts values
>
> - when adaptive RX would be turned on, we woud not be fetching the
> default parameters, we would stay with no timeout/1 packet per interrupt
> until the estimator kicks in and changes that
>
> - finally disabling adaptive RX coalescing while providing parameters
> would not be honored, and we would stay with whatever DIM had previously
> determined instead of the user requested parameters
>
> Fixes: 9f4ca05827a2 ("net: bcmgenet: Add support for adaptive RX coalescing")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 92 +++++++++++++++++---------
> drivers/net/ethernet/broadcom/genet/bcmgenet.h | 4 +-
> 2 files changed, 61 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index 7db8edc643ec..f8af472f324f 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -625,26 +625,46 @@ static int bcmgenet_get_coalesce(struct net_device *dev,
> return 0;
> }
>
> -static void bcmgenet_set_rx_coalesce(struct bcmgenet_rx_ring *ring)
> +static void bcmgenet_set_rx_coalesce(struct bcmgenet_rx_ring *ring,
> + u32 usecs, u32 pkts)
> {
> struct bcmgenet_priv *priv = ring->priv;
> unsigned int i = ring->index;
> u32 reg;
>
> - bcmgenet_rdma_ring_writel(priv, i, ring->dim.coal_pkts,
> - DMA_MBUF_DONE_THRESH);
> + bcmgenet_rdma_ring_writel(priv, i, pkts, DMA_MBUF_DONE_THRESH);
>
> reg = bcmgenet_rdma_readl(priv, DMA_RING0_TIMEOUT + i);
> reg &= ~DMA_TIMEOUT_MASK;
> - reg |= DIV_ROUND_UP(ring->dim.coal_usecs * 1000, 8192);
> + reg |= DIV_ROUND_UP(usecs * 1000, 8192);
> bcmgenet_rdma_writel(priv, reg, DMA_RING0_TIMEOUT + i);
> }
>
> +static void bcmgenet_set_ring_rx_coalesce(struct bcmgenet_rx_ring *ring,
> + struct ethtool_coalesce *ec)
> +{
> + struct net_dim_cq_moder moder;
> + u32 usecs, pkts;
> +
> + ring->rx_coalesce_usecs = ec->rx_coalesce_usecs;
> + ring->rx_max_coalesced_frames = ec->rx_max_coalesced_frames;
> + usecs = ring->rx_coalesce_usecs;
> + pkts = ring->rx_max_coalesced_frames;
> +
> + if (ec->use_adaptive_rx_coalesce && !ring->dim.use_dim) {
> + moder = net_dim_get_def_profile(ring->dim.dim.mode);
> + usecs = moder.usec;
> + pkts = moder.pkts;
> + }
> +
> + ring->dim.use_dim = ec->use_adaptive_rx_coalesce;
> + bcmgenet_set_rx_coalesce(ring, usecs, pkts);
> +}
> +
> static int bcmgenet_set_coalesce(struct net_device *dev,
> struct ethtool_coalesce *ec)
> {
> struct bcmgenet_priv *priv = netdev_priv(dev);
> - struct bcmgenet_rx_ring *ring;
> unsigned int i;
>
> /* Base system clock is 125Mhz, DMA timeout is this reference clock
> @@ -680,27 +700,9 @@ static int bcmgenet_set_coalesce(struct net_device *dev,
> ec->tx_max_coalesced_frames,
> DMA_MBUF_DONE_THRESH);
>
> - for (i = 0; i < priv->hw_params->rx_queues; i++) {
> - ring = &priv->rx_rings[i];
> - ring->dim.coal_usecs = ec->rx_coalesce_usecs;
> - ring->dim.coal_pkts = ec->rx_max_coalesced_frames;
> - if (!ec->use_adaptive_rx_coalesce && ring->dim.use_dim) {
> - ring->dim.coal_pkts = 1;
> - ring->dim.coal_usecs = 0;
> - }
> - ring->dim.use_dim = ec->use_adaptive_rx_coalesce;
> - bcmgenet_set_rx_coalesce(ring);
> - }
> -
> - ring = &priv->rx_rings[DESC_INDEX];
> - ring->dim.coal_usecs = ec->rx_coalesce_usecs;
> - ring->dim.coal_pkts = ec->rx_max_coalesced_frames;
> - if (!ec->use_adaptive_rx_coalesce && ring->dim.use_dim) {
> - ring->dim.coal_pkts = 1;
> - ring->dim.coal_usecs = 0;
> - }
> - ring->dim.use_dim = ec->use_adaptive_rx_coalesce;
> - bcmgenet_set_rx_coalesce(ring);
> + for (i = 0; i < priv->hw_params->rx_queues; i++)
> + bcmgenet_set_ring_rx_coalesce(&priv->rx_rings[i], ec);
> + bcmgenet_set_ring_rx_coalesce(&priv->rx_rings[DESC_INDEX], ec);
>
> return 0;
> }
> @@ -1924,10 +1926,7 @@ static void bcmgenet_dim_work(struct work_struct *work)
> struct net_dim_cq_moder cur_profile =
> net_dim_get_profile(dim->mode, dim->profile_ix);
>
> - ring->dim.coal_usecs = cur_profile.usec;
> - ring->dim.coal_pkts = cur_profile.pkts;
> -
> - bcmgenet_set_rx_coalesce(ring);
> + bcmgenet_set_rx_coalesce(ring, cur_profile.usec, cur_profile.pkts);
> dim->state = NET_DIM_START_MEASURE;
> }
>
> @@ -2079,9 +2078,11 @@ static void init_umac(struct bcmgenet_priv *priv)
> dev_dbg(kdev, "done init umac\n");
> }
>
> -static void bcmgenet_init_dim(struct bcmgenet_net_dim *dim,
> +static void bcmgenet_init_dim(struct bcmgenet_rx_ring *ring,
> void (*cb)(struct work_struct *work))
> {
> + struct bcmgenet_net_dim *dim = &ring->dim;
> +
> INIT_WORK(&dim->dim.work, cb);
> dim->dim.mode = NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE;
> dim->event_ctr = 0;
> @@ -2089,6 +2090,25 @@ static void bcmgenet_init_dim(struct bcmgenet_net_dim *dim,
> dim->bytes = 0;
> }
>
> +static void bcmgenet_init_rx_coalesce(struct bcmgenet_rx_ring *ring)
> +{
> + struct bcmgenet_net_dim *dim = &ring->dim;
> + struct net_dim_cq_moder moder;
> + u32 usecs, pkts;
> +
> + usecs = ring->rx_coalesce_usecs;
> + pkts = ring->rx_max_coalesced_frames;
> +
> + /* If DIM was enabled, re-apply default parameters */
> + if (dim->use_dim) {
> + moder = net_dim_get_def_profile(dim->dim.mode);
> + usecs = moder.usec;
> + pkts = moder.pkts;
> + }
> +
> + bcmgenet_set_rx_coalesce(ring, usecs, pkts);
> +}
> +
> /* Initialize a Tx ring along with corresponding hardware registers */
> static void bcmgenet_init_tx_ring(struct bcmgenet_priv *priv,
> unsigned int index, unsigned int size,
> @@ -2178,7 +2198,8 @@ static int bcmgenet_init_rx_ring(struct bcmgenet_priv *priv,
> if (ret)
> return ret;
>
> - bcmgenet_init_dim(&ring->dim, bcmgenet_dim_work);
> + bcmgenet_init_dim(ring, bcmgenet_dim_work);
> + bcmgenet_init_rx_coalesce(ring);
>
> /* Initialize Rx NAPI */
> netif_napi_add(priv->dev, &ring->napi, bcmgenet_rx_poll,
> @@ -2186,7 +2207,6 @@ static int bcmgenet_init_rx_ring(struct bcmgenet_priv *priv,
>
> bcmgenet_rdma_ring_writel(priv, index, 0, RDMA_PROD_INDEX);
> bcmgenet_rdma_ring_writel(priv, index, 0, RDMA_CONS_INDEX);
> - bcmgenet_rdma_ring_writel(priv, index, 1, DMA_MBUF_DONE_THRESH);
> bcmgenet_rdma_ring_writel(priv, index,
> ((size << DMA_RING_SIZE_SHIFT) |
> RX_BUF_LENGTH), DMA_RING_BUF_SIZE);
> @@ -3424,6 +3444,7 @@ static int bcmgenet_probe(struct platform_device *pdev)
> struct net_device *dev;
> const void *macaddr;
> struct resource *r;
> + unsigned int i;
> int err = -EIO;
> const char *phy_mode_str;
>
> @@ -3552,6 +3573,11 @@ static int bcmgenet_probe(struct platform_device *pdev)
> netif_set_real_num_tx_queues(priv->dev, priv->hw_params->tx_queues + 1);
> netif_set_real_num_rx_queues(priv->dev, priv->hw_params->rx_queues + 1);
>
> + /* Set default coalescing parameters */
> + for (i = 0; i < priv->hw_params->rx_queues; i++)
> + priv->rx_rings[i].rx_max_coalesced_frames = 1;
> + priv->rx_rings[DESC_INDEX].rx_max_coalesced_frames = 1;
> +
Do you still want to keep {usecs,frames}={0,1} as default static
configuration? Is the latency so important for the static case? I'm
assuming RT latency is at least 10us so you can somewhat increase the
timer and counter without causing an increase in latency. This should be
properly tested of course so maybe in a future patch.
> /* libphy will determine the link state */
> netif_carrier_off(dev);
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
> index 22c41e0430fb..b773bc07edf7 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
> @@ -578,8 +578,6 @@ struct bcmgenet_net_dim {
> u16 event_ctr;
> unsigned long packets;
> unsigned long bytes;
> - u32 coal_usecs;
> - u32 coal_pkts;
> struct net_dim dim;
> };
>
> @@ -598,6 +596,8 @@ struct bcmgenet_rx_ring {
> unsigned int end_ptr; /* Rx ring end CB ptr */
> unsigned int old_discards;
> struct bcmgenet_net_dim dim;
> + u32 rx_max_coalesced_frames;
> + u32 rx_coalesce_usecs;
> void (*int_enable)(struct bcmgenet_rx_ring *);
> void (*int_disable)(struct bcmgenet_rx_ring *);
> struct bcmgenet_priv *priv;
>
Reviewed-by: Tal Gilboa <talgi@mellanox.com>
^ permalink raw reply
* Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610
From: Loic Poulain @ 2018-03-29 7:40 UTC (permalink / raw)
To: Ramon Fried
Cc: Kalle Valo, wcn36xx, linux-wireless, netdev, linux-kernel,
devicetree
In-Reply-To: <2d978343-2057-8424-a249-83a0394da5a7@codeaurora.org>
Hi Ramon,
On 29 March 2018 at 09:32, Ramon Fried <rfried@codeaurora.org> wrote:
>> Should we document qcom,wcn3610 just like wcn3620 is:
>>
>> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt: "qcom,wcn3620",
> IMHO the mentioned bindings is related to the PIL (peripheral image loaded) which is just the firmware part and has
> nothing to do with wifi frontend(IRIS).
>
It seems that the RF is a subnode of the PIL node:
"= SUBNODES
A required subnode of the WCNSS PIL is used to describe the attached rf module
and its resource dependencies. It is described by the following properties:"
So we should add qcom,wcn3610 to the exiting list of 'compatible' rf modules.
Regards,
Loic
^ 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