[PATCH net-next 1/7] net: dsa: mv88e6xxx: provide printing macros

The mv88e6xxx driver accesses a port's netdev mostly for printing. This is bad for 2 reasons: DSA and CPU ports do not have a netdev pointer; it doesn't give us a correct picture of why a DSA driver might need to access a port's netdev. Introduce mv88e6xxx_{dbg,err,warn} macros to print messages

[PATCH net-next 2/7] net: dsa: mv88e6xxx: add egress mode enumeration

As for the frame mode, add a mv88e6xxx_egress_mode enumeration instead of a 16-bit register mask. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 11 ++- drivers/net/dsa/mv88e6xxx/chip.h | 7 +++

[PATCH net-next 5/7] net: dsa: mv88e6xxx: rework pause limit operation

All Marvell chips supporting Pause frames limiting use 1-byte value for input and output. Old chips have both bytes adjacent in a 16-bit register. New ones have an indirect table using 8-bit data. The mv88e6xxx library functions (such as in port.c) must not contain driver logic, but only generic

[PATCH net-next 6/7] net: dsa: mv88e6xxx: rework jumbo size operation

Marvell chips have a Jumbo Mode to set the maximum frame size (MTU). The mv88e6xxx_ops structure is meant to contain generic functionalities, no driver logic. Change port_jumbo_config to port_set_jumbo_size setting the mode from a given maximum size value. There is no functional changes since we

Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On 08/06/17 19:41, Alexei Starovoitov wrote: > On Thu, Jun 08, 2017 at 06:12:39PM +0100, Edward Cree wrote: >> On 08/06/17 17:50, Alexei Starovoitov wrote: >>> On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote: On 08/06/17 03:35, Alexei Starovoitov wrote: > such large back and

[PATCH net-next 7/7] net: dsa: mv88e6xxx: prefix PHY macros

Prefix the PHY_* macros with a Marvell specific MV88E6XXX_ prefix. There is no functional changes. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/phy.c | 11 ++- drivers/net/dsa/mv88e6xxx/phy.h | 4 ++-- 2 files changed, 8

[PATCH net-next 4/7] net: dsa: mv88e6xxx: do not prefix ops with g1

The mv88e6xxx_ops describe functionalities, regardless their locations (which can be Global1, Global2, or whatever register set.) Rename the g1_set_cpu_port and g1_set_egress_port ops to set_cpu_port and set_egress_port. No functional changes. Signed-off-by: Vivien Didelot

[PATCH net-next 0/7] net: dsa: mv88e6xxx: ops cosmetics

This patchset brings no functional changes. It is a first step in a bigger cosmetics change to the driver. It provides macros and polishes data types and chip operations. The next patchs will only prefix and document the port registers macros. Vivien Didelot (7): net: dsa: mv88e6xxx: provide

[PATCH net-next 3/7] net: dsa: mv88e6xxx: use bridge state values

Reuse the BR_STATE_* values to abstract a port STP state value. This provides shorter names and better control over the DSA switch operation call. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 23 ++-

[PATCH] geneve: add missing rx stats accounting

There are few places on the receive path where packet drops and packet errors were not accounted for. This patch fixes that issue. Signed-off-by: Girish Moodalbail --- drivers/net/geneve.c | 36 1 file changed, 24 insertions(+),

[PATCH net-next] net: ethernet: ti: cpdma: do not enable host error misc irq

CPSW driver does not handle this interrupt, so there are no reasons to enable it in hardware. Signed-off-by: Grygorii Strashko --- no changes, just resubmitting with proper subj line. drivers/net/ethernet/ti/davinci_cpdma.c | 5 + 1 file changed, 1 insertion(+), 4

[PATCH net-next] net: ethernet: ti: cpsw: enable HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter

CPSW driver supports PTP v1 messages, but for unknown reasons this filter is not advertised. As result, ./tools/testing/selftests/networking/timestamping/timestamping utility can't be used for testing of CPSW RX timestamping with option SOF_TIMESTAMPING_RX_HARDWARE, because it uses

Re: [net-next 0/2][pull request] 1GbE Intel Wired LAN Driver Updates 2017-06-07

From: Jeff Kirsher Date: Wed, 7 Jun 2017 22:32:35 -0700 > This series contains a fix for e1000e and igb. > > Colin Ian King fixes sparse warnings in igb by making functions static. > > Chris Wilson provides a fix for a previous commit which is causing an > issue

Re: [PATCH net-next] cxgb4: fix to bring link down after adapter crash

From: Ganesh Goudar Date: Thu, 8 Jun 2017 10:52:11 +0530 > From: Rahul Lakkireddy > > Use PORT_REG for T4 and T5_PORT_REG for > T4 to write to correct > register to bring down link during shutdown after adapter crash. > > Signed-off-by:

Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On Thu, Jun 08, 2017 at 06:12:39PM +0100, Edward Cree wrote: > On 08/06/17 17:50, Alexei Starovoitov wrote: > > On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote: > >> On 08/06/17 03:35, Alexei Starovoitov wrote: > >>> such large back and forth move doesn't help reviewing. > >>> may be

Re: [patch iproute2/net-next] tc: add support for TRAP action

Thu, Jun 08, 2017 at 07:26:12PM CEST, jb...@redhat.com wrote: >On Mon, 5 Jun 2017 16:39:45 +0200, Jiri Pirko wrote: >> From: Jiri Pirko >> >> Signed-off-by: Jiri Pirko >> --- >> include/linux/pkt_cls.h | 5 + >> tc/tc_util.c| 3 +++ >> 2

Re: [PATCH net-next v2] net: ipmr: add getlink support

From: Nikolay Aleksandrov Date: Wed, 7 Jun 2017 18:02:32 +0300 > Currently there's no way to dump the VIF table for an ipmr table other > than the default (via proc). This is a major issue when debugging ipmr > issues and in general it is good to know which

Re: [patch net-next 0/3] mlxsw: Remove compatibility with old firmware

From: Jiri Pirko Date: Thu, 8 Jun 2017 08:47:42 +0200 > Up until recently we couldn't enforce a minimal firmware version, which > forced us to be compatible with old firmware versions. This patchset > removes this code and simplifies the driver. Series applied, thanks Jiri.

Re: [PATCH net] ipv4: igmp: fix a use after free

On Thu, Jun 8, 2017 at 9:43 PM, Eric Dumazet wrote: > From: Eric Dumazet > > Andrey reported a use-after-free in add_grec(), courtesy of syzkaller. > > Problem here is that igmp_stop_timer() uses a del_timer(), so we can not > guarantee that another

Re: [patch net-next v2 00/19] Remove support from bridge bypass for mlxsw/rocker drivers

From: Jiri Pirko Date: Thu, 8 Jun 2017 08:44:09 +0200 > Currently setting bridge port attributes and adding FDBs are done via > setting the SELF flag which implies unconsistent offloading model. This > patch-set fixes this behavior by making the bridge and drivers which are >

Re: [PATCH net-next v2 6/6] vxlan: allow multiple VXLANs with same VNI for IPv6 link-local addresses

On 04/16/2017 05:15 PM, Matthias Schiffer wrote: > On 04/14/2017 07:38 PM, Stephen Hemminger wrote: >> On Fri, 14 Apr 2017 18:44:46 +0200 >> Matthias Schiffer wrote: >> >>> As link-local addresses are only valid for a single interface, we can allow >>> to use the

Re: [PATCH] cpsw: cpts: enable HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter

From: Grygorii Strashko Date: Thu, 8 Jun 2017 11:40:44 -0500 > Hi David, > > On 06/08/2017 08:52 AM, David Miller wrote: >> These two patches do not apply cleanly to my net GIT tree, please >> respin. >> > > I did it on top of net-next as there some conflicts, >

Re: [patch iproute2/net-next] tc: add support for TRAP action

On Mon, 5 Jun 2017 16:39:45 +0200 Jiri Pirko wrote: > From: Jiri Pirko > > Signed-off-by: Jiri Pirko Applied to net-next

[PATCH 2/2 net-next] net: stmmac: Improve documentation on AVB parameters

This patch fixes the description of the DT AVB parameters and gives an accurate example. It was also included the base values that were used to get the example' CBS paremeter values. Signed-off-by: Joao Pinto --- Documentation/devicetree/bindings/net/stmmac.txt | 24

[PATCH 1/2 net-next] net: stmmac: fix RX routing function name

This patch fixes the RX packet routing function name in dwmac4_core. It also calls the correct dwmac4_core callback for the routing configuration purpose. Signed-off-by: Joao Pinto --- drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 +++---

Re: [PATCH iproute] tc: flower: add support for matching on ip tos and ttl

On Wed, 7 Jun 2017 15:17:54 +0300 Or Gerlitz wrote: > Allow users to set flower classifier filter rules which > include matches for ip tos and ttl. > > Signed-off-by: Or Gerlitz > Reviewed-by: Jiri Pirko Applied to net-next

[PATCH] net: vrf: Make add_fib_rules per network namespace flag

Commit 1aa6c4f6b8cd8 ("net: vrf: Add l3mdev rules on first device create") adds the l3mdev FIB rule the first time a VRF device is created. However, it only creates the rule once and only in the namespace the first device is created - which may not be init_net. Fix by using the net_generic

ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic

Hi, I have here two problems with Khadas VIM Pro device and Ethernet. 1) sometimes with the Kernel Linux 4.12-rc4 the Ethernet link is Up but only 10Mbps. Don't work (either SSH to device nor over serial console to ping out) meson8b-dwmac c941.ethernet eth0: Link is Up - 10Mbps/Half - flow

Re: [patch iproute2/net-next] tc: add support for TRAP action

On Mon, 5 Jun 2017 16:39:45 +0200, Jiri Pirko wrote: > From: Jiri Pirko > > Signed-off-by: Jiri Pirko > --- > include/linux/pkt_cls.h | 5 + > tc/tc_util.c| 3 +++ > 2 files changed, 8 insertions(+) No documentation again. Please add the

Using HTB and FQ on the same interface

Hello, I need to use simultaneously on the same interface the classful qdisc HTB and the classless qdisc FQ. The rationale is: - I need to send properly shaped UDP streams to a few remote IP addresses. For this I'm using htb classes and u32 filters. - for a few other remote peers I need FQ

Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On 08/06/17 17:50, Alexei Starovoitov wrote: > On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote: >> On 08/06/17 03:35, Alexei Starovoitov wrote: >>> such large back and forth move doesn't help reviewing. >>> may be just merge it into previous patch? >>> Or keep that function in the

[PATCH net] bpf, tests: fix endianness selection

I noticed that test_l4lb was failing in selftests: # ./test_progs test_pkt_access:PASS:ipv4 77 nsec test_pkt_access:PASS:ipv6 44 nsec test_xdp:PASS:ipv4 2933 nsec test_xdp:PASS:ipv6 1500 nsec test_l4lb:PASS:ipv4 377 nsec test_l4lb:PASS:ipv6 544 nsec test_l4lb:FAIL:stats 629760

ATENCIÓN;

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

Re: [PATCH v2 7/8] net: mvmdio: add xmdio support

On Thu, Jun 08, 2017 at 09:42:21AM -0700, Florian Fainelli wrote: > On 06/08/2017 02:26 AM, Antoine Tenart wrote: > > This patch adds the xMDIO interface support in the mvmdio driver. This > > interface is used in Ethernet controllers on Marvell 370, 7k and 8k (as > > of now). The xSMI interface

Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote: > On 08/06/17 03:35, Alexei Starovoitov wrote: > > such large back and forth move doesn't help reviewing. > > may be just merge it into previous patch? > > Or keep that function in the right place in patch 2 already? > I think 'diff' got

Re: [PATCH net 2/3] bonding: fix 802.3ad support for 14G speed

On Thu, Jun 08, 2017 at 11:18:12AM +0200, Nicolas Dichtel wrote: > This patch adds 14 Gbps enum definition, and fixes > aggregated bandwidth calculation based on above slave links. > > Fixes: 0d7e2d2166f6 ("IB/ipoib: add get_link_ksettings in ethtool") > Signed-off-by: Nicolas Dichtel

Re: [RFC PATCH net-next 4/5] bpf/verifier: track signed and unsigned min/max values

On Thu, Jun 08, 2017 at 04:23:24PM +0100, Edward Cree wrote: > On 08/06/17 03:40, Alexei Starovoitov wrote: > > On Wed, Jun 07, 2017 at 03:59:25PM +0100, Edward Cree wrote: > >> Allows us to, sometimes, combine information from a signed check of one > >> bound and an unsigned check of the other.

Re: [RFC PATCH net-next 2/5] bpf/verifier: rework value tracking

On Thu, Jun 08, 2017 at 03:53:36PM +0100, Edward Cree wrote: > >> > >> - } else if (reg->type == FRAME_PTR || reg->type == PTR_TO_STACK) { > >> + } else if (reg->type == PTR_TO_STACK) { > >> + /* stack accesses must be at a fixed offset, so that we can > >> + * determine

Re: [PATCH v2 7/8] net: mvmdio: add xmdio support

On 06/08/2017 02:26 AM, Antoine Tenart wrote: > This patch adds the xMDIO interface support in the mvmdio driver. This > interface is used in Ethernet controllers on Marvell 370, 7k and 8k (as > of now). The xSMI interface supported by this driver complies with the > IEEE 802.3 clause 45 (while

Re: [PATCH] cpsw: cpts: enable HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter

Hi David, On 06/08/2017 08:52 AM, David Miller wrote: These two patches do not apply cleanly to my net GIT tree, please respin. I did it on top of net-next as there some conflicts, git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git I've just re-checked and both can be applied

Re: [PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

On 06/08/2017 06:25 AM, Christoph Hellwig wrote: > DMA_ERROR_CODE is not a public API and will go away. Instead properly > unwind based on the loop counter. > > Signed-off-by: Christoph Hellwig Acked-by: Dave Jiang > --- > drivers/dma/ioat/init.c | 24

Re: [PATCH 19/44] s390: implement ->mapping_error

On Thu, 8 Jun 2017 15:25:44 +0200 Christoph Hellwig wrote: > s390 can also use noop_dma_ops, and while that currently does not return > errors it will so in the future. Implementing the mapping_error method > is the proper way to have per-ops error conditions. > > Signed-off-by:

[PATCH net-next 3/8] qed: Cleaner seperation of LL2 inputs

A LL2 connection [qed_ll2_info] has a sub-structure of type qed_ll2_conn that contain various inputs for ll2 acquisition, but the connection also utilizes a couple of other inputs. Restructure the input structure to include all the inputs and refactor the code necessary to populate those.

[PATCH net-next 2/8] qed: Revise ll2 Rx completion

This introduces qed_ll2_comp_rx_data as a public struct and moves handling of Rx packets in LL2 into using it. Signed-off-by: Yuval Mintz --- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 84 ++- include/linux/qed/qed_ll2_if.h| 25

[PATCH net-next 6/8] qed: No need for LL2 frags indication

This is a legacy leftover; There's no current flow where 'frags_mapped' would be set. Signed-off-by: Yuval Mintz --- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 31 --- 1 file changed, 8 insertions(+), 23 deletions(-) diff --git

Re: [PATCH net-next] skbuff: only inherit relevant tx_flags

On Thu, 2017-06-08 at 11:35 -0400, Willem de Bruijn wrote: > From: Willem de Bruijn > > When inheriting tx_flags from one skbuff to another, always apply a > mask to avoid overwriting unrelated other bits in the field. > > The two SKBTX_SHARED_FRAG cases clears all other

[PATCH net-next 7/8] qed: Call rx_release_cb() when flushing LL2

Driver to inform the connection owner that the its buffers are being released as part of a flush. Signed-off-by: Yuval Mintz --- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git

[PATCH net-next 4/8] qed: LL2 code relocations

Instead of having the OOO logic packetd, divide it with rest of code according to establish/release flows. Signed-off-by: Yuval Mintz --- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 58 +++ 1 file changed, 28 insertions(+), 30 deletions(-)

[PATCH net-next 8/8] qed: collect GSI port statistics

The LL2 statistics already have place holders for these, but haven't populated them so far. Signed-off-by: Yuval Mintz --- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 23 +++ 1 file changed, 23 insertions(+) diff --git

[PATCH net-next 5/8] qed*: LL2 callback operations

From: Michal Kalderon LL2 today is interrupt driven - when tx/rx completion arrives [or any other indication], qed needs to operate on the connection and pass the information to the protocol-driver [or internal qed consumer]. Since we have several flavors of ll2

[PATCH net-next 0/8] qed*: Light L2 updates

This series does a major overhaul of the LL2 logic in qed. The single biggest change done here is in #5 where we're changing the API qed provides for LL2 [both internally in case of storage and externally in case of RoCE] to become callback-based to allow cleaner scalability in preperation to the

[PATCH net-next 1/8] qed: LL2 to use packed information for tx

First step in revising the LL2 interface, this declares qed_ll2_tx_pkt_info as part of the ll2 interface, and uses it for transmission instead of receiving lots of parameters. Signed-off-by: Yuval Mintz --- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 127

Re: [PATCH v2 7/8] net: mvmdio: add xmdio support

On Thu, Jun 08, 2017 at 11:26:52AM +0200, Antoine Tenart wrote: > +#define MVMDIO_XSMI_MGNT_REG 0x0 > +#define MVMDIO_XSMI_READ_VALID BIT(29) > +#define MVMDIO_XSMI_BUSYBIT(30) > +#define MVMDIO_XSMI_ADDR_REG 0x8 > +#define MVMDIO_XSMI_PHYADDR_SHIFT 16

Re: [PATCH 2/5] net: mvpp2: use {get,put}_cpu() instead of smp_processor_id()

On 08/06/17 16:27, Thomas Petazzoni wrote: > smp_processor_id() should not be used in migration-enabled contexts. We > originally thought it was OK in the specific situation of this driver, > but it was wrong, and calling smp_processor_id() in a migration-enabled > context prints a big fat warning

Re: [PATCH net-next] skbuff: only inherit relevant tx_flags

On Thu, Jun 8, 2017 at 11:35 AM, Willem de Bruijn wrote: > > From: Willem de Bruijn > > When inheriting tx_flags from one skbuff to another, always apply a > mask to avoid overwriting unrelated other bits in the field. > > The two

[PATCH] net: Fix build regression in rtl8723bs staging driver.

drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function ‘rtw_cfg80211_add_monitor_if’: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:2670:10: error: ‘struct net_device’ has no member named ‘destructor’ mon_ndev->destructor = rtw_ndev_destructor; ^ Signed-off-by: David S.

Re: [PATCH net v2 0/3] netvsc: bug fixes

From: Stephen Hemminger Date: Wed, 7 Jun 2017 15:53:46 -0700 > These are bugfixes for netvsc driver in 4.12. Looks good, series applied, thanks.

Re: [PATCH net-next v2 0/5] net: dsa: add cross-chip VLAN support

From: Vivien Didelot Date: Wed, 7 Jun 2017 18:12:12 -0400 > The current code in DSA does not support cross-chip VLAN. This means > that in a multi-chip environment such as this one (similar to ZII Rev B) ... > adding a VLAN to p9 won't be enough to reach

Re: [PATCH net-next 0/3] rxrpc: Tx length parameter

From: David Howells Date: Wed, 07 Jun 2017 22:12:32 +0100 > Here's a set of patches that allows someone initiating a client call with > AF_RXRPC to indicate upfront the total amount of data that will be > transmitted. This will allow AF_RXRPC to encrypt directly from source

Re: [RESEND PATCH 0/4] Missing QRTR features

From: Bjorn Andersson Date: Wed, 7 Jun 2017 14:07:35 -0700 > The QMUX specification covers packet routing as well as service life cycle and > discovery. The current implementation of qrtr supports the prior part, but in > order to fully implement service management

[PATCH net-next] skbuff: only inherit relevant tx_flags

From: Willem de Bruijn When inheriting tx_flags from one skbuff to another, always apply a mask to avoid overwriting unrelated other bits in the field. The two SKBTX_SHARED_FRAG cases clears all other bits. In practice, tx_flags are zero at this point now. But this is

Re: [PATCH] mISDN: remove unnecessary variable assignments

From: "Gustavo A. R. Silva" Date: Wed, 7 Jun 2017 15:15:01 -0500 > Remove unnecessary variable assignments. > > Addresses-Coverity-ID: 1226917 > Signed-off-by: Gustavo A. R. Silva Applied to net-next, thanks.

Re: [RFC PATCH net-next 5/5] selftests/bpf: change test_verifier expectations

On 08/06/17 03:43, Alexei Starovoitov wrote: > On Wed, Jun 07, 2017 at 04:00:02PM +0100, Edward Cree wrote: >> Some of the verifier's error messages have changed, and some constructs >> that previously couldn't be verified are now accepted. >> >> Signed-off-by: Edward Cree

[PATCH 5/5] net: mvpp2: remove mvpp2_pool_refill()

When all a function does is calling another function with the exact same arguments, in the exact same order, you know it's time to remove said function. Which is exactly what this commit does. Signed-off-by: Thomas Petazzoni ---

[PATCH 3/5] net: mvpp2: add comments about smp_processor_id() usage

A previous commit modified a number of smp_processor_id() used in migration-enabled contexts into get_cpu/put_cpu sections. However, a few smp_processor_id() calls remain in the driver, and this commit adds comments explaining why they can be kept. Signed-off-by: Thomas Petazzoni

[PATCH 4/5] net: mvpp2: remove unused mvpp2_bm_cookie_pool_set() function

This function is not used in the driver, remove it. Signed-off-by: Thomas Petazzoni --- drivers/net/ethernet/marvell/mvpp2.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/drivers/net/ethernet/marvell/mvpp2.c

[PATCH 0/5] net: mvpp2: fixes and cleanups

Hello, Here is a small set of fixes/improvements for the mvpp2 driver. The first two patches are fixes: they fix bogus usage of smp_processor_id() in a migration-enabled context. Indeed currently the driver outputs some fat warnings in CONFIG_DEBUG_PREEMPT-enabled kernels. Therefore, some fixes

[PATCH 2/5] net: mvpp2: use {get,put}_cpu() instead of smp_processor_id()

smp_processor_id() should not be used in migration-enabled contexts. We originally thought it was OK in the specific situation of this driver, but it was wrong, and calling smp_processor_id() in a migration-enabled context prints a big fat warning when CONFIG_DEBUG_PREEMPT=y. Therefore, this

[PATCH 1/5] net: mvpp2: remove mvpp2_bm_cookie_{build,pool_get}

This commit removes the useless remove mvpp2_bm_cookie_{build,pool_get} functions. All what mvpp2_bm_cookie_build() was doing is compute a 32-bit value by concatenating the pool number and the CPU number... only to get the pool number re-extracted by mvpp2_bm_cookie_pool_get() later on. Instead,

Re: [PATCH v2 net-next] tcp: add TCPMemoryPressuresChrono counter

From: Eric Dumazet Date: Wed, 07 Jun 2017 13:29:12 -0700 > From: Eric Dumazet > > DRAM supply shortage and poor memory pressure tracking in TCP > stack makes any change in SO_SNDBUF/SO_RCVBUF (or equivalent autotuning > limits) and tcp_mem[] quite

Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On 08/06/17 03:35, Alexei Starovoitov wrote: > such large back and forth move doesn't help reviewing. > may be just merge it into previous patch? > Or keep that function in the right place in patch 2 already? I think 'diff' got a bit confused, and maybe with different options I could have got it

Re: [RFC PATCH net-next 4/5] bpf/verifier: track signed and unsigned min/max values

On 08/06/17 03:40, Alexei Starovoitov wrote: > On Wed, Jun 07, 2017 at 03:59:25PM +0100, Edward Cree wrote: >> Allows us to, sometimes, combine information from a signed check of one >> bound and an unsigned check of the other. >> We now track the full range of possible values, rather than

Re: net/can: trying to register non-static key in can_rx_register

On Thu, Jun 8, 2017 at 5:20 PM, Marc Kleine-Budde wrote: > On 06/08/2017 05:16 PM, Andrey Konovalov wrote: >> Hi, >> >> I've got the following error report while fuzzing the kernel with syzkaller. >> >> On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+). >> >>

Re: net/can: trying to register non-static key in can_rx_register

On 06/08/2017 05:16 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+). > > INFO: trying to register non-static key. > the code is fine but needs lockdep

net/can: trying to register non-static key in can_rx_register

Hi, I've got the following error report while fuzzing the kernel with syzkaller. On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+). INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID:

Re: [PATCH net] net: ipv6: Release route when device is unregistering

From: David Ahern Date: Wed, 7 Jun 2017 12:26:23 -0600 > Roopa reported attempts to delete a bond device that is referenced in a > multipath route is hanging: > > $ ifdown bond2# ifupdown2 command that deletes virtual devices > unregister_netdevice: waiting for bond2 to

Re: [PATCH net] net: Zero ifla_vf_info in rtnl_fill_vfinfo()

From: Yuval Mintz Date: Wed, 7 Jun 2017 21:00:33 +0300 > Some of the structure's fields are not initialized by the > rtnetlink. If driver doesn't set those in ndo_get_vf_config(), > they'd leak memory to user. > > Signed-off-by: Yuval Mintz > CC:

Re: [PATCH] mwifiex: Replace semaphore async_sem with mutex

On Thu, Jun 8, 2017 at 12:03 PM, Binoy Jayan wrote: > The semaphore 'async_sem' is used as a simple mutex, so > it should be written as one. Semaphores are going away in the future. > > Signed-off-by: Binoy Jayan > --- > > This patch is part of a

Re: [RFC PATCH net-next 2/5] bpf/verifier: rework value tracking

On 08/06/17 03:32, Alexei Starovoitov wrote: > On Wed, Jun 07, 2017 at 03:58:31PM +0100, Edward Cree wrote: >> +/* Arithmetic and logical ops */ >> +/* Shift a tnum left (by a fixed shift) */ >> +struct tnum tn_sl(struct tnum a, u8 shift); >> +/* Shift a tnum right (by a fixed shift) */ >> +struct

Re: [PATCH net-next 0/4] tcp: Namespaceify 3 sysctls

From: Eric Dumazet Date: Wed, 7 Jun 2017 10:34:35 -0700 > Move tcp_sack, tcp_window_scaling and tcp_timestamps > sysctls to network namespaces. > > Eric Dumazet (4): > tcp: add a struct net parameter to tcp_parse_options() > tcp: Namespaceify sysctl_tcp_sack > tcp:

Re: next-20170608 build: 1 failures 4 warnings (next-20170608)

Hi, On Thu, Jun 08, 2017 at 10:17:57AM -0400, David Miller wrote: > > On Thu, Jun 08, 2017 at 11:32:31AM +0100, Mark Brown wrote: > >> On Thu, Jun 08, 2017 at 10:57:50AM +0100, Build bot for Mark Brown wrote: > >> > >> Today's -next fails to build an ARM allmodconfig due to: > >> > >> >

Re: [PATCH v2 2/2] net: emac: fix and unify emac_mdio functions

From: Christian Lamparter Date: Wed, 7 Jun 2017 15:51:16 +0200 > emac_mdio_read_link() was not copying the requested phy settings > back into the emac driver's own phy api. This has caused a link > speed mismatch issue for the AR8035 as the emac driver kept > trying to

Re: [PATCH v2 1/2] net: emac: fix reset timeout with AR8035 phy

From: Christian Lamparter Date: Wed, 7 Jun 2017 15:51:15 +0200 > This patch fixes a problem where the AR8035 PHY can't be > detected on an Cisco Meraki MR24, if the ethernet cable is > not connected on boot. ... > Cc: Chris Blake >

Re: [PATCH 25/44] arm: implement ->mapping_error

BOn Thu, Jun 08, 2017 at 03:25:50PM +0200, Christoph Hellwig wrote: > +static int dmabounce_mapping_error(struct device *dev, dma_addr_t dma_addr) > +{ > + if (dev->archdata.dmabounce) > + return 0; I'm not convinced that we need this check here: dev->archdata.dmabounce =

Re: [PATCH v2] decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb

From: Mateusz Jurczyk Date: Wed, 7 Jun 2017 16:41:57 +0200 > On Wed, Jun 7, 2017 at 4:18 PM, Florian Westphal wrote: >> Mateusz Jurczyk wrote: >>> Verify that the length of the socket buffer is sufficient to cover the >>> nlmsghdr

Re: [PATCH 20/44] sparc: implement ->mapping_error

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:45 +0200 > DMA_ERROR_CODE is going to go away, so don't rely on it. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller

Re: [PATCH 28/44] sparc: remove arch specific dma_supported implementations

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:53 +0200 > Usually dma_supported decisions are done by the dma_map_ops instance. > Switch sparc to that model by providing a ->dma_supported instance for > sbus that always returns false, and implementations tailored to the sun4u

Re: [PATCH] net/ethtool: Replace memset with compiler directive

From: Yuval Shaia Date: Thu, 8 Jun 2017 16:32:21 +0300 > Take advantage of compiler variable zero-ing and remove calls to memset. > > Signed-off-by: Yuval Shaia That construct looks so ugly, also the memset()'s in some cases are constrained to

Re: [PATCH 28/44] sparc: remove arch specific dma_supported implementations

Hi Christoph, On Thu, Jun 8, 2017 at 11:25 PM, Christoph Hellwig wrote: > Usually dma_supported decisions are done by the dma_map_ops instance. > Switch sparc to that model by providing a ->dma_supported instance for > sbus that always returns false, and implementations tailored to

Re: [PATCH 27/44] sparc: remove leon_dma_ops

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:52 +0200 > We can just use pci32_dma_ops. > > Btw, given that leon is 32-bit and appears to be PCI based, do even need > the special case for it in get_arch_dma_ops at all? I would need to defer to the LEON developers on that,

Re: [PATCH 02/44] ibmveth: properly unwind on init errors

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:27 +0200 > That way the driver doesn't have to rely on DMA_ERROR_CODE, which > is not a public API and going away. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller

Re: clean up and modularize arch dma_mapping interface

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:25 +0200 > for a while we have a generic implementation of the dma mapping routines > that call into per-arch or per-device operations. But right now there > still are various bits in the interfaces where don't clearly operate >

Re: merge net into net-next?

From: Johannes Berg Date: Thu, 08 Jun 2017 14:14:15 +0200 > On Thu, 2017-06-08 at 14:10 +0200, Johannes Berg wrote: >> Hi Dave, >> >> Could you do me a favour and merge net into net-next? I want to merge >> that back in order to apply a patch to mac80211-next that

Re: merge net into net-next?

From: Johannes Berg Date: Thu, 08 Jun 2017 14:10:55 +0200 > Could you do me a favour and merge net into net-next? I want to > merge that back in order to apply a patch to mac80211-next that > otherwise conflicts fairly badly with a change in mac80211. I'll try to do

Re: next-20170608 build: 1 failures 4 warnings (next-20170608)

From: Sebastian Reichel Date: Thu, 8 Jun 2017 13:33:26 +0200 > Hi, > > On Thu, Jun 08, 2017 at 11:32:31AM +0100, Mark Brown wrote: >> On Thu, Jun 08, 2017 at 10:57:50AM +0100, Build bot for Mark Brown wrote: >> >> Today's -next fails to build an ARM allmodconfig due to: >> >>

Re: next-20170608 build: 1 failures 4 warnings (next-20170608)

From: Stephen Rothwell <s...@canb.auug.org.au> Date: Thu, 8 Jun 2017 20:27:04 +1000 > Hi Dave, > > On Thu, 08 Jun 2017 10:57:50 +0100 Build bot for Mark Brown > <broo...@kernel.org> wrote: >> >> Tree/Branch: next-20170608 >> Git describe: next-201

Re: kisskb: FAILED linux-next/s390-defconfig/s390x Thu Jun 08, 18:28

From: Stephen Rothwell Date: Thu, 8 Jun 2017 19:11:43 +1000 > From: Stephen Rothwell > Date: Thu, 8 Jun 2017 19:06:29 +1000 > Subject: [PATCH] net: s390: fix up for "Fix inconsistent teardown and release > of private netdev state" > >

Re: [PATCH 16/44] arm64: remove DMA_ERROR_CODE

On 08/06/17 14:25, Christoph Hellwig wrote: > The dma alloc interface returns an error by return NULL, and the > mapping interfaces rely on the mapping_error method, which the dummy > ops already implement correctly. > > Thus remove the DMA_ERROR_CODE define. Reviewed-by: Robin Murphy

Re: [PATCH v3 2/2] ip6_tunnel: fix potential issue in __ip6_tnl_rcv

From: 严海双 Date: Thu, 8 Jun 2017 15:33:58 +0800 >> On 8 Jun 2017, at 1:00 PM, Alexei Starovoitov >> wrote: >> >> On Thu, Jun 08, 2017 at 12:56:58PM +0800, 严海双 wrote: >>> On 8 Jun 2017, at 12:38 PM, Alexei Starovoitov

Re: [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

Hi Christoph, On 08/06/17 14:25, Christoph Hellwig wrote: > DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu > driver already implements a proper ->mapping_error method, so it's only > using the value internally. Add a new local define using the value > that arm64 which

<    1   2   3   4   >