Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

Hi Florian, Thank for taking your time on reviewing. Add comment as inline. On Wed, 2017-03-22 at 11:39 -0700, Florian Fainelli wrote: > On 03/21/2017 02:35 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > MT7530 is a 7-ports Gigabit Ethernet Switch that

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

On Mon 27 Mar 16:04 PDT 2017, David Miller wrote: > From: Bjorn Andersson > Date: Mon, 27 Mar 2017 15:58:37 -0700 > > > I'm sorry, but I can't figure out how to reproduce this. > > All of my builds are "make allmodconfig" so it should be easy to reproduce. Thanks,

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

Hello all, Am 21.02.2017 um 17:43 schrieb Rob Herring: On Sun, Feb 19, 2017 at 11:19 PM, Heiko Schocher wrote: Hello all, Am 13.02.2017 um 22:31 schrieb Rob Herring: On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher wrote: Hello Rob, Am 10.02.2017 um 16:51

[PATCH v2 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

By moving these client drivers to use RPMSG instead of the direct SMD API we can reuse them ontop of the newly added GLINK wire-protocol support found in the 820 and 835 Qualcomm platforms. As the new (RPMSG-based) and old SMD implementations are mutually exclusive we have to change all client

[PATCH v2 3/3] soc: qcom: smd-rpm: Add msm8996 compatibility

With the RPM driver transitioned to RPMSG we can reuse the SMD-RPM driver ontop of GLINK for 8996, without any modifications. Acked-by: Andy Gross Signed-off-by: Bjorn Andersson --- drivers/soc/qcom/smd-rpm.c | 1 + 1 file changed, 1

[PATCH v2 2/3] soc: qcom: smd: Remove standalone driver

Remove the standalone SMD implementation as we have transitioned the client drivers to use the RPMSG based one. Also remove all dependencies on QCOM_SMD from Kconfig files, in order to keep them selectable in the absence of the removed symbol. Acked-by: Andy Gross

Re: genphy_read_status() vs. 1000bT Pause capability

On Tue, 2017-03-28 at 16:17 +1100, Benjamin Herrenschmidt wrote: > Hence my question ... how "standard" is the re-use of the LPA bits > for these alternate meanings in 1000bT and should we update genphy > to perform that decoding ? And btw, I'm happy to provide patches if we agree on the approach

Re: genphy_read_status() vs. 1000bT Pause capability

On Mon, 2017-03-27 at 21:14 -0700, Florian Fainelli wrote: > > Doesn't fix my other problem with Pause in 1000bT land. Do you know if > > that way of reflecting the pause capability by hijacking the old > > LPA bits is widely implemented enough that we should put it in > > genphy_read_status() ? >

Re: EINVAL when using connect() for udp sockets

On Fri, Mar 24, 2017 at 4:19 PM, Eric Dumazet wrote: > On Fri, 2017-03-24 at 15:34 -0700, Cong Wang wrote: >> (Cc'ing Michael Kerrisk) >> >> On Wed, Mar 22, 2017 at 10:18 PM, Eric Dumazet >> wrote: >> > On Thu, 2017-03-23 at 13:22 +1100,

Re: [pull request][net-next 00/14] Mellanox mlx5e Fail-safe config

From: Saeed Mahameed Date: Mon, 27 Mar 2017 23:48:56 +0300 > This series provides a fail-safe mechanism to allow safely re-configuring > mlx5e netdevice and provides a resiliency against sporadic > configuration failures. > > For additional information please see below. >

Re: [PATCHv2 net] sctp: change to save MSG_MORE flag into assoc

On Tue, Mar 28, 2017 at 6:43 AM, Marcelo Ricardo Leitner wrote: > On Mon, Mar 27, 2017 at 12:21:15AM +0800, Xin Long wrote: >> David Laight noticed the support for MSG_MORE with datamsg->force_delay >> didn't really work as we expected, as the first msg with MSG_MORE

Re: genphy_read_status() vs. 1000bT Pause capability

Hi Ben, On 03/27/2017 07:55 PM, Benjamin Herrenschmidt wrote: > On Tue, 2017-03-28 at 13:28 +1100, Benjamin Herrenschmidt wrote: >> >>> Hi Ben >>> >>> It is worth reading Documentation/networking/phy.txt >>> >>> The MAC should set SUPPORTED_Pause and SUPPORTED_Asym_Pause if the MAC >>> supports

Re: [PATCH next 0/5] link-status fixes for mii-monitoring

From: Mahesh Bandewar Date: Mon, 27 Mar 2017 11:37:24 -0700 > From: Mahesh Bandewar > > The mii monitoring is divided into two phases - inspect and commit. The > inspect phase technically should not make any changes to the state and > defer it to the

Re: [PATCH] net: ipconfig: fix ic_close_devs() use-after-free

From: Mark Rutland Date: Mon, 27 Mar 2017 18:00:14 +0100 > Our chosen ic_dev may be anywhere in our list of ic_devs, and we may > free it before attempting to close others. When we compare d->dev and > ic_dev->dev, we're potentially dereferencing memory returned to the >

Re: [PATCH v2] net: moxa: fix TX overrun memory leak

From: Jonas Jensen Date: Mon, 27 Mar 2017 14:31:19 +0200 > @@ -25,6 +25,7 @@ > #include > #include > #include > +#include > > #include "moxart_ether.h" > > @@ -297,6 +298,7 @@ static void moxart_tx_finished(struct net_device *ndev) > tx_tail =

Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route

David Ahern writes: > On 3/27/17 4:39 AM, Robert Shearman wrote: >> On 25/03/17 19:15, Eric W. Biederman wrote: >>> David Ahern writes: >>> Bump the maximum number of labels for MPLS routes from 2 to 12. To keep memory consumption in

Re: genphy_read_status() vs. 1000bT Pause capability

On Tue, 2017-03-28 at 13:28 +1100, Benjamin Herrenschmidt wrote: > > > Hi Ben > > > > It is worth reading Documentation/networking/phy.txt > > > > The MAC should set SUPPORTED_Pause and SUPPORTED_Asym_Pause if the MAC > > supports these features. The PHY will then negotiate them. > Haha ! The

Re: [PATCH] net: mvneta: set rx mode during resume if interface is running

Dear David, On Mon, 27 Mar 2017 16:15:34 -0700 David Miller wrote: > From: Jisheng Zhang > Date: Mon, 27 Mar 2017 18:59:05 +0800 > > > I found a bug by: > > > > 0. boot and start dhcp client > > 1. echo mem > /sys/power/state > > 2. resume back immediately > > 3. don't

Re: genphy_read_status() vs. 1000bT Pause capability

On Tue, 2017-03-28 at 03:09 +0200, Andrew Lunn wrote: > On Tue, Mar 28, 2017 at 11:49:50AM +1100, Benjamin Herrenschmidt wrote: > > Hi ! > > > > I noticed that flow control isn't being enabled on a system I'm > > working on by default. I've tracked it down to two things: > > > >  - The realtec.c

Re: [PATCH net-next 2/4] net: mpls: change mpls_route layout

David Ahern writes: > diff --git a/net/mpls/internal.h b/net/mpls/internal.h > index 66f388ba2d49..302d48f54b57 100644 > --- a/net/mpls/internal.h > +++ b/net/mpls/internal.h > @@ -64,7 +64,6 @@ struct mpls_dev { > struct sk_buff; > > #define LABEL_NOT_SPECIFIED (1

Re: genphy_read_status() vs. 1000bT Pause capability

On Tue, Mar 28, 2017 at 11:49:50AM +1100, Benjamin Herrenschmidt wrote: > Hi ! > > I noticed that flow control isn't being enabled on a system I'm > working on by default. I've tracked it down to two things: > > - The realtec.c PHY driver doesn't have Pause or Asym_Pause in > its exposed

Re: [PATCH] net: udp: add socket option to report RX queue level

Sorry, I have been transferring jobs and had no time to look at this. Josh Hunt's change seems to solve a different problem. I was looking for something that works the same way as SO_RXQ_OVERFL, providing information as ancillary data to the recvmsg() call. The problem with SO_RXQ_OVERFL alone is

genphy_read_status() vs. 1000bT Pause capability

Hi ! I noticed that flow control isn't being enabled on a system I'm working on by default. I've tracked it down to two things: - The realtec.c PHY driver doesn't have Pause or Asym_Pause in its exposed capabilities. This is in part because PHY_GBIT_FEATURES does not include SUPPORTED_Pause and

Re: [net-next v2 00/10][pull request] 40GbE Intel Wired LAN Driver Updates 2017-03-27

From: Jeff Kirsher Date: Mon, 27 Mar 2017 16:52:00 -0700 > This series contains updates to i40e and i40evf only. Pulled, thanks Jeff.

[net-next v2 10/10] i40e: initialize params before notifying of l2_param_changes

From: Jacob Keller Probably due to some mis-merging fix a bug associated with commits d7ce6422d6e6 ("i40e: don't check params until after checking for client instance", 2017-02-09) and 3140aa9a78c9 ("i40e: KISS the client interface", 2017-03-14) The first commit tried

[net-next v2 09/10] i40evf: dereference VSI after VSI has been null checked

From: Colin Ian King VSI is being dereferenced before the VSI null check; if VSI is null we end up with a null pointer dereference. Fix this by performing VSI deference after the VSI null check. Also remove the need for using adapter by using vsi->back->cinst.

[net-next v2 00/10][pull request] 40GbE Intel Wired LAN Driver Updates 2017-03-27

This series contains updates to i40e and i40evf only. Alex updates the driver code so that we can do bulk updates of the page reference count instead of just incrementing it by one reference at a time. Fixed an issue where we were not resetting skb back to NULL when we have freed it. Cleaned up

[net-next v2 08/10] i40e: Drop FCoE code that always evaluates to false or 0

From: Alexander Duyck Since FCoE isn't supported by the i40e products there isn't much point in carrying around code that will always evaluate to false. This patch goes through and strips out the code in several spots so that we don't go around carrying variables

[net-next v2 06/10] i40e/i40evf: Clean-up process_skb_fields

From: Alexander Duyck This is a minor clean-up to make the i40e/i40evf process_skb_fields function look a little more like what we have in igb. The Rx checksum function called out a need for skb->protocol but I can't see where it actually needs it. I am assuming

[net-next v2 02/10] i40e: fix configuration of RSS table with DCB

From: Harshitha Ramamurthy There exists a bug in the driver where the calculation of the RSS size was not taking into account the number of traffic classes enabled. This patch factors in the traffic classes both in the initial configuration of the table as well as

[net-next v2 05/10] i40e: removed no longer needed delays

From: Bimmy Pujari Removed no longer needed delays. At preproduction stage those delays were needed but now these delays are not needed. Signed-off-by: Bimmy Pujari Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher

[net-next v2 07/10] i40e: Drop FCoE code from core driver files

From: Alexander Duyck Looking over the code for FCoE it looks like the Rx path has been broken at least since the last major Rx refactor almost a year ago. It seems like FCoE isn't supported for any of the Fortville/Fortpark hardware so there isn't much point in

[net-next v2 01/10] i40e/i40evf: Update code to better handle incrementing page count

From: Alexander Duyck Update the driver code so that we do bulk updates of the page reference count instead of just incrementing it by one reference at a time. The advantage to doing this is that we cut down on atomic operations and this in turn should give us a

[BUG] ethernet:mellanox:mlx5: Oops in health_recover get_nic_state(dev)

Stack frame: [ 1744.418958] [] get_nic_state+0x24/0x40 [mlx5_core] [ 1744.425273] [] health_recover+0x28/0x80 [mlx5_core] [ 1744.431496] [] process_one_work+0x150/0x460 [ 1744.437218] [] worker_thread+0x50/0x4b8 [ 1744.442609] [] kthread+0xd8/0xf0 [ 1744.447377] [] ret_from_fork+0x10/0x20

[net-next v2 03/10] i40e/i40evf: Fix use after free in Rx cleanup path

From: Alexander Duyck We need to reset skb back to NULL when we have freed it in the Rx cleanup path. I found one spot where this wasn't occurring so this patch fixes it. Change-ID: Iaca68934200732cd4a63eb0bd83b539c95f8c4dd Signed-off-by: Alexander Duyck

[net-next v2 04/10] i40e: Fixed race conditions in VF reset

From: Robert Konklewski First, this patch eliminates IOMMU DMAR Faults caused by VF hardware. This is done by enabling VF hardware only after VSI resources are freed. Otherwise, hardware could DMA into memory that is (or just has been) being freed. Then, the VF

Re: [PATCH net] MAINTAINERS: Add Andrew Lunn as co-maintainer of PHYLIB

From: Florian Fainelli Date: Mon, 27 Mar 2017 10:48:11 -0700 > Andrew has been contributing a lot to PHYLIB over the past months and > his feedback on patches is more than welcome. > > Signed-off-by: Florian Fainelli Applied, thanks.

Re: [net-next 00/11][pull request] 40GbE Intel Wired LAN Driver Updates 2017-03-25

On Sat, 2017-03-25 at 01:12 -0700, Jeff Kirsher wrote: > This series contains updates to i40e and i40evf only. > > Alex updates the driver code so that we can do bulk updates of the > page > reference count instead of just incrementing it by one reference at a > time.  Fixed an issue where we

Re: [PATCH] net: mvneta: set rx mode during resume if interface is running

From: Jisheng Zhang Date: Mon, 27 Mar 2017 18:59:05 +0800 > I found a bug by: > > 0. boot and start dhcp client > 1. echo mem > /sys/power/state > 2. resume back immediately > 3. don't touch dhcp client to renew the lease > 4. ping the gateway. No acks > > Usually, after

Re: [PATCH net-next] ipv6: sr: select DST_CACHE by default

From: David Lebrun Date: Mon, 27 Mar 2017 11:43:59 +0200 > When CONFIG_IPV6_SEG6_LWTUNNEL is selected, automatically select DST_CACHE. > This allows to remove multiple ifdefs. > > Signed-off-by: David Lebrun Applied, thanks for following

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

From: Bjorn Andersson Date: Mon, 27 Mar 2017 15:58:37 -0700 > I'm sorry, but I can't figure out how to reproduce this. All of my builds are "make allmodconfig" so it should be easy to reproduce.

Re: [PATCH net-next] net: ibmveth: Remove unused stats member from struct ibmveth_adapter

From: Tobias Klauser Date: Mon, 27 Mar 2017 08:56:15 +0200 > The ibmveth driver keeps its statistics in net_device->stats, so the > stats member in struct ibmveth_adapter is unused. Remove it. > > Signed-off-by: Tobias Klauser Applied.

Re: [PATCH net-next] net: ibmvnic: Remove unused net_stats member from struct ibmvnic_adapter

From: Tobias Klauser Date: Mon, 27 Mar 2017 08:56:59 +0200 > The ibmvnic driver keeps its statistics in net_device->stats, so the > net_stats member in struct ibmvnic_adapter is unused. Remove it. > > Signed-off-by: Tobias Klauser Applied.

Re: [PATCH] netvsc: fix dereference before null check errors

From: Haiyang Zhang Date: Mon, 27 Mar 2017 00:50:27 + > > >> -Original Message- >> From: Colin King [mailto:colin.k...@canonical.com] >> Sent: Saturday, March 25, 2017 10:27 AM >> To: KY Srinivasan ; Haiyang Zhang >>

Re: [PATCH net-next 1/4] net: mpls: Convert number of nexthops to u8

David Ahern writes: > On 3/26/17 9:11 PM, Eric W. Biederman wrote: >> I don't like this. Byte writes don't exist on all architectures. >> >> So while I think always writing to rtn_nhn_alive under the >> rtn_lock ensures that we don't have wrong values written >> it is

Re: [PATCH net-next] net: bfin_mac: Remove unused stats member from struct bfin_mac_local

From: Tobias Klauser Date: Mon, 27 Mar 2017 08:55:11 +0200 > The bfin_mac driver keeps its statistics in net_device->stats, so the > stats member in struct bfin_mac_local is unused. Remove it, as well as > the accompanying comment. > > Cc:

Re: [PATCH] net: tehuti: use new api ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 26 Mar 2017 22:03:13 +0200 > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > As I don't have the hardware, I'd be very pleased if > someone may test this patch. > >

Re: [PATCH net-next] rtnl: Add support for netdev event to link messages

From: Vladislav Yasevich Date: Sat, 25 Mar 2017 21:59:47 -0400 > RTNL currently generates notifications on some netdev notifier events. > However, user space has no idea what changed. All it sees is the > data and has to infer what has changed. For some events that is not

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

On Thu 23 Mar 16:56 PDT 2017, David Miller wrote: > From: Bjorn Andersson > Date: Wed, 22 Mar 2017 14:57:33 -0700 > > > On Wed 22 Mar 11:44 PDT 2017, David Miller wrote: > > > >> From: Bjorn Andersson > >> Date: Mon, 20 Mar 2017 16:35:42

Re: [PATCH] net: cris: eth_v10: use new api ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Sat, 25 Mar 2017 19:39:05 +0100 > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > As I don't have the hardware, I'd be very pleased if > someone may test this patch. > >

Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route

From: David Ahern Date: Sat, 25 Mar 2017 10:03:24 -0700 > Bump the maximum number of labels for MPLS routes from 2 to 12. This doesn't apply cleanly to net-next, please respin. Perhaps it conflicts with your recent cleanups.

Re: [patch net-next 0/8] Add support for pipeline debug (dpipe)

Please fix up these warnings and resubmit: drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c: In function ‘mlxsw_sp_rif_counter_free’: drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:208:2: warning: ‘p_counter_index’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Re: [PATCH RFC v2 3/3] net: phy: allow EEE with SGMII interface modes

On Mon, Mar 27, 2017 at 03:42:57PM -0700, Florian Fainelli wrote: > I think David will require you to resubmit this as an entire patch > series and without an RFC tag. Do you want to hold off a bit to get > build coverage or go ahead and target net-next right away? I'd prefer to get build

[PATCH net-next] vxlan: don't age NTF_EXT_LEARNED fdb entries

From: Roopa Prabhu vxlan driver already implicitly supports installing of external fdb entries with NTF_EXT_LEARNED. This patch just makes sure these entries are not aged by the vxlan driver. An external entity managing these entries will age them out. This is

Re: [PATCHv2 net] sctp: change to save MSG_MORE flag into assoc

On Mon, Mar 27, 2017 at 12:21:15AM +0800, Xin Long wrote: > David Laight noticed the support for MSG_MORE with datamsg->force_delay > didn't really work as we expected, as the first msg with MSG_MORE set > would always block the following chunks' dequeuing. > > This Patch is to rewrite it by

Re: [PATCH RFC v2 3/3] net: phy: allow EEE with SGMII interface modes

On 03/27/2017 01:15 PM, Russell King - ARM Linux wrote: > Here's the revised patch as requested. > > Thanks. > > 8<=== > From: Russell King > Subject: [PATCH] net: phy: allow EEE with any interface mode > > EEE is able to work in any PHY interface mode, there is

[PATCH v2] net: netfilter: Remove multiple assignment.

This patch removes multiple assignments to follow the kernel coding style as also reported by checkpatch.pl. Done using coccinelle. @@ identifier i1,i2; constant c; @@ - i1=i2=c; + i1=c; + i2=i1; Signed-off-by: Arushi Singhal --- changes in v2 -Make the commit

Re: Extending socket timestamping API for NTP

> On Mar 27, 2017, at 13:58, Richard Cochran wrote: > > On Mon, Mar 27, 2017 at 12:18:47PM -0700, Denny Page wrote: >> I think that on average, the Vendor’s numbers are likely to be more >> accurate than anyone else’s. The concept that independent software >>

Re: [PATCH net-next 0/2] net: mpls: multipath route cleanups

From: David Ahern Date: Fri, 24 Mar 2017 15:21:55 -0700 > When a device associated with a nexthop is deleted, the nexthop in > the route is effectively removed, so remove it from the route dump. > > Further, when all nexhops have been deleted the route is effectively >

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

From: Joao Pinto Date: Mon, 27 Mar 2017 18:44:22 +0100 > For what I am understanding, SoCs base on Core versions >= 4.00 are working > properly and for some reason SoCs based on older versions are not working. Please send me a revert, and work offline with these people

Re: Extending socket timestamping API for NTP

On Mon, Mar 27, 2017 at 12:19:57PM -0700, Denny Page wrote: > Do you still have the resulting correction values from this? No, I don't, but next time I drag out the phyter I will take another look and let you know. Thanks, Richard

Re: Extending socket timestamping API for NTP

On Mon, Mar 27, 2017 at 12:18:47PM -0700, Denny Page wrote: > I think that on average, the Vendor’s numbers are likely to be more > accurate than anyone else’s. The concept that independent software > implementations are going to somehow obtain and maintain better > numbers is too much of a

Re: [PATCH net-next 2/2] cls_flower: add support for matching MPLS labels

Mon, Mar 27, 2017 at 08:16:02PM CEST, benjamin.laha...@netronome.com wrote: >Add support to tc flower to match based on fields in MPLS labels (TTL, >Bottom of Stack, TC field, Label). > >Signed-off-by: Benjamin LaHaise >Signed-off-by: Benjamin LaHaise

[net-next 13/14] net/mlx5e: Fail safe tc setup

Use the new fail-safe channels switch mechanism to set up new tc parameters. Signed-off-by: Saeed Mahameed Reviewed-by: Tariq Toukan --- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 20 1 file changed, 12 insertions(+), 8

[net-next 10/14] net/mlx5e: Introduce switch channels

A fail safe helper functions that allows switching to new channels on the fly, In simple words: make_new_config(new_params) { new_channels = open_channels(new_params); if (!new_channels) return "Failed, but current channels are still active :)"

[net-next 01/14] net/mlx5e: Set SQ max rate on mlx5e_open_txqsq rather on open_channel

Instead of iterating over the channel SQs to set their max rate, do it on SQ creation per TXQ SQ. Signed-off-by: Saeed Mahameed Reviewed-by: Tariq Toukan --- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 22 ++ 1 file changed,

[net-next 02/14] net/mlx5e: Set netdev->rx_cpu_rmap on netdev creation

To simplify mlx5e_open_locked flow we set netdev->rx_cpu_rmap on netdev creation rather on netdev open, it is redundant to set it every time on mlx5e_open_locked. Signed-off-by: Saeed Mahameed Reviewed-by: Tariq Toukan ---

[net-next 03/14] net/mlx5e: Introduce mlx5e_channels

Have a dedicated "channels" handler that will serve as channels (RQs/SQs/etc..) holder to help with separating channels/parameters operations, for the downstream fail-safe configuration flow, where we will create a new instance of mlx5e_channels with the new requested parameters and switch to the

[net-next 09/14] net/mlx5e: Minimize mlx5e_{open/close}_locked

mlx5e_redirect_rqts_to_{channels,drop} and mlx5e_{add,del}_sqs_fwd_rules and Set real num tx/rx queues belong to mlx5e_{activate,deactivate}_priv_channels, for that we move those functions and minimize mlx5e_open/close flows. This will be needed in downstream patches to replace old channels with

[net-next 05/14] net/mlx5e: Refactor refresh TIRs

Rename mlx5e_refresh_tirs_self_loopback to mlx5e_refresh_tirs, as it will be used in downstream (Safe config flow) patches, and make it fail safe on mlx5e_open. Signed-off-by: Saeed Mahameed Reviewed-by: Tariq Toukan ---

[net-next 12/14] net/mlx5e: Fail safe cqe compressing/moderation mode setting

Use the new fail-safe channels switch mechanism to set new CQE compressing and CQE moderation mode settings. We also move RX CQE compression modify function out of en_rx file to a more appropriate place. Signed-off-by: Saeed Mahameed Reviewed-by: Tariq Toukan

[net-next 14/14] net/mlx5e: Fail safe mtu and lro setting

Use the new fail-safe channels switch mechanism to set new netdev mtu and lro settings. MTU and lro settings demand some HW configuration changes after new channels are created and ready for action. In order to unify switch channels routine for LRO and MTU changes, and maybe future configuration

[net-next 04/14] net/mlx5e: Redirect RQT refactoring

RQ Tables are always created once (on netdev creation) pointing to drop RQ and at that stage, RQ tables (indirection tables) are always directed to drop RQ. We don't need to use mlx5e_fill_{direct,indir}_rqt_rqns to fill the drop RQ in create RQT procedure. Instead of having separate flows to

[net-next 11/14] net/mlx5e: Fail safe ethtool settings

Use the new fail-safe channels switch mechanism to set new ethtool settings: - ring parameters - coalesce parameters - tx copy break parameters Signed-off-by: Saeed Mahameed Reviewed-by: Tariq Toukan ---

[net-next 08/14] net/mlx5e: CQ and RQ don't need priv pointer

Remove mlx5e_priv pointer from CQ and RQ structs, it was needed only to access mdev pointer from priv pointer. Instead we now pass mdev where needed. Signed-off-by: Saeed Mahameed Reviewed-by: Tariq Toukan ---

[net-next 07/14] net/mlx5e: Isolate open_channels from priv->params

In order to have a clean separation between channels resources creation flows and current active mlx5e netdev parameters, make sure each resource creation function do not access priv->params, and only works with on a new fresh set of parameters. For this we add "new" mlx5e_params field to

[pull request][net-next 00/14] Mellanox mlx5e Fail-safe config

Hi Dave, This series provides a fail-safe mechanism to allow safely re-configuring mlx5e netdevice and provides a resiliency against sporadic configuration failures. For additional information please see below. Please pull and let me know if there's any problem. Thanks, Saeed. --- The

[net-next 06/14] net/mlx5e: Split open/close channels to stages

As a foundation for safe config flow, a simple clear API such as (Open then Activate) where the "Open" handles the heavy unsafe creation operation and the "activate" will be fast and fail safe, to enable the newly created channels. For this we split the RQs/TXQ SQs and channels open/close flows

Re: [PATCH net-next 2/2] cls_flower: add support for matching MPLS labels

On Mon, Mar 27, 2017 at 10:30:41PM +0200, Jiri Pirko wrote: > Mon, Mar 27, 2017 at 08:16:02PM CEST, benjamin.laha...@netronome.com wrote: > >Add support to tc flower to match based on fields in MPLS labels (TTL, > >Bottom of Stack, TC field, Label). > > Please use scripts/get_maintainer.pl to

Re: [PATCH net-next 1/2] flow_dissector: add mpls support

Mon, Mar 27, 2017 at 08:13:42PM CEST, benjamin.laha...@netronome.com wrote: >Add support for parsing MPLS flows to the flow dissector in preparation for >adding MPLS match support to cls_flower. > >Signed-off-by: Benjamin LaHaise >Signed-off-by: Benjamin LaHaise

Re: [PATCH net-next 2/2] cls_flower: add support for matching MPLS labels

Mon, Mar 27, 2017 at 08:16:02PM CEST, benjamin.laha...@netronome.com wrote: >Add support to tc flower to match based on fields in MPLS labels (TTL, >Bottom of Stack, TC field, Label). Please use scripts/get_maintainer.pl to get list of ccs for the patches you submit. > >Signed-off-by: Benjamin

Re: [PATCH RFC net-next 3/3] net: phy: stop the PHY clock during LPI only if supported

On Mon, Mar 27, 2017 at 11:47:21AM -0700, Florian Fainelli wrote: > Now that we detect whether a PHY supports stopping its clock during LPI, > deny a call to phy_init_eee() with clk_stop_enable being set and the PHY > not supporting that. Hi Florian We are not denying the call. This just ignores

Re: [PATCH RFC net-next 2/3] net: phy: read whether PHY supports stopping clock during LPI

On Mon, Mar 27, 2017 at 11:47:20AM -0700, Florian Fainelli wrote: > In order to use phy_init_eee() correctly, in particular the clk_stop > argument, we need to know whether the Ethernet PHY supports stopping its > clock. > > Right now, we would have to call phy_init_eee(phydev, 1), see if that >

Re: [PATCH RFC v4 07/10] dt-bindings: net: add binding for QCA7000 UART

On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren wrote: > This is the serdev binding for the QCA7000 UART driver (Ethernet over UART). > > Signed-off-by: Stefan Wahren > --- > > According to this binding are still some questions: > > Where should be

Re: [PATCH RFC v2 3/3] net: phy: allow EEE with SGMII interface modes

Here's the revised patch as requested. Thanks. 8<=== From: Russell King Subject: [PATCH] net: phy: allow EEE with any interface mode EEE is able to work in any PHY interface mode, there is nothing which fundamentally restricts it to only a few modes. For example,

Re: [PATCH net] MAINTAINERS: Add Andrew Lunn as co-maintainer of PHYLIB

On Mon, Mar 27, 2017 at 10:48:11AM -0700, Florian Fainelli wrote: > Andrew has been contributing a lot to PHYLIB over the past months and > his feedback on patches is more than welcome. > > Signed-off-by: Florian Fainelli Thanks Florian Acked-by: Andrew Lunn

Re: [PATCH RFC v4 09/10] tty: serdev-ttyport: return actual baudrate from ttyport_set_baudrate

On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren wrote: > Instead of returning the requested baudrate, we better return the > actual one because it isn't always the same. > > Signed-off-by: Stefan Wahren > --- > drivers/tty/serdev/serdev-ttyport.c |

Re: [PATCH RFC v4 10/10] tty: serdev: add functions to retrieve common UART settings

On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren wrote: > Currently serdev core doesn't provide functions to retrieve common > UART settings like data bits, stop bits or parity. This patch adds > the interface to the core and the necessary implementation for >

[PATCH v2] cfg80211: Fix array-bounds warning in fragment copy

__ieee80211_amsdu_copy_frag intentionally initializes a pointer to array[-1] to increment it later to valid values. clang rightfully generates an array-bounds warning on the initialization statement. Initialize the pointer to array[0] and change the algorithm from increment before to increment

Re: [PATCH RFC v2 3/3] net: phy: allow EEE with SGMII interface modes

On Mon, Mar 27, 2017 at 11:03:12AM -0700, Florian Fainelli wrote: > On 03/27/2017 10:00 AM, Russell King - ARM Linux wrote: > > On Mon, Mar 27, 2017 at 09:47:31AM -0700, Florian Fainelli wrote: > >> On 03/27/2017 02:59 AM, Russell King wrote: > >>> As EEE is able to work in SGMII mode as well, add

Re: [PATCH RFC v2 3/3] net: phy: allow EEE with SGMII interface modes

On 03/27/2017 12:47 PM, Russell King - ARM Linux wrote: > On Mon, Mar 27, 2017 at 11:03:12AM -0700, Florian Fainelli wrote: >> On 03/27/2017 10:00 AM, Russell King - ARM Linux wrote: >>> On Mon, Mar 27, 2017 at 09:47:31AM -0700, Florian Fainelli wrote: On 03/27/2017 02:59 AM, Russell King

Re: [PATCH] cfg80211: Fix array-bounds warning in fragment copy

El Mon, Mar 27, 2017 at 12:47:59PM +0200 Johannes Berg ha dit: > On Fri, 2017-03-24 at 18:06 -0700, Matthias Kaehlcke wrote: > > __ieee80211_amsdu_copy_frag intentionally initializes a pointer to > > array[-1] to increment it later to valid values. clang rightfully > > generates an array-bounds

Re: Extending socket timestamping API for NTP

[Resend in plain text for vger] > On Mar 27, 2017, at 11:28, Richard Cochran wrote: > > I didn't do anything super methodical, and I didn't keep notes, but I > had a phyter (whose delays were published by TI and independently > confirmed in a ISPCS paper by Christian

Re: Extending socket timestamping API for NTP

[Resend in plain text for vger] > On Mar 27, 2017, at 11:28, Richard Cochran wrote: > > On Mon, Mar 27, 2017 at 09:25:03AM -0700, Denny Page wrote: > >> I agree that the values in the igb driver are incorrect. They were >> middle of the range values from the old

Re: Extending socket timestamping API for NTP

> On Mar 27, 2017, at 11:28, Richard Cochran wrote: > > On Mon, Mar 27, 2017 at 09:25:03AM -0700, Denny Page wrote: > >> I agree that the values in the igb driver are incorrect. They were >> middle of the range values from the old tables. At least for 100Mb, >> Intel

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

On Mon, Mar 27, 2017 at 06:44:22PM +0100, Joao Pinto wrote: > Às 6:28 PM de 3/27/2017, David Miller escreveu: > > From: Corentin Labbe > > Date: Mon, 27 Mar 2017 19:00:58 +0200 > > > >> On Mon, Mar 27, 2017 at 04:26:48PM +0100, Joao Pinto wrote: > >>> Hi David, > >>> >

[PATCH RFC net-next 2/3] net: phy: read whether PHY supports stopping clock during LPI

In order to use phy_init_eee() correctly, in particular the clk_stop argument, we need to know whether the Ethernet PHY supports stopping its clock. Right now, we would have to call phy_init_eee(phydev, 1), see if that tails, and call again with phy_init_eee(phydev, 0) to enable EEE this is not

[PATCH RFC net-next 3/3] net: phy: stop the PHY clock during LPI only if supported

Now that we detect whether a PHY supports stopping its clock during LPI, deny a call to phy_init_eee() with clk_stop_enable being set and the PHY not supporting that. Signed-off-by: Florian Fainelli --- drivers/net/phy/phy.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH RFC net-next 1/3] net: mdio: add definition for MDIO_STAT1_CLOCK_STOP_CAPABLE

Add the definition for the Clause 45 IEEE PCS Status 1 Register (3.1) reporting whether a PHY supports stopping its clock or not during LPI (EEE). Signed-off-by: Florian Fainelli --- include/uapi/linux/mdio.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH RFC net-next 0/3] net: phy: Read if PHY can stop its clock

This patch series update PHYLIB to read whether the PHY is actually capable of stopping its clocks during EEE low power modes. One problem (not the only one) with phy_init_eee() is that it takes a clk_stop_enable argument that the caller has no idea how to determine. This patch series makes the

  1   2   3   >