Re: [PATCH net-next v4 02/13] phy: add the mvebu cp110 comphy driver

On Wednesday 30 August 2017 01:59 PM, Antoine Tenart wrote: > On the CP110 unit, which can be found on various Marvell platforms such > as the 7k and 8k (currently), a comphy (common PHYs) hardware block can > be found. This block provides a number of PHYs which can be used in > various modes by

Re: [PATCH v2 2/3] dt-binding: net: sfp binding documentation

Hi Sergei, On Wed, Aug 30, 2017 at 02:15:32PM +0300, Sergei Shtylyov wrote: > On 8/30/2017 2:11 PM, Baruch Siach wrote: > > > On Wed, Aug 30, 2017 at 02:04:11PM +0300, Sergei Shtylyov wrote: > > > On 8/30/2017 12:51 PM, Baruch Siach wrote: > > > > > > > Add device-tree binding documentation SFP

[PATCH v3 net-next] staging: irda: fix init level for irda core

When moving the IRDA code out of net/ into drivers/staging/irda/net, the link order changes when IRDA is built into the kernel. That causes a kernel crash at boot time as netfilter isn't initialized yet. To fix this, move the init call level of the irda core to be device_initcall() as the link

Re: [PATCH v2 2/3] dt-binding: net: sfp binding documentation

Hello! On 8/30/2017 12:51 PM, Baruch Siach wrote: Add device-tree binding documentation SFP transceivers. Support for SFP transceivers has been recently introduced (drivers/net/phy/sfp.c). Signed-off-by: Baruch Siach --- v2: Rename -gpio properties to -gpios Rename

Re: Question about ip_defrag

(trimmed CC list a bit) On Tue, 29 Aug 2017 09:53:15 +0200 Florian Westphal wrote: > Jesper Dangaard Brouer wrote: > > On Mon, 28 Aug 2017 16:00:32 +0200 > > Florian Westphal wrote: > > > > > liujian (CE) wrote: >

Re: [PATCH v2 net-next 4/6] udp: flow dissector offload

On Tue, 2017-08-29 at 16:27 -0700, Tom Herbert wrote: > Add support to perform UDP specific flow dissection. This is > primarily intended for dissecting encapsulated packets in UDP > encapsulation. > > This patch adds a flow_dissect offload for UDP4 and UDP6. The backend > function performs a

Re: [patch net-next 2/3] net/sched: Change cls_flower to use IDR

On Tue, Aug 29, 2017 at 03:25:35AM +, Chris Mi wrote: > > > > -Original Message- > > From: Simon Horman [mailto:simon.hor...@netronome.com] > > Sent: Monday, August 28, 2017 7:37 PM > > To: Chris Mi > > Cc: netdev@vger.kernel.org; j...@mojatatu.com; > >

[net-next PATCHv6 2/2] net: socionext: Add NetSec driver

This driver adds support for Socionext "netsec" IP Gigabit Ethernet + PHY IP used in a variety of their ARM-based ASICs. Signed-off-by: Jassi Brar --- drivers/net/ethernet/Kconfig | 1 + drivers/net/ethernet/Makefile | 1

[net-next PATCHv6 1/2] dt-bindings: net: Add DT bindings for Socionext Netsec

This patch adds documentation for Device-Tree bindings for the Socionext NetSec Controller driver. Signed-off-by: Jassi Brar --- .../devicetree/bindings/net/socionext-netsec.txt | 46 ++ 1 file changed, 46 insertions(+) create mode 100644

[net-next PATCHv6 0/2] net: ethernet: Socionext Netsec

Hello, The OGMA/Netsec controller is used in latest SoC from Socionext/Fujitsu. I am refreshing the patchset by basically using official name of the IP from 'OGMA' to 'Netsec'. And the company is renamed too, from Fujitsu to Socionext to better reflect the reality. I have addressed comments

Re: [PATCH v2] ipv6: sr: fix get_srh() to comply with IPv6 standard "RFC 8200"

On 08/30/2017 10:50 AM, Ahmed Abdelsalam wrote: > This patch fixes the get_srh(), so it gets the segment routing header > regardless of its position in the chain of the extension headers in IPv6 > packet, and makes sure that the IPv6 routing extension header is of Type 4. > > Signed-off-by: Ahmed

Re: [PATCH] net: stmmac: dwmac-sun8i: Use reset exclusive

On Fri, Aug 25, 2017 at 07:12:33PM +0200, Maxime Ripard wrote: > On Fri, Aug 25, 2017 at 05:17:33PM +0200, Corentin Labbe wrote: > > On Fri, Aug 25, 2017 at 04:48:32PM +0200, Maxime Ripard wrote: > > > On Fri, Aug 25, 2017 at 04:38:05PM +0200, Corentin Labbe wrote: > > > > The current dwmac_sun8i

Re: [PATCH] DSA support for Micrel KSZ8895

2017-08-30 0:23 GMT+03:00 Florian Fainelli : > On 08/29/2017 02:15 PM, Pavel Machek wrote: >> On Tue 2017-08-29 14:26:04, Andrew Lunn wrote: But the MDIO emaulation code is from their driver, after lots of deletions. >>> >>> Is this driver supposed to run on lots of

[PATCH net 5/9] sch_cbq: fix null pointer dereferences on init failure

CBQ can fail on ->init by wrong nl attributes or simply for missing any, f.e. if it's set as a default qdisc then TCA_OPTIONS (opt) will be NULL when it is activated. The first thing init does is parse opt but it will dereference a null pointer if used as a default qdisc, also since init failure

Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

Hello, Yi Yang writes: [...] > +struct ovs_key_nsh { > + u8 flags; > + u8 ttl; > + u8 mdtype; > + u8 np; > + __be32 path_hdr; > + __be32 context[NSH_MD1_CONTEXT_SIZE]; > +}; > + > struct sw_flow_key { > u8 tun_opts[IP_TUNNEL_OPTS_MAX]; >

[PATCH v2 3/3] net: phy: sfp: rename the rate-select property

Make the Rx rate select control gpio property name match the documented binding. This would make the addition of 'rate-select1-gpios' for SFP+ support more natural. Signed-off-by: Baruch Siach --- v2: New patch in this series --- drivers/net/phy/sfp.c | 2 +- 1 file changed,

[PATCH v2 1/3] dt-bindings: add SFF vendor prefix

Signed-off-by: Baruch Siach --- v2: New patch in this series --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt

[PATCH v2 2/3] dt-binding: net: sfp binding documentation

Add device-tree binding documentation SFP transceivers. Support for SFP transceivers has been recently introduced (drivers/net/phy/sfp.c). Signed-off-by: Baruch Siach --- v2: Rename -gpio properties to -gpios Rename the rate-select-gpio property to rate-select0-gpios Add

Re: [GIT] Networking

Hi! Could we get this one in? wl1251 misses a spin_lock_init(). https://www.mail-archive.com/netdev@vger.kernel.org/msg177031.html It seems pretty trivial, yet getting the backtraces is not nice. Thanks, Pavel -- (english)

[PATCH net 1/9] sch_htb: fix crash on init failure

The commit below added a call to the ->destroy() callback for all qdiscs which failed in their ->init(), but some were not prepared for such change and can't handle partially initialized qdisc. HTB is one of them and if any error occurs before the qdisc watchdog timer and qdisc work are

[PATCH net 2/9] sch_multiq: fix double free on init failure

The below commit added a call to ->destroy() on init failure, but multiq still frees ->queues on error in init, but ->queues is also freed by ->destroy() thus we get double free and corrupted memory. Very easy to reproduce (eth0 not multiqueue): $ tc qdisc add dev eth0 root multiq RTNETLINK

[PATCH net 8/9] sch_sfq: fix null pointer dereference on init failure

Currently only a memory allocation failure can lead to this, so let's initialize the timer first. Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure") Signed-off-by: Nikolay Aleksandrov --- net/sched/sch_sfq.c | 6 +++--- 1 file changed, 3

[PATCH net 3/9] sch_hhf: fix null pointer dereference on init failure

If sch_hhf fails in its ->init() function (either due to wrong user-space arguments as below or memory alloc failure of hh_flows) it will do a null pointer deref of q->hh_flows in its ->destroy() function. To reproduce the crash: $ tc qdisc add dev eth0 root hhf quantum 200 non_hh_weight

[PATCH net 9/9] sch_tbf: fix two null pointer dereferences on init failure

sch_tbf calls qdisc_watchdog_cancel() in both its ->reset and ->destroy callbacks but it may fail before the timer is initialized due to missing options (either not supplied by user-space or set as a default qdisc), also q->qdisc is used by ->reset and ->destroy so we need it initialized.

[PATCH net 6/9] sch_fq_codel: avoid double free on init failure

It is very unlikely to happen but the backlogs memory allocation could fail and will free q->flows, but then ->destroy() will free q->flows too. For correctness remove the first free and let ->destroy clean up. Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation") Signed-off-by:

[PATCH net 7/9] sch_netem: avoid null pointer deref on init failure

netem can fail in ->init due to missing options (either not supplied by user-space or used as a default qdisc) causing a timer->base null pointer deref in its ->destroy() and ->reset() callbacks. Reproduce: $ sysctl net.core.default_qdisc=netem $ ip l set ethX up Crash log: [ 1814.846943] BUG:

[PATCH net 4/9] sch_hfsc: fix null pointer deref and double free on init failure

Depending on where ->init fails we can get a null pointer deref due to uninitialized hires timer (watchdog) or a double free of the qdisc hash because it is already freed by ->destroy(). Fixes: 8d5537387505 ("net/sched/hfsc: allocate tcf block for hfsc root class") Fixes: 87b60cfacf9f

[PATCH net 0/9] net/sched: init failure fixes

Hi all, I went over all qdiscs' init, destroy and reset callbacks and found the issues fixed in each patch. Mostly they are null pointer dereferences due to uninitialized timer (qdisc watchdog) or double frees due to ->destroy cleaning up a second time. There's more information in each patch. I've

[PATCH] net: bcm63xx_enet: make bcm_enetsw_ethtool_ops const

Make this const as it is never modified. Signed-off-by: Bhumika Goyal --- drivers/net/ethernet/broadcom/bcm63xx_enet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c

Re: [PATCH v3 3/6] dt: booting-without-of: DT fix s/#interrupt-cell/#interrupt-cells/

Geert Uytterhoeven writes: > Signed-off-by: Geert Uytterhoeven > Acked-by: Rob Herring > --- Rob this has your ack, but I'd expect it to go via your tree? Or should I grab it? cheers > diff --git

[PATCH v2] ipv6: sr: fix get_srh() to comply with IPv6 standard "RFC 8200"

IPv6 packet may carry more than one extension header, and IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet. Hence, there should be no assumption that Segment Routing extension header is to appear immediately after the

Re: [PATCH v2 net-next 0/6] flow_dissector: Protocol specific flow dissector offload

Hello Tom, Tom Herbert writes: > This patch set adds a new offload type to perform flow dissection for > specific protocols (either by EtherType or by IP protocol). This is > primary useful to crack open UDP encapsulations (like VXLAN, GUE) for > the purposes of parsing the

[PATCH net-next v4 01/13] phy: add sgmii and 10gkr modes to the phy_mode enum

This patch adds more generic PHY modes to the phy_mode enum, to allow configuring generic PHYs to the SGMII and/or the 10GKR mode by using the set_mode callback. Signed-off-by: Antoine Tenart Acked-by: Kishon Vijay Abraham I ---

[PATCH net-next v4 04/13] net: mvpp2: initialize the comphy

On some platforms, the comphy is between the MAC GoP and the PHYs. The mvpp2 driver currently relies on the firmware/bootloader to configure the comphy. As a comphy driver was added to the generic PHY framework, this patch uses it in the mvpp2 driver to configure the comphy at boot time to avoid

[PATCH net-next v4 02/13] phy: add the mvebu cp110 comphy driver

On the CP110 unit, which can be found on various Marvell platforms such as the 7k and 8k (currently), a comphy (common PHYs) hardware block can be found. This block provides a number of PHYs which can be used in various modes by other controllers (network, SATA ...). These common PHYs must be

[PATCH net-next v4 03/13] Documentation/bindings: phy: document the Marvell comphy driver

The Marvell Armada 7K/8K SoCs contains an hardware block called COMPHY that provides a number of shared PHYs used by various interfaces in the SoC: network, SATA, PCIe, etc. This Device Tree binding allows to describe this COMPHY hardware block. Signed-off-by: Antoine Tenart

[PATCH net-next v4 09/13] arm64: dts: marvell: extend the cp110 syscon register area length

This patch extends on both cp110 the system register area length to include some of the comphy registers as well. Signed-off-by: Antoine Tenart --- arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +- arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi

[PATCH net-next v4 00/13] net: mvpp2: comphy configuration

Hi all, This series, following up the one one the GoP/MAC configuration, aims at stopping to depend on the firmware/bootloader configuration when using the PPv2 engine. With this series the PPv2 driver does not need to rely on a previous configuration, and dynamic reconfiguration while the kernel

[PATCH net-next v4 06/13] net: mvpp2: improve the link management function

When the link status changes, the phylib calls the link_event function in the mvpp2 driver. Before this patch only the egress/ingress transmit was enabled/disabled. This patch adds more functionality to the link status management code by enabling/disabling the port per-cpu interrupts, and the port

[PATCH net-next v4 05/13] net: mvpp2: simplify the link_event function

The link_event function is somewhat complicated. This cosmetic patch simplifies it. Signed-off-by: Antoine Tenart --- drivers/net/ethernet/marvell/mvpp2.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git

[PATCH net-next v4 12/13] arm64: dts: marvell: 7040-db: add comphy references to Ethernet ports

This patch adds comphy phandles to the Ethernet ports in the 7040-db device tree. The comphy is used to configure the serdes PHYs used by these ports. Signed-off-by: Antoine Tenart --- arch/arm64/boot/dts/marvell/armada-7040-db.dts | 1 + 1 file changed, 1

[PATCH net-next v4 11/13] arm64: dts: marvell: mcbin: add comphy references to Ethernet ports

This patch adds comphy phandles to the Ethernet ports in the mcbin device tree. The comphy is used to configure the serdes PHYs used by these ports. Signed-off-by: Antoine Tenart --- arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 3 +++ 1 file changed, 3

[PATCH net-next] xfrm: Add support for network devices capable of removing the ESP trailer

From: Yossi Kuperman In conjunction with crypto offload [1], removing the ESP trailer by hardware can potentially improve the performance by avoiding (1) a cache miss incurred by reading the nexthdr field and (2) the necessity to calculate the csum value of the trailer in

[PATCH net-next v4 08/13] net: mvpp2: dynamic reconfiguration of the comphy/GoP/MAC

This patch adds logic to reconfigure the comphy/GoP/MAC when the link state is updated at runtime. This is very useful on boards where many link speed are supported: depending on what is negotiated the PPv2 driver will automatically reconfigures the link between the PHY and the MAC.

[PATCH net-next v4 13/13] arm64: defconfig: enable Marvell CP110 comphy

From: Miquel Raynal The comphy is an hardware block giving access to common PHYs that can be used by various other engines (Network, SATA, ...). This is used on Marvell 7k/8k platforms for now. Enable the corresponding driver. Signed-off-by: Miquel Raynal

[PATCH net-next v4 10/13] arm64: dts: marvell: add comphy nodes on cp110 master and slave

Now that the comphy driver is available, this patch adds the corresponding nodes in the cp110 master and slave device trees. Signed-off-by: Antoine Tenart --- .../boot/dts/marvell/armada-cp110-master.dtsi | 38 ++

[PATCH] net: ti: cpsw-common: dont print error if ti_cm_get_macid() fails

It is quite common for ti_cm_get_macid() to fail on some of the platforms it is invoked on. They include any platform where mac address is not part of SoC register space. On these platforms, mac address is read and populated in device-tree by bootloader. An example is TI DA850. Downgrade the

Re: nflog performance ...

Anybody? On Tue, Aug 29, 2017 at 4:11 PM, Akshat Kakkar wrote: > I am using ulogd2 to log iptables activity. > However, when using pgsql as output plugin ... performance is very > very sluggish. (~130-150 entries per second) > > To enhance performance I am trying > >

Re: [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG

Indeed, sorry I missed that as well. So what should we make of that #ifdef? The code inside it doesn't compile (anymore? I didn't find any development history for that patch except the original mail), as there is no definition of struct submit_ctx in the headers (for other rtl drivers - 8188eu,

Re: NFCT writing localhost conntrack entries too

Anybody ? On Tue, Aug 29, 2017 at 3:53 PM, Akshat Kakkar wrote: > With ulog/nflog, NFCT plugin, is it possible to not log entries with src ip > as 127.0.0.1 > > I can see following options in ulogd.conf > #accept_src_filter=192.168.1.0/24,1:2::/64 # source ip of connection

Re: [PATCH net-next 0/4] nsh: headers, GSO

On Wed, 30 Aug 2017 15:19:37 +0800, Yang, Yi wrote: > Do you mean we need move push_nsh from net/openvswitch/actions.c to > net/nsh/nsh.c in order that kernel can load nsh kernel module > automatically? Yes. Without that struct sw_flow_key parameter but that's obvious. Jiri

Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface

Tue, Aug 29, 2017 at 02:50:04PM CEST, and...@lunn.ch wrote: >On Tue, Aug 29, 2017 at 08:25:23AM +0200, Jiri Pirko wrote: >> Mon, Aug 28, 2017 at 10:08:34PM CEST, and...@lunn.ch wrote: >> >> I see this overlaps a lot with DPIPE. Why won't you use that to expose >> >> your hw state? >> > >> >We took

Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface

Tue, Aug 29, 2017 at 05:57:54PM CEST, vivien.dide...@savoirfairelinux.com wrote: >Hi David, Jiri, > >Jiri Pirko writes: > >> Tue, Aug 29, 2017 at 06:38:37AM CEST, da...@davemloft.net wrote: >>>From: Vivien Didelot >>>Date: Mon, 28 Aug 2017

Re: [PATCH net-next 0/4] nsh: headers, GSO

On Wed, Aug 30, 2017 at 09:20:40AM +0200, Jiri Benc wrote: > > > I'll post new OVS NSH kernel datapath patch series if NSH GSO is done. > > Please do. Note that it's important to ensure that whenever there's a > NSH header added, the nsh module gets loaded. The easiest way is to > factor out

Re: [PATCH net] sch_hhf: fix null pointer dereference on init failure

On 30/08/17 04:24, Cong Wang wrote: > On Tue, Aug 29, 2017 at 12:02 PM, Nikolay Aleksandrov > wrote: >> First I did it with the check in the for () conditional, but this is more >> visible and explicit. Let me know if you'd like the shorter version. :-) > > Or, if

Re: [PATCH net-next 0/4] nsh: headers, GSO

On Wed, 30 Aug 2017 13:23:04 +0800, Yang, Yi wrote: > David has merged your NSH GSO series, do you have one more patch series > to fix VxLAN-gpe+NSH GSO issue? I think we still need do something in > skb_udp_tunnel_segment in net/ipv4/udp_offload.c to support > VxLAN-gpe+NSH GSO. This should work

[PATCH net-next] dp83640: don't hold spinlock while calling netif_rx_ni

We should not hold a spinlock while pushing the skb into the networking stack, so move the call to netif_rx_ni out of the critical region to where we have dropped the spinlock. Signed-off-by: Stefan Sørensen --- drivers/net/phy/dp83640.c | 7 +-- 1 file

[PATCH net-next] net: cpsw: Don't handle SIOC[GS]HWTSTAMP when CPTS is disabled

There is no reason to handle SIOC[GS]HWTSTAMP and return -EOPNOTSUPP when CPTS is disabled, so just pass them on to the phy. This will allow PTP timestamping on a capable phy by disabling CPTS. Signed-off-by: Stefan Sørensen --- drivers/net/ethernet/ti/cpsw.c |

Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver

Hi Kishon, On Wed, Aug 30, 2017 at 11:01:56AM +0530, Kishon Vijay Abraham I wrote: > > I think we should just select the mode that a particular lane has been > configured here instead of populating all the modes. But I think that doesn't > make sense since the mode is set by the consumer and the

Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver

Hi Kishon, On Wed, Aug 30, 2017 at 10:49:13AM +0530, Kishon Vijay Abraham I wrote: > On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote: > > + > > +static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode) > > the mode need not be passed as argument here since this

[patch net-next v2 0/3] net/sched: Improve getting objects by indexes

Using current TC code, it is very slow to insert a lot of rules. In order to improve the rules update rate in TC, we introduced the following two changes: 1) changed cls_flower to use IDR to manage the filters. 2) changed all act_xxx modules to use IDR instead of a

[patch net-next v2 2/3] net/sched: Change cls_flower to use IDR

Currently, all filters with the same priority are linked in a doubly linked list. Every filter should have a unique handle. To make the handle unique, we need to iterate the list every time to see if the handle exists or not when inserting a new filter. It is time-consuming. For example, it takes

[patch net-next v2 1/3] idr: Add new APIs to support unsigned long

The following new APIs are added: int idr_alloc_ext(struct idr *idr, void *ptr, unsigned long *index, unsigned long start, unsigned long end, gfp_t gfp); void *idr_remove_ext(struct idr *idr, unsigned long id); void *idr_find_ext(const struct idr *idr, unsigned long id); void

[patch net-next v2 3/3] net/sched: Change act_api and act_xxx modules to use IDR

Typically, each TC filter has its own action. All the actions of the same type are saved in its hash table. But the hash buckets are too small that it degrades to a list. And the performance is greatly affected. For example, it takes about 0m11.914s to insert 64K rules. If we convert the hash

Re: [lkp-robot] [irda] 66d98e78e4: BUG:unable_to_handle_kernel

On 08/30, Greg Kroah-Hartman wrote: >On Wed, Aug 30, 2017 at 02:04:11PM +0800, kernel test robot wrote: >> FYI, we noticed the following commit: >> >> commit: 66d98e78e44ccb969cb3196995759d200e64b49b ("irda: move net/irda/ to >> drivers/staging/irda/net/") >> url: >>

Re: [lkp-robot] [irda] 66d98e78e4: BUG:unable_to_handle_kernel

On Wed, Aug 30, 2017 at 02:04:11PM +0800, kernel test robot wrote: > FYI, we noticed the following commit: > > commit: 66d98e78e44ccb969cb3196995759d200e64b49b ("irda: move net/irda/ to > drivers/staging/irda/net/") > url: >

[PATCH] net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()

Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv() in net/dccp/ipv6.c, similar to the handling in net/ipv6/tcp_ipv6.c Signed-off-by: Andrii Vladyka diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c index 1b58eac..fdff10b 100644 --- a/net/dccp/ipv6.c +++ b/net/dccp/ipv6.c @@ -16,6

[lkp-robot] [irda] 66d98e78e4: BUG:unable_to_handle_kernel

FYI, we noticed the following commit: commit: 66d98e78e44ccb969cb3196995759d200e64b49b ("irda: move net/irda/ to drivers/staging/irda/net/") url: https://github.com/0day-ci/linux/commits/Greg-Kroah-Hartman/irda-move-it-to-drivers-staging-so-we-can-delete-it/20170829-090816 in testcase: trinity

<    1   2   3