On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
> On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
> > On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
> > > On Wed 25-01-17 14:10:06, Michal Hocko wrote:
> > > > On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
> [...]
> > > > > > Are ther
On 20/01/2017 21:07, Benjamin LaHaise wrote:
v2 - update to address changes in 00697ca19ae3e1118f2af82c3b41ac4335fe918b.
When using the tc flower filter, rules marked with "protocol all" do not
actually match all packets. This is due to a bug in f_flower.c that passes
in ETH_P_ALL in the TCA_
This introduces a device independent napi instance that
handles GRO for IPsec. I was not able to use gro cells
directly because I don't have a netdevice where I can
hang off the napi instance. We now may have a secpath
at a GRO merged skb, so we need to drop it. This is the
only cange to the generi
This patch adds a napi instance for IPsec GRO.
With this, we handle IPsec GRO with no impact
on the generic networking code.
Signed-off-by: Steffen Klassert
---
net/xfrm/xfrm_input.c | 87 ++-
1 file changed, 86 insertions(+), 1 deletion(-)
diff -
With a followup patch, a gro merged skb can have a secpath.
So drop it before freeing or reusing the skb.
Signed-off-by: Steffen Klassert
---
net/core/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 56818f7..c9e541e 100644
--- a/net/core/dev.c
++
On 1/25/17 9:46 PM, Eric W. Biederman wrote:
Alexei Starovoitov writes:
in cases where bpf programs are looking at sockets and packets
that belong to different netns, it could be useful to read netns inode,
so that programs can make intelligent decisions.
For example to disallow raw sockets in
tetst teste tetet tetest
tetett
On 01/26/2017 01:46 PM, Eric W. Biederman wrote:
> Alexei Starovoitov writes:
>
>> in cases where bpf programs are look
Alexei Starovoitov writes:
> in cases where bpf programs are looking at sockets and packets
> that belong to different netns, it could be useful to read netns inode,
> so that programs can make intelligent decisions.
> For example to disallow raw sockets in all non-init netns the program can do:
do_execute_actions() implements a worthwhile optimization: in case
an output action is the last action in an action list, skb_clone()
can be avoided by outputing the current skb. However, the
implementation is more complicated than necessary. This patch
simplify this logic.
Signed-off-by: Andy Zh
From: Arnd Bergmann
Date: Wed, 25 Jan 2017 23:29:33 +0100
> The only caller of this new function is inside of an #ifdef checking
> for CONFIG_BRIDGE_IGMP_SNOOPING, so we should move the implementation
> there too, in order to avoid this harmless warning:
>
> net/bridge/br_forward.c:177:13: error
From: Daniel Borkmann
Date: Thu, 26 Jan 2017 00:42:49 +0100
> We currently used len instead of prefix_len for the strncmp() in
> fdinfo on the prog_tag. It still worked as we matched on the correct
> output line also with first 8 instead of 10 chars, but lets fix it
> properly to use the intended
From: Rafał Miłecki
Date: Wed, 25 Jan 2017 21:00:24 +0100
> I will probably need to use broadcom.ko for PHY connected to interface
> of bgmac supported device so I started looking at it willing to
> understand it better.
>
> I found AUXCTL part of the driver / lib a bit confusing and hard to rea
From: Simon Wunderlich
Date: Wed, 25 Jan 2017 17:25:05 +0100
> here is a bugfix for net which we would like to have integrated.
>
> Please pull or let me know of any problem!
Pulled, thanks.
From: Sainath Grandhi
Date: Wed, 25 Jan 2017 13:25:32 -0800
> Tap character devices can be implemented on other virtual interfaces like
> ipvlan, similar to macvtap. Source code for tap functionality in macvtap
> can be re-used for this purpose.
>
> This patch series splits macvtap source into t
From: Thomas Falcon
Date: Wed, 25 Jan 2017 15:02:20 -0600
> In the current driver, the MTU is set to the maximum value
> capable for the backing device. This patch sets the MTU to the
> default value for a Linux net device.
Why are you doing this?
What happens to users who depend upon the curre
From: Thomas Falcon
Date: Wed, 25 Jan 2017 15:02:19 -0600
> Move most interrupt handler processing into a tasklet, and
> introduce a delay after re-enabling interrupts to fix timing
> issues encountered in hardware testing.
>
> Signed-off-by: Thomas Falcon
I don't think you have any idea what
The address generation mode for IPv6 link-local can only be configured
by netlink messages. This patch adds the ability to change the address
generation mode via sysctl.
v1 -> v2
Removed the rtnl lock and switch to use RCU lock to iterate through
the netdev list.
v2 -> v3
Removed the addrgenmode
Signed-off-by: Felix Jia
---
net/ipv6/addrconf.c | 5 +
net/ipv6/ip6_gre.c | 3 +++
net/ipv6/ip6_vti.c | 4
3 files changed, 12 insertions(+)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index e35259dd17ba..4c47656b9f09 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrcon
From: Simon Wunderlich
Date: Wed, 25 Jan 2017 17:42:58 +0100
> From: Gao Feng
>
> The tc could return NET_XMIT_CN as one congestion notification, but
> it does not mean the packet is lost. Other modules like ipvlan,
> macvlan, and others treat NET_XMIT_CN as success too.
>
> So batman-adv shou
David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, January 26, 2017 11:48 AM
[...]
> Series applied.
Thank you very much. I would try to find better way, too.
Best Regards,
Hayes
From: John Fastabend
Date: Wed, 25 Jan 2017 18:22:48 -0800
> In the small buffer case during driver unload we currently use
> put_page instead of dev_kfree_skb. Resolve this by adding a check
> for virtnet mode when checking XDP queue type. Also name the
> function so that the code reads correctl
From: Jakub Kicinski
Date: Wed, 25 Jan 2017 14:56:36 -0800
> commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
> added a new XDP helper to prepend and remove data from a frame.
> Make virtio_net reject programs making use of this helper until
> proper support is added.
>
> Sign
From: Hayes Wang
Date: Thu, 26 Jan 2017 09:38:30 +0800
> v3:
> simply the argument for patch #3. Replace &tp->napi with napi.
>
> v2:
> Add smp_mb__after_atomic() for patch #1.
>
> v1:
> Scheduling the napi during the following periods would let it be ignored.
> And the events wouldn't be handl
From: Hayes Wang
Date: Thu, 26 Jan 2017 03:04:45 +
> May you apply these patches first, until I find another way to replace
> current one?
Yes, I will.
Копия:
Это сообщение было отправлено через раздел Контакты сайта http://elondon.ru/:
MeriGadabimb
Огромный выбop вариaнтов oтбеливания зубов заведёт в тупик любого. Каждый метод
уникалeн по-своеmу, нo не каждый полезен для зубов. Главнoе – не oшибиться при
выбоpе, ведь cтоиmocть тaких процeдур
in cases where bpf programs are looking at sockets and packets
that belong to different netns, it could be useful to read netns inode,
so that programs can make intelligent decisions.
For example to disallow raw sockets in all non-init netns the program can do:
if (sk->type == SOCK_RAW && sk->netns
David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, January 26, 2017 3:31 AM
[...]
> I think the fundamental issue is that since you can't stop URBs from
> queueing up, you cannot properly synchronize NAPI and schedule polling
> properly.
>
> From my perspective what happened here is you w
On Wed, Jan 25, 2017 at 02:56:36PM -0800, Jakub Kicinski wrote:
> commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
> added a new XDP helper to prepend and remove data from a frame.
> Make virtio_net reject programs making use of this helper until
> proper support is added.
>
> S
On 2017年01月26日 06:56, Jakub Kicinski wrote:
commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
added a new XDP helper to prepend and remove data from a frame.
Make virtio_net reject programs making use of this helper until
proper support is added.
Signed-off-by: Jakub Kicinski
In the small buffer case during driver unload we currently use
put_page instead of dev_kfree_skb. Resolve this by adding a check
for virtnet mode when checking XDP queue type. Also name the
function so that the code reads correctly to match the additional
check.
Fixes: bb91accf2733 ("virtio-net: X
Eric Dumazet [mailto:eric.duma...@gmail.com]
> Sent: Wednesday, January 25, 2017 10:13 PM
[...]
> You also could use napi_complete_done() instead of napi_complete(), as
> it allows users to tune the performance vs latency for GRO.
>
> Looking at this driver, I do not see any limitation on the numb
Schedule the napi after napi_enable() for rx, if it is necessary.
If the rx is completed when napi is disabled, the sheduling of napi
would be lost. Then, no one handles the rx packet until next napi
is scheduled.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 7 ++-
1 file changed
Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit()
from calling napi_schedule() directly during runtime suspend.
After calling napi_disable() or clearing the flag of WORK_ENABLE,
scheduling the napi is useless.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 12
v3:
simply the argument for patch #3. Replace &tp->napi with napi.
v2:
Add smp_mb__after_atomic() for patch #1.
v1:
Scheduling the napi during the following periods would let it be ignored.
And the events wouldn't be handled until next napi_schedule() is called.
1. after napi_disable and before
Stop the tx when the napi is disabled to prevent napi_schedule() is
called.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 23bef8e..ec882be 100644
--- a/driv
Re-schedule napi after napi_complete() for tx, if it is necessay.
In r8152_poll(), if the tx is completed after tx_bottom() and before
napi_complete(), the scheduling of napi would be lost. Then, no
one handles the next tx until the next napi_schedule() is called.
Signed-off-by: Hayes Wang
---
Eric Dumazet [mailto:eric.duma...@gmail.com]
> Sent: Wednesday, January 25, 2017 9:57 PM
[...]
> > napi_complete(napi);
> > if (!list_empty(&tp->rx_done))
> > napi_schedule(napi);
> > + else if (!skb_queue_empty(&tp->tx_queue) &&
> > +
Andy Lutomirski writes:
> On Tue, Jan 24, 2017 at 4:11 PM, Alexei Starovoitov
> wrote:
>> On Tue, Jan 24, 2017 at 01:24:54PM -0800, Andy Lutomirski wrote:
>>> On Tue, Jan 24, 2017 at 12:29 PM, David Ahern
>>> wrote:
>>> >
>>> > Users do not run around exec'ing commands in random network contex
On Wed, 25 Jan 2017 23:29:33 +0100
Arnd Bergmann wrote:
> The only caller of this new function is inside of an #ifdef checking
> for CONFIG_BRIDGE_IGMP_SNOOPING, so we should move the implementation
> there too, in order to avoid this harmless warning:
>
> net/bridge/br_forward.c:177:13: error:
We currently used len instead of prefix_len for the strncmp() in
fdinfo on the prog_tag. It still worked as we matched on the correct
output line also with first 8 instead of 10 chars, but lets fix it
properly to use the intended length.
Fixes: 62b64660262a ("bpf: add prog tag test case to bpf sel
On Mon, Jan 23, 2017 at 2:07 AM, Jiri Pirko wrote:
> +
> +static int tcf_sample_init(struct net *net, struct nlattr *nla,
> + struct nlattr *est, struct tc_action **a, int ovr,
> + int bind)
> +{
> + struct tc_action_net *tn = net_generic(net
On Tue, 2017-01-24 at 17:07 +0530, Varun Prakash wrote:
> For T6 adapters use T6 specific macro to set force bit.
Thanks, I have applied this patch.
Bart.
commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
added a new XDP helper to prepend and remove data from a frame.
Make virtio_net reject programs making use of this helper until
proper support is added.
Signed-off-by: Jakub Kicinski
Acked-by: John Fastabend
---
drivers/net/vir
All,
I am experiencing a kernel panic on different (but identical)
hardware in ip_rcv_finish on Linux 4.4.39 (but I can see no changes that
would improve the situation on 4.4.44, or master).
Looking at the disassembly at the last stack frame it looks like we are
calling a NULL function poin
All,
I am experiencing a kernel panic on different (but identical)
hardware in ip_rcv_finish on Linux 4.4.39 (but I can see no changes that
would improve the situation on 4.4.44, or master).
Looking at the disassembly at the last stack frame it looks like we are
calling a NULL function poi
The only caller of this new function is inside of an #ifdef checking
for CONFIG_BRIDGE_IGMP_SNOOPING, so we should move the implementation
there too, in order to avoid this harmless warning:
net/bridge/br_forward.c:177:13: error: 'maybe_deliver_addr' defined but not
used [-Werror=unused-function]
I noticed that this function uses a lot of kernel stack when the
"latent entropy" plugin is enabled:
drivers/isdn/hardware/eicon/message.c: In function 'sig_ind':
drivers/isdn/hardware/eicon/message.c:6113:1: error: the frame size of 1168
bytes is larger than 1152 bytes [-Werror=frame-larger-than
On Tue, Jan 24, 2017 at 11:39 AM, Sriram V wrote:
> Hello,
>
> Apologies in case, this is not the right list of this question.
>
> I wanted to check, How can i find out if a network status has changed
>
> 1. How can the user application find out if the link status has changed?
There are some flag
Hi Chad,
[auto build test WARNING on net/master]
[also build test WARNING on v4.10-rc5 next-20170125]
[cannot apply to net-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dupuis
On Wed, 2017-01-25 at 14:03 -0500, David Miller wrote:
> From: Eric Dumazet
> Date: Wed, 25 Jan 2017 10:38:52 -0800
>
> > Do you think we could change __pskb_pull_tail() right away and fix the
> > few places that would break, or should we add various helpers with extra
> > parameters to take a sa
> On Jan 23, 2017, at 5:45 PM, Cong Wang wrote:
>
> On Mon, Jan 23, 2017 at 2:37 PM, Joel Cunningham
> wrote:
>> Hi,
>>
>> I’m working on a research effort to understand the synchronization
>> mechanisms for accessing and modifying a struct net_device object. One area
>> that isn’t clear i
macvtap module has code for tap/queue management and link management. This
patch splits
the code into macvtap_main.c for link management and tap.c for tap/queue
management.
Functionality in tap.c can be re-used for implementing tap on other virtual
interfaces.
Signed-off-by: Sainath Grandhi
--
macvlan object is re-structured to hold tap related elements in a separate
entity, tap_dev. Upon NETDEV_REGISTER device_event, tap_dev is registered with
idr and fetched again on tap_open. Few of the tap functions are modified to
accepted tap_dev as argument. tap_dev object includes callbacks to be
Tap character devices can be implemented on other virtual interfaces like
ipvlan, similar to macvtap. Source code for tap functionality in macvtap
can be re-used for this purpose.
This patch series splits macvtap source into two modules, macvtap and tap.
This patch series also includes a patch for
This patch makes tap a separate module for other types of virtual interfaces,
for example,
ipvlan to use.
Signed-off-by: Sainath Grandhi
---
drivers/net/Kconfig | 15 +++
drivers/net/Makefile | 3 +--
drivers/net/{macvtap_main.c => macvtap
Renaming tap related APIs, data structures and macros in tap.c from macvtap_.*
to tap_.*
Signed-off-by: Sainath Grandhi
---
drivers/net/macvtap_main.c | 18 +--
drivers/net/tap.c | 332 ++---
drivers/vhost/net.c| 3 +-
include/linux/if
This patch provides tap device create/destroy APIs in tap.c.
Signed-off-by: Sainath Grandhi
---
drivers/net/macvtap_main.c | 30 +++---
drivers/net/tap.c | 62 ++
include/linux/if_tap.h | 3 +++
3 files changed, 63 inserti
This patch adds a tap character device driver that is based on the
IP-VLAN network interface, called ipvtap. An ipvtap device can be created
in the same way as an ipvlan device, using 'type ipvtap', and then accessed
using the tap user space interface.
Signed-off-by: Sainath Grandhi
---
drivers/
Extending tap APIs get/free_minor and create/destroy_cdev to handle more than
one
type of virtual interface.
Signed-off-by: Sainath Grandhi
---
drivers/net/macvtap_main.c | 6 +--
drivers/net/tap.c | 98 +++---
include/linux/if_tap.h | 4 +-
On Tue, Jan 24, 2017 at 10:59:15AM -0800, Florian Fainelli wrote:
> On 01/19/2017 10:12 AM, Florian Fainelli wrote:
> >
> > Back to the actual code that triggered this discussion, the whole
> > purpose is just a safeguard. Given a device reference, we can assume
> > that it is indeed the backing d
On Wed, Jan 25, 2017 at 6:34 PM, David Miller wrote:
> From: Greentime Hu
> Date: Tue, 24 Jan 2017 16:46:14 +0800
>> We also use the same binding document to describe the same faraday ethernet
>> controller and add faraday to vendor-prefixes.txt.
>
> Why are you renaming the MOXA binding file ins
In the current driver, the MTU is set to the maximum value
capable for the backing device. This patch sets the MTU to the
default value for a Linux net device. It also corrects a
discrepancy between MTU values received from firmware, which includes
the ethernet header length, and net device MTU val
Error reports received from firmware were not being converted from
big endian values, leading to bogus error codes reported on little
endian systems.
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dr
Move most interrupt handler processing into a tasklet, and
introduce a delay after re-enabling interrupts to fix timing
issues encountered in hardware testing.
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 21 +++--
drivers/net/ethernet/ibm/ibmvnic.h | 1
When a IBM VNIC client driver requests a faulty device setting, the
server returns an acceptable value for the client to request.
This 64 bit value was incorrectly being swapped as a 32 bit value,
resulting in loss of data. This patch corrects that by using
the 64 bit swap function.
Signed-off-by:
Initialize this completion structure before requesting that
a buffer be long-term mapped . This fix resolves a bug where firmware
sends a response before the structure is initialized.
Signed-off-by: John Allen
Signed-off-by: Nathan Fontenot
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet
On Wed, Jan 25, 2017 at 5:33 AM, Oliver Hartkopp wrote:
> On 01/25/2017 10:39 AM, Hayes Wang wrote:
>>
>> Oliver Neukum [mailto:oneu...@suse.com]
>>>
>>> Sent: Wednesday, January 25, 2017 5:35 PM
>>
>> [...]
>>>
>>> looking at r8152 I noticed that it uses NAPI. I never considered
>>> this for the
On 01/25/2017 12:00 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> 1) Use 0x%02x format for register number. This follows some other
>defines and makes it easier to distinct register from values.
> 2) Put register define above values and sort the values. It makes
>reading header code
From: "Dupuis, Chad"
This series introduces the hardware offload FCoE initiator driver for the
41000 Series Converged Network Adapters (579xx chip) by Cavium. The overall
driver design includes a common module ('qed') and protocol specific
dependent modules ('qedf' for FCoE).
This driver uses th
From: Arun Easi
This adds the backbone required for the various HW initalizations
which are necessary for the FCoE driver (qedf) for QLogic FastLinQ
4 line of adapters - FW notification, resource initializations, etc.
Signed-off-by: Arun Easi
Signed-off-by: Yuval Mintz
---
drivers/net/eth
On 01/25/2017 12:00 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> We had two defines for the same bit (both were used with the
> MII_BCM54XX_AUXCTL_SHDWSEL_MISC register).
>
> Signed-off-by: Rafał Miłecki
Reviewed-by: Florian Fainelli
--
Florian
On Tue, Jan 24, 2017 at 4:11 PM, Alexei Starovoitov
wrote:
> On Tue, Jan 24, 2017 at 01:24:54PM -0800, Andy Lutomirski wrote:
>> On Tue, Jan 24, 2017 at 12:29 PM, David Ahern
>> wrote:
>> >
>> > Users do not run around exec'ing commands in random network contexts
>> > (namespace, vrf, device, w
On 01/25/2017 04:56 PM, William Tu wrote:
Looks good to me, I tested with several complex program without any
problem. Thanks for the patch.
Thanks for re-testing, William!
On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
On Wed 25-01-17 14:10:06, Michal Hocko wrote:
On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
[...]
Are there any more comments? I would really appreciate to hear from
networking folks
From: Rafał Miłecki
Starting with commit 5b4e29005123 ("net: phy: broadcom: add
bcm54xx_auxctl_read") we have a reading helper so use it and avoid code
duplication.
It also means we don't need MII_BCM54XX_AUXCTL_SHDWSEL_MISC define as
it's the same as MII_BCM54XX_AUXCTL_SHDWSEL_MISC just for read
From: Rafał Miłecki
1) Use 0x%02x format for register number. This follows some other
defines and makes it easier to distinct register from values.
2) Put register define above values and sort the values. It makes
reading header code easier.
3) Use 0x%04x format for all values. It's about c
From: Rafał Miłecki
I will probably need to use broadcom.ko for PHY connected to interface
of bgmac supported device so I started looking at it willing to
understand it better.
I found AUXCTL part of the driver / lib a bit confusing and hard to read
so I'm trying to clean it up a bit. I hope thi
From: Rafał Miłecki
We had two defines for the same bit (both were used with the
MII_BCM54XX_AUXCTL_SHDWSEL_MISC register).
Signed-off-by: Rafał Miłecki
---
V2: Drop the other define to match datasheet. Thanks Florian.
---
drivers/net/phy/broadcom.c | 2 +-
include/linux/brcmphy.h| 1 -
2
From: Andrew Lunn
Date: Wed, 25 Jan 2017 15:04:17 +0100
> Previous patches have moved the temperature sensor code into the
> Marvell PHYs. A few now dead references to NET_DSA_HWMON were left
> behind. Go reap them.
>
> Reported-by: Valentin Rothberg
> Signed-off-by: Andrew Lunn
Applied to...
Hello,
On Mon, Jan 23, 2017 at 9:17 PM, Kaiwen Xu wrote:
> Hi netdev folks,
>
> I am currently experiencing an issue related with the loopback during
> network devices shutdown inside a network namespace, which mainfested as
>
> unregister_netdevice: waiting for lo to become free. Usage count
From: Florian Fainelli
Date: Wed, 25 Jan 2017 09:10:41 -0800
> Commit 448b4482c671 ("net: dsa: Add lockdep class to tx queues to avoid
> lockdep splat") removed the netif_device_detach() call done in
> dsa_slave_suspend() which is necessary, and paired with a corresponding
> netif_device_attach()
From: Bert Kenward
Date: Wed, 25 Jan 2017 13:48:17 +
> From: Tomáš Pilař
>
> PIO buffer allocation can fail for two valid reasons:
> - we've run out of them (results in -ENOSPC)
> - the NIC configuration doesn't support them (results in -EPERM)
> Since both these failures are expected net
From: sunil.kovv...@gmail.com
Date: Wed, 25 Jan 2017 17:36:22 +0530
> These patches adds support to set queue sizes from ethtool and changes
> the way serdes lane configuration is done by BGX driver on 81/83xx
> platforms.
Series applied, thanks.
From: Geert Uytterhoeven
Date: Wed, 25 Jan 2017 11:39:47 +0100
> I started seeing crashes during s2ram and poweroff on all my ARM boards,
> like:
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
> ...
> [] (__list_del_entry_valid) from []
> (led_tr
Hi Andrew,
Andrew Lunn writes:
>> if (reg == MII_PHYSID2 && (*val & 0xfff0) == 0)
>
> This should be 0x3f0. There are 10 bits for the device model, of which
> Marvell uses the lowest 4 for version.
>
>> *val |= chip->info->prod_num << 4;
>
> #define PORT_SWITCH_ID_PROD_NU
From: John Crispin
Date: Wed, 25 Jan 2017 09:20:54 +0100
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
From: John Crispin
Date: Wed, 25 Jan 2017 09:20:55 +0100
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
From: Oliver Neukum
Date: Wed, 25 Jan 2017 10:34:41 +0100
> looking at r8152 I noticed that it uses NAPI. I never considered
> this for the generic USB networking code as you cannot disable
> interrupts for USB. Is it still worth it? What are the benefits?
I think it's not a good approach for ge
From: Hayes Wang
Date: Wed, 25 Jan 2017 16:13:17 +0800
> v2:
> Add smp_mb__after_atomic() for patch #1.
>
> v1:
> Scheduling the napi during the following periods would let it be ignored.
> And the events wouldn't be handled until next napi_schedule() is called.
>
> 1. after napi_disable and be
On Wed, Jan 25, 2017 at 01:03:43PM -0500, Vivien Didelot wrote:
> Andrew,
>
> Vivien Didelot writes:
>
> > Since several chips have this issue, we can introduce a u16 physid2_mask
> > member in the mv88e6xxx_info structure and move the check in
> > mv88e6xxx_phy_read() so that the logic of devic
> Note that I am not sure we correctly test that a second connect() can be
> done, and I am not sure kernel would check that the remote IP and
> destination port is the same.
> Ie what should happen for
> setsockopt(fd, SOL_TCP, TCP_FASTOPEN_CONNECT, &on, 4)
> connect(fd, "1.2.3.4:80")
> connect
From: Willy Tarreau
Date: Wed, 25 Jan 2017 14:42:46 +0100
> Without TFO, any subsequent connect() call after a successful one returns
> -1 EISCONN. The last API update ensured that __inet_stream_connect() can
> return -1 EINPROGRESS in response to sendmsg() when TFO is in use to
> indicate that t
From: Wei Wang
Date: Mon, 23 Jan 2017 10:59:19 -0800
> The patch series is to add support for new userspace API for TCP fastopen
> sockets.
> In the current code, user has to call sendto()/sendmsg() with special flag
> MSG_FASTOPEN for TCP fastopen sockets. This API is quite different from the
>
From: Wei Wang
Date: Wed, 25 Jan 2017 10:54:50 -0800
>> Yes sorry David, for me it's OK. If Wei runs his whole series of tests
>> on it again, it should be perfect.
>
> I just ran all the TFO related tests with Willy's patch on top of this
> patch series.
> And everything passes.
Great, I'll ap
From: Eric Dumazet
Date: Wed, 25 Jan 2017 10:38:52 -0800
> Do you think we could change __pskb_pull_tail() right away and fix the
> few places that would break, or should we add various helpers with extra
> parameters to take a safe route ?
It should always be safe as long as we see no socket at
On Wed, 2017-01-25 at 10:54 -0800, Wei Wang wrote:
> > Yes sorry David, for me it's OK. If Wei runs his whole series of tests
> > on it again, it should be perfect.
>
> I just ran all the TFO related tests with Willy's patch on top of this
> patch series.
> And everything passes.
Note that I am n
Adding Bob Bernstein
Jon Pannell
-Original Message-
From: Gregory CLEMENT [mailto:gregory.clem...@free-electrons.com]
Sent: Tuesday, January 24, 2017 11:56 PM
To: Andrew Lunn
Cc: Vivien Didelot ; Florian Fainelli
; netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
David S. Miller
> Yes sorry David, for me it's OK. If Wei runs his whole series of tests
> on it again, it should be perfect.
I just ran all the TFO related tests with Willy's patch on top of this
patch series.
And everything passes.
On Wed, Jan 25, 2017 at 9:54 AM, Willy Tarreau wrote:
> On Wed, Jan 25, 2017 a
On 01/25/2017 10:39 AM, Alexey Brodkin wrote:
>> Also I wonder if, other version of the stmmac worked on this platform
>> before.
> It did work and still works. The only problem is we're getting
> a lot of noise now about bogus link status change. That's because
> this info is now in pr_info() comp
Hi Giuseppe,
On Mon, 2016-11-14 at 09:14 +0100, Giuseppe CAVALLARO wrote:
> Hello Alexey
>
> Sorry for my late reply. In that case, I think that the stmmac
> is using own RGMII/SGMII support (PCS) to dialog with the
> transceiver. I think, from the HW capability register
> this feature is present
1 - 100 of 215 matches
Mail list logo