* Re: [pull request][for-next 00/15] Mellanox, mlx5 core and netdev updates 2018-05-17
From: Jason Gunthorpe @ 2018-05-18 17:21 UTC (permalink / raw)
To: David Miller; +Cc: saeedm, dledford, leonro, ogerlitz, netdev, linux-rdma
In-Reply-To: <20180518.130351.456975805564832525.davem@davemloft.net>
On Fri, May 18, 2018 at 01:03:51PM -0400, David Miller wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Thu, 17 May 2018 18:22:43 -0700
>
> > Below you can find two pull requests,
> >
> > 1. mlx5 core updates to be shared for both netdev and RDMA, (patches 1..9)
> > which is based on the last mlx5-next pull request
> >
> > The following changes since commit a8408f4e6db775e245f20edf12b13fd58cc03a1c:
> >
> > net/mlx5: fix spelling mistake: "modfiy" -> "modify" (2018-05-04 12:11:51 -0700)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git tags/mlx5-updates-2018-05-17
> >
> > for you to fetch changes up to 10ff5359f883412728ba816046ee3a696625ca02:
> >
> > net/mlx5e: Explicitly set source e-switch in offloaded TC rules (2018-05-17 14:17:35 -0700)
> >
> > 2. mlx5e netdev updates only for net-next branch (patches 10..15) based on net-next
> > and the above pull request.
> >
> > The following changes since commit 538e2de104cfb4ef1acb35af42427bff42adbe4d:
> >
> > Merge branch 'net-Allow-more-drivers-with-COMPILE_TEST' (2018-05-17 17:11:07 -0400)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5e-updates-2018-05-17
> >
> > for you to fetch changes up to a228060a7c9ab88597eeac131e4578595d5d46ae:
> >
> > net/mlx5e: Add HW vport counters to representor ethtool stats (2018-05-17 17:48:54 -0700)
> >
> > Dave, for your convenience you can either pull 1. and then 2. or pull 2.
> > directly.
>
> Looks good.
>
> I pulled 1 then I pulled 2. That seemed to work well. Particularly
> it allowed me to capture the two different merge commit messages one
> by one.
Does this double up the merge commit though? I see this in Saeed's
tags/mlx5e-updates-2018-05-17 ?
commit 260ab7042e24ccd4407985c6e775e39d064fab2b
Merge: 538e2de104cfb4 10ff5359f88341
Author: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu May 17 17:47:09 2018 -0700
Merge tag 'mlx5-updates-2018-05-17' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
mlx5-updates-2018-05-17
mlx5 core dirver updates for both net-next and rdma-next branches.
From Christophe JAILLET, first three patches to use kvfree where needed.
From: Or Gerlitz <ogerlitz@mellanox.com>
Next six patches from Roi and Co adds support for merged
sriov e-switch which comes to serve cases where both PFs, VFs set
on them and both uplinks are to be used in single v-switch SW model.
When merged e-switch is supported, the per-port e-switch is logically
merged into one e-switch that spans both physical ports and all the VFs.
This model allows to offload TC eswitch rules between VFs belonging
to different PFs (and hence have different eswitch affinity), it also
sets the some of the foundations needed for uplink LAG support.
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
And this in your tree:
commit 3888ea4e2f1fb2f61e5418adf4b8332107ac0c8f
Merge: 2c47a65b7009eb 10ff5359f88341
Author: David S. Miller <davem@davemloft.net>
Date: Fri May 18 13:00:08 2018 -0400
Merge tag 'mlx5-updates-2018-05-17' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
Saeed Mahameed says:
====================
mlx5-updates-2018-05-17
mlx5 core dirver updates for both net-next and rdma-next branches.
From Christophe JAILLET, first three patche to use kvfree where needed.
From: Or Gerlitz <ogerlitz@mellanox.com>
Next six patches from Roi and Co adds support for merged
sriov e-switch which comes to serve cases where both PFs, VFs set
on them and both uplinks are to be used in single v-switch SW model.
When merged e-switch is supported, the per-port e-switch is logically
merged into one e-switch that spans both physical ports and all the VFs.
This model allows to offload TC eswitch rules between VFs belonging
to different PFs (and hence have different eswitch affinity), it also
sets the some of the foundations needed for uplink LAG support.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
I think the trouble is the Saeed needs to merge the 'core' stuff to
create the non-core patches for netdev (just like we want to do for
rdma)
So maybe netdev should take the #2 pull request and rdma should
take number #1?
This seems to be working OK from RDMA's side, we have much less netdev
stuff in our tree now which seems good!
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH bpf-next 0/5] fix test_sockmap
From: Daniel Borkmann @ 2018-05-18 17:23 UTC (permalink / raw)
To: Shuah Khan, Prashant Bhole, Alexei Starovoitov, John Fastabend
Cc: David S . Miller, netdev, linux-kselftest@vger.kernel.org
In-Reply-To: <7ca8b025-c152-b0c9-a58b-cff722c2223e@kernel.org>
On 05/18/2018 06:54 PM, Shuah Khan wrote:
> On 05/18/2018 01:17 AM, Prashant Bhole wrote:
>> This series fixes bugs in test_sockmap code. They weren't caught
>> previously because failure in RX/TX thread was not notified to the
>> main thread.
>>
>> Also fixed data verification logic and slightly improved test output
>> such that parameters values (cork, apply, start, end) of failed test
>> can be easily seen.
>>
>> Note: Even after fixing above problems there are issues with tests
>> which set cork parameter. Tests fail (RX thread timeout) when cork
>> value is non-zero and overall data sent by TX thread isn't multiples
>> of cork value.
>>
>> Prashant Bhole (5):
>> selftests/bpf: test_sockmap, check test failure
>> selftests/bpf: test_sockmap, join cgroup in selftest mode
>> selftests/bpf: test_sockmap, fix test timeout
>> selftests/bpf: test_sockmap, fix data verification
>> selftests/bpf: test_sockmap, print additional test options
>>
>> tools/testing/selftests/bpf/test_sockmap.c | 76 +++++++++++++++++++++++-------
>> 1 file changed, 58 insertions(+), 18 deletions(-)
>
> Please remember to cc linux-kselftest mailing list as well. I would like to see
> all the test patches cc'ed to it. Linaro and other test users watch the kselftest
> mailing list. I also have patchwork project now to manage the patch volume.
>
> I am okay with patches going through net/bpf trees - there are always test
> dependencies on net/bpf trees.
Yep, routing all the BPF selftest patches via bpf/bpf-next tree is the only
viable model that works for us in BPF case, in fact also looks like BPF
selftests are the busiest subdir in #commits so avoiding merge conflicts is
crucial. Whenever appropriate, most fixes or new features are very often
accompanied in a patch set with extensive selftests for BPF, so it has a
deep dependency on the two trees.
Best,
Daniel
^ permalink raw reply
* Re: [net-next 3/6] ixgbe: release lock for the duration of ixgbe_suspend_close()
From: Sergei Shtylyov @ 2018-05-18 17:28 UTC (permalink / raw)
To: Pavel Tatashin, Jeff Kirsher, davem; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <9ee4abce-0841-374d-5395-0c5170880eb1@oracle.com>
On 05/18/2018 02:37 PM, Pavel Tatashin wrote:
> * parallelized this function, so drop lock for the
>>
>> Parallelizing? Else the sentence doesn't parse for me. :-)
My comment hardly makes sense when you removed all the context...
> Hi Sergei,
>
> In a separate series I parallelized device_shutdown(), see:
> http://lkml.kernel.org/r/20180516024004.28977-1-pasha.tatashin@oracle.com
>
> But, this particular patch should be dropped, as discussed in this thread:
> http://lkml.kernel.org/r/20180503035931.22439-2-pasha.tatashin@oracle.com
>
>
> Alexander Duyck, made a point that a generic RTNL scalability fix should be done. This particular patch might introduce a race, since it relies on assumption that RTNL is not needed in this place because ixgbe_close() does not have it, but Alexander Duyck, says that the callers of ixgbe_close() are assumed to own this lock.
My comment was about the English grammar only. :-)
> Thank you,
> Pavel
MBR, Sergei
^ permalink raw reply
* Re: [RFC PATCH net-next] tcp: tcp_rack_reo_wnd() can be static
From: David Miller @ 2018-05-18 17:28 UTC (permalink / raw)
To: fengguang.wu
Cc: ycheng, kbuild-all, netdev, ncardwell, edumazet, soheil,
priyarjha, kuznet, yoshfuji, linux-kernel
In-Reply-To: <20180518051423.GA41595@lkp-ivb-ep02>
From: kbuild test robot <fengguang.wu@intel.com>
Date: Fri, 18 May 2018 13:14:23 +0800
> Fixes: 20b654dfe1be ("tcp: support DUPACK threshold in RACK")
> Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
Looks good, applied, thanks!
^ permalink raw reply
* Re: [net-next 3/6] ixgbe: release lock for the duration of ixgbe_suspend_close()
From: Pavel Tatashin @ 2018-05-18 17:35 UTC (permalink / raw)
To: Sergei Shtylyov, Jeff Kirsher, davem; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <a16f2e4d-45fe-47b7-23fc-af4f506ac059@cogentembedded.com>
On 05/18/2018 01:28 PM, Sergei Shtylyov wrote:
> On 05/18/2018 02:37 PM, Pavel Tatashin wrote:
>
>> * parallelized this function, so drop lock for the
>>>
>>> Parallelizing? Else the sentence doesn't parse for me. :-)
>
> My comment hardly makes sense when you removed all the context...
Hi Sergei,
Ah gotcha:
+ /* Suspend takes a long time, device_shutdown may be
+ * parallelized this function, so drop lock for the
The comment should have been:
ixgbe_close_suspend() takes a long time, and device_shutdown may parallelize ixgbe_shutdown(), therefore drop lock to allow concurrent execution of ixgbe_close_suspend().
Anyway, as I said, this patch should be dropped.
Thank you,
Pavel
^ permalink raw reply
* Re: [PATCH] net/atheros: fix spelling mistake: "Ddescription" -> "Description"
From: David Miller @ 2018-05-18 17:43 UTC (permalink / raw)
To: colin.king; +Cc: jcliburn, chris.snook, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180518092206.21635-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 18 May 2018 10:22:06 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistakes in name field text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/ethernet/atheros/atl1e/atl1e_param.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_param.c b/drivers/net/ethernet/atheros/atl1e/atl1e_param.c
> index fa314282c9ad..6a375f4bd054 100644
> --- a/drivers/net/ethernet/atheros/atl1e/atl1e_param.c
> +++ b/drivers/net/ethernet/atheros/atl1e/atl1e_param.c
> @@ -192,7 +192,7 @@ void atl1e_check_options(struct atl1e_adapter *adapter)
> { /* Transmit Ring Size */
> struct atl1e_option opt = {
> .type = range_option,
> - .name = "Transmit Ddescription Count",
> + .name = "Transmit Description Count",
In this context, "Descriptor" would be the most appropriate word.
Thank you.
^ permalink raw reply
* Re: [PATCH] hippi: fix spelling mistake: "Framming" -> "Framing"
From: David Miller @ 2018-05-18 17:46 UTC (permalink / raw)
To: colin.king; +Cc: jes, linux-hippi, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180518100922.28790-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 18 May 2018 11:09:22 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in printk message text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] sh_eth: Change platform check to CONFIG_ARCH_RENESAS
From: David Miller @ 2018-05-18 17:46 UTC (permalink / raw)
To: geert+renesas; +Cc: sergei.shtylyov, netdev, linux-renesas-soc
In-Reply-To: <1526640771-473-1-git-send-email-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 18 May 2018 12:52:51 +0200
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
>
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check.
>
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Applied.
^ permalink raw reply
* Re: [PATCH net] sock_diag: fix use-after-free read in __sk_free
From: David Miller @ 2018-05-18 17:48 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, kraig
In-Reply-To: <20180518114755.56152-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 18 May 2018 04:47:55 -0700
> We must not call sock_diag_has_destroy_listeners(sk) on a socket
> that has no reference on net structure.
...
> Fixes: b922622ec6ef ("sock_diag: don't broadcast kernel sockets")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Craig Gallek <kraig@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: mvpp2: typo and cosmetic fixes
From: David Miller @ 2018-05-18 17:48 UTC (permalink / raw)
To: antoine.tenart
Cc: netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180518123451.31365-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Fri, 18 May 2018 14:34:51 +0200
> This patch on the Marvell PPv2 driver is only cosmetic. Two typos are
> removed as well as other cosmetic fixes, such as extra new lines or tabs
> vs spaces.
>
> Suggested-by: Stefan Chulski <stefanc@marvell.com>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version
From: David Miller @ 2018-05-18 17:51 UTC (permalink / raw)
To: andrea.greco.gapmilano; +Cc: tobin, a.greco, m.grzeschik, linux-kernel, netdev
In-Reply-To: <CAPoXtQJJ-Fv6dBWxFs+r+B-+jhQAF+AxdqDg9g55AwSyBJ0U6g@mail.gmail.com>
From: Andrea Greco <andrea.greco.gapmilano@gmail.com>
Date: Fri, 18 May 2018 14:18:41 +0200
> In com20020.c found this:
> /* FIXME: do this some other way! */
> if (!dev->dev_addr[0])
> dev->dev_addr[0] = arcnet_inb(ioaddr, 8);
>
> NODE-ID, must be univoque, for all arcnet network.
> My previews idea was take random value but, this could create a
> collision over network.
>
> A possible solution is:
> In case of collision com20020 set a bit in status register.
> Then peak a new NODE-ID and repeat this while correct NODE-ID is found.
>
> Other ideas is pass it via DTS.
> But suppose have 2 same product in same network, same address same problem.
> For this reason i prefer left standard driver behavior.
>
> Other ideas for solve this ?
Is there no way to obtain a unique value from the device?
If having a unique ID to talk on the ARCNET is so critical, there must
be some way to properly allocation and use a unique ID.
I guess this must be a general problem with this driver already.
You still need to address the issue of 'dev' being leaked on probe
error paths.
Thank you.
^ permalink raw reply
* Re: [PATCH net] net: sched: red: avoid hashing NULL child
From: David Miller @ 2018-05-18 17:53 UTC (permalink / raw)
To: pabeni; +Cc: netdev, jhs, xiyou.wangcong, jiri, liuhangbin, jkosina
In-Reply-To: <286744ab66eaa07d61d5d8ce8a07cb0b1615d35c.1526647813.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Fri, 18 May 2018 14:51:44 +0200
> Hangbin reported an Oops triggered by the syzkaller qdisc rules:
...
> When a red qdisc is updated with a 0 limit, the child qdisc is left
> unmodified, no additional scheduler is created in red_change(),
> the 'child' local variable is rightfully NULL and must not add it
> to the hash table.
>
> This change addresses the above issue moving qdisc_hash_add() right
> after the child qdisc creation. It additionally removes unneeded checks
> for noop_qdisc.
>
> Reported-by: Hangbin Liu <liuhangbin@gmail.com>
> Fixes: 49b499718fa1 ("net: sched: make default fifo qdiscs appear in the dump")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied and queued up for -stable, thanks Paolo.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: collect SGE PF/VF queue map
From: David Miller @ 2018-05-18 17:55 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, ganeshgr, nirranjan, indranil
In-Reply-To: <1526650973-20752-1-git-send-email-rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Fri, 18 May 2018 19:12:53 +0530
> For T6, collect info on queue mapping to corresponding PF/VF in SGE.
>
> Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] cxgb4: fix offset in collecting TX rate limit info
From: David Miller @ 2018-05-18 17:55 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, ganeshgr, nirranjan, indranil
In-Reply-To: <1526651017-20795-1-git-send-email-rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Fri, 18 May 2018 19:13:37 +0530
> Correct the indirect register offsets in collecting TX rate limit info
> in UP CIM logs.
>
> Also, T5 doesn't support these indirect register offsets, so remove
> them from collection logic.
>
> Fixes: be6e36d916b1 ("cxgb4: collect TX rate limit info in UP CIM logs")
> Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: stmmac: Populate missing callbacks in HWIF initialization
From: David Miller @ 2018-05-18 17:56 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, clabbe.montjoie, Joao.Pinto, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <6f26505abcb91747df73f09019c7e2bcb0c3835a.1526658592.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Fri, 18 May 2018 16:54:38 +0100
> Some HW specific setups, like sun8i, do not populate all the necessary
> callbacks, which is what HWIF helpers were expecting.
>
> Fix this by always trying to get the generic helpers and populate them
> if they were not previously populated by HW specific setup.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Fixes: 5f0456b43140 ("net: stmmac: Implement logic to automatically
> select HW Interface")
Please don't split up Fixes: tag lines like this in the future. No matter
how long it is, keep it a single line.
> Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] selftests: bpf: config: enable NET_SCH_INGRESS for xdp_meta.sh
From: Anders Roxell @ 2018-05-18 18:23 UTC (permalink / raw)
To: ast, daniel, shuah; +Cc: netdev, linux-kernel, linux-kselftest, Anders Roxell
When running bpf's selftest test_xdp_meta.sh it fails:
./test_xdp_meta.sh
Error: Specified qdisc not found.
selftests: test_xdp_meta [FAILED]
Need to enable CONFIG_NET_SCH_INGRESS and CONFIG_NET_CLS_ACT to get the
test to pass.
Fixes: 22c8852624fc ("bpf: improve selftests and add tests for meta pointer")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
tools/testing/selftests/bpf/config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/bpf/config b/tools/testing/selftests/bpf/config
index 983dd25d49f4..1eefe211a4a8 100644
--- a/tools/testing/selftests/bpf/config
+++ b/tools/testing/selftests/bpf/config
@@ -5,3 +5,5 @@ CONFIG_BPF_EVENTS=y
CONFIG_TEST_BPF=m
CONFIG_CGROUP_BPF=y
CONFIG_NETDEVSIM=m
+CONFIG_NET_CLS_ACT=y
+CONFIG_NET_SCH_INGRESS=y
--
2.17.0
^ permalink raw reply related
* [PATCH v2 0/3] Add Renesas R8A77980 GEther support
From: Sergei Shtylyov @ 2018-05-18 18:28 UTC (permalink / raw)
To: netdev, devicetree, David S. Miller, Rob Herring
Cc: Mark Rutland, linux-renesas-soc
Hello!
Here's a set of 3 patches against DaveM's 'net-next.git' repo. They (gradually)
add R8A77980 GEther support to the 'sh_eth' driver, starting with couple new
register bits/values introduced with this chip, and ending with adding a new
'struct sh_eth_cpu_data' instance connected to the new DT "compatible" prop
value...
[1/1] sh_eth: add RGMII support
[2/3] sh_eth: add EDMR.NBST support
[3/3] sh_eth: add R8A77980 support
MBR, Sergei
^ permalink raw reply
* [PATCH v2 1/1] sh_eth: add RGMII support
From: Sergei Shtylyov @ 2018-05-18 18:30 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <f30c98ff-f6da-9e7f-c637-49076a428885@cogentembedded.com>
The R-Car V3H (AKA R8A77980) GEther controller adds support for the RGMII
PHY interface mode as a new value for the RMII_MII register.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- included PHY_INTERFACE_MODE_RGMII_{|RX|TX}ID in the RGMII *case*.
drivers/net/ethernet/renesas/sh_eth.c | 3 +++
1 file changed, 3 insertions(+)
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
@@ -466,6 +466,9 @@ static void sh_eth_select_mii(struct net
u32 value;
switch (mdp->phy_interface) {
+ case PHY_INTERFACE_MODE_RGMII ... PHY_INTERFACE_MODE_RGMII_TXID:
+ value = 0x3;
+ break;
case PHY_INTERFACE_MODE_GMII:
value = 0x2;
break;
^ permalink raw reply
* [PATCH v2 2/3] sh_eth: add EDMR.NBST support
From: Sergei Shtylyov @ 2018-05-18 18:31 UTC (permalink / raw)
To: netdev, devicetree, David S. Miller, Rob Herring
Cc: Mark Rutland, linux-renesas-soc
In-Reply-To: <f30c98ff-f6da-9e7f-c637-49076a428885@cogentembedded.com>
The R-Car V3H (AKA R8A77980) GEther controller adds the DMA burst mode bit
(NBST) in EDMR and the manual tells to always set it before doing any DMA.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
Changes in version 2:
- added Simon's tag.
drivers/net/ethernet/renesas/sh_eth.c | 4 ++++
drivers/net/ethernet/renesas/sh_eth.h | 2 ++
2 files changed, 6 insertions(+)
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
@@ -1434,6 +1434,10 @@ static int sh_eth_dev_init(struct net_de
sh_eth_write(ndev, mdp->cd->trscer_err_mask, TRSCER);
+ /* DMA transfer burst mode */
+ if (mdp->cd->nbst)
+ sh_eth_modify(ndev, EDMR, EDMR_NBST, EDMR_NBST);
+
if (mdp->cd->bculr)
sh_eth_write(ndev, 0x800, BCULR); /* Burst sycle set */
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
@@ -184,6 +184,7 @@ enum GECMR_BIT {
/* EDMR */
enum DMAC_M_BIT {
+ EDMR_NBST = 0x80,
EDMR_EL = 0x40, /* Litte endian */
EDMR_DL1 = 0x20, EDMR_DL0 = 0x10,
EDMR_SRST_GETHER = 0x03,
@@ -505,6 +506,7 @@ struct sh_eth_cpu_data {
unsigned bculr:1; /* EtherC have BCULR */
unsigned tsu:1; /* EtherC have TSU */
unsigned hw_swap:1; /* E-DMAC have DE bit in EDMR */
+ unsigned nbst:1; /* E-DMAC has NBST bit in EDMR */
unsigned rpadir:1; /* E-DMAC have RPADIR */
unsigned no_trimd:1; /* E-DMAC DO NOT have TRIMD */
unsigned no_ade:1; /* E-DMAC DO NOT have ADE bit in EESR */
^ permalink raw reply
* [PATCH v2 3/3] sh_eth: add R8A77980 support
From: Sergei Shtylyov @ 2018-05-18 18:32 UTC (permalink / raw)
To: netdev, devicetree, David S. Miller, Rob Herring
Cc: Mark Rutland, linux-renesas-soc
In-Reply-To: <f30c98ff-f6da-9e7f-c637-49076a428885@cogentembedded.com>
Finally, add support for the DT probing of the R-Car V3H (AKA R8A77980) --
it's the only R-Car gen3 SoC having the GEther controller -- others have
only EtherAVB...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
Changes in version 2:
- added Simon's tag.
Documentation/devicetree/bindings/net/sh_eth.txt | 1
drivers/net/ethernet/renesas/sh_eth.c | 44 +++++++++++++++++++++++
2 files changed, 45 insertions(+)
Index: net-next/Documentation/devicetree/bindings/net/sh_eth.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/sh_eth.txt
+++ net-next/Documentation/devicetree/bindings/net/sh_eth.txt
@@ -14,6 +14,7 @@ Required properties:
"renesas,ether-r8a7791" if the device is a part of R8A7791 SoC.
"renesas,ether-r8a7793" if the device is a part of R8A7793 SoC.
"renesas,ether-r8a7794" if the device is a part of R8A7794 SoC.
+ "renesas,gether-r8a77980" if the device is a part of R8A77980 SoC.
"renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
"renesas,rcar-gen1-ether" for a generic R-Car Gen1 device.
"renesas,rcar-gen2-ether" for a generic R-Car Gen2 or RZ/G1
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
@@ -753,6 +753,49 @@ static struct sh_eth_cpu_data rcar_gen2_
.rmiimode = 1,
.magic = 1,
};
+
+/* R8A77980 */
+static struct sh_eth_cpu_data r8a77980_data = {
+ .soft_reset = sh_eth_soft_reset_gether,
+
+ .set_duplex = sh_eth_set_duplex,
+ .set_rate = sh_eth_set_rate_gether,
+
+ .register_type = SH_ETH_REG_GIGABIT,
+
+ .edtrr_trns = EDTRR_TRNS_GETHER,
+ .ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD | ECSR_MPD,
+ .ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP |
+ ECSIPR_MPDIP,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ EESIPR_RMAFIP | EESIPR_RRFIP |
+ EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
+
+ .tx_check = EESR_FTC | EESR_CD | EESR_RTO,
+ .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
+ EESR_RFE | EESR_RDE | EESR_RFRMER |
+ EESR_TFE | EESR_TDE | EESR_ECI,
+ .fdr_value = 0x0000070f,
+
+ .apr = 1,
+ .mpr = 1,
+ .tpauser = 1,
+ .bculr = 1,
+ .hw_swap = 1,
+ .nbst = 1,
+ .rpadir = 1,
+ .rpadir_value = 2 << 16,
+ .no_trimd = 1,
+ .no_ade = 1,
+ .xdfar_rw = 1,
+ .hw_checksum = 1,
+ .select_mii = 1,
+ .magic = 1,
+ .cexcr = 1,
+};
#endif /* CONFIG_OF */
static void sh_eth_set_rate_sh7724(struct net_device *ndev)
@@ -3134,6 +3177,7 @@ static const struct of_device_id sh_eth_
{ .compatible = "renesas,ether-r8a7791", .data = &rcar_gen2_data },
{ .compatible = "renesas,ether-r8a7793", .data = &rcar_gen2_data },
{ .compatible = "renesas,ether-r8a7794", .data = &rcar_gen2_data },
+ { .compatible = "renesas,gether-r8a77980", .data = &r8a77980_data },
{ .compatible = "renesas,ether-r7s72100", .data = &r7s72100_data },
{ .compatible = "renesas,rcar-gen1-ether", .data = &rcar_gen1_data },
{ .compatible = "renesas,rcar-gen2-ether", .data = &rcar_gen2_data },
^ permalink raw reply
* cascaded switch
From: Ran Shalit @ 2018-05-18 18:35 UTC (permalink / raw)
To: netdev
Hello,
I am trying to understand the concept of cascaded switch.
I haven't find much information on this topic.
Can anyone please explain the general concept, when is it used, and
why does the device tree need to know about cascaded switch ?
Thank you,
ranran
^ permalink raw reply
* Re: WARNING in ip_recv_error
From: Willem de Bruijn @ 2018-05-18 18:44 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, DaeLyong Jeong, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Network Development, LKML, Byoungyoung Lee, Kyungtae Kim,
bammanag, Willem de Bruijn
In-Reply-To: <CAF=yD-Kb4ZfJ3sMAnWEOB_s9Y=TTnLbRZxrDPiGZLO=trPjY5Q@mail.gmail.com>
On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Fri, May 18, 2018 at 11:44 AM, David Miller <davem@davemloft.net> wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Fri, 18 May 2018 08:30:43 -0700
>>
>>> We probably need to revert Willem patch (7ce875e5ecb8562fd44040f69bda96c999e38bbc)
>>
>> Is it really valid to reach ip_recv_err with an ipv6 socket?
>
> I guess the issue is that setsockopt IPV6_ADDRFORM is not an
> atomic operation, so that the socket is neither fully ipv4 nor fully
> ipv6 by the time it reaches ip_recv_error.
>
> sk->sk_socket->ops = &inet_dgram_ops;
> < HERE >
> sk->sk_family = PF_INET;
>
> Even calling inet_recv_error to demux would not necessarily help.
>
> Safest would be to look up by skb->protocol, similar to what
> ipv6_recv_error does to handle v4-mapped-v6.
>
> Or to make that function safe with PF_INET and swap the order
> of the above two operations.
>
> All sound needlessly complicated for this rare socket option, but
> I don't have a better idea yet. Dropping on the floor is not nice,
> either.
Ensuring that ip_recv_error correctly handles packets from either
socket and removing the warning should indeed be good.
It is robust against v4-mapped packets from an AF_INET6 socket,
but see caveat on reconnect below.
The code between ipv6_recv_error for v4-mapped addresses and
ip_recv_error is essentially the same, the main difference being
whether to return network headers as sockaddr_in with SOL_IP
or sockaddr_in6 with SOL_IPV6.
There are very few other locations in the stack that explicitly test
sk_family in this way and thus would be vulnerable to races with
IPV6_ADDRFORM.
I'm not sure whether it is possible for a udpv6 socket to queue a
real ipv6 packet on the error queue, disconnect, connect to an
ipv4 address, call IPV6_ADDRFORM and then call ip_recv_error
on a true ipv6 packet. That would return buggy data, e.g., in
msg_name.
^ permalink raw reply
* Re: WARNING in ip_recv_error
From: Willem de Bruijn @ 2018-05-18 18:46 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, DaeLyong Jeong, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Network Development, LKML, Byoungyoung Lee, Kyungtae Kim,
bammanag, Willem de Bruijn
In-Reply-To: <CAF=yD-LvZk+gdyf_Kq1j+hoJBmFnTKgR=DResvMAC7tEJCgGJw@mail.gmail.com>
On Fri, May 18, 2018 at 2:44 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>> On Fri, May 18, 2018 at 11:44 AM, David Miller <davem@davemloft.net> wrote:
>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>> Date: Fri, 18 May 2018 08:30:43 -0700
>>>
>>>> We probably need to revert Willem patch (7ce875e5ecb8562fd44040f69bda96c999e38bbc)
>>>
>>> Is it really valid to reach ip_recv_err with an ipv6 socket?
>>
>> I guess the issue is that setsockopt IPV6_ADDRFORM is not an
>> atomic operation, so that the socket is neither fully ipv4 nor fully
>> ipv6 by the time it reaches ip_recv_error.
>>
>> sk->sk_socket->ops = &inet_dgram_ops;
>> < HERE >
>> sk->sk_family = PF_INET;
>>
>> Even calling inet_recv_error to demux would not necessarily help.
>>
>> Safest would be to look up by skb->protocol, similar to what
>> ipv6_recv_error does to handle v4-mapped-v6.
>>
>> Or to make that function safe with PF_INET and swap the order
>> of the above two operations.
>>
>> All sound needlessly complicated for this rare socket option, but
>> I don't have a better idea yet. Dropping on the floor is not nice,
>> either.
>
> Ensuring that ip_recv_error correctly handles packets from either
> socket and removing the warning should indeed be good.
>
> It is robust against v4-mapped packets from an AF_INET6 socket,
> but see caveat on reconnect below.
>
> The code between ipv6_recv_error for v4-mapped addresses and
> ip_recv_error is essentially the same, the main difference being
> whether to return network headers as sockaddr_in with SOL_IP
> or sockaddr_in6 with SOL_IPV6.
>
> There are very few other locations in the stack that explicitly test
> sk_family in this way and thus would be vulnerable to races with
> IPV6_ADDRFORM.
>
> I'm not sure whether it is possible for a udpv6 socket to queue a
> real ipv6 packet on the error queue, disconnect, connect to an
> ipv4 address, call IPV6_ADDRFORM and then call ip_recv_error
> on a true ipv6 packet. That would return buggy data, e.g., in
> msg_name.
In do_ipv6_setsockopt IPV6_ADDRFORM we can test that the
error queue is empty, and then take its lock for the duration of the
operation.
^ permalink raw reply
* [net-next] Revert "ixgbe: release lock for the duration of ixgbe_suspend_close()"
From: Jeff Kirsher @ 2018-05-18 18:58 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This reverts commit 6710f970d9979d8f03f6e292bb729b2ee1526d0e.
Gotta love when developers have offline discussions, thinking everyone
is reading their responses/dialog.
The change had the potential for a number of race conditions on
shutdown, which is why we are reverting the change.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 5ddfb93ed491..a52d92e182ee 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6698,15 +6698,8 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake)
rtnl_lock();
netif_device_detach(netdev);
- if (netif_running(netdev)) {
- /* Suspend takes a long time, device_shutdown may be
- * parallelized this function, so drop lock for the
- * duration of this call.
- */
- rtnl_unlock();
+ if (netif_running(netdev))
ixgbe_close_suspend(adapter);
- rtnl_lock();
- }
ixgbe_clear_interrupt_scheme(adapter);
rtnl_unlock();
--
2.17.0
^ permalink raw reply related
* Re: WARNING in ip_recv_error
From: Willem de Bruijn @ 2018-05-18 18:59 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, DaeLyong Jeong, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Network Development, LKML, Byoungyoung Lee, Kyungtae Kim,
bammanag, Willem de Bruijn
In-Reply-To: <CAF=yD-+QLz63Z6h5OpC-ar+nHvpCpkVi79h9Vtn=7fzmHCK8Lg@mail.gmail.com>
On Fri, May 18, 2018 at 2:46 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Fri, May 18, 2018 at 2:44 PM, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>> On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn
>> <willemdebruijn.kernel@gmail.com> wrote:
>>> On Fri, May 18, 2018 at 11:44 AM, David Miller <davem@davemloft.net> wrote:
>>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>>> Date: Fri, 18 May 2018 08:30:43 -0700
>>>>
>>>>> We probably need to revert Willem patch (7ce875e5ecb8562fd44040f69bda96c999e38bbc)
>>>>
>>>> Is it really valid to reach ip_recv_err with an ipv6 socket?
>>>
>>> I guess the issue is that setsockopt IPV6_ADDRFORM is not an
>>> atomic operation, so that the socket is neither fully ipv4 nor fully
>>> ipv6 by the time it reaches ip_recv_error.
>>>
>>> sk->sk_socket->ops = &inet_dgram_ops;
>>> < HERE >
>>> sk->sk_family = PF_INET;
>>>
>>> Even calling inet_recv_error to demux would not necessarily help.
>>>
>>> Safest would be to look up by skb->protocol, similar to what
>>> ipv6_recv_error does to handle v4-mapped-v6.
>>>
>>> Or to make that function safe with PF_INET and swap the order
>>> of the above two operations.
>>>
>>> All sound needlessly complicated for this rare socket option, but
>>> I don't have a better idea yet. Dropping on the floor is not nice,
>>> either.
>>
>> Ensuring that ip_recv_error correctly handles packets from either
>> socket and removing the warning should indeed be good.
>>
>> It is robust against v4-mapped packets from an AF_INET6 socket,
>> but see caveat on reconnect below.
>>
>> The code between ipv6_recv_error for v4-mapped addresses and
>> ip_recv_error is essentially the same, the main difference being
>> whether to return network headers as sockaddr_in with SOL_IP
>> or sockaddr_in6 with SOL_IPV6.
>>
>> There are very few other locations in the stack that explicitly test
>> sk_family in this way and thus would be vulnerable to races with
>> IPV6_ADDRFORM.
>>
>> I'm not sure whether it is possible for a udpv6 socket to queue a
>> real ipv6 packet on the error queue, disconnect, connect to an
>> ipv4 address, call IPV6_ADDRFORM and then call ip_recv_error
>> on a true ipv6 packet. That would return buggy data, e.g., in
>> msg_name.
>
> In do_ipv6_setsockopt IPV6_ADDRFORM we can test that the
> error queue is empty, and then take its lock for the duration of the
> operation.
Actually, no reason to hold the lock. This setsockopt holds the socket
lock, which connect would need, too. So testing that the queue
is empty after testing that it is connected to a v4 address is
sufficient to ensure that no ipv6 packets are queued for reception.
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 4d780c7f0130..a975d6311341 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -199,6 +199,11 @@ static int do_ipv6_setsockopt(struct sock *sk,
int level, int optname,
if (ipv6_only_sock(sk) ||
!ipv6_addr_v4mapped(&sk->sk_v6_daddr)) {
retv = -EADDRNOTAVAIL;
break;
}
+ if (!skb_queue_empty(&sk->sk_error_queue)) {
+ retv = -EBUSY;
+ break;
+ }
+
fl6_free_socklist(sk);
__ipv6_sock_mc_close(sk);
After this it should be safe to remove the warning in ip_recv_error.
^ 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