* [PATCH V2 net 0/1] net/smc and the RDMA core
From: Ursula Braun @ 2017-05-12 17:09 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: hch-jcswGhMUV9g, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
jwi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
schwidefsky-tA70FqPdS9bQT0dZR+AlfA,
heiko.carstens-tA70FqPdS9bQT0dZR+AlfA,
raspl-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
ubraun-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
From: Ursula Braun <ursula.braun-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Hi Dave,
yesterday I included a patch proposal into a response to Christoph Hellwig,
which is now already seen here:
http://patchwork.ozlabs.org/patch/761250/
Christoph suggested an additional improvement not to use __internal_mr.
Thus I come up with this improved version V2.
Kind regards, Ursula
Ursula Braun (1):
smc: switch to usage of IB_PD_UNSAFE_GLOBAL_RKEY
net/smc/smc_clc.c | 4 ++--
net/smc/smc_core.c | 16 +++-------------
net/smc/smc_core.h | 2 +-
net/smc/smc_ib.c | 21 ++-------------------
net/smc/smc_ib.h | 2 --
5 files changed, 8 insertions(+), 37 deletions(-)
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] sfc: revert changes to NIC revision numbers
From: David Miller @ 2017-05-12 16:34 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, netdev
In-Reply-To: <5a87b5cf-1696-0fbc-209d-95fa85023918@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Fri, 12 May 2017 17:18:50 +0100
> From: Bert Kenward <bkenward@solarflare.com>
>
> The revision enum values (eg EFX_REV_HUNT_A0) form part of our API,
> and are included in ethtool. If these are inconsistent then ethtool
> will print garbage for a register dump (ethtool -d).
>
> Fixes: 5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver")
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH] vmxnet3: ensure that adapter is in proper state during force_close
From: David Miller @ 2017-05-12 16:24 UTC (permalink / raw)
To: nhorman; +Cc: netdev, skhare, pv-drivers
In-Reply-To: <20170512160001.24425-1-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 12 May 2017 12:00:01 -0400
> There are several paths in vmxnet3, where settings changes cause the
> adapter to be brought down and back up (vmxnet3_set_ringparam among
> them). Should part of the reset operation fail, these paths call
> vmxnet3_force_close, which enables all napi instances prior to calling
> dev_close (with the expectation that vmxnet3_close will then properly
> disable them again). However, vmxnet3_force_close neglects to clear
> VMXNET3_STATE_BIT_QUIESCED prior to calling dev_close. As a result
> vmxnet3_quiesce_dev (called from vmxnet3_close), returns early, and
> leaves all the napi instances in a enabled state while the device itself
> is closed. If a device in this state is activated again, napi_enable
> will be called on already enabled napi_instances, leading to a BUG halt.
>
> The fix is to simply enausre that the QUIESCED bit is cleared in
> vmxnet3_force_close to allow quesence to be completed properly on close.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Looks good, applied, thanks Neil.
^ permalink raw reply
* Re: [PATCH] mdio: mux: fix device_node_continue.cocci warnings
From: David Miller @ 2017-05-12 16:22 UTC (permalink / raw)
To: julia.lawall
Cc: netdev, jon.mason, andrew, f.fainelli, kbuild-all, linux-kernel
In-Reply-To: <alpine.DEB.2.20.1705122252440.3416@hadrien>
From: Julia Lawall <julia.lawall@lip6.fr>
Date: Fri, 12 May 2017 22:54:23 +0800 (SGT)
> Device node iterators put the previous value of the index variable, so an
> explicit put causes a double put.
...
> @@ -169,7 +169,6 @@ int mdio_mux_init(struct device *dev,
> if (r) {
> mdiobus_free(cb->mii_bus);
> devm_kfree(dev, cb);
> - of_node_put(child_bus_node);
> } else {
I think we're instead simply missing a break; statement here.
^ permalink raw reply
* Re: [PATCH net-next] tools: hv: Add clean up for included files in Ubuntu net config
From: David Miller @ 2017-05-12 16:20 UTC (permalink / raw)
To: haiyangz, haiyangz; +Cc: netdev, kys, olaf, vkuznets, linux-kernel
In-Reply-To: <1494598413-19106-1-git-send-email-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@exchange.microsoft.com>
Date: Fri, 12 May 2017 07:13:33 -0700
>
> + local fn
> + for fn in "${fnlist[@]}"
> + do
> awk "/$nic_end/{x=0} x{next} /$nic_start/{x=1;next} 1" $fn >$tmpfl
>
> cp $tmpfl $fn
> + done
Please indent the body of this loop properly.
^ permalink raw reply
* [PATCH net] sfc: revert changes to NIC revision numbers
From: Edward Cree @ 2017-05-12 16:18 UTC (permalink / raw)
To: linux-net-drivers, davem; +Cc: netdev
From: Bert Kenward <bkenward@solarflare.com>
The revision enum values (eg EFX_REV_HUNT_A0) form part of our API,
and are included in ethtool. If these are inconsistent then ethtool
will print garbage for a register dump (ethtool -d).
Fixes: 5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver")
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/nic.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/nic.h b/drivers/net/ethernet/sfc/nic.h
index 7b916aa..4d7fb8a 100644
--- a/drivers/net/ethernet/sfc/nic.h
+++ b/drivers/net/ethernet/sfc/nic.h
@@ -18,8 +18,12 @@
#include "mcdi.h"
enum {
- EFX_REV_SIENA_A0 = 0,
- EFX_REV_HUNT_A0 = 1,
+ /* Revisions 0-2 were Falcon A0, A1 and B0 respectively.
+ * They are not supported by this driver but these revision numbers
+ * form part of the ethtool API for register dumping.
+ */
+ EFX_REV_SIENA_A0 = 3,
+ EFX_REV_HUNT_A0 = 4,
};
static inline int efx_nic_rev(struct efx_nic *efx)
^ permalink raw reply related
* Re: [PATCH] net: ch9200: add missing USB-descriptor endianness conversions
From: David Miller @ 2017-05-12 16:16 UTC (permalink / raw)
To: johan; +Cc: linux-usb, netdev
In-Reply-To: <20170512101326.2029-1-johan@kernel.org>
From: Johan Hovold <johan@kernel.org>
Date: Fri, 12 May 2017 12:13:26 +0200
> Add the missing endianness conversions to a debug statement printing
> the USB device-descriptor idVendor and idProduct fields during probe.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: irda: irda-usb: fix firmware name on big-endian hosts
From: David Miller @ 2017-05-12 16:16 UTC (permalink / raw)
To: johan; +Cc: samuel, netdev, stable, nfedchik
In-Reply-To: <20170512101113.1935-1-johan@kernel.org>
From: Johan Hovold <johan@kernel.org>
Date: Fri, 12 May 2017 12:11:13 +0200
> Add missing endianness conversion when using the USB device-descriptor
> bcdDevice field to construct a firmware file name.
>
> Fixes: 8ef80aef118e ("[IRDA]: irda-usb.c: STIR421x cleanups")
> Cc: stable <stable@vger.kernel.org> # 2.6.18
> Cc: Nick Fedchik <nfedchik@atlantic-link.com.ua>
> Signed-off-by: Johan Hovold <johan@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: add default case to switch
From: David Miller @ 2017-05-12 16:15 UTC (permalink / raw)
To: garsilva; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20170512031129.GA4065@embeddedgus>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Thu, 11 May 2017 22:11:29 -0500
> Add default case to switch in order to avoid any chance of using an
> uninitialized variable _low_, in case s->type does not match any of
> the listed case values.
>
> Addresses-Coverity-ID: 1398130
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied, thanks.
^ permalink raw reply
* Re: [net 1/6] net/mlx5e: Use a spinlock to synchronize statistics
From: David Miller @ 2017-05-12 16:13 UTC (permalink / raw)
To: saeedm; +Cc: netdev, galp, kernel-team
In-Reply-To: <20170512115650.11635-2-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Fri, 12 May 2017 14:56:45 +0300
> From: Gal Pressman <galp@mellanox.com>
>
> Add a spinlock to prevent races when querying statistics, for example
> querying counters in the middle of a non atomic memcpy() operation in
> mlx5e_update_stats().
>
> This RW lock should be held when accessing priv->stats, to prevent other
> reads/writes.
>
> Fixes: 9218b44dcc05 ("net/mlx5e: Statistics handling refactoring")
> Signed-off-by: Gal Pressman <galp@mellanox.com>
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: kernel-team@fb.com
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
This is overkill, and that rwlock is going to show up in perf for some
workloads.
Furthermore, two kzalloc()'s for a single state update operation?
That's not reasonable either.
Use a seqlock, which is the primitive for handling this kind of
situation cheaply, and adds no atomics to the read path.
Thank you.
^ permalink raw reply
* 48683 netdev
From: mari.kayhko @ 2017-05-12 16:02 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 829.zip --]
[-- Type: application/zip, Size: 1985 bytes --]
^ permalink raw reply
* [PATCH] vmxnet3: ensure that adapter is in proper state during force_close
From: Neil Horman @ 2017-05-12 16:00 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Shrikrishna Khare, VMware, Inc., David S. Miller
There are several paths in vmxnet3, where settings changes cause the
adapter to be brought down and back up (vmxnet3_set_ringparam among
them). Should part of the reset operation fail, these paths call
vmxnet3_force_close, which enables all napi instances prior to calling
dev_close (with the expectation that vmxnet3_close will then properly
disable them again). However, vmxnet3_force_close neglects to clear
VMXNET3_STATE_BIT_QUIESCED prior to calling dev_close. As a result
vmxnet3_quiesce_dev (called from vmxnet3_close), returns early, and
leaves all the napi instances in a enabled state while the device itself
is closed. If a device in this state is activated again, napi_enable
will be called on already enabled napi_instances, leading to a BUG halt.
The fix is to simply enausre that the QUIESCED bit is cleared in
vmxnet3_force_close to allow quesence to be completed properly on close.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Shrikrishna Khare <skhare@vmware.com>
CC: "VMware, Inc." <pv-drivers@vmware.com>
CC: "David S. Miller" <davem@davemloft.net>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 25bc764..d1c7029 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2962,6 +2962,11 @@ vmxnet3_force_close(struct vmxnet3_adapter *adapter)
/* we need to enable NAPI, otherwise dev_close will deadlock */
for (i = 0; i < adapter->num_rx_queues; i++)
napi_enable(&adapter->rx_queue[i].napi);
+ /*
+ * Need to clear the quiesce bit to ensure that vmxnet3_close
+ * can quiesce the device properly
+ */
+ clear_bit(VMXNET3_STATE_BIT_QUIESCED, &adapter->state);
dev_close(adapter->netdev);
}
--
2.9.3
^ permalink raw reply related
* Re: Queries regarding TAP interface
From: Stephen Hemminger @ 2017-05-12 15:52 UTC (permalink / raw)
To: Kashyap, Saurav; +Cc: netdev@vger.kernel.org
In-Reply-To: <C7C039BE-EDC9-4E82-BC66-EEDE814F9E56@cavium.com>
On Fri, 12 May 2017 05:02:37 +0000
"Kashyap, Saurav" <Saurav.Kashyap@cavium.com> wrote:
> Hi,
>
> I am using upstream kernel 4.11.0 and base is RHEL 7.2. I am playing around with TAP devices and created it using following commands
> =======
> ip tuntap add tap10 mode tap
> ip addr add 172.28.12.1/24 dev tap10
> ip link set tap10 up
> ethtool -s tap10 msglvl 1
> =======
>
> I enabled debug in driver and also added some prints in tun_net_xmit function. I tried to ping using tap10 but I don’t see request reaching driver. I also tried to create a bridge using brctl and link with physical ethernet interface but it didn’t work.
>
> Second experiment I did was to create two tap device on same system and try pinging one from another, that also didn’t worked.
> I have following queries
> 1) Is I am missing something?
> 2) Is is possible to hook my own tx/rx to that tap device, so that data packets actually goes on wire?
> 3) Does DHCP works with tap devices?
>
>
> Thanks,
> ~Saurav
>
Don't you need an application reading/writing the tap device?
The carrier state of tap device is up/down based on whether the corresponding tap device is open
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Implement limits on hop by hop and destination options
From: David Miller @ 2017-05-12 15:38 UTC (permalink / raw)
To: tom; +Cc: netdev, kafai
In-Reply-To: <1494451999-19031-1-git-send-email-tom@herbertland.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 10 May 2017 14:33:19 -0700
> RFC 2460 (IPv6) defines hop by hop options and destination options
> extension headers. Both of these carry a list of TLVs which is
> only limited by the maximum length of the extension header (2048
> bytes). By the spec a host must process all the TLVs in these
> options, however these could be used as a fairly obvious
> denial of service attack. I think this could in fact be
> a significant DOS vector on the Internet, one mitigating
> factor might be that many FWs drop all packets with EH (and
> obviously this is only IPv6) so an Internet wide attack might not
> be so effective (yet!).
>
> By my calculation, the worse case packet with TLVs in a standard
> 1500 byte MTU packet that would be processed by the stack contains
> 1282 invidual TLVs (including pad TLVS) or 724 two byte TLVs. I
> wrote a quick test program that floods a whole bunch of these
> packets to a host and sure enough there is substantial time spent
> in ip6_parse_tlv. These packets contain nothing but unknown TLVS
> (that are ignored), TLV padding, and bogus UDP header with zero
> payload length.
...
> Default values are set to 8 for options counts, and set to INT_MAX
> for maximum length. Note the choice to limit options to 8 is an
> arbitrary guess (roughly based on the fact that the stack supports
> three HBH options and just one destination option).
So the maximum number of TLVs we could process is some function of the
option count limit, and the number of padding TLVs that can be stuffed
alongside of those 8 non-padding options?
^ permalink raw reply
* Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.
From: David Miller @ 2017-05-12 15:24 UTC (permalink / raw)
To: mq; +Cc: netdev, linux-kernel, dsa, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20170512111510.2697-1-mq@ucw.cz>
From: Jan Moskyto Matejka <mq@ucw.cz>
Date: Fri, 12 May 2017 13:15:10 +0200
> -int rt6_dump_route(struct rt6_info *rt, void *p_arg);
> +int rt6_dump_route(struct rt6_info *rt, void *p_arg, int truncate);
Please use "bool" and "true"/"false" for boolean values.
What does ipv4 do in this situation?
I'm hesitant to be OK with adding a new nlmsg flag just for this case
if we solve this problem differently and using existing mechanisms
elsewhere.
^ permalink raw reply
* Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64__
From: Andrew Lunn @ 2017-05-12 15:17 UTC (permalink / raw)
To: David Miller; +Cc: ast, daniel, netdev
In-Reply-To: <20170512.104624.902298156565692816.davem@davemloft.net>
On Fri, May 12, 2017 at 10:46:24AM -0400, David Miller wrote:
> From: Alexei Starovoitov <ast@fb.com>
> Date: Thu, 11 May 2017 22:07:04 -0700
>
> > On 5/11/17 6:29 PM, David Miller wrote:
> >> This whole thing go me thinking however. What do you expect to happen
> >> on 32-bit architectures implementing an eBPF JIT?
> >
> > I doubt any 32-bit cpu architectures will do JIT in the near future.
>
> ARM 32-bit is being implemented as we speak, in fact it's been discussed
> on this very list over the past week.
It could be XDP is interesting on small embedded systems, i.e ARM32
and MIPS, used in WiFi access points and the like. I've heard it said
that the Linux network stack has become too big to run well on these
systems, it no longer fits in the instruction cache. It would be
interesting to see if XDP/eBPF can be used for handling part of the
packet load without thrashing the instruction cache.
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] net: macb: Add tsu_clk to device tree
From: Rob Herring @ 2017-05-12 15:12 UTC (permalink / raw)
To: Rafal Ozieblo
Cc: David Miller, nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
Richard Cochran, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
harini.katakam-gjFFaj9aHVfQT0dZR+AlfA,
andrei.pistirica-UWL1GkI3JZL3oGB3hsPCZA
In-Reply-To: <1494322010-15179-1-git-send-email-rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
On Tue, May 09, 2017 at 10:26:50AM +0100, Rafal Ozieblo wrote:
> Signed-off-by: Rafal Ozieblo <rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/macb.txt | 1 +
> 1 file changed, 1 insertion(+)
I acked the last version, please add acks when posting new versions.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] mdio: mux: fix device_node_continue.cocci warnings
From: Julia Lawall @ 2017-05-12 14:54 UTC (permalink / raw)
To: netdev, Jon Mason; +Cc: Andrew Lunn, Florian Fainelli, kbuild-all, linux-kernel
Device node iterators put the previous value of the index variable, so an
explicit put causes a double put.
In particular, of_mdiobus_register can fail before doing anything
interesting, so one could view it as a no-op from the reference count
point of view.
Generated by: scripts/coccinelle/iterators/device_node_continue.cocci
CC: Jon Mason <jon.mason@broadcom.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: 8785ded64cfb68b8d8b2583c7c1fc611f99eabf2
commit: b60161668199ac62011c024adc9e66713b9554e7 [13999/14120] mdio: mux:
mdio-mux.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/net/phy/mdio-mux.c
+++ b/drivers/net/phy/mdio-mux.c
@@ -169,7 +169,6 @@ int mdio_mux_init(struct device *dev,
if (r) {
mdiobus_free(cb->mii_bus);
devm_kfree(dev, cb);
- of_node_put(child_bus_node);
} else {
cb->next = pb->children;
pb->children = cb;
^ permalink raw reply
* Re: [PATCH net] sctp: fix src address selection if using secondary addresses for ipv6
From: David Miller @ 2017-05-12 14:51 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <7bbcf970cdc9eca6de6132a942d8c46eb7e138c0.1494571192.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Fri, 12 May 2017 14:39:52 +0800
> Commit 0ca50d12fe46 ("sctp: fix src address selection if using secondary
> addresses") has fixed a src address selection issue when using secondary
> addresses for ipv4.
>
> Now sctp ipv6 also has the similar issue. When using a secondary address,
> sctp_v6_get_dst tries to choose the saddr which has the most same bits
> with the daddr by sctp_v6_addr_match_len. It may make some cases not work
> as expected.
...
> This patch is to fix it with the same way as Marcelo's fix for sctp ipv4.
> As no ip_dev_find for ipv6, this patch is to use ipv6_chk_addr to check
> if the saddr is in a dev instead.
>
> Note that for backwards compatibility, it will still do the addr_match_len
> check here when no optimal is found.
>
> Reported-by: Patrick Talbert <ptalbert@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64__
From: David Miller @ 2017-05-12 14:46 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev
In-Reply-To: <0aab1aec-814c-e496-4254-ca33a81f8c7f@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Thu, 11 May 2017 22:07:04 -0700
> On 5/11/17 6:29 PM, David Miller wrote:
>> This whole thing go me thinking however. What do you expect to happen
>> on 32-bit architectures implementing an eBPF JIT?
>
> I doubt any 32-bit cpu architectures will do JIT in the near future.
ARM 32-bit is being implemented as we speak, in fact it's been discussed
on this very list over the past week.
^ permalink raw reply
* Re: [PATCH] ravb: add wake-on-lan support via magic packet
From: Geert Uytterhoeven @ 2017-05-12 14:43 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Sergei Shtylyov, netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170512143242.GA13939@bigcity.dyn.berto.se>
Hi Niklas,
On Fri, May 12, 2017 at 4:32 PM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> On 2017-05-12 14:58:53 +0200, Niklas Söderlund wrote:
>> On 2017-05-12 14:47:53 +0200, Geert Uytterhoeven wrote:
>> > On Fri, May 12, 2017 at 12:27 AM, Niklas Söderlund
>> > <niklas.soderlund+renesas@ragnatech.se> wrote:
>> > > WoL is enabled in the suspend callback by setting MagicPacket detection
>> > > and disabling all interrupts expect MagicPacket. In the resume path the
>> > > driver needs to reset the hardware to rearm the WoL logic, this prevents
>> > > the driver from simply restoring the registers and to take advantage of
>> > > that ravb was not suspended to reduce resume time. To reset the
>> > > hardware the driver closes the device, sets it in reset mode and reopens
>> > > the device just like it would do in a normal suspend/resume scenario
>> > > without WoL enabled, but it both closes and opens the device in the
>> > > resume callback since the device needs to be reset for WoL to work.
>> > >
>> > > One quirk needed for WoL is that the module clock needs to be prevented
>> > > from being switched off by Runtime PM. To keep the clock alive the
>> > > suspend callback need to call clk_enable() directly to increase the
>> > > usage count of the clock. Then when Runtime PM decreases the clock usage
>> > > count it won't reach 0 and be switched off.
>> > >
>> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>> >
>> > Thanks for your patch!
>> >
>> > Wake-on-LAN now works for me on Salvator-X (both H3 and M3).
>> >
>> > However, after a few cycles, Ethernet stopped working, because CMA ran out of
>> > memory:
>> >
>> > cma: cma_alloc: alloc failed, req-size: 6 pages, ret: -4
>> > dpm_run_callback(): ravb_resume+0x0/0x148 returns -12
>> > PM: Device e6800000.ethernet failed to resume: error -12
>> >
>> > Are we still missing some ravb patches in net-next, or is this a different
>> > issue?
>>
>> Interesting, I did a 100 loop test on H3 based on v4.11 without any
>> issues. What are you using as a base for your test and I will test if I
>> can reproduce it.
>
> I re-ran my test based on renesas-drivers-2017-05-02-v4.11 using the
> arm64 defconfig. And was not able to see this :-(
>
> My TC is basically a expect script that do:
>
> ethtool -s eth0 wol g
>
> for (i = 0; i < 100; i++) {
> echo s2idle > /sys/power/mem_sleep
> echo mem > /sys/power/state
>
> sleep 5
>
> HOST: etherwake -i net0 2e:09:0a:00:83:90
>
> WAIT_FOR_CONSOLE
> }
>
> I use the default DT and arm64 defconfig and no other modifications. I'm
> testing on H3 ES1.x board. What can be the different for us?
I'm not using "echo s2idle > /sys/power/mem_sleep", as renesas-drivers still
has my patches to not use PSCI suspend if any other wake-up sources
are configured.
I'll retry later...
>> > When using PSCI suspend/resume, and Wake-on-LAN cannot work due to
>> > PSCI firmware issues, Ethernet fails to come up afterwards:
>> >
>> > ravb e6800000.ethernet eth0: failed to switch device to config mode
>> > ravb e6800000.ethernet eth0: device will be stopped after h/w
>> > processes are done.
>> > ravb e6800000.ethernet eth0: failed to switch device to config mode
>> > dpm_run_callback(): ravb_resume+0x0/0x148 returns -110
>> > PM: Device e6800000.ethernet failed to resume: error -110
>> >
>> > Your resume routine cannot assume RAVB is in a sane mode, as it will
>> > have been reset if PSCI suspend was used.
>>
>> Ouch, yes this is true thanks for reporting will look in to it.
>>
>> The problem is that in the resume handler if WoL is enabled it will try
>> to close the device before reinitializing it from reset state. If WoL is
>> not enabled the device will be closed at suspend time so no need to
>> close it before restoring operation from reset in the resume handler.
>
> I was not able to reproduce this fault neither :-( But here I see
> something is wrong, nothing is outputted on the console if WoL is
> enabled:
>
> echo 0 > /sys/module/printk/parameters/console_suspend
> i2cset -f -y 7 0x30 0x20 0x0F
> <Flip SW23>
> echo mem > /sys/power/state
> <Flip SW23>
> <System wakes up>
>
> While:
> ethtool -s eth0 wol g
> echo 0 > /sys/module/printk/parameters/console_suspend
> i2cset -f -y 7 0x30 0x20 0x0F
> <Flip SW23>
> echo mem > /sys/power/state
> <Flip SW23>
> <Nothing happens on the console, not even firmware info is printed>
>
> Are you enabling anything else then console_suspend to be able to
> capture output at this point? I'm using the same setup tag and config as
> I described above.
With renesas-drivers, it will refuse to use PSCI suspend if any other wake-up
sources are configured, i.e. try
echo disabled > /sys/devices/platform/soc/e6800000.ethernet/power/wakeup
Good luck, and have a nice weekend!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 1/2] net: Added mtu parameter to dev_forward_skb calls
From: Fredrik Markström @ 2017-05-12 14:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Eric Dumazet, Daniel Borkmann, netdev, bridge, linux-kernel,
Alexei Starovoitov, David S. Miller
In-Reply-To: <20170511124454.473dd56e@xeon-e3>
On Thu, May 11, 2017 at 9:44 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Thu, 11 May 2017 21:10:11 +0200
> Fredrik Markström <fredrik.markstrom@gmail.com> wrote:
>
>> On Thu, May 11, 2017 at 6:01 PM, Stephen Hemminger
>> <stephen@networkplumber.org> wrote:
>> > On Thu, 11 May 2017 15:46:27 +0200
>> > Fredrik Markstrom <fredrik.markstrom@gmail.com> wrote:
>> >
>> >> From: Fredrik Markström <fredrik.markstrom@gmail.com>
>> >>
>> >> is_skb_forwardable() currently checks if the packet size is <= mtu of
>> >> the receiving interface. This is not consistent with most of the hardware
>> >> ethernet drivers that happily receives packets larger then MTU.
>> >
>> > Wrong.
>>
>> What is "Wrong" ? I was initially skeptical to implement this patch,
>> since it feels odd to have different MTU:s set on the two sides of a
>> link. After consulting some IP people and the RFC:s I kind of changed
>> my mind and thought I'd give it a shot. In the RFCs I couldn't find
>> anything that defined when and when not a received packet should be
>> dropped.
>>
>> >
>> > Hardware interfaces are free to drop any packet greater than MTU (actually MTU + VLAN).
>> > The actual limit is a function of the hardware. Some hardware can only limit by
>> > power of 2; some can only limit frames larger than 1500; some have no limiting at all.
>>
>> Agreed. The purpose of these patches is to be able to configure an
>> veth interface to mimic these different behaviors. Non of the Ethernet
>> interfaces I have access to drops packets due to them being larger
>> then the configured MTU like veth does.
>>
>> Being able to mimic real Ethernet hardware is useful when
>> consolidating hardware using containers/namespaces.
>>
>> In a reply to a comment from David Miller in my previous version of
>> the patch I attached the example below to demonstrate the case in
>> detail.
>>
>> This works with all ethernet hardware setups I have access to:
>>
>
> Why not just use an iptables rule to enforce what ever semantic you
> want?
>
I think that would be ok, but I can't find anything but TCPMSS but
that's only for TCP.
/Fredrik
^ permalink raw reply
* Re: [PATCH] ravb: add wake-on-lan support via magic packet
From: Niklas Söderlund @ 2017-05-12 14:32 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Sergei Shtylyov, netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170512125853.GH31437@bigcity.dyn.berto.se>
Hi Geert,
On 2017-05-12 14:58:53 +0200, Niklas Söderlund wrote:
> Hi Geert,
>
> Thanks for testing.
>
> On 2017-05-12 14:47:53 +0200, Geert Uytterhoeven wrote:
> > Hi Niklas,
> >
> > On Fri, May 12, 2017 at 12:27 AM, Niklas Söderlund
> > <niklas.soderlund+renesas@ragnatech.se> wrote:
> > > WoL is enabled in the suspend callback by setting MagicPacket detection
> > > and disabling all interrupts expect MagicPacket. In the resume path the
> > > driver needs to reset the hardware to rearm the WoL logic, this prevents
> > > the driver from simply restoring the registers and to take advantage of
> > > that ravb was not suspended to reduce resume time. To reset the
> > > hardware the driver closes the device, sets it in reset mode and reopens
> > > the device just like it would do in a normal suspend/resume scenario
> > > without WoL enabled, but it both closes and opens the device in the
> > > resume callback since the device needs to be reset for WoL to work.
> > >
> > > One quirk needed for WoL is that the module clock needs to be prevented
> > > from being switched off by Runtime PM. To keep the clock alive the
> > > suspend callback need to call clk_enable() directly to increase the
> > > usage count of the clock. Then when Runtime PM decreases the clock usage
> > > count it won't reach 0 and be switched off.
> > >
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> >
> > Thanks for your patch!
> >
> > Wake-on-LAN now works for me on Salvator-X (both H3 and M3).
> >
> > However, after a few cycles, Ethernet stopped working, because CMA ran out of
> > memory:
> >
> > cma: cma_alloc: alloc failed, req-size: 6 pages, ret: -4
> > dpm_run_callback(): ravb_resume+0x0/0x148 returns -12
> > PM: Device e6800000.ethernet failed to resume: error -12
> >
> > Are we still missing some ravb patches in net-next, or is this a different
> > issue?
>
> Interesting, I did a 100 loop test on H3 based on v4.11 without any
> issues. What are you using as a base for your test and I will test if I
> can reproduce it.
I re-ran my test based on renesas-drivers-2017-05-02-v4.11 using the
arm64 defconfig. And was not able to see this :-(
My TC is basically a expect script that do:
ethtool -s eth0 wol g
for (i = 0; i < 100; i++) {
echo s2idle > /sys/power/mem_sleep
echo mem > /sys/power/state
sleep 5
HOST: etherwake -i net0 2e:09:0a:00:83:90
WAIT_FOR_CONSOLE
}
I use the default DT and arm64 defconfig and no other modifications. I'm
testing on H3 ES1.x board. What can be the different for us?
>
> >
> > When using PSCI suspend/resume, and Wake-on-LAN cannot work due to
> > PSCI firmware issues, Ethernet fails to come up afterwards:
> >
> > ravb e6800000.ethernet eth0: failed to switch device to config mode
> > ravb e6800000.ethernet eth0: device will be stopped after h/w
> > processes are done.
> > ravb e6800000.ethernet eth0: failed to switch device to config mode
> > dpm_run_callback(): ravb_resume+0x0/0x148 returns -110
> > PM: Device e6800000.ethernet failed to resume: error -110
> >
> > Your resume routine cannot assume RAVB is in a sane mode, as it will
> > have been reset if PSCI suspend was used.
>
> Ouch, yes this is true thanks for reporting will look in to it.
>
> The problem is that in the resume handler if WoL is enabled it will try
> to close the device before reinitializing it from reset state. If WoL is
> not enabled the device will be closed at suspend time so no need to
> close it before restoring operation from reset in the resume handler.
I was not able to reproduce this fault neither :-( But here I see
something is wrong, nothing is outputted on the console if WoL is
enabled:
echo 0 > /sys/module/printk/parameters/console_suspend
i2cset -f -y 7 0x30 0x20 0x0F
<Flip SW23>
echo mem > /sys/power/state
<Flip SW23>
<System wakes up>
While:
ethtool -s eth0 wol g
echo 0 > /sys/module/printk/parameters/console_suspend
i2cset -f -y 7 0x30 0x20 0x0F
<Flip SW23>
echo mem > /sys/power/state
<Flip SW23>
<Nothing happens on the console, not even firmware info is printed>
Are you enabling anything else then console_suspend to be able to
capture output at this point? I'm using the same setup tag and config as
I described above.
>
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> > -- Linus Torvalds
>
> --
> Regards,
> Niklas Söderlund
--
Regards,
Niklas Söderlund
^ permalink raw reply
* [PATCH net-next] tools: hv: Add clean up for included files in Ubuntu net config
From: Haiyang Zhang @ 2017-05-12 14:13 UTC (permalink / raw)
To: davem, netdev; +Cc: haiyangz, kys, olaf, vkuznets, linux-kernel
From: Haiyang Zhang <haiyangz@microsoft.com>
The clean up function is updated to cover duplicate config info in
files included by "source" key word in Ubuntu network config.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
tools/hv/bondvf.sh | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/tools/hv/bondvf.sh b/tools/hv/bondvf.sh
index d85968c..1f42604 100755
--- a/tools/hv/bondvf.sh
+++ b/tools/hv/bondvf.sh
@@ -102,15 +102,29 @@ function create_bond_cfg_redhat {
}
function del_eth_cfg_ubuntu {
- local fn=$cfgdir/interfaces
+ local mainfn=$cfgdir/interfaces
+ local fnlist=( $mainfn )
+
+ local dirlist=(`awk '/^[ \t]*source/{print $2}' $mainfn`)
+
+ local i
+ for i in "${dirlist[@]}"
+ do
+ fnlist+=(`ls $i 2>/dev/null`)
+ done
+
local tmpfl=$(mktemp)
local nic_start='^[ \t]*(auto|iface|mapping|allow-.*)[ \t]+'$1
local nic_end='^[ \t]*(auto|iface|mapping|allow-.*|source)'
+ local fn
+ for fn in "${fnlist[@]}"
+ do
awk "/$nic_end/{x=0} x{next} /$nic_start/{x=1;next} 1" $fn >$tmpfl
cp $tmpfl $fn
+ done
rm $tmpfl
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 0/5] net-next: ethernet: add sun8i-emac driver
From: Corentin Labbe @ 2017-05-12 14:03 UTC (permalink / raw)
To: Mahesh Nanavalla
Cc: linux-sunxi, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <593bffd3-a04a-421b-86d4-ed3035c79445-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
On Fri, May 12, 2017 at 06:09:17AM -0700, Mahesh Nanavalla wrote:
> Hi All,
>
> I am new to Ethernet Driver.
>
> I am working on NanoPI Neo Based on SUN8i-H3 SOC ...
>
> can any body helpout to up the Ethernet on The NanoPi Neo.
>
Ouch, you answer to a very old email (1 year!).
The best way to check for support of your board is linux-sunxi.org
Anyway, I will update this week my github branch dwmac-sun8i branch with a DT patch for your board.
If it works, contact me directly.
Regards
Corentin Labbe
^ 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