* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: Or Gerlitz @ 2017-01-16 21:44 UTC (permalink / raw)
To: Tariq Toukan, Daniel Jurgens
Cc: David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <1484587805-12666-4-git-send-email-tariqt@mellanox.com>
On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
> From: Daniel Jurgens <danielj@mellanox.com>
>
> Use CPUs on the close NUMA when setting the EQ affinity hints.
Dan, are we sure there are no down-sides for always doing this? this
code is probably there for many years and we're introducing here new
behaviour to potentially to many Ms installs when they get distro
update that includes this patch.
^ permalink raw reply
* Re: [patch net-next] stmmac: indent an if statement
From: Julia Lawall @ 2017-01-16 21:46 UTC (permalink / raw)
To: Dan Carpenter
Cc: David Miller, peppe.cavallaro, Joao.Pinto, alexandre.torgue,
netdev, linux-kernel, kernel-janitors
In-Reply-To: <20170116093954.GB4104@mwanda>
On Mon, 16 Jan 2017, Dan Carpenter wrote:
> On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote:
> > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> > > From: Dan Carpenter <dan.carpenter@oracle.com>
> > > Date: Thu, 12 Jan 2017 21:46:32 +0300
> > >
> > > > The break statement should be indented one more tab.
> > > >
> > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > >
> > > Applied, but like Julia I think we might have a missing of_node_put()
> > > here.
> >
> > Of course, sorry for dropping the ball on this. I'll send a patch for
> > that.
> >
>
> Actually, I've looked at it some more and I think this function is OK.
> We're supposed to do an of_node_put() later... I can't find where that
> happens, but presumably that's because I don't know stmmac well. This
> code here, though, is fine.
Why do you think it is fine? Does anyone in the calling context know
which child would have caused the break? An extra put is only needed on
that one. Is there a guarantee that the break is always taken?
julia
^ permalink raw reply
* [PATCH v2] net: marvell: skge: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2017-01-16 21:46 UTC (permalink / raw)
To: mlindner, stephen, davem; +Cc: netdev, linux-kernel, Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
The callback set_link_ksettings no longer update the value
of advertising, as the struct ethtool_link_ksettings is
defined as const.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
Changelog:
v2:
- update the commit log with a note to explain that this code
was not tested on hardware (feedback from Stephen Hemminger)
drivers/net/ethernet/marvell/skge.c | 63 ++++++++++++++++++++--------------
1 files changed, 37 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 9146a51..81106b7 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -300,65 +300,76 @@ static u32 skge_supported_modes(const struct skge_hw *hw)
return supported;
}
-static int skge_get_settings(struct net_device *dev,
- struct ethtool_cmd *ecmd)
+static int skge_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
{
struct skge_port *skge = netdev_priv(dev);
struct skge_hw *hw = skge->hw;
+ u32 supported, advertising;
- ecmd->transceiver = XCVR_INTERNAL;
- ecmd->supported = skge_supported_modes(hw);
+ supported = skge_supported_modes(hw);
if (hw->copper) {
- ecmd->port = PORT_TP;
- ecmd->phy_address = hw->phy_addr;
+ cmd->base.port = PORT_TP;
+ cmd->base.phy_address = hw->phy_addr;
} else
- ecmd->port = PORT_FIBRE;
+ cmd->base.port = PORT_FIBRE;
+
+ advertising = skge->advertising;
+ cmd->base.autoneg = skge->autoneg;
+ cmd->base.speed = skge->speed;
+ cmd->base.duplex = skge->duplex;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
- ecmd->advertising = skge->advertising;
- ecmd->autoneg = skge->autoneg;
- ethtool_cmd_speed_set(ecmd, skge->speed);
- ecmd->duplex = skge->duplex;
return 0;
}
-static int skge_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+static int skge_set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
{
struct skge_port *skge = netdev_priv(dev);
const struct skge_hw *hw = skge->hw;
u32 supported = skge_supported_modes(hw);
int err = 0;
+ u32 advertising;
+
+ ethtool_convert_link_mode_to_legacy_u32(&advertising,
+ cmd->link_modes.advertising);
- if (ecmd->autoneg == AUTONEG_ENABLE) {
- ecmd->advertising = supported;
+ if (cmd->base.autoneg == AUTONEG_ENABLE) {
+ advertising = supported;
skge->duplex = -1;
skge->speed = -1;
} else {
u32 setting;
- u32 speed = ethtool_cmd_speed(ecmd);
+ u32 speed = cmd->base.speed;
switch (speed) {
case SPEED_1000:
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
setting = SUPPORTED_1000baseT_Full;
- else if (ecmd->duplex == DUPLEX_HALF)
+ else if (cmd->base.duplex == DUPLEX_HALF)
setting = SUPPORTED_1000baseT_Half;
else
return -EINVAL;
break;
case SPEED_100:
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
setting = SUPPORTED_100baseT_Full;
- else if (ecmd->duplex == DUPLEX_HALF)
+ else if (cmd->base.duplex == DUPLEX_HALF)
setting = SUPPORTED_100baseT_Half;
else
return -EINVAL;
break;
case SPEED_10:
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
setting = SUPPORTED_10baseT_Full;
- else if (ecmd->duplex == DUPLEX_HALF)
+ else if (cmd->base.duplex == DUPLEX_HALF)
setting = SUPPORTED_10baseT_Half;
else
return -EINVAL;
@@ -371,11 +382,11 @@ static int skge_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
return -EINVAL;
skge->speed = speed;
- skge->duplex = ecmd->duplex;
+ skge->duplex = cmd->base.duplex;
}
- skge->autoneg = ecmd->autoneg;
- skge->advertising = ecmd->advertising;
+ skge->autoneg = cmd->base.autoneg;
+ skge->advertising = advertising;
if (netif_running(dev)) {
skge_down(dev);
@@ -875,8 +886,6 @@ static int skge_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom
}
static const struct ethtool_ops skge_ethtool_ops = {
- .get_settings = skge_get_settings,
- .set_settings = skge_set_settings,
.get_drvinfo = skge_get_drvinfo,
.get_regs_len = skge_get_regs_len,
.get_regs = skge_get_regs,
@@ -899,6 +908,8 @@ static int skge_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom
.set_phys_id = skge_set_phys_id,
.get_sset_count = skge_get_sset_count,
.get_ethtool_stats = skge_get_ethtool_stats,
+ .get_link_ksettings = skge_get_link_ksettings,
+ .set_link_ksettings = skge_set_link_ksettings,
};
/*
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 1/2] qed: Add support for hardware offloaded FCoE.
From: Chad Dupuis @ 2017-01-16 21:47 UTC (permalink / raw)
To: martin.petersen
Cc: linux-scsi, fcoe-devel, netdev, yuval.mintz,
QLogic-Storage-Upstream
In-Reply-To: <1484596437-27637-2-git-send-email-chad.dupuis@cavium.com>
I forgot to add netdev-next to the subject line. Is a repost needed here?
On Mon, 16 Jan 2017, 7:53pm -0000, Dupuis, Chad wrote:
> From: Arun Easi <arun.easi@qlogic.com>
>
> This adds the backbone required for the various HW initalizations
> which are necessary for the FCoE driver (qedf) for QLogic FastLinQ
> 4xxxx line of adapters - FW notification, resource initializations, etc.
>
> Signed-off-by: Arun Easi <arun.easi@cavium.com>
> Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
> ---
> drivers/net/ethernet/qlogic/Kconfig | 3 +
> drivers/net/ethernet/qlogic/qed/Makefile | 1 +
> drivers/net/ethernet/qlogic/qed/qed.h | 11 +
> drivers/net/ethernet/qlogic/qed/qed_cxt.c | 98 ++-
> drivers/net/ethernet/qlogic/qed/qed_cxt.h | 3 +
> drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 11 +
> drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 1 +
> drivers/net/ethernet/qlogic/qed/qed_dev.c | 205 ++++-
> drivers/net/ethernet/qlogic/qed/qed_dev_api.h | 42 +
> drivers/net/ethernet/qlogic/qed/qed_fcoe.c | 990 ++++++++++++++++++++++
> drivers/net/ethernet/qlogic/qed/qed_fcoe.h | 52 ++
> drivers/net/ethernet/qlogic/qed/qed_hsi.h | 781 ++++++++++++++++-
> drivers/net/ethernet/qlogic/qed/qed_hw.c | 3 +
> drivers/net/ethernet/qlogic/qed/qed_ll2.c | 25 +
> drivers/net/ethernet/qlogic/qed/qed_ll2.h | 2 +-
> drivers/net/ethernet/qlogic/qed/qed_main.c | 7 +
> drivers/net/ethernet/qlogic/qed/qed_mcp.c | 3 +
> drivers/net/ethernet/qlogic/qed/qed_mcp.h | 1 +
> drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 8 +
> drivers/net/ethernet/qlogic/qed/qed_sp.h | 4 +
> drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 3 +
> include/linux/qed/common_hsi.h | 10 +-
> include/linux/qed/fcoe_common.h | 715 ++++++++++++++++
> include/linux/qed/qed_fcoe_if.h | 145 ++++
> include/linux/qed/qed_if.h | 39 +
> 25 files changed, 3152 insertions(+), 11 deletions(-)
> create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.c
> create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.h
> create mode 100644 include/linux/qed/fcoe_common.h
> create mode 100644 include/linux/qed/qed_fcoe_if.h
>
^ permalink raw reply
* Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool
From: Or Gerlitz @ 2017-01-16 21:48 UTC (permalink / raw)
To: Tariq Toukan, Ariel Levkovich
Cc: David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <1484587805-12666-7-git-send-email-tariqt@mellanox.com>
On Mon, Jan 16, 2017 at 7:30 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
0644
> --- a/include/linux/mlx4/device.h
> +++ b/include/linux/mlx4/device.h
> @@ -1539,8 +1539,13 @@ enum mlx4_ptys_proto {
> MLX4_PTYS_EN = 1<<2,
> };
>
> +enum mlx4_ptys_flags {
> + MLX4_PTYS_AN_DISABLE_CAP = 1 << 5,
> + MLX4_PTYS_AN_DISABLE_ADMIN = 1 << 6,
> +};
> +
> struct mlx4_ptys_reg {
> - u8 resrvd1;
> + u8 flags;
> u8 local_port;
> u8 resrvd2;
> u8 proto_mask;
Hi Ariel,
I didn't see any new dev cap bit, what happens with FW version which
don't support this, is the result well defined? what is it?
Or.
^ permalink raw reply
* Re: [PATCH] net: add regs attribute to phy device for user diagnose
From: David Miller @ 2017-01-16 21:54 UTC (permalink / raw)
To: f.fainelli; +Cc: cugyly, andrew, netdev, Linyu.Yuan
In-Reply-To: <cf3e3125-582f-8b91-9c23-05dbdd2c6d24@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 16 Jan 2017 12:22:16 -0800
> On 01/16/2017 04:59 AM, yuan linyu wrote:
>> On 日, 2017-01-15 at 18:21 +0100, Andrew Lunn wrote:
>>> On Sun, Jan 15, 2017 at 09:51:03AM +0800, yuan linyu wrote:
>>>>
>>>> I hope user/developer can read this attribute file "regs" to do
>>>> a full check of all registers value, and they can write any register
>>>> inside PHY through this file.
>>> Since this is intended for debug, it should not be sysfs, but debugfs.
>> agree,
>>> However, in general, Linux does not allow user space to peek and poke
>>> device registers. Can you point me at examples where i can do the same
>>> to my GPU? SATA controller? Ethernet controller, I2C temperature
>>> sensor? Any device?
>> we can read registers of ethernet controller(memory register accessed) through devmem or ethtool
>
> So why not add support in ethtool for reading PHY registers if you need
> it? There are handful of PHY "things" in ethtool, such as reading
> counters, configuring downshift etc., adding support for dumping
> registers does not sound out of space.
Agreed.
^ permalink raw reply
* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: Daniel Jurgens @ 2017-01-16 21:54 UTC (permalink / raw)
To: Or Gerlitz, Tariq Toukan
Cc: David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <CAJ3xEMiGQHV1Qc0aW43SJaNO7X5TRLdYRaZgEiA6099vbBAAXw@mail.gmail.com>
On 1/16/2017 3:44 PM, Or Gerlitz wrote:
> On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
>> From: Daniel Jurgens <danielj@mellanox.com>
>>
>> Use CPUs on the close NUMA when setting the EQ affinity hints.
> Dan, are we sure there are no down-sides for always doing this? this
> code is probably there for many years and we're introducing here new
> behaviour to potentially to many Ms installs when they get distro
> update that includes this patch.
>
I don't see a downside, this just favors using the node local CPUs before others. I don't understand your 2nd sentence there. "Ms installs"?
^ permalink raw reply
* Re: [net-next 0/3] tipc: improve interaction socket-link
From: David Miller @ 2017-01-16 21:54 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, viro, parthasarathy.bhuvaragan, ying.xue, maloy,
tipc-discussion
In-Reply-To: <A2BAEFC30C8FD34388F02C9B3121859D225F44DE@eusaamb103.ericsson.se>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 16 Jan 2017 20:35:08 +0000
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>> On Behalf Of David Miller
>> Sent: Monday, 16 January, 2017 14:45
>> To: Jon Maloy <jon.maloy@ericsson.com>
>> Cc: netdev@vger.kernel.org; viro@zeniv.linux.org.uk; Parthasarathy Bhuvaragan
>> <parthasarathy.bhuvaragan@ericsson.com>; Ying Xue
>> <ying.xue@windriver.com>; maloy@donjonn.com; tipc-
>> discussion@lists.sourceforge.net
>> Subject: Re: [net-next 0/3] tipc: improve interaction socket-link
>>
>> From: Jon Maloy <jon.maloy@ericsson.com>
>> Date: Tue, 3 Jan 2017 10:26:45 -0500
>>
>> > We fix a very real starvation problem that may occur when a link
>> > encounters send buffer congestion. At the same time we make the
>> > interaction between the socket and link layer simpler and more
>> > consistent.
>>
>> This doesn't apply to net-next, also the Date in your emails is 10 days
>> in the past. What's going on here?
>
> I don't know. This series was sent in on Jan 3rd, and applied by you the same day. Maybe the mail server decided to send you a duplicate?
If you look in the headers, they have "Received-by: " fields with
January 13th in the date. So something pushed them out again.
Really strange...
^ permalink raw reply
* Re: [PATCH V2] audit: log 32-bit socketcalls
From: David Miller @ 2017-01-16 21:55 UTC (permalink / raw)
To: paul; +Cc: rgb, netdev, linux-kernel, linux-audit
In-Reply-To: <CAHC9VhQwVOQ+-iZ1iC-efVvCUadMCdRJS60wqgUQWgExL51yEw@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Mon, 16 Jan 2017 15:38:33 -0500
> David, assuming Richard makes your requested changes, any objection if
> I merge this via the audit tree instead of the netdev tree? It's a
> bit easier for us from a testing perspective this way ...
No objection.
^ permalink raw reply
* Re: [patch net-next] stmmac: indent an if statement
From: Dan Carpenter @ 2017-01-16 21:56 UTC (permalink / raw)
To: Julia Lawall
Cc: David Miller, peppe.cavallaro, Joao.Pinto, alexandre.torgue,
netdev, linux-kernel, kernel-janitors
In-Reply-To: <alpine.DEB.2.20.1701162240100.2031@hadrien>
On Mon, Jan 16, 2017 at 10:46:22PM +0100, Julia Lawall wrote:
>
>
> On Mon, 16 Jan 2017, Dan Carpenter wrote:
>
> > On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote:
> > > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> > > > From: Dan Carpenter <dan.carpenter@oracle.com>
> > > > Date: Thu, 12 Jan 2017 21:46:32 +0300
> > > >
> > > > > The break statement should be indented one more tab.
> > > > >
> > > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > >
> > > > Applied, but like Julia I think we might have a missing of_node_put()
> > > > here.
> > >
> > > Of course, sorry for dropping the ball on this. I'll send a patch for
> > > that.
> > >
> >
> > Actually, I've looked at it some more and I think this function is OK.
> > We're supposed to do an of_node_put() later... I can't find where that
> > happens, but presumably that's because I don't know stmmac well. This
> > code here, though, is fine.
>
> Why do you think it is fine? Does anyone in the calling context know
> which child would have caused the break?
Yeah. It's saved in plat->mdio_node and we expect to be holding on
either path through the function.
(It would be better if one of the stmmac people were responding here
insead of a random fix the indenting weenie like myself.)
regards,
dan caprenter
^ permalink raw reply
* Re: [PATCH 1/2] qed: Add support for hardware offloaded FCoE.
From: David Miller @ 2017-01-16 21:56 UTC (permalink / raw)
To: chad.dupuis
Cc: martin.petersen, linux-scsi, fcoe-devel, netdev, yuval.mintz,
QLogic-Storage-Upstream
In-Reply-To: <alpine.OSX.2.00.1701161633290.2060@administrators-macbook-pro.local>
From: Chad Dupuis <chad.dupuis@cavium.com>
Date: Mon, 16 Jan 2017 16:47:52 -0500
> I forgot to add netdev-next to the subject line. Is a repost needed
> here?
Not this time, no.
^ permalink raw reply
* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: David Miller @ 2017-01-16 21:57 UTC (permalink / raw)
To: danielj; +Cc: gerlitz.or, tariqt, netdev, eranbe
In-Reply-To: <VI1PR0501MB2429F11A34431293F2D0C327C47D0@VI1PR0501MB2429.eurprd05.prod.outlook.com>
From: Daniel Jurgens <danielj@mellanox.com>
Date: Mon, 16 Jan 2017 21:54:36 +0000
> I don't understand your 2nd sentence there. "Ms installs"?
I think he meant "Mellanox's installs", meaning installations of Linux
using Mellanox hardware. At least that's how I read it.
^ permalink raw reply
* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: Or Gerlitz @ 2017-01-16 21:59 UTC (permalink / raw)
To: Daniel Jurgens
Cc: Tariq Toukan, David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <VI1PR0501MB2429F11A34431293F2D0C327C47D0@VI1PR0501MB2429.eurprd05.prod.outlook.com>
On Mon, Jan 16, 2017 at 11:54 PM, Daniel Jurgens <danielj@mellanox.com> wrote:
> On 1/16/2017 3:44 PM, Or Gerlitz wrote:
>> On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
>>> From: Daniel Jurgens <danielj@mellanox.com>
>>>
>>> Use CPUs on the close NUMA when setting the EQ affinity hints.
>> Dan, are we sure there are no down-sides for always doing this? this
>> code is probably there for many years and we're introducing here new
>> behaviour to potentially to many Ms installs when they get distro
>> update that includes this patch.
> I don't see a downside, this just favors using the node local CPUs before others.
OK, so this just favors before others and not limits (not in front of
the code now)? would be good to improve the change log and make this
clear.
> I don't understand your 2nd sentence there. "Ms installs"?
Millions of installs that run Linux driver.
^ permalink raw reply
* Re: [patch net-next] stmmac: indent an if statement
From: David Miller @ 2017-01-16 22:00 UTC (permalink / raw)
To: dan.carpenter
Cc: julia.lawall, peppe.cavallaro, Joao.Pinto, alexandre.torgue,
netdev, linux-kernel, kernel-janitors
In-Reply-To: <20170116215615.GG4104@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 17 Jan 2017 00:56:15 +0300
> (It would be better if one of the stmmac people were responding here
> insead of a random fix the indenting weenie like myself.)
They are all too busy trying to rename the driver, because that's so
much more important.
^ permalink raw reply
* Re: [patch net-next] stmmac: indent an if statement
From: Julia Lawall @ 2017-01-16 22:10 UTC (permalink / raw)
To: Dan Carpenter
Cc: David Miller, peppe.cavallaro, Joao.Pinto, alexandre.torgue,
netdev, linux-kernel, kernel-janitors
In-Reply-To: <20170116215615.GG4104@mwanda>
On Tue, 17 Jan 2017, Dan Carpenter wrote:
> On Mon, Jan 16, 2017 at 10:46:22PM +0100, Julia Lawall wrote:
> >
> >
> > On Mon, 16 Jan 2017, Dan Carpenter wrote:
> >
> > > On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote:
> > > > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> > > > > From: Dan Carpenter <dan.carpenter@oracle.com>
> > > > > Date: Thu, 12 Jan 2017 21:46:32 +0300
> > > > >
> > > > > > The break statement should be indented one more tab.
> > > > > >
> > > > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > > >
> > > > > Applied, but like Julia I think we might have a missing of_node_put()
> > > > > here.
> > > >
> > > > Of course, sorry for dropping the ball on this. I'll send a patch for
> > > > that.
> > > >
> > >
> > > Actually, I've looked at it some more and I think this function is OK.
> > > We're supposed to do an of_node_put() later... I can't find where that
> > > happens, but presumably that's because I don't know stmmac well. This
> > > code here, though, is fine.
> >
> > Why do you think it is fine? Does anyone in the calling context know
> > which child would have caused the break?
>
> Yeah. It's saved in plat->mdio_node and we expect to be holding on
> either path through the function.
>
> (It would be better if one of the stmmac people were responding here
> insead of a random fix the indenting weenie like myself.)
OK, I agree that there should not be an of_node_put with the break.
Perhaps there should be an of_node_put on plat->mdio_node in
stmmac_remove_config_dt, like there is an of_node_put on plat->phy_node.
But it would certainly be helpful to hear from someone who knows the code
better.
julia
^ permalink raw reply
* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: Daniel Jurgens @ 2017-01-16 22:21 UTC (permalink / raw)
To: Or Gerlitz
Cc: Tariq Toukan, David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <CAJ3xEMjGv8xm7vOgASd0CvpS9uQFLv8tT_n7aqsuoB7eTUAZUg@mail.gmail.com>
On 1/16/2017 3:59 PM, Or Gerlitz wrote:
> On Mon, Jan 16, 2017 at 11:54 PM, Daniel Jurgens <danielj@mellanox.com> wrote:
>> On 1/16/2017 3:44 PM, Or Gerlitz wrote:
>>> On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
>>>> From: Daniel Jurgens <danielj@mellanox.com>
>>>>
>>>> Use CPUs on the close NUMA when setting the EQ affinity hints.
>>> Dan, are we sure there are no down-sides for always doing this? this
>>> code is probably there for many years and we're introducing here new
>>> behaviour to potentially to many Ms installs when they get distro
>>> update that includes this patch.
>
>> I don't see a downside, this just favors using the node local CPUs before others.
> OK, so this just favors before others and not limits (not in front of
> the code now)? would be good to improve the change log and make this
> clear.
Right, doesn't limit. Just favors the local node. I can work with Tariq to update the commit message if you think it necessary.
^ permalink raw reply
* RE: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool
From: Ariel Levkovich @ 2017-01-16 23:08 UTC (permalink / raw)
To: Or Gerlitz, Tariq Toukan
Cc: David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <CAJ3xEMjEPQv=Agz5Wr-2UEL+iv7nz4NAcpCKY9=C4vs6SfKLLA@mail.gmail.com>
+ MLX4_PTYS_AN_DISABLE_CAP = 1 << 5,
It's there.
Best Regards,
Ariel Levkovich
Staff Engineer, SW
Mellanox Technologies
Beit Mellanox, Yokneam, P.O.Box 586, Israel 20692
Office: +972-74723-7652, Mobile: +972-52-3947-704
www.mellanox.com
Follow us on Facebook and Twitter
> -----Original Message-----
> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
> Sent: Monday, January 16, 2017 4:48 PM
> To: Tariq Toukan <tariqt@mellanox.com>; Ariel Levkovich
> <lariel@mellanox.com>
> Cc: David S. Miller <davem@davemloft.net>; Linux Netdev List
> <netdev@vger.kernel.org>; Eran Ben Elisha <eranbe@mellanox.com>
> Subject: Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning
> off link autonegotiation via ethtool
>
> On Mon, Jan 16, 2017 at 7:30 PM, Tariq Toukan <tariqt@mellanox.com>
> wrote:
> 0644
> > --- a/include/linux/mlx4/device.h
> > +++ b/include/linux/mlx4/device.h
> > @@ -1539,8 +1539,13 @@ enum mlx4_ptys_proto {
> > MLX4_PTYS_EN = 1<<2,
> > };
> >
> > +enum mlx4_ptys_flags {
> > + MLX4_PTYS_AN_DISABLE_CAP = 1 << 5,
> > + MLX4_PTYS_AN_DISABLE_ADMIN = 1 << 6, };
> > +
> > struct mlx4_ptys_reg {
> > - u8 resrvd1;
> > + u8 flags;
> > u8 local_port;
> > u8 resrvd2;
> > u8 proto_mask;
>
> Hi Ariel,
>
> I didn't see any new dev cap bit, what happens with FW version which don't
> support this, is the result well defined? what is it?
>
> Or.
^ permalink raw reply
* [PATCH net-next] bridge: sparse fixes in br_ip6_multicast_alloc_query()
From: Lance Richardson @ 2017-01-16 23:11 UTC (permalink / raw)
To: netdev
Changed type of csum field in struct igmpv3_query from __be16 to
__sum16 to eliminate type warning, made same change in struct
igmpv3_report for consistency.
Fixed up an ntohs() where htons() should have been used instead.
Signed-off-by: Lance Richardson <lrichard@redhat.com>
---
include/uapi/linux/igmp.h | 4 ++--
net/bridge/br_multicast.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/igmp.h b/include/uapi/linux/igmp.h
index ccbb32a..a97f9a7 100644
--- a/include/uapi/linux/igmp.h
+++ b/include/uapi/linux/igmp.h
@@ -53,7 +53,7 @@ struct igmpv3_grec {
struct igmpv3_report {
__u8 type;
__u8 resv1;
- __be16 csum;
+ __sum16 csum;
__be16 resv2;
__be16 ngrec;
struct igmpv3_grec grec[0];
@@ -62,7 +62,7 @@ struct igmpv3_report {
struct igmpv3_query {
__u8 type;
__u8 code;
- __be16 csum;
+ __sum16 csum;
__be32 group;
#if defined(__LITTLE_ENDIAN_BITFIELD)
__u8 qrv:3,
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b30e77e..f6634612 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -540,7 +540,7 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
break;
case 2:
mld2q = (struct mld2_query *)icmp6_hdr(skb);
- mld2q->mld2q_mrc = ntohs((u16)jiffies_to_msecs(interval));
+ mld2q->mld2q_mrc = htons((u16)jiffies_to_msecs(interval));
mld2q->mld2q_type = ICMPV6_MGM_QUERY;
mld2q->mld2q_code = 0;
mld2q->mld2q_cksum = 0;
--
2.5.5
^ permalink raw reply related
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Saeed Mahameed @ 2017-01-16 23:36 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, Saeed Mahameed, Doug Ledford, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky
In-Reply-To: <CALx6S377hzH8_DbUSKafkbCzMEunr0H7vrfcb2WfEWFHFnfUpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jan 16, 2017 at 11:06 PM, Tom Herbert <tom-BjP2VixgY4xUbtYUoyoikg@public.gmane.org> wrote:
> On Mon, Jan 16, 2017 at 12:30 PM, Saeed Mahameed
> <saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>> On Sat, Jan 14, 2017 at 12:07 AM, Saeed Mahameed
>> <saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>>> On Fri, Jan 13, 2017 at 7:14 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>> From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>>> Date: Thu, 12 Jan 2017 19:22:34 +0200
>>>>
>>>>> This pull request includes one patch from Leon, this patch as described
>>>>> below will change the driver directory structure and layout for better,
>>>>> logical and modular driver files separation.
>>>>>
>>>>> This change is important to both rdma and net maintainers in order to
>>>>> have smoother management of driver patches for different mlx5 sub modules
>>>>> and smoother rdma-next vs. net-next features submissions.
>>>>>
>>>>> Please find more info below -in the tag commit message-,
>>>>> review and let us know if there's any problem.
>>>>>
>>>>> This change doesn't introduce any conflicts with the current mlx5
>>>>> fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
>>>>> worked flawlessly with no issues.
>>>>>
>>>>> This is the last pull request meant for both rdma-next and net-next.
>>>>> Once pulled, this will be the base shared code for both trees.
>>>>
>>>> This is pretty crazy, it will make all bug fix backporting to -stable
>>>> a complete nightmare for myself, Doug, various distribution maintainers
>>>> and many other people who quietly have to maintain their own trees and
>>>> do backporting.
>>>>
>>>
>>> I hear you,
>>> But please bear with me here, what if we queue this patch up to -stable ? and we
>>> (Mellanox) and specifically our dedicated inbox team, will make sure
>>> that this patch
>>> will land on the various distributions and for those maintaining their
>>> own trees.
>>> This patch is really straight forward (rename files) and I already
>>> tried to cherry-pick it
>>> on older kernels, I only got a couple of conflicts on some of the
>>> "#inlcude" lines we've
>>> changed, and they are pretty straightforward to fix, we can even avoid
>>> this if we decide to
>>> not move mlx5 header files in this phase.
>>>
>>> If this is possible then all trees will be aligned and it will be a
>>> win win situation.
>>>
>>
>> Hi Dave,
>>
>> Any chance you saw my -stable suggestion above ?
>> I think it would really close the backporting gap.
>>
>> Sorry i am bothering you with this topic, but we really desire the new
>> structure and
>> I never got your feedback on this suggestion, so i would like to hear
>> your thoughts.
>>
> Saeed,
>
> I've already you specific suggestions on your new structure, please
> consider your reviewers feedback more carefully. Again, the starting
I know, sorry i didn't respond on time, I though Leno's response was sufficient.
> point for your restructuring should be to separate out the minimum set
> of files required to build reasonable driver and then cleanly
> compartmentalize the rest of the features to make it easy for your
> users to include or not include those in their build. Unless you've
I see your point and i am 100% with you on this, we are all on the
same page here,
we all want to achieve the same goal -modular break down and features
logic separation-.
And in order to achieve this we need to do some big steps.
some of them will have real benefits and others are just moving code around.
One thing I need to point out (that Leon already mentioned) that the
current driver files sitting flat
in mlx5/core directory can be categorized to 4 categories
1. core related & init flows
2. common (infinband/ethernet resource management API)
3. infiniband related logic and FW commands
4. ethernet related logic and FW commands
so we figured that first we should split the bigger chunks (ethernet
vs. inifniband) into their own directories.
then i can follow up with ethernet features break down and kconfig separation.
> done this I'm not seeing much benefit for this restructuring. Also, I
> would rather see this done in one shot then expecting some sort of
> evolution over time to the right solution-- as Dave said the
> complexity of this driver is to far down the road to do that.
>
Well, I also prefer to do this in one shot, but I don't want to start
wasting time doing such a huge change
then get a NACK on submission.
Let's assume we did this in one shot i.e:
1. restructure files and directories
2. re-arrange code (separate logic)
3. Kconfig features control - to show the immediate benefit of this change
If this is acceptable by you and we get Dave's blessing on this then i
would be happy to provide (as this is our
long term plan), but if Dave doesn't approve, then ... I don't really know.
Also for 1. backporting is really easy since such patch can be applied
easily to any kernel release back to 4.4.
but 2. and 3. are really tricky ones.
> Tom
>
>> Thanks,
>> Saeed.
>>
>>>> I really don't think you can justify this rearrangement based upon the
>>>> consequences and how much activity happens in this driver.
>>>>
>>>
>>> Right, but this is not the only justification, I can sum it up to that
>>> we would like
>>> to lay out the foundation for many years to come for a well designed
>>> driver with a modular
>>> sub modules break down and scalable infrastructure. We already plan to
>>> submit more mlx5
>>> independent sub modules - just like mlx5e (en_*) files and mlx5_ib
>>> driver- so this was also
>>> a reason for us to consider this re-engagement at this stage.
>>>
>>>> You should have thought long and hard about the layout a long time ago
>>>> rather than after the driver has been in the tree for many years.
>>>>
>>>
>>> I had this Idea for the separation before the mlx5 Ethernet
>>> submission, but I wasn't the maintainer
>>> back then, and i have been itching to submit such patch for long as
>>> well, still i don't think
>>> it is too late, We (Me and Leon) will keep maintaining this driver for
>>> only god knows how many years to come,
>>> and the mlx5 drivers are meant to serve at least 3-4 more future HW generations.
>>>
>>> Long story short, We would like to re-arrange the driver in a way that
>>> would serve us (the maintainers) and serve those
>>> who are going do develop the future Stack features and the future HW
>>> generations over the well designed (Hopefully)
>>> mlx5 infrastructure.
>>> Keeping it as it is today, will only make the situation worst in the
>>> future and it will be really hard to avoid having a spaghetti code
>>> in the mlx5 driver. All i want to point out here is that maintaining
>>> such a flat subtree is also nightmare.
>>>
>>> So i am only asking you to reconsider this change and give my -stable
>>> suggestion a thought.
>>>
>>> Thank you.
>>> Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] vxlan: fix byte order of vxlan-gpe port number
From: Lance Richardson @ 2017-01-16 23:37 UTC (permalink / raw)
To: netdev, jbenc
vxlan->cfg.dst_port is in network byte order, so an htons()
is needed here. Also reduced comment length to stay closer
to 80 column width (still slightly over, however).
Fixes: e1e5314de08b ("vxlan: implement GPE")
Signed-off-by: Lance Richardson <lrichard@redhat.com>
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ca7196c..8a79cfc 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2890,7 +2890,7 @@ static int vxlan_dev_configure(struct net *src_net, struct net_device *dev,
memcpy(&vxlan->cfg, conf, sizeof(*conf));
if (!vxlan->cfg.dst_port) {
if (conf->flags & VXLAN_F_GPE)
- vxlan->cfg.dst_port = 4790; /* IANA assigned VXLAN-GPE port */
+ vxlan->cfg.dst_port = htons(4790); /* IANA VXLAN-GPE port */
else
vxlan->cfg.dst_port = default_port;
}
--
2.5.5
^ permalink raw reply related
* [PATCH 1/1] ip: fix igmp parsing when iface is long
From: Petr Vorel @ 2017-01-16 23:25 UTC (permalink / raw)
To: netdev; +Cc: Petr Vorel
Entries with long vhost names in /proc/net/igmp have no whitespace
between name and colon, so sscanf() adds it to vhost and
'ip maddr show iface' doesn't include inet result.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
ip/ipmaddr.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ip/ipmaddr.c b/ip/ipmaddr.c
index 22eb407..4f726fd 100644
--- a/ip/ipmaddr.c
+++ b/ip/ipmaddr.c
@@ -136,13 +136,17 @@ static void read_igmp(struct ma_info **result_p)
while (fgets(buf, sizeof(buf), fp)) {
struct ma_info *ma;
+ size_t len;
if (buf[0] != '\t') {
sscanf(buf, "%d%s", &m.index, m.name);
+ len = strlen(m.name);
+ if (m.name[len - 1] == ':')
+ len--;
continue;
}
- if (filter.dev && strcmp(filter.dev, m.name))
+ if (filter.dev && strncmp(filter.dev, m.name, len))
continue;
sscanf(buf, "%08x%d", (__u32 *)&m.addr.data, &m.users);
--
2.11.0
^ permalink raw reply related
* fq_codel and skb->hash
From: Andrew Collins @ 2017-01-17 0:04 UTC (permalink / raw)
To: netdev; +Cc: edumazet
The fq_codel packet scheduler always regenerates the skb flow hash. Is there any reason
to do this other than the recent hash perturbation additions?
I ask because I have a case where an incoming set of TCP flows is encapsulated in a
single ipsec tunnel, which is then classified on egress into a single flow by fq_codel
resulting in poor behavior.
Reusing the skb hash set in receive results in much better behavior, as the value is
determined pre-encapsulation and flows end up being distributed more naturally across
codel queues.
Is opportunistically using the pre-existing skb hash (if available) problematic? Is
there a better way to manage flow separation in routed+encapsulated traffic?
Thanks,
Andrew Collins
^ permalink raw reply
* RE: [PATCH] net: add regs attribute to phy device for user diagnose
From: YUAN Linyu @ 2017-01-17 0:11 UTC (permalink / raw)
To: David Miller, f.fainelli@gmail.com
Cc: cugyly@163.com, andrew@lunn.ch, netdev@vger.kernel.org
In-Reply-To: <20170116.165401.1642553705400599921.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, January 17, 2017 5:54 AM
> To: f.fainelli@gmail.com
> Cc: cugyly@163.com; andrew@lunn.ch; netdev@vger.kernel.org; YUAN Linyu
> Subject: Re: [PATCH] net: add regs attribute to phy device for user diagnose
>
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Mon, 16 Jan 2017 12:22:16 -0800
>
> >
> > So why not add support in ethtool for reading PHY registers if you need
> > it? There are handful of PHY "things" in ethtool, such as reading
> > counters, configuring downshift etc., adding support for dumping
> > registers does not sound out of space.
Thanks, I will try this direction.
>
> Agreed.
^ permalink raw reply
* Re: [PATCH net 1/1] net sched actions: fix refcnt when GETing of action after bind
From: David Miller @ 2017-01-17 0:46 UTC (permalink / raw)
To: jhs; +Cc: netdev, xiyou.wangcong
In-Reply-To: <1484493246-10911-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sun, 15 Jan 2017 10:14:06 -0500
> From: Jamal Hadi Salim <jhs@mojatatu.com>
...
> Fixes: aecc5cefc389 ("net sched actions: fix GETing actions")
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied and queued up for -stable, thanks Jamal.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: ipv6: Allow shorthand delete of all nexthops in multipath route
From: David Miller @ 2017-01-17 0:51 UTC (permalink / raw)
To: dsa; +Cc: netdev, ddutt
In-Reply-To: <1484510826-2723-2-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Sun, 15 Jan 2017 12:07:04 -0800
> @@ -2143,6 +2143,26 @@ int ip6_del_rt(struct rt6_info *rt)
> return __ip6_del_rt(rt, &info);
> }
>
> +/* called with table lock held */
...
> @@ -2176,10 +2196,9 @@ static int ip6_route_del(struct fib6_config *cfg)
> continue;
> if (cfg->fc_protocol && cfg->fc_protocol != rt->rt6i_protocol)
> continue;
> - dst_hold(&rt->dst);
> - read_unlock_bh(&table->tb6_lock);
>
> - return __ip6_del_rt(rt, &cfg->fc_nlinfo);
> + err = __ip6_route_del(rt, cfg);
> + break;
> }
fib6_del() (invoked by __ip6_route_del()) has to be invoked with the
table lock held a sa writer, but here you are only holding it as a
reader.
I also think some more thought has to be put into whether we can
change behavior like this without using a flag, as suggested by Roopa.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox