Hi,
On Wed, 11 May 2016 09:47:27 -0700 Tom Herbert wrote:
> When performing foo-over-UDP, UDP packets are processed by the
> encapsulation handler which returns another protocol to process.
> This may result in processing two (or more) protocols in the
> loop that are marked as INET6_PROTO_FINAL.
From: Tien Hock Loh
Adds SGMII support for dwmac-socfpga to enable the SGMII PHY when phy-mode
of the dwmac is set to sgmii.
Signed-off-by: Tien Hock Loh
---
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 340 -
1 file changed, 330 insertions(+), 10 deletions(-)
diff
Original implementation commit e54bcde3d69d ("arm64: eBPF JIT compiler")
had the relevant code paths, but due to an oversight always fail jiting.
As a result, we had been falling back to BPF interpreter whenever a BPF
program has JMP_JSET_{X,K} instructions.
With this fix, we confirm that the cor
Please disregard this patch. Wrong patch attached, I'll send a correct
one in a short while.
On Fri, May 13, 2016 at 2:27 PM, wrote:
> From: Tien Hock Loh
>
> Adds SGMII support for dwmac-socfpga to enable the SGMII PHY when phy-mode
> of the dwmac is set to sgmii.
>
> Signed-off-by: Tien Hock
Hi,
On Thu, 12 May 2016 14:45:36 -0700 Tom Herbert wrote:
> On Thu, May 12, 2016 at 1:23 PM, Shmulik Ladkani
> wrote:
> >> @@ -222,13 +222,14 @@ static int ip6_input_finish(struct net *net, struct
> >> sock *sk, struct sk_buff *sk
> >>*/
> >>
> >> rcu_read_lock();
> >> -resubmit:
Hello Sergei,
On Fri, May 13, 2016 at 12:41:47AM +0300, Sergei Shtylyov wrote:
> On 05/12/2016 01:00 PM, Uwe Kleine-König wrote:
>
> >The framework only asserts (for now) that the reset gpio is not active.
> >
> >Signed-off-by: Uwe Kleine-König
> >---
> > Documentation/devicetree/bindings/net/ph
Fri, May 13, 2016 at 12:23:13AM CEST, f.faine...@gmail.com wrote:
>2016-05-12 14:10 GMT-07:00 Roopa Prabhu :
>> On 5/12/16, 4:48 AM, Jiri Pirko wrote:
>>> From: Nogah Frankel
>>>
>>> Till now we had a ndo statistics function that returned SW statistics.
>>> We want to change the "basic" statistics
From: Soheil Hassas Yeganeh
Date: Fri, 13 May 2016 00:47:10 -0400
> From: Soheil Hassas Yeganeh
>
> SO_TIMESTAMP(NS), RXQ_OVFL, and WIFI_STATUS can be returned as
> receive-side control messages from recvmsg(). Although invalid,
> some applications may reflect those receive-side control message
Thu, May 12, 2016 at 11:10:08PM CEST, ro...@cumulusnetworks.com wrote:
>On 5/12/16, 4:48 AM, Jiri Pirko wrote:
>> From: Nogah Frankel
>>
>> Till now we had a ndo statistics function that returned SW statistics.
>> We want to change the "basic" statistics to return HW statistics if
>> available.
>>
From: Paul Durrant
Date: Thu, 12 May 2016 14:43:03 +0100
> Patch 562abd39 "xen-netback: support multiple extra info fragments
> passed from frontend" contained a mistake which can result in an in-
> correct number of responses being generated when handling errors
> encountered when processing pac
From: Alexander Duyck
Date: Thu, 12 May 2016 16:23:44 -0700
> While testing an OpenStack configuration using VXLANs I saw the following
> call trace:
...
> The following trace is seen when receiving a DHCP request over a flow-based
> VXLAN tunnel. I believe this is caused by the metadata dst ha
Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less
CPUs were assigned. especially when DCB is enabled, so we should take
num_online_cpus() as top limit, and aslo to make sure every TC has
at least one queue, take the MAX_TRAFFIC_CLASS as bottom limit of queues
number.
Signed-off-
From: Eric Dumazet
Date: Thu, 12 May 2016 21:41:39 -0700
> From: Eric Dumazet
>
> sunrpc is using SOCKWQ_ASYNC_NOSPACE without setting SOCK_FASYNC,
> so the recent optimizations done in sk_set_bit() and sk_clear_bit()
> broke it.
>
> There is still the risk that a subsequent sock_fasync() call
From: Soheil Hassas Yeganeh
SO_TIMESTAMP(NS), RXQ_OVFL, and WIFI_STATUS can be returned as
receive-side control messages from recvmsg(). Although invalid,
some applications may reflect those receive-side control messages
back to sendmsg(). Since socket-level control messages were being
ignored in
On Thu, 2016-05-12 at 16:23 -0700, Alexander Duyck wrote:
> While testing an OpenStack configuration using VXLANs I saw the following
> call trace:
> The following trace is seen when receiving a DHCP request over a flow-based
> VXLAN tunnel. I believe this is caused by the metadata dst having a N
From: Eric Dumazet
sunrpc is using SOCKWQ_ASYNC_NOSPACE without setting SOCK_FASYNC,
so the recent optimizations done in sk_set_bit() and sk_clear_bit()
broke it.
There is still the risk that a subsequent sock_fasync() call
would clear SOCK_FASYNC, but sunrpc does not use this yet.
Fixes: 9317b
Hi Tom,
On Thu, 12 May 2016 14:45:36 -0700 Tom Herbert wrote:
> On Thu, May 12, 2016 at 1:23 PM, Shmulik Ladkani
> wrote:
> > On Wed, 11 May 2016 09:47:26 -0700 Tom Herbert
> > wrote:
> >> In ip6_input_finish the protocol handle returns a value greater than
> >> zero the packet needs to be r
> >>+ gpiod = fwnode_get_named_gpiod(&child->fwnode, "reset-gpios");
> >>+ /* Deassert the reset signal */
> >>+ if (!IS_ERR(gpiod))
> >>+ gpiod_direction_output(gpiod, 0);
> >
> >This is wrong I think. You must only ignore -ENODEV, all other error
>
>At least -ENOSYS should al
On Fri, May 13, 2016 at 6:02 AM, Arend van Spriel
wrote:
> On 12-05-16 11:34, Wei-Ning Huang wrote:
>> On Thu, May 12, 2016 at 2:33 AM, Dan Williams wrote:
>>> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote:
On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang
wrote:
>
> On
Hi,
Marcel Holtmann wrote:
> Hi Dave,
:
>> include/linux/netdevice.h | 6 +-
>> include/net/6lowpan.h | 24 ++
>> include/net/addrconf.h| 3 +
>> include/net/ndisc.h | 124 -
>> net/6lowpan/6lowpan_i.h | 2 +
>> net/6lowpan/Makefile | 2 +-
>
This set of patches export TCA_CLS_FLAGS_SKIP_HW to userspace and also
introduces another flag TCA_CLS_FLAGS_SKIP_SW. These flags enable offloading
u32 filters to either SW or HW only.
The default semantics with no flags is to add the filter to HW if possible and
also into SW.
With SKIP_HW flag,
Signed-off-by: Sridhar Samudrala
---
include/net/pkt_cls.h| 3 ---
include/uapi/linux/pkt_cls.h | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index caa5e18..339ef08 100644
--- a/include/net/pkt_cls.h
+++ b/include/net
On devices that support TC U32 offloads, this flag enables a filter to be
added only to HW. skip-sw and skip-hw are mutually exclusive flags. By
default without any flags, the filter is added to both HW and SW, but no
error checks are done in case of failure to add to HW. With skip-sw,
failure to a
While testing an OpenStack configuration using VXLANs I saw the following
call trace:
RIP: 0010:[] udp4_lib_lookup_skb+0x49/0x80
RSP: 0018:88103867bc50 EFLAGS: 00010286
RAX: 88103269bf00 RBX: 88103269bf00 RCX:
RDX: 4300 RSI: RDI: 8
Hi Devs,
I have the following system: Ubuntu 14.04.4 with the latest kernel
3.13.0-86-generic (x86_64), it has an MSI Z87-G55 motherboard with the
latest BIOS (v10.7), there is the Realtek 8111G NIC on it, which is
handled by the r8169 module by default.
I had the following issue:
1. I woke the P
2016-05-12 14:10 GMT-07:00 Roopa Prabhu :
> On 5/12/16, 4:48 AM, Jiri Pirko wrote:
>> From: Nogah Frankel
>>
>> Till now we had a ndo statistics function that returned SW statistics.
>> We want to change the "basic" statistics to return HW statistics if
>> available.
>> In this case we need to exp
On 12-05-16 11:34, Wei-Ning Huang wrote:
> On Thu, May 12, 2016 at 2:33 AM, Dan Williams wrote:
>> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote:
>>> On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang
>>> wrote:
On Fri, May 6, 2016 at 12:07 AM, Dan Williams
wrote:
>
On Thu, May 12, 2016 at 1:23 PM, Shmulik Ladkani
wrote:
> Hi Tom,
>
> On Wed, 11 May 2016 09:47:26 -0700 Tom Herbert wrote:
>> In ip6_input_finish the protocol handle returns a value greater than
>> zero the packet needs to be resubmitted using the returned protocol.
>> The returned protocol is b
On 05/12/2016 01:00 PM, Uwe Kleine-König wrote:
The framework only asserts (for now) that the reset gpio is not active.
Signed-off-by: Uwe Kleine-König
---
Documentation/devicetree/bindings/net/phy.txt | 3 +++
drivers/net/phy/phy_device.c | 8
2 files changed, 11 in
Hello.
On 05/12/2016 09:42 PM, Uwe Kleine-König wrote:
[we already talked about this patch in #armlinux, I'm now just
forwarding my comments on the list. Background was that I sent an easier
and less complete patch with the same idea. See
http://patchwork.ozlabs.org/patch/621418/]
[added Linus
From: Jon Maloy
Date: Wed, 11 May 2016 19:15:45 -0400
> When an ACTIVATE or data packet is received in a link in state
> ESTABLISHING, the link does not immediately change state to
> ESTABLISHED, but does instead return a LINK_UP event to the caller,
> which will execute the state change in a dif
On 5/12/16, 4:48 AM, Jiri Pirko wrote:
> From: Nogah Frankel
>
> Till now we had a ndo statistics function that returned SW statistics.
> We want to change the "basic" statistics to return HW statistics if
> available.
> In this case we need to expose a new ndo to return the SW statistics.
> Add a
Francois Romieu :
> Ard Biesheuvel :
> > On 12 May 2016 at 16:09, Francois Romieu wrote:
> [...]
> > By resurrecting 353176888386, I mean the patch that changes the
> > default for PCI express devices, so I think we are in agreement here ?
>
> Almost 353176888386: please modify it so that there
On Thu, 2016-05-12 at 22:58 +0200, Paolo Abeni wrote:
> On Thu, 2016-05-12 at 13:49 -0700, Eric Dumazet wrote:
> > On Thu, 2016-05-12 at 22:07 +0200, Paolo Abeni wrote:
> >
> > > > > static inline bool ksoftirqd_running(void)
> > > > > {
> > > > > return __this_cpu_read(ksoftirqd)->state ==
On Thu, 2016-05-12 at 13:49 -0700, Eric Dumazet wrote:
> On Thu, 2016-05-12 at 22:07 +0200, Paolo Abeni wrote:
>
> > > > static inline bool ksoftirqd_running(void)
> > > > {
> > > > return __this_cpu_read(ksoftirqd)->state == TASK_RUNNING;
> >
> > here something like:
> >
> > struct
From: Arnd Bergmann
Date: Wed, 11 May 2016 22:13:23 +0200
> I tried to fix this before, but my previous fix was incomplete
> and we can still get the same link error in randconfig builds
> because of the way that Kconfig treats the
>
> default y if MVNETA=y && MVNETA_BM_ENABLE
>
> line th
From: Fabio Estevam
Date: Wed, 11 May 2016 17:02:05 -0300
> From: Fabio Estevam
>
> Replace the hardcoded mask 0x00f0 with MICREL_PHY_ID_MASK for
> better readability.
>
> Suggested-by: Andrew Lunn
> Signed-off-by: Fabio Estevam
Applied.
On Thu, 2016-05-12 at 13:27 -0700, Alexander Duyck wrote:
> I'm assuming this was using skb_dst(skb)->dev in order to allow for
> use of this function by other callers since the original function
> __udp4_lib_lookup_skb was using that. If we change this then it
> reduces the likelihood of the cod
From: Haishuang Yan
Date: Wed, 11 May 2016 18:48:32 +0800
> When dealing with WCCP in gre6 tunnel, it sets the wrong tpi->protocol,
> that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic.
>
> Signed-off-by: Haishuang Yan
Applied.
From: Haishuang Yan
Date: Wed, 11 May 2016 18:48:31 +0800
> Do not include attribute IFLA_GRE_TOS.
>
> Signed-off-by: Haishuang Yan
Applied.
On Thu, 2016-05-12 at 22:07 +0200, Paolo Abeni wrote:
> > > static inline bool ksoftirqd_running(void)
> > > {
> > > return __this_cpu_read(ksoftirqd)->state == TASK_RUNNING;
>
> here something like:
>
> struct task_struct *tsk = __this_cpu_read(ksoftirqd);
> return tsk && (tsk->
Ard Biesheuvel :
> On 12 May 2016 at 16:09, Francois Romieu wrote:
[...]
> By resurrecting 353176888386, I mean the patch that changes the
> default for PCI express devices, so I think we are in agreement here ?
Almost 353176888386: please modify it so that there's no change of
behavior for mac_
On 05/12/2016 02:19 PM, Cong Wang wrote:
On Thu, May 12, 2016 at 1:05 PM, Chris Friesen wrote:
I hope this is a simple question...with legacy naming ethernet devices are
named ethX. Where is that X determined? I've been looking in
alloc_netdev_mqs() and friends, but haven't found it yet.
Hi Tom,
On Wed, 11 May 2016 09:47:26 -0700 Tom Herbert wrote:
> In ip6_input_finish the protocol handle returns a value greater than
> zero the packet needs to be resubmitted using the returned protocol.
> The returned protocol is being ignored and each time through resubmit
> nexthdr is taken fr
On Thu, May 12, 2016 at 12:55 PM, Eric Dumazet wrote:
> On Thu, 2016-05-12 at 12:51 -0700, Alexander Duyck wrote:
>> While testing an OpenStack configuration using VXLANs I saw the following
>> call trace:
>
>> The following trace is seen when receiving a DHCP request over a flow-based
>> VXLAN tu
On Thu, May 12, 2016 at 1:05 PM, Chris Friesen wrote:
>
> Hi,
>
> I hope this is a simple question...with legacy naming ethernet devices are
> named ethX. Where is that X determined? I've been looking in
> alloc_netdev_mqs() and friends, but haven't found it yet.
__dev_alloc_name()
On Thu, May 12, 2016 at 1:02 PM, Cong Wang wrote:
> On Thu, May 12, 2016 at 12:51 PM, Alexander Duyck wrote:
>> The following trace is seen when receiving a DHCP request over a flow-based
>> VXLAN tunnel. I believe this is caused by the metadata dst having a NULL
>> dev value and as a result dev
Hi,
I hope this is a simple question...with legacy naming ethernet devices are named
ethX. Where is that X determined? I've been looking in alloc_netdev_mqs() and
friends, but haven't found it yet.
Thanks,
Chris
On Wed, 2016-05-11 at 14:56 -0700, Eric Dumazet wrote:
> On Wed, 2016-05-11 at 08:55 +0200, Peter Zijlstra wrote:
> > On Tue, May 10, 2016 at 03:51:37PM -0700, Eric Dumazet wrote:
> > > diff --git a/kernel/softirq.c b/kernel/softirq.c
> > > index 17caf4b63342..22463217e3cf 100644
> > > --- a/kernel
On Thu, May 12, 2016 at 12:51 PM, Alexander Duyck wrote:
> The following trace is seen when receiving a DHCP request over a flow-based
> VXLAN tunnel. I believe this is caused by the metadata dst having a NULL
> dev value and as a result dev_net(dev) is causing a NULL pointer dereference.
>
> To
On Thu, 2016-05-12 at 12:51 -0700, Alexander Duyck wrote:
> While testing an OpenStack configuration using VXLANs I saw the following
> call trace:
> The following trace is seen when receiving a DHCP request over a flow-based
> VXLAN tunnel. I believe this is caused by the metadata dst having a N
While testing an OpenStack configuration using VXLANs I saw the following
call trace:
RIP: 0010:[] udp4_lib_lookup_skb+0x49/0x80
RSP: 0018:88103867bc50 EFLAGS: 00010286
RAX: 88103269bf00 RBX: 88103269bf00 RCX:
RDX: 4300 RSI: RDI: 8
On 05/03/2016 10:33 AM, Florian Westphal wrote:
> Replace all trans_start updates with netif_trans_update helper.
> change was done via spatch:
>
> struct net_device *d;
> @@
> - d->trans_start = jiffies
> + netif_trans_update(d)
>
> Compile tested only.
>
> Cc: user-mode-linux-de...@lists.sourc
On 05/03/2016 10:30 AM, Florian Westphal wrote:
> a trans_start struct member exists twice:
> - in struct net_device (legacy)
> - in struct netdev_queue
>
> Instead of open-coding dev->trans_start usage to obtain the current
> trans_start value, use dev_trans_start() instead.
>
> This is not exac
Using the software based channel scan mechanism from mac80211 keeps us
offline for 10-15 second, we should instead issue a start_scan/end_scan
on each channel reducing this time.
Signed-off-by: Bjorn Andersson
---
With this implementation I see a reduction of throughput for about 1-2 seconds
wit
From: Pablo Neira Ayuso
Date: Thu, 12 May 2016 17:16:31 +0200
> This patch fixes a netns leak.
>
> Fixes: 93edb8c7f94f ("gtp: reload GTPv1 header after pskb_may_pull()")
> Reported-by: Cong Wang
> Signed-off-by: Pablo Neira Ayuso
Applied.
From: Yuval Mintz
Date: Wed, 11 May 2016 16:36:11 +0300
> This patch adds SR-IOV support to qed/qede drivers, adding a new PCI
> device ID for a VF that is shared between all the various PFs that
> support IOV.
Series applied.
Hi,
On Wed, 11 May 2016 09:47:25 -0700 Tom Herbert wrote:
> This patch adds IP tunnel encapsulation operations for IPv6. This
> includes the infrastructure to add and delete operations. IPv6 variants
> of fou6_build_header and gue6_build_header are added in a new
> fou6 module. These encapsulatio
Hi Tom,
On Wed, 11 May 2016 09:47:24 -0700 Tom Herbert wrote:
>
> -int fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
> - u8 *protocol, struct flowi4 *fl4);
> -int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
> - u8 *protoc
Hello Sergei,
[we already talked about this patch in #armlinux, I'm now just
forwarding my comments on the list. Background was that I sent an easier
and less complete patch with the same idea. See
http://patchwork.ozlabs.org/patch/621418/]
[added Linus Walleij to Cc, there is a question for you/
On Thu, May 12, 2016 at 8:16 AM, Pablo Neira Ayuso wrote:
> This patch fixes a netns leak.
>
> Fixes: 93edb8c7f94f ("gtp: reload GTPv1 header after pskb_may_pull()")
> Reported-by: Cong Wang
> Signed-off-by: Pablo Neira Ayuso
Reviewed-by: Cong Wang
Thanks.
On 12 May 2016 at 16:09, Francois Romieu wrote:
>> On 12 May 2016 at 01:58, David Miller wrote:
>> > From: Ard Biesheuvel
>> > Date: Wed, 11 May 2016 09:47:49 +0200
> [...]
>> > I think we should just seriously consider changing the default, it's
>> > a really outdated reasoning behind the curre
Now ixgbevf_write/read_posted_mbx use -IXGBE_ERR_MBX as the initiative
return value, but it's incorrect, cause in ixgbevf_vlan_rx_add_vid(),
it use err == IXGBE_ERR_MBX, the err returned from mac.ops.set_vfta,
and in ixgbevf_set_vfta_vf, it return from write/read_posted. so we
should initialize err
On 05/05/2016 04:51 PM, Saeed Mahameed wrote:
> On Thu, May 5, 2016 at 8:16 PM, Doug Ledford wrote:
>>
>> That depends on which interface actually generated the oops. If it was
>> the base interface, then I don't manually set any special params on it.
>> If it's one of the vlan interfaces, then t
On Wed, May 11, 2016 at 8:43 PM, Eric Dumazet wrote:
> On Wed, 2016-05-11 at 19:24 -0700, Alexander Duyck wrote:
>> While testing an OpenStack configuration using VXLANs I saw the following
>> call trace:
>
>>
>> I believe the trace is pointing to the call to dev_net(dev) in
>> udp4_lib_lookup_skb
Eric W. Biederman wrote:
> > On Wed, May 11, 2016 at 05:41:13PM +0200, Florian Westphal wrote:
> >> diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
> >> index 5baa8e2..9722819 100644
> >> --- a/net/netfilter/nf_queue.c
> >> +++ b/net/netfilter/nf_queue.c
> >> @@ -102,6 +102,13 @@
Pablo Neira Ayuso writes:
> On Wed, May 11, 2016 at 05:41:13PM +0200, Florian Westphal wrote:
>> diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
>> index 5baa8e2..9722819 100644
>> --- a/net/netfilter/nf_queue.c
>> +++ b/net/netfilter/nf_queue.c
>> @@ -102,6 +102,13 @@ void nf_qu
> It's worse: before the patch series we get 'struct hv_device' (as it is
> called from core VMBus code and we simply cannot get to 'struct
> net_device' we need without traveling through 'struct
> netvsc_device'. This structure is removed and re-created by both
> netvsc_set_channels() and netvsc_
Hello,
On Thu, May 12, 2016 at 05:16:56PM +0300, Roger Quadros wrote:
> On 12/05/16 17:02, Roger Quadros wrote:
> > On 12/05/16 16:50, Nishanth Menon wrote:
> >> On 05/12/2016 05:00 AM, Uwe Kleine-König wrote:
> >>> The framework only asserts (for now) that the reset gpio is not active.
> >>>
> >>
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> David Miller
> Sent: 12 May 2016 16:52
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; netdev@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH net-next v2 0/4] xen-netback: support for
>
From: Paul Durrant
Date: Wed, 11 May 2016 16:16:26 +0100
> My recent patch to import an up-to-date include/xen/interface/io/netif.h
> from the Xen Project brought in the necessary definitions to support the
> new control shared ring and protocol. This patch series updates xen-netback
> to support
From: Jiri Pirko
Date: Thu, 12 May 2016 13:48:48 +0200
> sp = nla_data(attr);
> dev_get_stats(dev, sp);
>
> + err = dev_get_sw_stats(dev, &sw_stats);
> + if (!err) {
> + attr = nla_reserve_64bit(skb, IFLA_SW_STATS64,
> + sizeo
From: Johannes Berg
Date: Thu, 12 May 2016 13:06:01 +0200
> A few more patches for 4.7 - I listed the notable ones below in the tag
> message.
>
> Note that this isn't the tip of my tree - I merged the namespace work
> for nl80211 and hwsim there, but at least the hwsim one needs some more
> fol
Hi Arnd,
On mer., mai 11 2016, Arnd Bergmann wrote:
> I tried to fix this before, but my previous fix was incomplete
> and we can still get the same link error in randconfig builds
> because of the way that Kconfig treats the
>
> default y if MVNETA=y && MVNETA_BM_ENABLE
>
> line that do
This patch fixes a netns leak.
Fixes: 93edb8c7f94f ("gtp: reload GTPv1 header after pskb_may_pull()")
Reported-by: Cong Wang
Signed-off-by: Pablo Neira Ayuso
---
drivers/net/gtp.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gtp.c b/drivers/ne
"Lino Sanfilippo" writes:
> Hi,
>
>>
>> MTU change and set channels operations are implemented as netvsc device
>> re-creation destroying internal structures (struct net_device stays). This
>> is really unfortunate but there is no support from Hyper-V host to do it
>> in a different way. Such re-
On Thu, May 12, 2016 at 11:59:54AM +0200, Jiri Pirko wrote:
> From: Jiri Pirko
>
> Until now we had stats functions return SW statistics. However, it makes
> a lot of sense to return HW stats as default.
Hi Jiri
DSA has always returned the HW stats, i.e, ethtool -S shows the
counters the switch
Hi,
>
> MTU change and set channels operations are implemented as netvsc device
> re-creation destroying internal structures (struct net_device stays). This
> is really unfortunate but there is no support from Hyper-V host to do it
> in a different way. Such re-creation is unsurprisingly racy, Hai
Thu, May 12, 2016 at 04:36:45PM CEST, and...@lunn.ch wrote:
>On Thu, May 12, 2016 at 11:59:54AM +0200, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Until now we had stats functions return SW statistics. However, it makes
>> a lot of sense to return HW stats as default.
>
>Hi Jiri
>
>DSA has always
Patch 562abd39 "xen-netback: support multiple extra info fragments
passed from frontend" contained a mistake which can result in an in-
correct number of responses being generated when handling errors
encountered when processing packets containing extra info fragments.
This patch fixes the problem.
On 5/12/2016 5:16 PM, Roger Quadros wrote:
The framework only asserts (for now) that the reset gpio is not active.
Signed-off-by: Uwe Kleine-König
---
Documentation/devicetree/bindings/net/phy.txt | 3 +++
drivers/net/phy/phy_device.c | 8
2 files changed, 11 inserti
On 12/05/16 17:02, Roger Quadros wrote:
> Hi,
>
> On 12/05/16 16:50, Nishanth Menon wrote:
>> On 05/12/2016 05:00 AM, Uwe Kleine-König wrote:
>>> The framework only asserts (for now) that the reset gpio is not active.
>>>
>>> Signed-off-by: Uwe Kleine-König
>>> ---
>>> Documentation/devicetree/b
On Thu, May 12, 2016 at 02:43:03PM +0100, Paul Durrant wrote:
> Patch 562abd39 "xen-netback: support multiple extra info fragments
> passed from frontend" contained a mistake which can result in an in-
> correct number of responses being generated when handling errors
> encountered when processing
On 05/12/2016 09:02 AM, Roger Quadros wrote:
[...]
>> This looks like the right approach to me at least: I see that TI EVMs
>> will also benefit with this approach.
>>
>
> Agreed. Although on some of our boards we actually need a RESET pulse
> to get the PHY in a sane state. I can send a patch on
> On 12 May 2016 at 01:58, David Miller wrote:
> > From: Ard Biesheuvel
> > Date: Wed, 11 May 2016 09:47:49 +0200
[...]
> > I think we should just seriously consider changing the default, it's
> > a really outdated reasoning behind the current default setting. Maybe
> > relevant a decade ago, bu
Hello ChenYu
On Thu, May 12, 2016 at 9:49 AM, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, May 12, 2016 at 9:40 PM, Javier Martinez Canillas
> wrote:
>> [adding Krzysztof as cc]
>>
>> On Thu, May 12, 2016 at 8:25 AM, Sergei Shtylyov
>> wrote:
>>> Hello.
>>>
>>>
>>> On 5/12/2016 10:15 AM, Uwe Kleine-Kö
Hi,
On 12/05/16 16:50, Nishanth Menon wrote:
> On 05/12/2016 05:00 AM, Uwe Kleine-König wrote:
>> The framework only asserts (for now) that the reset gpio is not active.
>>
>> Signed-off-by: Uwe Kleine-König
>> ---
>> Documentation/devicetree/bindings/net/phy.txt | 3 +++
>> drivers/net/phy/phy_
On 05/12/2016 05:00 AM, Uwe Kleine-König wrote:
> The framework only asserts (for now) that the reset gpio is not active.
>
> Signed-off-by: Uwe Kleine-König
> ---
> Documentation/devicetree/bindings/net/phy.txt | 3 +++
> drivers/net/phy/phy_device.c | 8
> 2 files cha
Hi,
On Thu, May 12, 2016 at 9:40 PM, Javier Martinez Canillas
wrote:
> [adding Krzysztof as cc]
>
> On Thu, May 12, 2016 at 8:25 AM, Sergei Shtylyov
> wrote:
>> Hello.
>>
>>
>> On 5/12/2016 10:15 AM, Uwe Kleine-König wrote:
>>
>>> I have a machine here where the reset pin of the phy is connected
[adding Krzysztof as cc]
On Thu, May 12, 2016 at 8:25 AM, Sergei Shtylyov
wrote:
> Hello.
>
>
> On 5/12/2016 10:15 AM, Uwe Kleine-König wrote:
>
>> I have a machine here where the reset pin of the phy is connected to a
>> GPIO.
>>
>> There are different possibilities available today to handle thi
Hi David,
On 12/05/16 00:26, David Miller wrote:
From: Harvey Hunt
Date: Tue, 10 May 2016 17:43:21 +0100
@@ -1686,8 +1686,7 @@ dm9000_probe(struct platform_device *pdev)
}
if (!is_valid_ether_addr(ndev->dev_addr)) {
- dev_warn(db->dev, "%s: Invalid ethernet MAC
Hi Stephen,
On 10/05/16 19:31, Stephen Hemminger wrote:
On Tue, 10 May 2016 17:43:21 +0100
Harvey Hunt wrote:
For ethernet devices, net_device.name will be eth%d before
register_netdev() is called. Don't print the net_device name until
the format string is replaced.
Cc: Robert Jarzmik
Cc: B
MTU change and set channels operations are implemented as netvsc device
re-creation destroying internal structures (struct net_device stays). This
is really unfortunate but there is no support from Hyper-V host to do it
in a different way. Such re-creation is unsurprisingly racy, Haiyang
reported a
When netvsc device is removed during mtu change or channels setup we get
into troubles as both paths are trying to remove the device. Synchronize
them with start_remove flag and rtnl lock.
Signed-off-by: Vitaly Kuznetsov
---
drivers/net/hyperv/netvsc_drv.c | 9 +++--
1 file changed, 7 insert
We have the following structures keeping netvsc adapter state:
- struct net_device
- struct net_device_context
- struct netvsc_device
- struct rndis_device
- struct hv_device
and there are pointers/dependencies between them:
- struct net_device_context is contained in struct net_device
- struct hv_
netvsc_link_change() can race with netvsc_change_mtu() or
netvsc_set_channels() as these functions destroy struct netvsc_device and
rndis filter. Use start_remove flag for syncronization. As
netvsc_change_mtu()/netvsc_set_channels() are called with rtnl lock held
we need to take it before checking
struct netvsc_device is destroyed on mtu change so keeping the
protection flag there is not a good idea. Move it to struct
net_device_context which is preserved.
Signed-off-by: Vitaly Kuznetsov
---
drivers/net/hyperv/hyperv_net.h | 4 +++-
drivers/net/hyperv/netvsc.c | 3 +--
drivers/net/h
Simplify netvsvc pointer graph by getting rid of the redundant ndev
pointer. We can always get a pointer to struct net_device from somewhere
else.
Signed-off-by: Vitaly Kuznetsov
---
drivers/net/hyperv/hyperv_net.h | 2 --
drivers/net/hyperv/netvsc.c | 30 --
Crash in netvsc_send() is observed when netvsc device is re-created on
mtu change/set channels. The crash is caused by dereferencing of NULL
channel pointer which comes from chn_table. The root cause is a mixture
of two facts:
- we set nvdev pointer in net_device_context in alloc_net_device()
bef
Hello.
On 5/12/2016 10:15 AM, Uwe Kleine-König wrote:
I have a machine here where the reset pin of the phy is connected to a
GPIO.
There are different possibilities available today to handle this
situation, here are the ones I'm aware of:
- Use a gpio-hog to set the reset gpio to non-active
1 - 100 of 126 matches
Mail list logo
