[PATCH net-next 6/8] bnxt_en: Include some hardware port statistics in ndo_get_stats64().

Include some of the port error counters (e.g. crc) in ->ndo_get_stats64() for the PF device. Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 16 1 file changed, 16 insertions(+) diff --git

[PATCH net-next 7/8] bnxt_en: Include hardware port statistics in ethtool -S.

Include the more useful port statistics in ethtool -S for the PF device. Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 105 +- 1 file changed, 103 insertions(+), 2 deletions(-) diff --git

[PATCH net-next 4/8] bnxt_en: Extend autoneg to all speeds.

Allow all autoneg speeds aupported by firmware to be advertised. If the advertising parameter is 0, then all supported speeds will be advertised. Remove BNXT_ALL_COPPER_ETHTOOL_SPEED which is no longer used as all supported speeds can be advertised. Signed-off-by: Michael Chan

[PATCH net-next 0/8] bnxt_en: Updates for net-next.

Updates to support autoneg for all supported speeds, add PF port statistics, and Advanced Error Reporting. Michael Chan (8): bnxt_en: Refactor bnxt_fw_to_ethtool_advertised_spds(). bnxt_en: Add reporting of link partner advertisement. bnxt_en: Use common function to get ethtool supported

[PATCH net-next 5/8] bnxt_en: Add port statistics support.

Gather periodic port statistics if the device is PF and link is up. This is triggered in bnxt_timer() every one second to request firmware to DMA the counters. Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 50

[PATCH net-next 8/8] bnxt_en: Enable AER support.

From: Satish Baddipadige Add pci_error_handler callbacks to support for pcie advanced error recovery. Signed-off-by: Satish Baddipadige Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 109

[PATCH net-next 2/8] bnxt_en: Add reporting of link partner advertisement.

And report actual pause settings to ETHTOOL_GPAUSEPARAM to let ethtool resolve the actual pause settings. Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +++ drivers/net/ethernet/broadcom/bnxt/bnxt.h | 2 ++

[PATCH net-next 1/8] bnxt_en: Refactor bnxt_fw_to_ethtool_advertised_spds().

Include the conversion of pause bits and add one extra call layer so that the same refactored function can be reused to get the link partner advertisement bits. Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 33 ++- 1

[PATCH net-next 3/8] bnxt_en: Use common function to get ethtool supported flags.

The supported bits and advertising bits in ethtool have the same definitions. The same is true for the firmware bits. So use the common function to handle the conversion for both supported and advertising bits. Signed-off-by: Michael Chan ---

Re: [PATCH net] bridge: a netlink notification should be sent whenever those attributes change

On Sun, Mar 6, 2016 at 3:43 AM, Nikolay Aleksandrov wrote: > On 03/05/2016 03:44 PM, Xin Long wrote: > > See the comment above dev_ifsioc: > /* > * Perform the SIOCxIFxxx calls, inside rtnl_lock() > */ > static int dev_ifsioc(struct net *net, struct ifreq *ifr,

Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket

From: Wei Wang Date: Wed, 2 Mar 2016 11:19:21 -0800 > @@ -566,7 +567,16 @@ void __udp6_lib_err(struct sk_buff *skb, struct > inet6_skb_parm *opt, > if (type == ICMPV6_PKT_TOOBIG) { > if (!ip6_sk_accept_pmtu(sk)) > goto out; > -

Re: [PATCH net] sctp: use gfp insteaad of GFP_NOWAIT in idr_alloc_cyclic when sctp_assoc_set_id

On Sun, Mar 6, 2016 at 12:42 AM, Eric Dumazet wrote: > On sam., 2016-03-05 at 23:59 +0800, Xin Long wrote: > > Are you sure idr_alloc(... GFP_KERNEL) makes sense inside spin_lock_bh() > section ? > > idr_alloc() has : > > might_sleep_if(gfpflags_allow_blocking(gfp_mask));

Re: PHY hardware reset

On Sun, Mar 06, 2016 at 01:09:40AM +0300, Sergei Shtylyov wrote: > Hello. > >I have a need to de-assert the active-low PHY hardware reset > signal (mapped to a GPIO) before the MDIO bus scansince it's left > asserted by the bootloader (U-Boot). Hi Sergei There is a thread about power

RE: [PATCH RESEND] net:fec:Fix error checking in the function fec_enet_init

From: Nicholas Krause Sent: Saturday, March 05, 2016 4:00 AM > To: da...@davemloft.net > Cc: b38...@freescale.com; and...@lunn.ch; fabio.este...@freescale.com; > l.st...@pengutronix.de; rmk+ker...@arm.linux.org.uk; trem...@gmail.com; > johan...@sipsolutions.net;

RE: [PATCH net-next V2 07/16] net: fec: set cbd_sc without relying on previous value

From: Troy Kisky Sent: Saturday, March 05, 2016 12:08 AM > To: Fugang Duan ; netdev@vger.kernel.org; > da...@davemloft.net; b38...@freescale.com > Cc: fabio.este...@freescale.com; l.st...@pengutronix.de; and...@lunn.ch; > trem...@gmail.com;

Re: skb_under_panic in ip_tunnel_xmit

Eric Dumazet writes: > On mer., 2016-03-02 at 09:11 -0800, Francesco Ruggeri wrote: >> I can consistently get this panic on 4.4.1 as well as 3.18. >> >> [ 2076.264975] gre: GRE over IPv4 demultiplexor driver >> [ 2076.269326] ip_gre: GRE over IPv4 tunneling driver >> [

Re: [PATCH v3 net-next 0/9] API set for HW Buffer management

Hi, On sam., mars 05 2016, Gregory CLEMENT wrote: > This is a third version of an API set for HW Buffer management that I Please ignore this version. Being able to select the HWBM support though the kernel configuration was not as trivial as I initially

[PATCH v4 net-next 5/9] ARM: dts: armada-xp-openblocks-ax3-4: Add BM support

Allow Openblock AX3 using hardware buffer management with mvneta. Signed-off-by: Gregory CLEMENT --- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git

[PATCH v4 net-next 1/9] ARM: dts: armada-38x: add buffer manager nodes

From: Marcin Wojtas Armada 38x network controller supports hardware buffer management (BM). Since it is now enabled in mvneta driver, appropriate nodes can be added to armada-38x.dtsi - for the actual common BM unit (bm@c8000) and its internal SRAM (bm-bppi), which is used for

[PATCH v4 net-next 3/9] ARM: dts: armada-xp: add buffer manager nodes

From: Marcin Wojtas Armada XP network controller supports hardware buffer management (BM). Since it is now enabled in mvneta driver, appropriate nodes can be added to armada-xp.dtsi - for the actual common BM unit (bm@c) and its internal SRAM (bm-bppi), which is used for

[PATCH v4 net-next 6/9] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information

From: Marcin Wojtas This commit enables finding appropriate mbus window and obtaining its target id and attribute for given physical address in two separate routines, both for IO and DRAM windows. This functionality is needed for Armada XP/38x Network Controller's Buffer

[PATCH v4 net-next 4/9] ARM: dts: armada-xp: enable buffer manager support on Armada XP boards

From: Marcin Wojtas Since mvneta driver supports using hardware buffer management (BM), in order to use it, board files have to be adjusted accordingly. This commit enables BM on AXP-DB and AXP-GP in same manner - because number of ports on those boards is the same as number

[PATCH v4 net-next 2/9] ARM: dts: armada-38x: enable buffer manager support on Armada 38x boards

From: Marcin Wojtas Since mvneta driver supports using hardware buffer management (BM), in order to use it, board files have to be adjusted accordingly. This commit enables BM on: * A385-DB-AP - each port has its own pool for long and common pool for short packets, *

[PATCH v4 net-next 8/9] net: add a hardware buffer management helper API

This basic implementation allows to share code between driver using hardware buffer management. As the code is hardware agnostic, there is few helpers, most of the optimization brought by the an HW BM has to be done at driver level. Signed-off-by: Gregory CLEMENT

[PATCH v4 net-next 7/9] net: mvneta: bm: add support for hardware buffer management

From: Marcin Wojtas Buffer manager (BM) is a dedicated hardware unit that can be used by all ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX path by sparing DRAM access on refilling buffer pool, hardware-based filling of descriptor ring data and

[PATCH v4 net-next 0/9] API set for HW Buffer management

This forth version of the API set for HW Buffer management (that was initially submitted here: http://thread.gmane.org/gmane.linux.kernel/2125152), is actually the third version done right. Now it is really possible to disable the HWBM through the kernel configuration. Since the second version I

PHY hardware reset

Hello. I have a need to de-assert the active-low PHY hardware reset signal (mapped to a GPIO) before the MDIO bus scansince it's left asserted by the bootloader (U-Boot). I have a device tree probed MAX driver (ravb) and I'm somewhat at a loss about where and how to do this. The existing

Re: [iproute PATCH] libnetlink: Double the dump buffer size

On Fri, 2016-03-04 at 15:35 -0800, Stephen Hemminger wrote: >  > > There have been reports about 'ip addr' printing "Message > > truncated" on [...] > I thought this was addressed in kernel by making the VF info > optional. > The netlink protocol is showing some strain, this is one of them. I

Re: Possible double-free in the usbnet driver

On March 5, 2016 4:51:30 PM CET, Oliver Neukum wrote: >On Fri, 2016-03-04 at 14:43 -0800, Linus Torvalds wrote: > >> So you have usbnet_defer_kevent() getting triggered, which in turn >> ends up using "usbnet->kevent" >> >> But somebody like Oliver is really the right person

Re: [Patch] rose_route_frame() NULL pointer dereference kernel panic

f6bvp : > Le 05/03/2016 17:22, David Miller a écrit : [...] > > If that's what he intended he would have implemented the entirety of > > rose_xmit() as "kfree_skb(skb)". But that's obviously not the case. > > > > The author meant the packet to be sent in some way, perhaps using a

Re: [PATCH net] bridge: a netlink notification should be sent whenever those attributes change

On 03/05/2016 03:44 PM, Xin Long wrote: > On Thu, Mar 3, 2016 at 8:29 PM, Nikolay Aleksandrov > wrote: >> >> This is incorrect because you don't have rtnl here, bridge device sysfs >> options take care of rtnl only on per-option basis and they obtain and >> release it

Re: [RFC] net: ipv4 -- Introduce ifa limit per net

On Sat, Mar 05, 2016 at 11:33:12AM -0500, David Miller wrote: ... > > Probably the same optimization can be applied there, see patch below. > And if that doesn't do it, there is a really easy way to batch the > delete by scanning the FIB tree in one go and deleting every entry > that points to

Re: [PATCH v3 net-next 9/9] net: mvneta: Use the new hwbm framework

Hi Gregory, [auto build test ERROR on v4.5-rc6] [cannot apply to net-next/master robh/for-next next-20160304] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url:

Re: [PATCH v3 net-next 7/9] net: mvneta: bm: add support for hardware buffer management

Hi Marcin, [auto build test ERROR on v4.5-rc6] [also build test ERROR on next-20160304] [cannot apply to net-next/master robh/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url:

Re: [Patch] rose_route_frame() NULL pointer dereference kernel panic

Le 05/03/2016 17:22, David Miller a écrit : > From: f6bvp > Date: Sat, 5 Mar 2016 16:32:42 +0100 > >> I understand I did not explain clearly or completely things. >> >> I agree that each time patched rose_xmit() is calling >> rose_route_frame() it will >> get a 0 return. >> And

[PATCH v3 net-next 8/9] net: add a hardware buffer management helper API

This basic implementation allows to share code between driver using hardware buffer management. As the code is hardware agnostic, there is few helpers, most of the optimization brought by the an HW BM has to be done at driver level. Signed-off-by: Gregory CLEMENT

[PATCH v3 net-next 4/9] ARM: dts: armada-xp: enable buffer manager support on Armada XP boards

From: Marcin Wojtas Since mvneta driver supports using hardware buffer management (BM), in order to use it, board files have to be adjusted accordingly. This commit enables BM on AXP-DB and AXP-GP in same manner - because number of ports on those boards is the same as number

[PATCH v3 net-next 2/9] ARM: dts: armada-38x: enable buffer manager support on Armada 38x boards

From: Marcin Wojtas Since mvneta driver supports using hardware buffer management (BM), in order to use it, board files have to be adjusted accordingly. This commit enables BM on: * A385-DB-AP - each port has its own pool for long and common pool for short packets, *

[PATCH v3 net-next 9/9] net: mvneta: Use the new hwbm framework

Now that the hardware buffer management framework had been introduced, let's use it. Signed-off-by: Gregory CLEMENT --- drivers/net/ethernet/marvell/Kconfig | 1 + drivers/net/ethernet/marvell/mvneta.c| 38 +++--

[PATCH v3 net-next 3/9] ARM: dts: armada-xp: add buffer manager nodes

From: Marcin Wojtas Armada XP network controller supports hardware buffer management (BM). Since it is now enabled in mvneta driver, appropriate nodes can be added to armada-xp.dtsi - for the actual common BM unit (bm@c) and its internal SRAM (bm-bppi), which is used for

[PATCH v3 net-next 7/9] net: mvneta: bm: add support for hardware buffer management

From: Marcin Wojtas Buffer manager (BM) is a dedicated hardware unit that can be used by all ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX path by sparing DRAM access on refilling buffer pool, hardware-based filling of descriptor ring data and

[PATCH v3 net-next 6/9] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information

From: Marcin Wojtas This commit enables finding appropriate mbus window and obtaining its target id and attribute for given physical address in two separate routines, both for IO and DRAM windows. This functionality is needed for Armada XP/38x Network Controller's Buffer

[PATCH v3 net-next 1/9] ARM: dts: armada-38x: add buffer manager nodes

From: Marcin Wojtas Armada 38x network controller supports hardware buffer management (BM). Since it is now enabled in mvneta driver, appropriate nodes can be added to armada-38x.dtsi - for the actual common BM unit (bm@c8000) and its internal SRAM (bm-bppi), which is used for

[PATCH v3 net-next 0/9] API set for HW Buffer management

This is a third version of an API set for HW Buffer management that I initially submit here: http://thread.gmane.org/gmane.linux.kernel/2125152 Since the last version I took into account David's remarks: - I made a HWBM and a SWBM version of the mvneta_rx() function in order to reduce the the

[PATCH v3 net-next 5/9] ARM: dts: armada-xp-openblocks-ax3-4: Add BM support

Allow Openblock AX3 using hardware buffer management with mvneta. Signed-off-by: Gregory CLEMENT --- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git

Re: [RFC] net: ipv4 -- Introduce ifa limit per net

On Sat, Mar 05, 2016 at 11:33:12AM -0500, David Miller wrote: > > and until everything get cleaned up I couldn't connect > > to the node via ssh. I continue playing with patch maybe > > I find some other optimization paths. Thanks! > > What is the order of magnitude of the delay, as a function of

Re: [PATCH net] sctp: use gfp insteaad of GFP_NOWAIT in idr_alloc_cyclic when sctp_assoc_set_id

On sam., 2016-03-05 at 23:59 +0800, Xin Long wrote: > The following call trace appears because of idr_alloc_cyclic(..., GFP_NOWAIT), > that is a stress test, and the reason should be a heavy use. it will cause > sctp_process_init return 0, and make connection init fail. > > All the allocations of

Re: [RFC] net: ipv4 -- Introduce ifa limit per net

From: Cyrill Gorcunov Date: Sat, 5 Mar 2016 18:57:14 +0300 > On Fri, Mar 04, 2016 at 11:11:09PM -0500, David Miller wrote: >> From: Eric Dumazet >> Date: Fri, 04 Mar 2016 16:08:30 -0800 >> >> > __inet_del_ifa() should probably take into account

Re: [Patch] rose_route_frame() NULL pointer dereference kernel panic

From: f6bvp Date: Sat, 5 Mar 2016 16:32:42 +0100 > I understand I did not explain clearly or completely things. > > I agree that each time patched rose_xmit() is calling > rose_route_frame() it will > get a 0 return. > And I think this is what was intended by the author of

Hellion dear

Nice meet you i"m ms delson by name you got me interested on fb how are you doing my dear?

[PATCH net] sctp: use gfp insteaad of GFP_NOWAIT in idr_alloc_cyclic when sctp_assoc_set_id

The following call trace appears because of idr_alloc_cyclic(..., GFP_NOWAIT), that is a stress test, and the reason should be a heavy use. it will cause sctp_process_init return 0, and make connection init fail. All the allocations of idr_alloc_cyclic should respect gfp flag. So we can fix it by

Re: [RFC] net: ipv4 -- Introduce ifa limit per net

On Fri, Mar 04, 2016 at 11:11:09PM -0500, David Miller wrote: > From: Eric Dumazet > Date: Fri, 04 Mar 2016 16:08:30 -0800 > > > __inet_del_ifa() should probably take into account in_dev->dead (no > > promotion, no list scan...) > > Indeed, that is the real problem:

Re: Possible double-free in the usbnet driver

On Fri, 2016-03-04 at 14:43 -0800, Linus Torvalds wrote: > So you have usbnet_defer_kevent() getting triggered, which in turn > ends up using "usbnet->kevent" > > But somebody like Oliver is really the right person to check this. For > example, it's entirely possible that we should just instead

Re: [Patch] rose_route_frame() NULL pointer dereference kernel panic

David, I understand I did not explain clearly or completely things. I agree that each time patched rose_xmit() is calling rose_route_frame() it will get a 0 return. And I think this is what was intended by the author of rose_xmit(). He wrote a null argument in order to obtain this result but

Re: [PATCH net] bridge: a netlink notification should be sent whenever those attributes change

On Thu, Mar 3, 2016 at 8:29 PM, Nikolay Aleksandrov wrote: > > This is incorrect because you don't have rtnl here, bridge device sysfs > options take care of rtnl only on per-option basis and they obtain and > release it themselves, so you won't have rtnl held when

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

Am 04.03.2016 um 17:18 schrieb Paul Bolle: > [Added Tilman and Christoph.] > > On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote: >> I actually did more patches that I ended up not submitting: >> >> * move hisax to staging >> * remove i4l support from gigaset > > For the record: I have no

Re: [PATCH nf 2/3] netfilter: ipvs: allow rescheduling after RST

Hello, On Thu, 18 Feb 2016, Sergei Shtylyov wrote: > On 2/18/2016 3:41 AM, Simon Horman wrote: > > > From: Julian Anastasov > > > > "RFC 5961, 4.2. Mitigation" describes a mechanism to request > > client to confirm with RST the restart of TCP connection > > before

Re: [PATCH net 1/3] net: validate variable length ll headers

Am 04.03.2016 21:44, schrieb Willem de Bruijn: > From: Willem de Bruijn > > Netdevice parameter hard_header_len is variously interpreted both as > an upper and lower bound on link layer header length. The field is > used as upper bound when reserving room at allocation, as