* 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
* 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] 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] 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 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 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 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] 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 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: [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 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: [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 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 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
* [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 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
* 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: marvell: skge: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2017-01-16 21:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, mlindner, netdev, linux-kernel
In-Reply-To: <20170116095003.6998b773@xeon-e3>
Hi Stephen,
On 1/16/17, Stephen Hemminger <stephen@networkplumber.org> wrote:
> On Mon, 16 Jan 2017 12:36:17 -0500 (EST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Stephen Hemminger <stephen@networkplumber.org>
>> Date: Mon, 16 Jan 2017 09:29:51 -0800
>>
>> > On Sat, 14 Jan 2017 13:08:28 +0100
>> > Philippe Reynes <tremyfr@gmail.com> wrote:
>> >
>> >> 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.
>> >>
>> >> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
>> >
>> > Did you test this on real hardware?
>>
>> Philippe probably doesn't have physical access to most of the
>> drivers he is converting.
>>
>> But, he is the only person working on converting all of the drivers,
>> and therefore when the change looks straightforward I am going to
>> reward his work and effort by applying his changes and hope there
>> isn't any fallout.
>>
>> Those who really care can test his patches and give a Tested-by:
>>
>> Thanks.
>
> Yes, it looks mechanical and should be applied. There are lots of pieces of
> old hardware that no developer is running, and if we required full test
> suite runs
> on all drivers, then no refactoring would ever be possible.
>
> My preference is to always add commit note that the patch was compile
> tested only so that if someone has a problem with real hardware then they
> know
> what to suspect.
David is right, I don't have the hardware to test all drivers.
I haven't added a little note on all commit, because I was
thinking it would be a lot of noise. But if you prefer (and
David agrees), I'll add a note on all the following patches.
Btw, thanks David for applying my patches.
Philippe
^ permalink raw reply
* Re: [PATCH v2] net/irda: fix lockdep annotation
From: Dmitry Vyukov @ 2017-01-16 21:11 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Dave Jones, Samuel Ortiz, David Miller,
Alexander Potapenko, andreyknvl, netdev
In-Reply-To: <201701170149.G5mmkfWa%fengguang.wu@intel.com>
On Mon, Jan 16, 2017 at 7:09 PM, kbuild test robot <lkp@intel.com> wrote:
> Hi Dmitry,
>
> [auto build test ERROR on tip/locking/core]
> [also build test ERROR on v4.10-rc4 next-20170116]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Dmitry-Vyukov/net-irda-fix-lockdep-annotation/20170117-001737
> config: i386-defconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from include/linux/mmzone.h:7:0,
> from include/linux/gfp.h:5,
> from include/linux/slab.h:14,
> from drivers/gpu/drm/i915/i915_sw_fence.c:10:
> drivers/gpu/drm/i915/i915_sw_fence.c: In function '__i915_sw_fence_wake_up_all':
>>> include/linux/spinlock.h:217:3: error: void value not ignored as it ought to be
> (void)subclass; \
>
>>> include/linux/spinlock.h:335:2: note: in expansion of macro 'raw_spin_lock_irqsave_nested'
> raw_spin_lock_irqsave_nested(spinlock_check(lock), flags, subclass); \
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> drivers/gpu/drm/i915/i915_sw_fence.c:68:2: note: in expansion of macro 'spin_lock_irqsave_nested'
> spin_lock_irqsave_nested(&x->lock, flags, 1 + !!continuation);
> ^~~~~~~~~~~~~~~~~~~~~~~~
Mailed v3.
> vim +217 include/linux/spinlock.h
>
> 211 typecheck(unsigned long, flags); \
> 212 flags = _raw_spin_lock_irqsave_nested(lock, subclass); \
> 213 } while (0)
> 214 #else
> 215 #define raw_spin_lock_irqsave_nested(lock, flags, subclass) \
> 216 do { \
> > 217 (void)subclass; \
> 218 typecheck(unsigned long, flags); \
> 219 flags = _raw_spin_lock_irqsave(lock); \
> 220 } while (0)
> 221 #endif
> 222
> 223 #else
> 224
> 225 #define raw_spin_lock_irqsave(lock, flags) \
> 226 do { \
> 227 typecheck(unsigned long, flags); \
> 228 _raw_spin_lock_irqsave(lock, flags); \
> 229 } while (0)
> 230
> 231 #define raw_spin_lock_irqsave_nested(lock, flags, subclass) \
> 232 raw_spin_lock_irqsave(lock, flags)
> 233
> 234 #endif
> 235
> 236 #define raw_spin_lock_irq(lock) _raw_spin_lock_irq(lock)
> 237 #define raw_spin_lock_bh(lock) _raw_spin_lock_bh(lock)
> 238 #define raw_spin_unlock(lock) _raw_spin_unlock(lock)
> 239 #define raw_spin_unlock_irq(lock) _raw_spin_unlock_irq(lock)
> 240
> 241 #define raw_spin_unlock_irqrestore(lock, flags) \
> 242 do { \
> 243 typecheck(unsigned long, flags); \
> 244 _raw_spin_unlock_irqrestore(lock, flags); \
> 245 } while (0)
> 246 #define raw_spin_unlock_bh(lock) _raw_spin_unlock_bh(lock)
> 247
> 248 #define raw_spin_trylock_bh(lock) \
> 249 __cond_lock(lock, _raw_spin_trylock_bh(lock))
> 250
> 251 #define raw_spin_trylock_irq(lock) \
> 252 ({ \
> 253 local_irq_disable(); \
> 254 raw_spin_trylock(lock) ? \
> 255 1 : ({ local_irq_enable(); 0; }); \
> 256 })
> 257
> 258 #define raw_spin_trylock_irqsave(lock, flags) \
> 259 ({ \
> 260 local_irq_save(flags); \
> 261 raw_spin_trylock(lock) ? \
> 262 1 : ({ local_irq_restore(flags); 0; }); \
> 263 })
> 264
> 265 /**
> 266 * raw_spin_can_lock - would raw_spin_trylock() succeed?
> 267 * @lock: the spinlock in question.
> 268 */
> 269 #define raw_spin_can_lock(lock) (!raw_spin_is_locked(lock))
> 270
> 271 /* Include rwlock functions */
> 272 #include <linux/rwlock.h>
> 273
> 274 /*
> 275 * Pull the _spin_*()/_read_*()/_write_*() functions/declarations:
> 276 */
> 277 #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
> 278 # include <linux/spinlock_api_smp.h>
> 279 #else
> 280 # include <linux/spinlock_api_up.h>
> 281 #endif
> 282
> 283 /*
> 284 * Map the spin_lock functions to the raw variants for PREEMPT_RT=n
> 285 */
> 286
> 287 static __always_inline raw_spinlock_t *spinlock_check(spinlock_t *lock)
> 288 {
> 289 return &lock->rlock;
> 290 }
> 291
> 292 #define spin_lock_init(_lock) \
> 293 do { \
> 294 spinlock_check(_lock); \
> 295 raw_spin_lock_init(&(_lock)->rlock); \
> 296 } while (0)
> 297
> 298 static __always_inline void spin_lock(spinlock_t *lock)
> 299 {
> 300 raw_spin_lock(&lock->rlock);
> 301 }
> 302
> 303 static __always_inline void spin_lock_bh(spinlock_t *lock)
> 304 {
> 305 raw_spin_lock_bh(&lock->rlock);
> 306 }
> 307
> 308 static __always_inline int spin_trylock(spinlock_t *lock)
> 309 {
> 310 return raw_spin_trylock(&lock->rlock);
> 311 }
> 312
> 313 #define spin_lock_nested(lock, subclass) \
> 314 do { \
> 315 raw_spin_lock_nested(spinlock_check(lock), subclass); \
> 316 } while (0)
> 317
> 318 #define spin_lock_nest_lock(lock, nest_lock) \
> 319 do { \
> 320 raw_spin_lock_nest_lock(spinlock_check(lock), nest_lock); \
> 321 } while (0)
> 322
> 323 static __always_inline void spin_lock_irq(spinlock_t *lock)
> 324 {
> 325 raw_spin_lock_irq(&lock->rlock);
> 326 }
> 327
> 328 #define spin_lock_irqsave(lock, flags) \
> 329 do { \
> 330 raw_spin_lock_irqsave(spinlock_check(lock), flags); \
> 331 } while (0)
> 332
> 333 #define spin_lock_irqsave_nested(lock, flags, subclass) \
> 334 do { \
> > 335 raw_spin_lock_irqsave_nested(spinlock_check(lock), flags, subclass); \
> 336 } while (0)
> 337
> 338 static __always_inline void spin_unlock(spinlock_t *lock)
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH v3] net/irda: fix lockdep annotation
From: Dmitry Vyukov @ 2017-01-16 21:10 UTC (permalink / raw)
To: davej, samuel, davem; +Cc: glider, andreyknvl, Dmitry Vyukov, netdev
The current annotation uses a global variable as recursion counter.
The variable is not atomic nor protected with a mutex, but mutated
by multiple threads. This causes lockdep bug reports episodically:
BUG: looking up invalid subclass: 4294967295
...
_raw_spin_lock_irqsave_nested+0x120/0x180
hashbin_delete+0x4fe/0x750
__irias_delete_object+0xab/0x170
irias_delete_object+0x5f/0xc0
ircomm_tty_detach_cable+0x1d5/0x3f0
...
Make the hashbin_lock_depth variable atomic to prevent bug reports.
As is this causes "unused variable 'depth'" warning without LOCKDEP.
So also change raw_spin_lock_irqsave_nested() macro to not cause
the warning without LOCKDEP. Similar to what raw_spin_lock_nested()
already does.
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Fixes: c7630a4b932af ("[IrDA]: irda lockdep annotation")
---
Changes since v1:
- Added raw_spin_lock_irqsave_nested() change
as 0-DAY bot reported compiler warning without LOCKDEP.
Changes since v2:
- Use ((void)(subclass), (lock)) instead of (void)subclass
to prevent unused variable warning. Now 0-DAY complaints
"error: void value not ignored as it ought to be".
My compiler does not produce warning with W=1 either way,
but the comma trick is what already used in raw_spin_lock_nested().
---
include/linux/spinlock.h | 2 +-
net/irda/irqueue.c | 12 +++++++-----
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 47dd0cebd204..beeb5a39bd8b 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -218,7 +218,7 @@ static inline void do_raw_spin_unlock(raw_spinlock_t *lock) __releases(lock)
#define raw_spin_lock_irqsave_nested(lock, flags, subclass) \
do { \
typecheck(unsigned long, flags); \
- flags = _raw_spin_lock_irqsave(lock); \
+ flags = _raw_spin_lock_irqsave(((void)(subclass), (lock))); \
} while (0)
#endif
diff --git a/net/irda/irqueue.c b/net/irda/irqueue.c
index acbe61c7e683..b9fd74e6ca99 100644
--- a/net/irda/irqueue.c
+++ b/net/irda/irqueue.c
@@ -384,21 +384,23 @@ EXPORT_SYMBOL(hashbin_new);
* just supply kfree, which should take care of the job.
*/
#ifdef CONFIG_LOCKDEP
-static int hashbin_lock_depth = 0;
+static atomic_t hashbin_lock_depth = ATOMIC_INIT(0);
#endif
int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
{
irda_queue_t* queue;
unsigned long flags = 0;
- int i;
+ int i, depth = 0;
IRDA_ASSERT(hashbin != NULL, return -1;);
IRDA_ASSERT(hashbin->magic == HB_MAGIC, return -1;);
/* Synchronize */
if ( hashbin->hb_type & HB_LOCK ) {
- spin_lock_irqsave_nested(&hashbin->hb_spinlock, flags,
- hashbin_lock_depth++);
+#ifdef CONFIG_LOCKDEP
+ depth = atomic_inc_return(&hashbin_lock_depth) - 1;
+#endif
+ spin_lock_irqsave_nested(&hashbin->hb_spinlock, flags, depth);
}
/*
@@ -423,7 +425,7 @@ int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
if ( hashbin->hb_type & HB_LOCK) {
spin_unlock_irqrestore(&hashbin->hb_spinlock, flags);
#ifdef CONFIG_LOCKDEP
- hashbin_lock_depth--;
+ atomic_dec(&hashbin_lock_depth);
#endif
}
--
2.11.0.483.g087da7b7c-goog
^ permalink raw reply related
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Tom Herbert @ 2017-01-16 21:06 UTC (permalink / raw)
To: Saeed Mahameed
Cc: David Miller, Saeed Mahameed, Doug Ledford, Linux Netdev List,
linux-rdma, Leon Romanovsky
In-Reply-To: <CALzJLG--ZRVk0Zy+6UaGCWbOhki+PZnkmrh9rjojU1ZDm_5Y6w@mail.gmail.com>
On Mon, Jan 16, 2017 at 12:30 PM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Sat, Jan 14, 2017 at 12:07 AM, Saeed Mahameed
> <saeedm@dev.mellanox.co.il> wrote:
>> On Fri, Jan 13, 2017 at 7:14 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Saeed Mahameed <saeedm@mellanox.com>
>>> 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
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
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.
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.
^ permalink raw reply
* Re: [PATCH] net: constify mdiobb_ops structures
From: Sergei Shtylyov @ 2017-01-16 20:48 UTC (permalink / raw)
To: Bhumika Goyal, julia.lawall, pantelis.antoniou, vbordug,
f.fainelli, netdev, linux-kernel, linuxppc-dev, linux-renesas-soc
In-Reply-To: <1484330546-16569-1-git-send-email-bhumirks@gmail.com>
Hello!
On 01/13/2017 09:02 PM, Bhumika Goyal wrote:
> Declare mdiobb_ops structures as const as they are only stored in the
> ops field of mdiobb_ctrl structures. This field is of type const, so
> mdiobb_ops structures having this property can be declared const too.
> Done using Coccinelle:
[...]
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
[...]
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 92d7692..1b0acd1 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -171,7 +171,7 @@ static int ravb_get_mdio_data(struct mdiobb_ctrl *ctrl)
> }
>
> /* MDIO bus control struct */
> -static struct mdiobb_ops bb_ops = {
> +static const struct mdiobb_ops bb_ops = {
> .owner = THIS_MODULE,
> .set_mdc = ravb_set_mdc,
> .set_mdio_dir = ravb_set_mdio_dir,
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index 00fafab..6ef5dd8 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -1052,7 +1052,7 @@ static void sh_mdc_ctrl(struct mdiobb_ctrl *ctrl, int bit)
> }
>
> /* mdio bus control struct */
> -static struct mdiobb_ops bb_ops = {
> +static const struct mdiobb_ops bb_ops = {
> .owner = THIS_MODULE,
> .set_mdc = sh_mdc_ctrl,
> .set_mdio_dir = sh_mmd_ctrl,
[...]
For the above 2 drivers:
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
From: Sergei Shtylyov @ 2017-01-16 20:41 UTC (permalink / raw)
To: Simon Horman; +Cc: David Miller, Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20170112131821.GA16060@verge.net.au>
Hello!
On 01/12/2017 04:18 PM, Simon Horman wrote:
> ...
>>>> Here, it stop once an untransmitted buffer is encountered...
>>>
>>> Yes, I see that now.
>>>
>>> I wonder if we should:
>>>
>>> a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
>>> (current behaviour) or all buffers (new behaviour).
>>> b) provide a different version of this loop in ravb_ring_free()
>>>
>>> What are your thoughts?
>>
>> I'm voting for (b).
After looking at this issue for another time, I'll vote for (a). Sorry for
back-and-forth on this matter -- I somehow thought we could do a better job by
scanning all the TX ring...
> Ok, something like this?
>
> @@ -215,6 +225,30 @@ static void ravb_ring_free(struct net_device *ndev, int q)
> }
>
> if (priv->tx_ring[q]) {
> + for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
> + struct ravb_tx_desc *desc;
> + int entry;
> +
> + entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
> + NUM_TX_DESC);
> + desc = &priv->tx_ring[q][entry];
> +
> + /* Free the original skb. */
> + if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
> + u32 size = le16_to_cpu(desc->ds_tagl) & TX_DS;
> +
> + dma_unmap_single(ndev->dev.parent,
> + le32_to_cpu(desc->dptr),
> + size, DMA_TO_DEVICE);
> + /* Last packet descriptor? */
> + if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
> + entry /= NUM_TX_DESC;
> + dev_kfree_skb_any(priv->tx_skb[q][entry]);
> + priv->tx_skb[q][entry] = NULL;
> + }
> + }
> + }
> +
This is only different from ravb_tx_free() by not stopping on unfinished
descriptor, so we must be good with adding an extra param to it...
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH V2] audit: log 32-bit socketcalls
From: Paul Moore @ 2017-01-16 20:38 UTC (permalink / raw)
To: David Miller; +Cc: rgb, netdev, linux-kernel, linux-audit
In-Reply-To: <20170116.132745.1831536278596554491.davem@davemloft.net>
On Mon, Jan 16, 2017 at 1:27 PM, David Miller <davem@davemloft.net> wrote:
> From: Richard Guy Briggs <rgb@redhat.com>
> Date: Fri, 13 Jan 2017 04:51:48 -0500
>
>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>> index 9d4443f..43d8003 100644
>> --- a/include/linux/audit.h
>> +++ b/include/linux/audit.h
>> @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs, unsigned long *args)
>> return __audit_socketcall(nargs, args);
>> return 0;
>> }
>> +static inline int audit_socketcall_compat(int nargs, u32 *args)
>> +{
>
> Please put an empty line between function definitions.
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 ...
>> + if (unlikely(!audit_dummy_context())) {
>> + int i;
>> + unsigned long a[AUDITSC_ARGS];
>
> Please order local variable declarations from longest to shortest line.
>
>> +
>> + for (i=0; i<nargs; i++)
>
> Please put a space around operators such as "=" and "<".
>
>> + a[i] = (unsigned long)args[i];
>> + return __audit_socketcall(nargs, a);
>> + }
>> + return 0;
>> +}
>> static inline int audit_sockaddr(int len, void *addr)
>
> Again, empty line between function definitions please.
>
>> @@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct compat_mmsghdr __user *, mmsg,
>>
>> COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
>> {
>> + unsigned int len;
>> int ret;
>> - u32 a[6];
>> + u32 a[AUDITSC_ARGS];
>> u32 a0, a1;
>
> Longest to shortest line for local variable declarations please.
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
^ permalink raw reply
* RE: [net-next 0/3] tipc: improve interaction socket-link
From: Jon Maloy @ 2017-01-16 20:35 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, viro@zeniv.linux.org.uk,
Parthasarathy Bhuvaragan, Ying Xue, maloy@donjonn.com,
tipc-discussion@lists.sourceforge.net
In-Reply-To: <20170116.144514.1071967219363714348.davem@davemloft.net>
> -----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?
///jon
^ 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