RE: [PATCH v2] net: stmmac: bug fix to synchronize stmmac_open and stmmac_dvr_probe

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, December 28, 2016 12:34 AM > To: Kweh, Hock Leong > Cc: joao.pi...@synopsys.com; peppe.cavall...@st.com; > seraphin.bonna...@st.com; f.faine...@gmail.com; >

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hello, On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote: > Hannes Frederic Sowa wrote: > > On 24.12.2016 00:39, George Spelvin wrote: > > > We just finished discussing why 8 bytes isn't enough. If you only > > > feed back 8 bytes, an attacker who can do 2^64 computation can find it > > >

Re: [PATCH 01/12] Make and configuration files.

On 12/27/2016 08:47 PM, Rami Rosen wrote: Hi, David, For the Makefile, you should follow the pattern which is common in Linux Kernel Ethernet drivers, for example, http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/i40e/Makefile or

Re: [PATCH 05/12] Support for NIC-specific code

Hi, David, Several nitpicks and comments, from a brief overview: The commented label //err_exit: should be removed > +++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c > @@ -0,0 +1,993 @@ > +//err_exit: > +//err_exit: Shouldn't aq_nic_rss_init() be static? isn't it called only from

Re: [PATCH 01/12] Make and configuration files.

Hi, David, For the Makefile, you should follow the pattern which is common in Linux Kernel Ethernet drivers, for example, http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/i40e/Makefile or http://lxr.free-electrons.com/source/drivers/net/ethernet/mellanox/mlx5/core/Makefile Don't

net-next is OPEN

I know you are all chomping at the bit to bomb me with net-next changes. :-)

Re: [PATCH] net: handle no dst on skb in icmp6_send

From: Hannes Frederic Sowa Date: Thu, 08 Dec 2016 15:04:17 +0100 > Hello David, > > On Mon, Nov 28, 2016, at 22:13, David Miller wrote: >> From: David Ahern >> Date: Sun, 27 Nov 2016 18:52:53 -0800 >> >> > Andrey reported the following

Re: [PATCH net] net: stmmac: Fix race between stmmac_drv_probe and stmmac_open

From: Florian Fainelli Date: Tue, 27 Dec 2016 18:23:06 -0800 > There is currently a small window during which the network device registered > by > stmmac can be made visible, yet all resources, including and clock and MDIO > bus > have not had a chance to be set up, this

[PATCH net] net: stmmac: Fix race between stmmac_drv_probe and stmmac_open

There is currently a small window during which the network device registered by stmmac can be made visible, yet all resources, including and clock and MDIO bus have not had a chance to be set up, this can lead to the following error to occur: [ 473.919358] stmmaceth :01:00.0 (unnamed

RE: [PATCH v2] net: stmmac: bug fix to synchronize stmmac_open and stmmac_dvr_probe

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, December 28, 2016 12:34 AM > To: Kweh, Hock Leong > Cc: joao.pi...@synopsys.com; peppe.cavall...@st.com; > seraphin.bonna...@st.com; f.faine...@gmail.com; >

sunrpc: Illegal context switch in RCU read-side critical section!

Just noticed this on 4.9. Will try and repro on 4.10rc1 later, but hitting unrelated boot problems on that machine right now. === [ INFO: suspicious RCU usage. ] 4.9.0-backup-debug+ #1 Not tainted --- ./include/linux/rcupdate.h:557 Illegal

Re: [PATCH] fddi: skfp: Use more common logging styles

Applied.

Re: [PATCH] skfp: hwmtm: Use proper logging macros, correct mismatches

From: Joe Perches Date: Wed, 21 Dec 2016 16:41:52 -0800 > Logging macros should allow format and argument validation. > The DB_TX, DB_RX, and DB_GEN macros did not. > > Update the macros and uses and add no_printk validation to the > previously compiled away #ifndef DEBUG

Re: [PATCH] net: Use kmemdup instead of kmalloc and memcpy

From: Shyam Saini Date: Sat, 24 Dec 2016 00:44:58 +0530 > when some other buffer is immediately copied into allocated region. > Replace calls to kmalloc followed by a memcpy with a direct > call to kmemdup. > > Signed-off-by: Shyam Saini

RE: [RFC PATCH] i40e: enable PCIe relax ordering for SPARC

> -Original Message- > From: tndave [mailto:tushar.n.d...@oracle.com] > Sent: Wednesday, December 28, 2016 6:28 AM > To: maowenan; jeffrey.t.kirs...@intel.com; intel-wired-...@lists.osuosl.org > Cc: netdev@vger.kernel.org; weiyongjun (A); Dingtianhong > Subject: Re: [RFC PATCH] i40e:

RE: [Intel-wired-lan] [RFC PATCH] i40e: enable PCIe relax ordering for SPARC

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Alexander Duyck > Sent: Tuesday, December 06, 2016 5:55 AM > To: Tushar Dave > Cc: Jeff Kirsher; intel-wired-lan; Netdev > Subject: Re: [Intel-wired-lan] [RFC PATCH] i40e:

Re: driver r8169 suddenly failed

Robert Grasso : [...] > So, what is your opinion : > - should I broaden my request for help to other teams than yours (kernel > maintainers) ? If I had to untangle this mess, I would check that my router is not configured with an empty dhcp range. Then I would put

Re: [RFC PATCH] i40e: enable PCIe relax ordering for SPARC

On 12/26/2016 03:39 AM, maowenan wrote: -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Tushar Dave Sent: Tuesday, December 06, 2016 1:07 AM To: jeffrey.t.kirs...@intel.com; intel-wired-...@lists.osuosl.org Cc:

Re: [PATCH] staging: octeon: Call SET_NETDEV_DEV()

On 12/20/2016 07:20 PM, David Miller wrote: > From: Florian Fainelli > Date: Tue, 20 Dec 2016 17:02:37 -0800 > >> On 12/14/2016 05:13 PM, Florian Fainelli wrote: >>> The Octeon driver calls into PHYLIB which now checks for >>> net_device->dev.parent, so make sure we do set

Re: [PATCH v3 2/2] drivers: net: ethernet: 3com: fix return value

On Sun, 2016-12-25 at 01:30 +0100, Thomas Preisner wrote: > In some cases the return value of a failing function is not being used > and the function typhoon_init_one() returns another negative error > code instead. I'm not sure these changes are especially valuable, since we'll need to look at

Re: Re: [PATCH v2 1/2] drivers: net: ethernet: 3com: fix return value

On Sun, 2016-12-25 at 01:30 +0100, Thomas Preisner wrote: > Those spaces were actually left out purposely: The file in question > (typhoon.c) > is missing those spaces between the statements (if, for, while) and the > following opening bracket pretty much always (except 2-3 times) and we figured

[GIT] Networking

1) Various ipvlan fixes from Eric Dumazet and Mahesh Bandewar. The most important is to not assume the packet is RX just because the destination address matches that of the device. Such an assumption causes problems when an interface is put into loopback mode. 2) If we retry when

Re: driver r8169 suddenly failed

Hello, I have some unexpected (and interesting) news. I did not run the test yet. While I was investigating my issue, I ordered a fast Ethernet-to-USB3 converter, able to reach 1000Mbit/s, in order to recover my broadband quickly : here is the chip as reported by dmesg : [8.114327]

Re: [PATCH] net: fix incorrect original ingress device index in PKTINFO

From: Wei Zhang Date: Tue, 27 Dec 2016 17:52:24 +0800 > When we send a packet for our own local address on a non-loopback > interface (e.g. eth0), due to the change had been introduced from > commit 0b922b7a829c ("net: original ingress device index in PKTINFO"), the > original

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On Tue, Dec 27, 2016 at 6:16 AM, Daniel Borkmann wrote: > On 12/27/2016 10:58 AM, Herbert Xu wrote: >> >> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: >>> >>> >>> According to Daniel, the networking folks want to let embedded systems >>> include BPF

Re: [net/mm PATCH v2 0/3] Page fragment updates

From: Alexander Duyck Date: Tue, 27 Dec 2016 10:54:14 -0800 > Dave, I was wondering if you would be okay with me trying to push the > three patches though net-next. I'm thinking I might scale back the > first patch so that it is just a rename instead of making any >

[PATCH 2/2] ath9k: ar9003_mac: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some new features (e.g.

Re: [net/mm PATCH v2 0/3] Page fragment updates

On Fri, Dec 23, 2016 at 9:50 AM, David Miller wrote: > From: Alexander Duyck > Date: Fri, 23 Dec 2016 09:16:39 -0800 > >> I tried to get in touch with Andrew about this fix but I haven't heard any >> reply to the email I sent out on Tuesday. The

[PATCH 1/2] ath9k: ar9002_mac: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some new features (e.g.

[PATCH 0/2] ath9k: kill of ACCESS_ONCE() in MAC drivers

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be

Re: [Intel-wired-lan] [RFC PATCH] i40e: enable PCIe relax ordering for SPARC

On Mon, Dec 26, 2016 at 3:39 AM, maowenan wrote: > > >> -Original Message- >> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] >> On Behalf Of Tushar Dave >> Sent: Tuesday, December 06, 2016 1:07 AM >> To: jeffrey.t.kirs...@intel.com;

Re: [PATCH] net: dev_weight: TX/RX orthogonality

On 12/27/2016 05:47 PM, Marcelo Ricardo Leitner wrote: > On Tue, Dec 27, 2016 at 09:25:47AM +0100, Matthias Tafelmeier wrote: >> Oftenly, introducing side effects on packet processing on the other half >> of the stack by adjusting one of TX/RX via sysctl is not desirable. >> There are cases of

Re: [PATCH] net: stmmac: fix incorrect bit set in gmac4 mdio addr register

From: "Kweh, Hock Leong" Date: Wed, 28 Dec 2016 04:07:41 +0800 > From: "Kweh, Hock Leong" > > Fixing the gmac4 mdio write access to use MII_GMAC4_WRITE only instead of > OR together with MII_WRITE. > > Signed-off-by: Kweh, Hock

Re: [PATCH net] net: xdp: remove unused bfp_warn_invalid_xdp_buffer()

From: Jason Wang Date: Tue, 27 Dec 2016 10:49:54 +0800 > After commit 73b62bd085f4737679ea9afc7867fa5f99ba7d1b ("virtio-net: > remove the warning before XDP linearizing"), there's no users for > bpf_warn_invalid_xdp_buffer(), so remove it. This is a revert for > commit

Re: [PATCH net-next] r8169: add support for RTL8168 series add-on card.

From: Chun-Hao Lin Date: Tue, 27 Dec 2016 16:29:43 +0800 > This chip is the same as RTL8168, but its device id is 0x8161. > > Signed-off-by: Chun-Hao Lin Applied.

Re: [PATCH v2] ipv4: Namespaceify tcp_tw_reuse knob

From: Haishuang Yan Date: Sun, 25 Dec 2016 14:33:16 +0800 > Different namespaces might have different requirements to reuse > TIME-WAIT sockets for new connections. This might be required in > cases where different namespace applications are in place which >

Re: [PATCH net] openvswitch: upcall: Fix vlan handling.

From: Pravin B Shelar Date: Mon, 26 Dec 2016 08:31:27 -0800 > Networking stack accelerate vlan tag handling by > keeping topmost vlan header in skb. This works as > long as packet remains in OVS datapath. But during > OVS upcall vlan header is pushed on to the packet. > When

Re: [PATCH net-next 0/5] SCTP cleanups

From: Marcelo Ricardo Leitner Date: Tue, 27 Dec 2016 15:08:27 -0200 > Some cleanups/simplifications I've been collecting. Please resubmit these when I open the net-next tree back up. Thank you.

[PATCH net-next 4/5] sctp: remove return value from sctp_packet_init/config

There is no reason to use this cascading. It doesn't add anything. Let's remove it and simplify. Signed-off-by: Marcelo Ricardo Leitner --- include/net/sctp/structs.h | 7 +++ net/sctp/output.c | 14 +- net/sctp/sm_statefuns.c| 5 +++--

[PATCH net-next 5/5] sctp: sctp_chunk_length_valid should return bool

Signed-off-by: Marcelo Ricardo Leitner --- net/sctp/sm_statefuns.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c index

[PATCH net-next 3/5] sctp: simplify addr copy

Make it a bit easier to read. Signed-off-by: Marcelo Ricardo Leitner --- net/sctp/ipv6.c | 16 +++- net/sctp/protocol.c | 18 +++--- 2 files changed, 14 insertions(+), 20 deletions(-) diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c index

[PATCH net-next 0/5] SCTP cleanups

Some cleanups/simplifications I've been collecting. Marcelo Ricardo Leitner (5): sctp: reduce indent level at sctp_sf_tabort_8_4_8 sctp: reduce indent level in sctp_sf_shut_8_4_5 sctp: simplify addr copy sctp: remove return value from sctp_packet_init/config sctp:

[PATCH net-next 1/5] sctp: reduce indent level at sctp_sf_tabort_8_4_8

Signed-off-by: Marcelo Ricardo Leitner --- net/sctp/sm_statefuns.c | 44 +--- 1 file changed, 21 insertions(+), 23 deletions(-) diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c index

[PATCH net-next 2/5] sctp: reduce indent level in sctp_sf_shut_8_4_5

Signed-off-by: Marcelo Ricardo Leitner --- net/sctp/sm_statefuns.c | 58 - 1 file changed, 28 insertions(+), 30 deletions(-) diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c index

[PATCH v2 06/16] net: mvpp2: adjust the allocation/free of BM pools for PPv2.2

This commit adjusts the allocation and freeing of BM pools to support PPv2.2. This involves: - Checking that the number of buffer pointers is a multiple of 16, as required by the hardware. - Adjusting the size of the DMA coherent area allocated for buffer pointers. Indeed, PPv2.2 needs

Re: [PATCH v2 00/11] net: mvpp2: misc improvements and preparation patches

net-next is still closed, please do not submit cleanups and new features

[PATCH v2 08/16] net: mvpp2: adapt mvpp2_defaults_set() to PPv2.2

This commit modifies the mvpp2_defaults_set() function to not do the loopback and FIFO threshold initialization, which are not needed for PPv2.2. Signed-off-by: Thomas Petazzoni --- drivers/net/ethernet/marvell/mvpp2.c | 22 -- 1 file

[PATCH v2 14/16] net: mvpp2: adapt rxq distribution to PPv2.2

In PPv2.1, we have a maximum of 8 RXQs per port, with a default of 4 RXQs per port, and we were assigning RXQs 0->3 to the first port, 4->7 to the second port, 8->11 to the third port, etc. In PPv2.2, we have a maximum of 32 RXQs per port, and we must allocate RXQs from the range of 32 RXQs

[PATCH v2 10/16] net: mvpp2: handle register mapping and access for PPv2.2

This commit adjusts the mvpp2 driver register mapping and access logic to support PPv2.2, to handle a number of differences. Due to how the registers are laid out in memory, the Device Tree binding for the "reg" property is different: - On PPv2.1, we had a first area for the common registers,

[PATCH v2 02/16] net: mvpp2: add and use accessors for TX/RX descriptors

The PPv2.2 IP has a different TX and RX descriptor layout compared to PPv2.1. In order to prepare for the introduction of PPv2.2 support in mvpp2, this commit adds accessors for the different fields of the TX and RX descriptors, and changes the code to use them. For now, the mvpp2_port argument

[PATCH v2 09/16] net: mvpp2: adjust mvpp2_{rxq,txq}_init for PPv2.2

In PPv2.2, the MVPP2_RXQ_DESC_ADDR_REG and MVPP2_TXQ_DESC_ADDR_REG registers have a slightly different layout, because they need to contain a 64-bit address for the RX and TX descriptor arrays. This commit adjusts those functions accordingly. Signed-off-by: Thomas Petazzoni

[PATCH v2 13/16] net: mvpp2: rework RXQ interrupt group initialization for PPv2.2

This commit adjusts how the MVPP2_ISR_RXQ_GROUP_REG register is configured, since it changed between PPv2.1 and PPv2.2. Signed-off-by: Thomas Petazzoni --- drivers/net/ethernet/marvell/mvpp2.c | 45 1 file changed, 41

[PATCH v2 05/16] net: mvpp2: introduce PPv2.2 HW descriptors and adapt accessors

This commit adds the definition of the PPv2.2 HW descriptors, adjusts the mvpp2_tx_desc and mvpp2_rx_desc structures accordingly, and adapts the accessors to work on both PPv2.1 and PPv2.2. Signed-off-by: Thomas Petazzoni ---

[PATCH v2 01/16] dt-bindings: net: update Marvell PPv2 binding for PPv2.2 support

The Marvell PPv2 Device Tree binding was so far only used to describe the PPv2.1 network controller, used in the Marvell Armada 375. A new version of this IP block, PPv2.2 is used in the Marvell Armada 7K/8K processor. This commit extends the existing binding so that it can also be used to

[PATCH v2 16/16] net: mvpp2: finally add the PPv2.2 compatible string

Now that the mvpp2 driver has been modified to accommodate the support for PPv2.2, we can finally advertise this support by adding the appropriate compatible string. At the same time, we update the Kconfig description of the MVPP2 driver. Signed-off-by: Thomas Petazzoni

[PATCH v2 07/16] net: mvpp2: adapt the mvpp2_rxq_*_pool_set functions to PPv2.2

The MVPP2_RXQ_CONFIG_REG register has a slightly different layout between PPv2.1 and PPv2.2, so this commit adapts the functions modifying this register to accommodate for both the PPv2.1 and PPv2.2 cases. Signed-off-by: Thomas Petazzoni ---

[PATCH v2 15/16] net: mvpp2: add support for an additional clock needed for PPv2.2

The PPv2.2 variant of the network controller needs an additional clock, the "MG clock" in order for the IP block to operate properly. This commit adds support for this additional clock to the driver, reworking as needed the error handling path. Signed-off-by: Thomas Petazzoni

[PATCH v2 06/11] net: mvpp2: simplify mvpp2_bm_bufs_add()

The mvpp2_bm_bufs_add() currently creates a fake cookie by calling mvpp2_bm_cookie_pool_set(), just to be able to call mvpp2_pool_refill(). But all what mvpp2_pool_refill() does is extract the pool ID from the cookie, and call mvpp2_bm_pool_put() with this ID. Instead of doing this convoluted

[PATCH v2 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences

This commit handles a few miscellaneous differences between PPv2.1 and PPv2.2 in different areas, where code done for PPv2.1 doesn't apply for PPv2.2 or needs to be adjusted (getting the MAC address, disabling PHY polling, etc.). Signed-off-by: Thomas Petazzoni

[PATCH v2 05/11] net: mvpp2: drop useless fields in mvpp2_bm_pool and related code

This commit drops dead code from the mvpp2 driver. The 'in_use' and 'in_use_thresh' fields of 'struct mvpp2_bm_pool' are incremented/decremented/initialized in various places. But they are only used in one place: if (is_recycle && (atomic_read(_pool->in_use) <

[PATCH v2 10/11] net: mvpp2: switch to build_skb() in the RX path

This commit adapts the mvpp2 RX path to use the build_skb() method. Not only build_skb() is now the recommended mechanism, but it also simplifies the addition of support for the PPv2.2 variant. Indeed, without build_skb(), we have to keep track for each RX descriptor of the physical address of

[PATCH v2 02/11] net: mvpp2: handle too large value in mvpp2_rx_time_coal_set()

When configuring the MVPP2_ISR_RX_THRESHOLD_REG with the RX coalescing time threshold, we do not check for the maximum allowed value supported by the driver, which means we might overflow and use a bogus value. This commit adds a check for this situation, and if a value higher than what is

[PATCH v2 03/16] net: mvpp2: add hw_version field in "struct mvpp2"

In preparation to the introduction for the support of PPv2.2 in the mvpp2 driver, this commit adds a hw_version field to the struct mvpp2, and uses the .data field of the DT match table to fill it in. Having the MVPP21 and MVPP22 definitions available will allow to start adding the necessary

[PATCH v2 00/16] net: mvpp2: add basic support for PPv2.2

Hello, The goal of this patch series is to add basic support for PPv2.2 in the existing mvpp2 driver. mvpp2 currently supported the PPv2.1 version of the IP, used in the 32 bits Marvell Armada 375 SoC. PPv2.2 is an evolution of this IP block, used in the 64 bits Marvell Armada 7K/8K SoCs. In

[PATCH v2 11/11] net: mvpp2: enable building on 64-bit platforms

The mvpp2 is going to be extended to support the Marvell Armada 7K/8K platform, which is ARM64. As a preparation to this work, this commit enables building the mvpp2 driver on ARM64, by: - Adjusting the Kconfig dependency - Fixing the types used in the driver so that they are 32/64-bits

[PATCH v2 01/11] net: mvpp2: handle too large value handling in mvpp2_rx_pkts_coal_set()

Currently, mvpp2_rx_pkts_coal_set() does the following to avoid setting a too large value for the RX coalescing by packet number: val = (pkts & MVPP2_OCCUPIED_THRESH_MASK); This means that if you set a value that is slightly higher the the maximum number of packets, you in fact get a very low

[PATCH v2 12/16] net: mvpp2: add AXI bridge initialization for PPv2.2

The PPv2.2 unit is connected to an AXI bus on Armada 7K/8K, so this commit adds the necessary initialization of the AXI bridge. Signed-off-by: Thomas Petazzoni --- drivers/net/ethernet/marvell/mvpp2.c | 85 1 file

[PATCH v2 09/11] net: mvpp2: simplify MVPP2_PRS_RI_* definitions

Some of the MVPP2_PRS_RI_* definitions use the ~(value) syntax, which doesn't compile nicely on 64-bit. Moreover, those definitions are in fact unneeded, since they are always used in combination with a bit mask that ensures only the appropriate bits are modified. Therefore, such definitions

[PATCH v2 04/16] net: mvpp2: introduce an intermediate union for the TX/RX descriptors

Since the format of the HW descriptors is different between PPv2.1 and PPv2.2, this commit introduces an intermediate union, with for now only the PPv2.1 descriptors. The bulk of the driver code only manipulates opaque mvpp2_tx_desc and mvpp2_rx_desc pointers, and the descriptors can only be

[PATCH v2 03/11] net: mvpp2: release reference to txq_cpu[] entry after unmapping

The mvpp2_txq_bufs_free() function is called upon TX completion to DMA unmap TX buffers, and free the corresponding SKBs. It gets the references to the SKB to free and the DMA buffer to unmap from a per-CPU txq_pcpu data structure. However, the code currently increments the pointer to the next

[PATCH v2 00/11] net: mvpp2: misc improvements and preparation patches

Hello, This series contains a number of misc improvements and preparation patches for an upcoming series that adds support for the new PPv2.2 network controller to the mvpp2 driver. The most significant improvements are: - Switching to using build_skb(), which is necessary for the upcoming

[PATCH v2 08/11] net: mvpp2: fix indentation of MVPP2_EXT_GLOBAL_CTRL_DEFAULT

Signed-off-by: Thomas Petazzoni --- drivers/net/ethernet/marvell/mvpp2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c index edffcc1..36c73dc 100644 ---

[PATCH v2 07/11] net: mvpp2: remove unused register definitions

Signed-off-by: Thomas Petazzoni --- drivers/net/ethernet/marvell/mvpp2.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c index 8174f40..edffcc1 100644 ---

[PATCH v2 04/11] net: mvpp2: remove unused 'tx_skb' field of 'struct mvpp2_tx_queue'

This commit remove a field of 'struct mvpp2_tx_queue' that is not used anywhere. Signed-off-by: Thomas Petazzoni --- drivers/net/ethernet/marvell/mvpp2.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/ethernet/marvell/mvpp2.c

Re: [PATCH] net: dev_weight: TX/RX orthogonality

On Tue, Dec 27, 2016 at 09:25:47AM +0100, Matthias Tafelmeier wrote: > Oftenly, introducing side effects on packet processing on the other half > of the stack by adjusting one of TX/RX via sysctl is not desirable. > There are cases of demand for asymmetric, orthogonal configurability. > > This

Re: [PATCH v2] net: stmmac: bug fix to synchronize stmmac_open and stmmac_dvr_probe

From: "Kweh, Hock Leong" Date: Tue, 27 Dec 2016 22:42:36 +0800 > From: "Kweh, Hock Leong" You are not the author of this change, do not take credit for it. You have copied Florian's patch character by character, therefore he is the

Patch

Hello David, A few days ago you told me to resend a patch (https://lkml.org/lkml/2016/12/20/416) when the next-net git tree opened. Is this a good time to resend? Thanks, Joao

Patch

Hello David, A few days ago you told me to resend a patch (https://lkml.org/lkml/2016/12/20/416) when the next-net git tree opened. Is this a good time to resend? Thanks, Joao

Re: [PATCH 01/12] Make and configuration files.

On Tue, 2016-12-27 at 05:17 -0800, David VomLehn wrote: > Patches to create the make and configuration files. A few small things about this patch series that adds a new driver: These should be sent with a cover letter [0/N] so that the reason this series is useful can be added to the merge log.

Hi Dear !

Hi Dear ! How are you doing today,hope fine, My name is Lina and i am a girl. I saw your profile today and decided to extend my greetings to you. But I do have the mind that you could be a nice person is my believe and there are nice people out there who can appreciate the value of

Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

Mark - I will split this off soon. In the meantime - here is some more info about how we use it. We do use NFC structures.I did find an interesting clue in that there are certain bottles that cause neard to segfault, I'm not sure what is different about them. We write a string, like

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On 12/27/2016 10:58 AM, Herbert Xu wrote: On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: According to Daniel, the networking folks want to let embedded systems include BPF without requiring the crypto core. Last I checked the IPv4 stack depended on the crypto API so this

[PATCH 04/12] Low-level hardware interfaces

Add definitions of functions that interface directly with the hardware. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn ---

[PATCH 06/12] Atlantic A0 specific functions.

Add Atlantic A0-specific functions. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn --- .../ethernet/aquantia/atlantic/hw_atl/hw_atl_a0.c | 934

[PATCH 02/12] Common functions and definitions

Add files containing the functions and definitions used in common in different functional areas. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn ---

[PATCH 05/12] Support for NIC-specific code

Add support for code specific to the Atlantic NIC. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn --- drivers/net/ethernet/aquantia/atlantic/aq_nic.c|

[PATCH 09/12] Atlantic hardware abstraction layer

Add common functions for Atlantic hardware abstraction layer. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn ---

[PATCH 01/12] Make and configuration files.

Patches to create the make and configuration files. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn --- drivers/net/ethernet/aquantia/atlantic/Kconfig | 9

[PATCH 11/12] Ethtool support

Add the driver interfaces required for support by the ethtool utility. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn ---

[PATCH 08/12] PCI operations

Add functions that handle the PCI bus interface. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn --- .../net/ethernet/aquantia/atlantic/aq_pci_func.c |

[PATCH 01/12] Make and configuration files.

Patches to create the make and configuration files. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn --- drivers/net/ethernet/aquantia/atlantic/Kconfig | 9

[PATCH 03/12] Add ring spport code

Add code to support the firmware transmit and receive ring buffers. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn ---

[PATCH 10/12] Hardware interface and utility functions

Add functions to interface with the hardware and some utility functions. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn ---

[PATCH 12/12] Receive side scaling

Add definitions that support receive side scaling. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn --- drivers/net/ethernet/aquantia/atlantic/aq_rss.h | 35

[PATCH 07/12] Vector operations

Add functions to manululate the vector of receive and transmit rings. Signed-off-by: Dmitrii Tarakanov Signed-off-by: Alexander Loktionov Signed-off-by: David M. VomLehn ---

Re: [PATCH] net: stmmac: fix incorrect bit set in gmac4 mdio addr register

Às 8:07 PM de 12/27/2016, Kweh, Hock Leong escreveu: > From: "Kweh, Hock Leong" > > Fixing the gmac4 mdio write access to use MII_GMAC4_WRITE only instead of > OR together with MII_WRITE. > > Signed-off-by: Kweh, Hock Leong > --- >

[PATCH] net: stmmac: fix incorrect bit set in gmac4 mdio addr register

From: "Kweh, Hock Leong" Fixing the gmac4 mdio write access to use MII_GMAC4_WRITE only instead of OR together with MII_WRITE. Signed-off-by: Kweh, Hock Leong --- drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |4 +++- 1 file

Platform init code in stmmac_main

Hello, I spotted in stmmac_main.c, *_dvr_probe() function, some clocks initializations that are related with platform based setups: priv->pclk = devm_clk_get(priv->device, "pclk"); if (IS_ERR(priv->pclk)) { if (PTR_ERR(priv->pclk) == -EPROBE_DEFER) {

Re: [PATCH v2] net: stmmac: bug fix to synchronize stmmac_open and stmmac_dvr_probe

On Tue 2016-12-27 22:42:36, Kweh, Hock Leong wrote: > From: "Kweh, Hock Leong" > > If kernel module stmmac driver being loaded after OS booted, there is a > race condition between stmmac_open() and stmmac_mdio_register(), which is > invoked inside stmmac_dvr_probe(),

Re: [PATCH] net: fix incorrect original ingress device index in PKTINFO

Hello! On 12/27/2016 10:52 AM, Wei Zhang wrote: When we send a packet for our own local address on a non-loopback interface (e.g. eth0), due to the change had been introduced from commit 0b922b7a829c ("net: original ingress device index in PKTINFO"), the original ingress device index would be

  1   2   >