* [PATCH net-next v2 00/10] netvsc fixes and new features
From: Stephen Hemminger @ 2017-07-26 23:40 UTC (permalink / raw)
To: kys, haiyangz, sthemmin, corbet; +Cc: devel, linux-doc, netdev
This series has updates for Hyper-V network driver.
The first four patches are just minor fixes.
The next group of patches aims to reduce the driver memory footprint
by reducing the size of the per-device receive and send buffers, and
the per-channel receive completion queue.
The biggest change is in the last three patches that implement transparent
management of SR-IOV VF device. A little more explaination is required.
What does it do?
With the new netvsc VF logic, the Linux hyper-V network
virtual driver will directly manage the link to SR-IOV VF device.
When VF device is detected (hot plug) it is automatically made a
slave device of the netvsc device. The VF device state reflects
the state of the netvsc device; i.e. if netvsc is set down, then
VF is set down. If netvsc is set up, then VF is brought up.
Packet flow is independent of VF status; all packets are sent and
received as if they were associated with the netvsc device. If VF is
removed or link is down then the synthetic VMBUS path is used.
What was wrong with using bonding script?
A lot of work went into getting the bonding script to work on all
distributions, but it was a major struggle. Linux network devices
can be configured many, many ways and there is no one solution from
userspace to make it all work. What is really hard is when
configuration is attached to synthetic device during boot (eth0) and
then the same addresses and firewall rules needs to also work later if
doing bonding. The new code gets around all of this.
How does VF work during initialization?
Since all packets are sent and received through the logical netvsc
device, initialization is much easier. Just configure the regular
netvsc Ethernet device; when/if SR-IOV is enabled it just
works. Provisioning and cloud init only need to worry about setting up
netvsc device (eth0). If SR-IOV is enabled (even as a later step), the
address and rules stay the same.
What devices show up?
Both netvsc and PCI devices are visible in the system. The netvsc
device is active and named in usual manner (eth0). The PCI device is
visible to Linux and gets renamed by udev to a persistent name
(enP2p3s0). The PCI device name is now irrelevant now.
The logica also sets the PCI VF device SLAVE flag on the network
device so network tools can see the relationship if they are smart
enough to understand how layered devices work.
This is a lot like how I see Windows working.
The VF device is visible in Device Manager, but is not configured.
Is there any performance impact?
There is no visible change in performance. The bonding
and netvsc driver both have equivalent steps.
Is it compatible with old bonding script?
It turns out that if you use the old bonding script, then everything
still works but in a sub-optimum manner. What happens is that bonding
is unable to steal the VF from the netvsc device so it creates a one
legged bond. Packet flow then is:
bond0 <--> eth0 <- -> VF (enP2p3s0).
In other words, if you get it wrong it still works, just
awkward and slower.
What if I add address or firewall rule onto the VF?
Same problems occur with now as already occur with bonding, bridging,
teaming on Linux if user incorrectly does configuration onto
an underlying slave device. It will sort of work, packets will come in
and out but the Linux kernel gets confused and things like ARP don’t
work right. There is no way to block manipulation of the slave
device, and I am sure someone will find some special use case where
they want it.
Stephen Hemminger (10):
netvsc: fix return value for set_channels
netvsc: fix warnings reported by lockdep
netvsc: don't print pointer value in error message
netvsc: remove unnecessary indirection of page_buffer
netvsc: optimize receive completions
netvsc: signal host if receive ring is emptied
netvsc: allow smaller send/recv buffer size
netvsc: transparent VF management
netvsc: add documentation
netvsc: remove bonding setup script
Documentation/networking/netvsc.txt | 50 ++++
MAINTAINERS | 1 +
drivers/net/hyperv/hyperv_net.h | 33 ++-
drivers/net/hyperv/netvsc.c | 317 +++++++++++-------------
drivers/net/hyperv/netvsc_drv.c | 476 ++++++++++++++++++++++++++++--------
drivers/net/hyperv/rndis_filter.c | 108 ++++----
tools/hv/bondvf.sh | 255 -------------------
7 files changed, 642 insertions(+), 598 deletions(-)
create mode 100644 Documentation/networking/netvsc.txt
delete mode 100755 tools/hv/bondvf.sh
--
2.11.0
^ permalink raw reply
* Re: [net-next v4 0/5][pull request] 10GbE Intel Wired LAN Driver Updates 2017-07-25
From: David Miller @ 2017-07-26 23:36 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20170725234138.42283-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 25 Jul 2017 16:41:33 -0700
> This series contains updates to ixgbe only.
>
> Tony provides all of the changes in the series, starting with adding a
> check to ensure that adding a MAC filter was successful, before setting the
> MACVLAN. In order to receive notifications of link configurations of the
> external PHY and support the configuration of the internal iXFI link on
> X552 devices, Tony enables LASI interrupts. Update the iXFI driver code
> flow, since the MAC register NW_MNG_IF_SEL fields have been redefined for
> X553 devices, so add MAC checks for iXFI flows. Added additional checks
> for flow control autonegotiation, since it is not support for X553 fiber
> and XFI devices.
>
> v2: removed unnecessary parens noticed by David Miller in patch 6 of the
> series.
> v3: dropped patch 6 of the original series, while we work out a more
> generic solution for malicious driver detection (MDD) support.
> v4: updated patch 1 of the series with the comments from Joe Perches which
> were:
> - switched logic to return on error
> - return 0 on success
> - declare retval as an integer
...
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 10GbE
Pulled, thanks Jeff!
^ permalink raw reply
* Re: [PATCH] net: inet: diag: expose sockets cgroup classid
From: Levin, Alexander (Sasha Levin) @ 2017-07-26 22:59 UTC (permalink / raw)
To: Cong Wang
Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAM_iQpWJur_+hFZwj8bLa3bZwEd=aT5mWdhfapd5E9h9Q0HVUg@mail.gmail.com>
On Wed, Jul 26, 2017 at 03:01:32PM -0700, Cong Wang wrote:
>On Wed, Jul 26, 2017 at 10:22 AM, Levin, Alexander (Sasha Levin)
><alexander.levin@verizon.com> wrote:
>> + if (ext & (1 << (INET_DIAG_CLASS_ID - 1))) {
>> + u32 classid = 0;
>> +
>> +#ifdef CONFIG_SOCK_CGROUP_DATA
>> + classid = sock_cgroup_classid(&sk->sk_cgrp_data);
>> +#endif
>
>
>If CONFIG_SOCK_CGROUP_DATA is not enabled, should we put 0
>or put nothing (that is, skipping this nla_put())?
My logic was that if CONFIG_SOCK_CGROUP_DATA is disabled, then all sockets have the same default classid ==> 0, rather than having to deal with whether that config is enabled or not.
>> +
>> + nla_put(skb, INET_DIAG_CLASS_ID, sizeof(classid), &classid);
>
>nla_put_u32()
Will fix, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH RFC 02/13] net: phy: split out PHY speed and duplex string generation
From: Florian Fainelli @ 2017-07-26 22:37 UTC (permalink / raw)
To: Russell King, Andrew Lunn; +Cc: netdev
In-Reply-To: <E1da0Q6-0007Kv-Mc@rmk-PC.armlinux.org.uk>
On 07/25/2017 07:02 AM, Russell King wrote:
> Other code would like to make use of this, so make the speed and duplex
> string generation visible, and place it in a separate file.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH RFC 01/13] net: phy: allow settings table to support more than 32 link modes
From: Florian Fainelli @ 2017-07-26 22:36 UTC (permalink / raw)
To: Russell King, Andrew Lunn; +Cc: netdev
In-Reply-To: <E1da0Q1-0007Ko-Fu@rmk-PC.armlinux.org.uk>
On 07/25/2017 07:02 AM, Russell King wrote:
> Allow the phy settings table to support more than 32 link modes by
> switching to the ethtool link mode bit number representation, rather
> than storing the mask. This will allow phylink and other ethtool
> code to share the settings table to look up settings.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH RFC 07/13] net: phy: add I2C mdio bus
From: Florian Fainelli @ 2017-07-26 22:35 UTC (permalink / raw)
To: Russell King, Andrew Lunn; +Cc: netdev
In-Reply-To: <E1da0QW-0007Lg-BH@rmk-PC.armlinux.org.uk>
On 07/25/2017 07:03 AM, Russell King wrote:
> Add an I2C MDIO bus bridge library, to allow phylib to access PHYs which
> are connected to an I2C bus instead of the more conventional MDIO bus.
> Such PHYs can be found in SFP adapters and SFF modules.
>
> Since PHYs appear at I2C bus address 0x40..0x5f, and 0x50/0x51 are
> reserved for SFP EEPROMs/diagnostics, we must not allow the MDIO bus
> to access these I2C addresses.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH V2 net-next 20/21] net-next/hinic: Add ethtool and stats
From: Andrew Lunn @ 2017-07-26 22:33 UTC (permalink / raw)
To: Aviad Krawczyk
Cc: Joe Perches, davem, linux-kernel, netdev, bc.y, victor.gissin,
zhaochen6, tony.qu
In-Reply-To: <9df7d969-6706-d702-a674-9207f5b1c3df@huawei.com>
On Wed, Jul 19, 2017 at 03:36:28PM +0300, Aviad Krawczyk wrote:
> Hi Joe,
>
> I tried to be consistent with the comments before, that requested
> that we will use dev_err exclude some special cases for use netif.
>
> We will replace the dev_err(&netdev->dev,.. to netdev_err in the
> next fix.
netdev_err() should be used when possible. You just have to be careful
in the probe() function, before netdev exists and you get "(NULL
net_device):" or before it is registered and you get "(unnamed
net_device)" instead of "eth42" etc.
Andrew
^ permalink raw reply
* Re: [PATCH RFC 12/13] phylink: add in-band autonegotiation support for 10GBase-KR mode.
From: Andrew Lunn @ 2017-07-26 22:23 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1da0Qw-0007MI-20@rmk-PC.armlinux.org.uk>
On Tue, Jul 25, 2017 at 03:03:34PM +0100, Russell King wrote:
> Add in-band autonegotation support for 10GBase-KR mode.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [Patch net v2] team: use a larger struct for mac address
From: Cong Wang @ 2017-07-26 22:22 UTC (permalink / raw)
To: netdev; +Cc: andreyknvl, Cong Wang, Jiri Pirko
IPv6 tunnels use sizeof(struct in6_addr) as dev->addr_len,
but in many places especially bonding, we use struct sockaddr
to copy and set mac addr, this could lead to stack out-of-bounds
access.
Fix it by using a larger address storage like bonding.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
drivers/net/team/team.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 464570409796..ae53e899259f 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -60,11 +60,11 @@ static struct team_port *team_port_get_rtnl(const struct net_device *dev)
static int __set_port_dev_addr(struct net_device *port_dev,
const unsigned char *dev_addr)
{
- struct sockaddr addr;
+ struct sockaddr_storage addr;
- memcpy(addr.sa_data, dev_addr, port_dev->addr_len);
- addr.sa_family = port_dev->type;
- return dev_set_mac_address(port_dev, &addr);
+ memcpy(addr.__data, dev_addr, port_dev->addr_len);
+ addr.ss_family = port_dev->type;
+ return dev_set_mac_address(port_dev, (struct sockaddr *)&addr);
}
static int team_port_set_orig_dev_addr(struct team_port *port)
--
2.13.0
^ permalink raw reply related
* [Patch net v2] net: check dev->addr_len for dev_set_mac_address()
From: Cong Wang @ 2017-07-26 22:22 UTC (permalink / raw)
To: netdev; +Cc: andreyknvl, Cong Wang, Jiri Pirko
Historically, dev_ifsioc() uses struct sockaddr as mac
address definition, this is why dev_set_mac_address()
accepts a struct sockaddr pointer as input but now we
have various types of mac addresse whose lengths
are up to MAX_ADDR_LEN, longer than struct sockaddr,
and saved in dev->addr_len.
It is too late to fix dev_ifsioc() due to API
compatibility, so just reject those larger than
sizeof(struct sockaddr), otherwise we would read
and use some random bytes from kernel stack.
Fortunately, only a few IPv6 tunnel devices have addr_len
larger than sizeof(struct sockaddr) and they don't support
ndo_set_mac_addr(). But with team driver, in lb mode, they
can still be enslaved to a team master and make its mac addr
length as the same.
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/core/dev_ioctl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index 06b147d7d9e2..709a4e6fb447 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -263,6 +263,8 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
return dev_set_mtu(dev, ifr->ifr_mtu);
case SIOCSIFHWADDR:
+ if (dev->addr_len > sizeof(struct sockaddr))
+ return -EINVAL;
return dev_set_mac_address(dev, &ifr->ifr_hwaddr);
case SIOCSIFHWBROADCAST:
--
2.13.0
^ permalink raw reply related
* Re: [PATCH RFC 07/13] net: phy: add I2C mdio bus
From: Andrew Lunn @ 2017-07-26 22:22 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1da0QW-0007Lg-BH@rmk-PC.armlinux.org.uk>
On Tue, Jul 25, 2017 at 03:03:08PM +0100, Russell King wrote:
> Add an I2C MDIO bus bridge library, to allow phylib to access PHYs which
> are connected to an I2C bus instead of the more conventional MDIO bus.
> Such PHYs can be found in SFP adapters and SFF modules.
>
> Since PHYs appear at I2C bus address 0x40..0x5f, and 0x50/0x51 are
> reserved for SFP EEPROMs/diagnostics, we must not allow the MDIO bus
> to access these I2C addresses.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH RFC 03/13] net: phy: move phy_lookup_setting() and guts of phy_supported_speeds() to phy-core
From: Andrew Lunn @ 2017-07-26 22:21 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1da0QB-0007L2-Rk@rmk-PC.armlinux.org.uk>
On Tue, Jul 25, 2017 at 03:02:47PM +0100, Russell King wrote:
> phy_lookup_setting() provides useful functionality in ethtool code
> outside phylib. Move it to phy-core and allow it to be re-used (eg,
> in phylink) rather than duplicated elsewhere. Note that this supports
> the larger linkmode space.
>
> As we move the phy settings table, we also need to move the guts of
> phy_supported_speeds() as well.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v3 1/3] ptp: introduce ptp auxiliary worker
From: Grygorii Strashko @ 2017-07-26 22:11 UTC (permalink / raw)
To: David S. Miller, netdev, Richard Cochran
Cc: Sekhar Nori, linux-kernel, linux-omap, Wingman Kwok,
Ivan Khoronzhuk, John Stultz, Thomas Gleixner, Grygorii Strashko
In-Reply-To: <20170726221138.12986-1-grygorii.strashko@ti.com>
Many PTP drivers required to perform some asynchronous or periodic work,
like periodically handling PHC counter overflow or handle delayed timestamp
for RX/TX network packets. In most of the cases, such work is implemented
using workqueues. Unfortunately, Kernel workqueues might introduce
significant delay in work scheduling under high system load and on -RT,
which could cause misbehavior of PTP drivers due to internal counter
overflow, for example, and there is no way to tune its execution policy and
priority manually.
Hence, The kthread_worker can be used instead of workqueues, as it creates
separate named kthread for each worker and its its execution policy and
priority can be configured using chrt tool.
This problem was reported for two drivers TI CPSW CPTS and dp83640, so
instead of modifying each of these driver it was proposed to add PTP
auxiliary worker to the PHC subsystem [1].
The patch adds PTP auxiliary worker in PHC subsystem using kthread_worker
and kthread_delayed_work and introduces two new PHC subsystem APIs:
- long (*do_aux_work)(struct ptp_clock_info *ptp) callback in
ptp_clock_info structure, which driver should assign if it require to
perform asynchronous or periodic work. Driver should return the delay of
the PTP next auxiliary work scheduling time (>=0) or negative value in case
further scheduling is not required.
- int ptp_schedule_worker(struct ptp_clock *ptp, unsigned long delay) which
allows schedule PTP auxiliary work.
The name of kthread_worker thread corresponds PTP PHC device name "ptp%d".
[1] https://www.spinics.net/lists/netdev/msg445392.html
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/ptp/ptp_clock.c | 41 ++++++++++++++++++++++++++++++++++++++++
drivers/ptp/ptp_private.h | 3 +++
include/linux/ptp_clock_kernel.h | 20 ++++++++++++++++++++
3 files changed, 64 insertions(+)
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index b774357..899433c 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -28,6 +28,7 @@
#include <linux/slab.h>
#include <linux/syscalls.h>
#include <linux/uaccess.h>
+#include <uapi/linux/sched/types.h>
#include "ptp_private.h"
@@ -184,6 +185,19 @@ static void delete_ptp_clock(struct posix_clock *pc)
kfree(ptp);
}
+static void ptp_aux_kworker(struct kthread_work *work)
+{
+ struct ptp_clock *ptp = container_of(work, struct ptp_clock,
+ aux_work.work);
+ struct ptp_clock_info *info = ptp->info;
+ long delay;
+
+ delay = info->do_aux_work(info);
+
+ if (delay >= 0)
+ kthread_queue_delayed_work(ptp->kworker, &ptp->aux_work, delay);
+}
+
/* public interface */
struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
@@ -217,6 +231,19 @@ struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
mutex_init(&ptp->pincfg_mux);
init_waitqueue_head(&ptp->tsev_wq);
+ if (ptp->info->do_aux_work) {
+ char *worker_name = kasprintf(GFP_KERNEL, "ptp%d", ptp->index);
+
+ kthread_init_delayed_work(&ptp->aux_work, ptp_aux_kworker);
+ ptp->kworker = kthread_create_worker(0, worker_name ?
+ worker_name : info->name);
+ if (IS_ERR(ptp->kworker)) {
+ err = PTR_ERR(ptp->kworker);
+ pr_err("failed to create ptp aux_worker %d\n", err);
+ goto kworker_err;
+ }
+ }
+
err = ptp_populate_pin_groups(ptp);
if (err)
goto no_pin_groups;
@@ -259,6 +286,9 @@ struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
no_device:
ptp_cleanup_pin_groups(ptp);
no_pin_groups:
+ if (ptp->kworker)
+ kthread_destroy_worker(ptp->kworker);
+kworker_err:
mutex_destroy(&ptp->tsevq_mux);
mutex_destroy(&ptp->pincfg_mux);
ida_simple_remove(&ptp_clocks_map, index);
@@ -274,6 +304,11 @@ int ptp_clock_unregister(struct ptp_clock *ptp)
ptp->defunct = 1;
wake_up_interruptible(&ptp->tsev_wq);
+ if (ptp->kworker) {
+ kthread_cancel_delayed_work_sync(&ptp->aux_work);
+ kthread_destroy_worker(ptp->kworker);
+ }
+
/* Release the clock's resources. */
if (ptp->pps_source)
pps_unregister_source(ptp->pps_source);
@@ -339,6 +374,12 @@ int ptp_find_pin(struct ptp_clock *ptp,
}
EXPORT_SYMBOL(ptp_find_pin);
+int ptp_schedule_worker(struct ptp_clock *ptp, unsigned long delay)
+{
+ return kthread_mod_delayed_work(ptp->kworker, &ptp->aux_work, delay);
+}
+EXPORT_SYMBOL(ptp_schedule_worker);
+
/* module operations */
static void __exit ptp_exit(void)
diff --git a/drivers/ptp/ptp_private.h b/drivers/ptp/ptp_private.h
index d958889..b86f1bf 100644
--- a/drivers/ptp/ptp_private.h
+++ b/drivers/ptp/ptp_private.h
@@ -22,6 +22,7 @@
#include <linux/cdev.h>
#include <linux/device.h>
+#include <linux/kthread.h>
#include <linux/mutex.h>
#include <linux/posix-clock.h>
#include <linux/ptp_clock.h>
@@ -56,6 +57,8 @@ struct ptp_clock {
struct attribute_group pin_attr_group;
/* 1st entry is a pointer to the real group, 2nd is NULL terminator */
const struct attribute_group *pin_attr_groups[2];
+ struct kthread_worker *kworker;
+ struct kthread_delayed_work aux_work;
};
/*
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index a026bfd..51349d1 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -99,6 +99,11 @@ struct system_device_crosststamp;
* parameter func: the desired function to use.
* parameter chan: the function channel index to use.
*
+ * @do_work: Request driver to perform auxiliary (periodic) operations
+ * Driver should return delay of the next auxiliary work scheduling
+ * time (>=0) or negative value in case further scheduling
+ * is not required.
+ *
* Drivers should embed their ptp_clock_info within a private
* structure, obtaining a reference to it using container_of().
*
@@ -126,6 +131,7 @@ struct ptp_clock_info {
struct ptp_clock_request *request, int on);
int (*verify)(struct ptp_clock_info *ptp, unsigned int pin,
enum ptp_pin_function func, unsigned int chan);
+ long (*do_aux_work)(struct ptp_clock_info *ptp);
};
struct ptp_clock;
@@ -211,6 +217,16 @@ extern int ptp_clock_index(struct ptp_clock *ptp);
int ptp_find_pin(struct ptp_clock *ptp,
enum ptp_pin_function func, unsigned int chan);
+/**
+ * ptp_schedule_worker() - schedule ptp auxiliary work
+ *
+ * @ptp: The clock obtained from ptp_clock_register().
+ * @delay: number of jiffies to wait before queuing
+ * See kthread_queue_delayed_work() for more info.
+ */
+
+int ptp_schedule_worker(struct ptp_clock *ptp, unsigned long delay);
+
#else
static inline struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
struct device *parent)
@@ -225,6 +241,10 @@ static inline int ptp_clock_index(struct ptp_clock *ptp)
static inline int ptp_find_pin(struct ptp_clock *ptp,
enum ptp_pin_function func, unsigned int chan)
{ return -1; }
+static inline int ptp_schedule_worker(struct ptp_clock *ptp,
+ unsigned long delay)
+{ return -EOPNOTSUPP; }
+
#endif
#endif
--
2.10.1
^ permalink raw reply related
* [PATCH v3 3/3] net: ethernet: ti: cpts: fix tx timestamping timeout
From: Grygorii Strashko @ 2017-07-26 22:11 UTC (permalink / raw)
To: David S. Miller, netdev, Richard Cochran
Cc: Sekhar Nori, linux-kernel, linux-omap, Wingman Kwok,
Ivan Khoronzhuk, John Stultz, Thomas Gleixner, Grygorii Strashko
In-Reply-To: <20170726221138.12986-1-grygorii.strashko@ti.com>
With the low speed Ethernet connection CPDMA notification about packet
processing can be received before CPTS TX timestamp event, which is set
when packet actually left CPSW while cpdma notification is sent when packet
pushed in CPSW fifo. As result, when connection is slow and CPU is fast
enough TX timestamping is not working properly.
Fix it, by introducing TX SKB queue to store PTP SKBs for which Ethernet
Transmit Event hasn't been received yet and then re-check this queue
with new Ethernet Transmit Events by scheduling CPTS overflow
work more often (every 1 jiffies) until TX SKB queue is not empty.
Side effect of this change is:
- User space tools require to take into account possible delay in TX
timestamp processing (for example ptp4l works with tx_timestamp_timeout=400
under net traffic and tx_timestamp_timeout=25 in idle).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/net/ethernet/ti/cpts.c | 86 ++++++++++++++++++++++++++++++++++++++++--
drivers/net/ethernet/ti/cpts.h | 1 +
2 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 3ed438e..c2121d2 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -31,9 +31,18 @@
#include "cpts.h"
+#define CPTS_SKB_TX_WORK_TIMEOUT 1 /* jiffies */
+
+struct cpts_skb_cb_data {
+ unsigned long tmo;
+};
+
#define cpts_read32(c, r) readl_relaxed(&c->reg->r)
#define cpts_write32(c, v, r) writel_relaxed(v, &c->reg->r)
+static int cpts_match(struct sk_buff *skb, unsigned int ptp_class,
+ u16 ts_seqid, u8 ts_msgtype);
+
static int event_expired(struct cpts_event *event)
{
return time_after(jiffies, event->tmo);
@@ -77,6 +86,47 @@ static int cpts_purge_events(struct cpts *cpts)
return removed ? 0 : -1;
}
+static bool cpts_match_tx_ts(struct cpts *cpts, struct cpts_event *event)
+{
+ struct sk_buff *skb, *tmp;
+ u16 seqid;
+ u8 mtype;
+ bool found = false;
+
+ mtype = (event->high >> MESSAGE_TYPE_SHIFT) & MESSAGE_TYPE_MASK;
+ seqid = (event->high >> SEQUENCE_ID_SHIFT) & SEQUENCE_ID_MASK;
+
+ /* no need to grab txq.lock as access is always done under cpts->lock */
+ skb_queue_walk_safe(&cpts->txq, skb, tmp) {
+ struct skb_shared_hwtstamps ssh;
+ unsigned int class = ptp_classify_raw(skb);
+ struct cpts_skb_cb_data *skb_cb =
+ (struct cpts_skb_cb_data *)skb->cb;
+
+ if (cpts_match(skb, class, seqid, mtype)) {
+ u64 ns = timecounter_cyc2time(&cpts->tc, event->low);
+
+ memset(&ssh, 0, sizeof(ssh));
+ ssh.hwtstamp = ns_to_ktime(ns);
+ skb_tstamp_tx(skb, &ssh);
+ found = true;
+ __skb_unlink(skb, &cpts->txq);
+ dev_consume_skb_any(skb);
+ dev_dbg(cpts->dev, "match tx timestamp mtype %u seqid %04x\n",
+ mtype, seqid);
+ } else if (time_after(jiffies, skb_cb->tmo)) {
+ /* timeout any expired skbs over 1s */
+ dev_dbg(cpts->dev,
+ "expiring tx timestamp mtype %u seqid %04x\n",
+ mtype, seqid);
+ __skb_unlink(skb, &cpts->txq);
+ dev_consume_skb_any(skb);
+ }
+ }
+
+ return found;
+}
+
/*
* Returns zero if matching event type was found.
*/
@@ -101,9 +151,15 @@ static int cpts_fifo_read(struct cpts *cpts, int match)
event->low = lo;
type = event_type(event);
switch (type) {
+ case CPTS_EV_TX:
+ if (cpts_match_tx_ts(cpts, event)) {
+ /* if the new event matches an existing skb,
+ * then don't queue it
+ */
+ break;
+ }
case CPTS_EV_PUSH:
case CPTS_EV_RX:
- case CPTS_EV_TX:
list_del_init(&event->list);
list_add_tail(&event->list, &cpts->events);
break;
@@ -229,8 +285,15 @@ static long cpts_overflow_check(struct ptp_clock_info *ptp)
struct cpts *cpts = container_of(ptp, struct cpts, info);
unsigned long delay = cpts->ov_check_period;
struct timespec64 ts;
+ unsigned long flags;
+
+ spin_lock_irqsave(&cpts->lock, flags);
+ ts = ns_to_timespec64(timecounter_read(&cpts->tc));
+
+ if (!skb_queue_empty(&cpts->txq))
+ delay = CPTS_SKB_TX_WORK_TIMEOUT;
+ spin_unlock_irqrestore(&cpts->lock, flags);
- cpts_ptp_gettime(&cpts->info, &ts);
pr_debug("cpts overflow check at %lld.%09lu\n", ts.tv_sec, ts.tv_nsec);
return (long)delay;
}
@@ -301,7 +364,7 @@ static u64 cpts_find_ts(struct cpts *cpts, struct sk_buff *skb, int ev_type)
return 0;
spin_lock_irqsave(&cpts->lock, flags);
- cpts_fifo_read(cpts, CPTS_EV_PUSH);
+ cpts_fifo_read(cpts, -1);
list_for_each_safe(this, next, &cpts->events) {
event = list_entry(this, struct cpts_event, list);
if (event_expired(event)) {
@@ -319,6 +382,19 @@ static u64 cpts_find_ts(struct cpts *cpts, struct sk_buff *skb, int ev_type)
break;
}
}
+
+ if (ev_type == CPTS_EV_TX && !ns) {
+ struct cpts_skb_cb_data *skb_cb =
+ (struct cpts_skb_cb_data *)skb->cb;
+ /* Not found, add frame to queue for processing later.
+ * The periodic FIFO check will handle this.
+ */
+ skb_get(skb);
+ /* get the timestamp for timeouts */
+ skb_cb->tmo = jiffies + msecs_to_jiffies(100);
+ __skb_queue_tail(&cpts->txq, skb);
+ ptp_schedule_worker(cpts->clock, 0);
+ }
spin_unlock_irqrestore(&cpts->lock, flags);
return ns;
@@ -360,6 +436,7 @@ int cpts_register(struct cpts *cpts)
{
int err, i;
+ skb_queue_head_init(&cpts->txq);
INIT_LIST_HEAD(&cpts->events);
INIT_LIST_HEAD(&cpts->pool);
for (i = 0; i < CPTS_MAX_EVENTS; i++)
@@ -400,6 +477,9 @@ void cpts_unregister(struct cpts *cpts)
cpts_write32(cpts, 0, int_enable);
cpts_write32(cpts, 0, control);
+ /* Drop all packet */
+ skb_queue_purge(&cpts->txq);
+
clk_disable(cpts->refclk);
}
EXPORT_SYMBOL_GPL(cpts_unregister);
diff --git a/drivers/net/ethernet/ti/cpts.h b/drivers/net/ethernet/ti/cpts.h
index 586edd9..73d73fa 100644
--- a/drivers/net/ethernet/ti/cpts.h
+++ b/drivers/net/ethernet/ti/cpts.h
@@ -125,6 +125,7 @@ struct cpts {
struct list_head pool;
struct cpts_event pool_data[CPTS_MAX_EVENTS];
unsigned long ov_check_period;
+ struct sk_buff_head txq;
};
void cpts_rx_timestamp(struct cpts *cpts, struct sk_buff *skb);
--
2.10.1
^ permalink raw reply related
* [PATCH v4 2/3] net: ethernet: ti: cpts: convert to use ptp auxiliary worker
From: Grygorii Strashko @ 2017-07-26 22:11 UTC (permalink / raw)
To: David S. Miller, netdev, Richard Cochran
Cc: Sekhar Nori, linux-kernel, linux-omap, Wingman Kwok,
Ivan Khoronzhuk, John Stultz, Thomas Gleixner, Grygorii Strashko
In-Reply-To: <20170726221138.12986-1-grygorii.strashko@ti.com>
There could be significant delay in CPTS work schedule under high system
load and on -RT which could cause CPTS misbehavior due to internal counter
overflow. Usage of own kthread_worker allows to avoid such kind of issues
and makes it possible to tune priority of CPTS kthread_worker thread on -RT.
Hence, the CPTS driver is converted to use PTP auxiliary worker as PHC
subsystem implements such functionality in a generic way now.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/net/ethernet/ti/cpts.c | 27 +++++++++++++--------------
drivers/net/ethernet/ti/cpts.h | 1 -
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 32279d2..3ed438e 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -224,6 +224,17 @@ static int cpts_ptp_enable(struct ptp_clock_info *ptp,
return -EOPNOTSUPP;
}
+static long cpts_overflow_check(struct ptp_clock_info *ptp)
+{
+ struct cpts *cpts = container_of(ptp, struct cpts, info);
+ unsigned long delay = cpts->ov_check_period;
+ struct timespec64 ts;
+
+ cpts_ptp_gettime(&cpts->info, &ts);
+ pr_debug("cpts overflow check at %lld.%09lu\n", ts.tv_sec, ts.tv_nsec);
+ return (long)delay;
+}
+
static struct ptp_clock_info cpts_info = {
.owner = THIS_MODULE,
.name = "CTPS timer",
@@ -236,18 +247,9 @@ static struct ptp_clock_info cpts_info = {
.gettime64 = cpts_ptp_gettime,
.settime64 = cpts_ptp_settime,
.enable = cpts_ptp_enable,
+ .do_aux_work = cpts_overflow_check,
};
-static void cpts_overflow_check(struct work_struct *work)
-{
- struct timespec64 ts;
- struct cpts *cpts = container_of(work, struct cpts, overflow_work.work);
-
- cpts_ptp_gettime(&cpts->info, &ts);
- pr_debug("cpts overflow check at %lld.%09lu\n", ts.tv_sec, ts.tv_nsec);
- schedule_delayed_work(&cpts->overflow_work, cpts->ov_check_period);
-}
-
static int cpts_match(struct sk_buff *skb, unsigned int ptp_class,
u16 ts_seqid, u8 ts_msgtype)
{
@@ -378,7 +380,7 @@ int cpts_register(struct cpts *cpts)
}
cpts->phc_index = ptp_clock_index(cpts->clock);
- schedule_delayed_work(&cpts->overflow_work, cpts->ov_check_period);
+ ptp_schedule_worker(cpts->clock, cpts->ov_check_period);
return 0;
err_ptp:
@@ -392,8 +394,6 @@ void cpts_unregister(struct cpts *cpts)
if (WARN_ON(!cpts->clock))
return;
- cancel_delayed_work_sync(&cpts->overflow_work);
-
ptp_clock_unregister(cpts->clock);
cpts->clock = NULL;
@@ -476,7 +476,6 @@ struct cpts *cpts_create(struct device *dev, void __iomem *regs,
cpts->dev = dev;
cpts->reg = (struct cpsw_cpts __iomem *)regs;
spin_lock_init(&cpts->lock);
- INIT_DELAYED_WORK(&cpts->overflow_work, cpts_overflow_check);
ret = cpts_of_parse(cpts, node);
if (ret)
diff --git a/drivers/net/ethernet/ti/cpts.h b/drivers/net/ethernet/ti/cpts.h
index 01ea82b..586edd9 100644
--- a/drivers/net/ethernet/ti/cpts.h
+++ b/drivers/net/ethernet/ti/cpts.h
@@ -119,7 +119,6 @@ struct cpts {
u32 cc_mult; /* for the nominal frequency */
struct cyclecounter cc;
struct timecounter tc;
- struct delayed_work overflow_work;
int phc_index;
struct clk *refclk;
struct list_head events;
--
2.10.1
^ permalink raw reply related
* [PATCH v3 0/3] net: ethernet: ti: cpts: fix tx timestamping timeout
From: Grygorii Strashko @ 2017-07-26 22:11 UTC (permalink / raw)
To: David S. Miller, netdev, Richard Cochran
Cc: Sekhar Nori, linux-kernel, linux-omap, Wingman Kwok,
Ivan Khoronzhuk, John Stultz, Thomas Gleixner, Grygorii Strashko
Hi
With the low Ethernet connection speed cpdma notification about packet
processing can be received before CPTS TX timestamp event, which is set
when packet actually left CPSW while cpdma notification is sent when packet
pushed in CPSW fifo. As result, when connection is slow and CPU is fast
enough TX timestamping is not working properly.
Issue was discovered using timestamping tool on am57x boards with Ethernet link
speed forced to 100M and on am335x-evm with Ethernet link speed forced to 10M.
Patch3 - This series fixes it by introducing TX SKB queue to store PTP SKBs for
which Ethernet Transmit Event hasn't been received yet and then re-check this
queue with new Ethernet Transmit Events by scheduling CPTS overflow
work more often until TX SKB queue is not empty.
Patch 1,2 - As CPTS overflow work is time critical task it important to ensure
that its scheduling is not delayed. Unfortunately, There could be significant
delay in CPTS work schedule under high system load and on -RT which could cause
CPTS misbehavior due to internal counter overflow and there is no way to tune
CPTS overflow work execution policy and priority manually. The kthread_worker
can be used instead of workqueues, as it creates separate named kthread for
each worker and its its execution policy and priority can be configured
using chrt tool. Instead of modifying CPTS driver itself it was proposed to
it was proposed to add PTP auxiliary worker to the PHC subsystem [1], so
other drivers can benefit from this feature also.
[1] https://www.spinics.net/lists/netdev/msg445392.html
changes in v3:
- patch 1: added proper error handling in ptp_clock_register.
minor comments applied.
changes in v2:
- added PTP auxiliary worker to the PHC subsystem
Links
v2: https://www.spinics.net/lists/netdev/msg445859.html
v1: https://www.spinics.net/lists/netdev/msg445387.html
Grygorii Strashko (3):
ptp: introduce ptp auxiliary worker
net: ethernet: ti: cpts: convert to use ptp auxiliary worker
net: ethernet: ti: cpts: fix tx timestamping timeout
drivers/net/ethernet/ti/cpts.c | 111 +++++++++++++++++++++++++++++++++------
drivers/net/ethernet/ti/cpts.h | 2 +-
drivers/ptp/ptp_clock.c | 41 +++++++++++++++
drivers/ptp/ptp_private.h | 3 ++
include/linux/ptp_clock_kernel.h | 20 +++++++
5 files changed, 160 insertions(+), 17 deletions(-)
--
2.10.1
^ permalink raw reply
* Re: [PATCH] net: inet: diag: expose sockets cgroup classid
From: Cong Wang @ 2017-07-26 22:01 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin)
Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170726172153.23436-1-alexander.levin@verizon.com>
On Wed, Jul 26, 2017 at 10:22 AM, Levin, Alexander (Sasha Levin)
<alexander.levin@verizon.com> wrote:
> + if (ext & (1 << (INET_DIAG_CLASS_ID - 1))) {
> + u32 classid = 0;
> +
> +#ifdef CONFIG_SOCK_CGROUP_DATA
> + classid = sock_cgroup_classid(&sk->sk_cgrp_data);
> +#endif
If CONFIG_SOCK_CGROUP_DATA is not enabled, should we put 0
or put nothing (that is, skipping this nla_put())?
> +
> + nla_put(skb, INET_DIAG_CLASS_ID, sizeof(classid), &classid);
nla_put_u32()
Thanks.
^ permalink raw reply
* Re: [PATCH RFC 04/13] net: phy: add 1000Base-X to phy settings table
From: Andrew Lunn @ 2017-07-26 21:52 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1da0QG-0007LL-Vj@rmk-PC.armlinux.org.uk>
On Tue, Jul 25, 2017 at 03:02:52PM +0100, Russell King wrote:
> Add the missing 1000Base-X entry to the phy settings table. This was
> not included because the original code could not cope with more than
> 32 bits of link mode mask.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Hi Russell
Looks like there are another 15 to add to the table. But that can wait
for another time when somebody needs them.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH RFC 02/13] net: phy: split out PHY speed and duplex string generation
From: Andrew Lunn @ 2017-07-26 21:48 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1da0Q6-0007Kv-Mc@rmk-PC.armlinux.org.uk>
On Tue, Jul 25, 2017 at 03:02:42PM +0100, Russell King wrote:
> Other code would like to make use of this, so make the speed and duplex
> string generation visible, and place it in a separate file.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: dsa: lan9303: Fixed MDIO interface
From: Andrew Lunn @ 2017-07-26 21:39 UTC (permalink / raw)
To: Egil Hjelmeland
Cc: David Miller, vivien.didelot, corbet, f.fainelli, kernel,
linux-doc, linux-kernel, netdev
In-Reply-To: <7a0d712b-1626-a4e5-e366-a626bdafc6cf@egil-hjelmeland.no>
> Good. Just one question about process. Could I have posted my work
> as a RFC? To get one round of initial feedback before chopping into
> small patch requests. As well as indicating where I am heading. Or is
> that just waste of human bandwidth?
Depends. Post 100 RFC patches, i won't look at them. Post 21 with a
cover note making it clear you are planning to submit them in blocks
of 7, i might.
But it is best to assume reviewers have small blocks of time. 21
patches take 3 times a long to review as 7. The block of time might
not be enough for 21, so the review gets differed. 7 are more likely
to fit in the available time, so it happens quickly.
Andrew
^ permalink raw reply
* Re: [PATCH] netpoll: Fix device name check in netpoll_setup()
From: Cong Wang @ 2017-07-26 20:52 UTC (permalink / raw)
To: Doug Anderson
Cc: Matthias Kaehlcke, David S . Miller,
Linux Kernel Network Developers, linux-kernel@vger.kernel.org
In-Reply-To: <CAD=FV=WiS3m=dr5VrhiOPiqVL4Rb53jfEambq79GtPffiYO-Pg@mail.gmail.com>
On Wed, Jul 26, 2017 at 11:44 AM, Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Tue, Jul 25, 2017 at 11:36 AM, Matthias Kaehlcke <mka@chromium.org> wrote:
>> Apparently netpoll_setup() assumes that netpoll.dev_name is a pointer
>> when checking if the device name is set:
>>
>> if (np->dev_name) {
>> ...
>>
>> However the field is a character array, therefore the condition always
>> yields true. Check instead whether the first byte of the array has a
>> non-zero value.
>>
>> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
>> ---
>> net/core/netpoll.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
>> index 8357f164c660..912731bed7b7 100644
>> --- a/net/core/netpoll.c
>> +++ b/net/core/netpoll.c
>> @@ -666,7 +666,7 @@ int netpoll_setup(struct netpoll *np)
>> int err;
>>
>> rtnl_lock();
>> - if (np->dev_name) {
>> + if (np->dev_name[0]) {
>> struct net *net = current->nsproxy->net_ns;
>> ndev = __dev_get_by_name(net, np->dev_name);
>> }
>
> It's really up to the maintainer of the code, but my first instinct
> here would be to instead remove the "if" test unless we really expect
> dev->dev_name to be blank in lots of cases. It will slightly slow
> down the error case but should avoid an "if" test in the non-error
> case. By definition it should be safe since currently the "if" test
> should always evaluate to true.
>
netconsole could set this dev_name to empty via configfs,
so this patch is correct.
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: dsa: lan9303: Fixed MDIO interface
From: Egil Hjelmeland @ 2017-07-26 20:47 UTC (permalink / raw)
To: David Miller, andrew
Cc: vivien.didelot, corbet, f.fainelli, kernel, linux-doc,
linux-kernel, netdev
In-Reply-To: <20170726.130747.9593997952509805.davem@davemloft.net>
Den 26. juli 2017 22:07, skrev David Miller:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Wed, 26 Jul 2017 19:52:24 +0200
>
>>>> So I really want to group the patches into only a few series in order
>>>> to not spend months on the process.
>>
>> I strongly agree with Vivien here. Good patches get accepted in about
>> 3 days. You should expect feedback within a day or two. That allows
>> you to have fast cycle times for getting patches in.
>
> +1
>
> Small simple patches will get everything in 10 times fast than if
> you clump everything together into larger, harder to review ones.
>
Good. Just one question about process. Could I have posted my work
as a RFC? To get one round of initial feedback before chopping into
small patch requests. As well as indicating where I am heading. Or is
that just waste of human bandwidth?
Egil
^ permalink raw reply
* Re: [PATCH net-next v2] bpf: install libbpf headers on 'make install'
From: David Miller @ 2017-07-26 20:43 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, daniel, oss-drivers, alexei.starovoitov
In-Reply-To: <20170725181711.21236-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 25 Jul 2017 11:17:11 -0700
> Add a new target to install the bpf.h header to $(prefix)/include/bpf/
> directory. This is necessary to build standalone applications using
> libbpf, without the need to clone the kernel sources and point to them.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied, thank you.
^ permalink raw reply
* Re: [Patch net] bonding: commit link status change after propose
From: David Miller @ 2017-07-26 20:43 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, benjamin.gilbert, maheshb
In-Reply-To: <20170725164425.9112-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 25 Jul 2017 09:44:25 -0700
> Commit de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring")
> moves link status commitment into bond_mii_monitor(), but it still relies
> on the return value of bond_miimon_inspect() as the hint. We need to return
> non-zero as long as we propose a link status change.
>
> Fixes: de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring")
> Reported-by: Benjamin Gilbert <benjamin.gilbert@coreos.com>
> Tested-by: Benjamin Gilbert <benjamin.gilbert@coreos.com>
> Cc: Mahesh Bandewar <maheshb@google.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 0/8] net: mvpp2: add TX interrupts support
From: David Miller @ 2017-07-26 20:35 UTC (permalink / raw)
To: thomas.petazzoni
Cc: netdev, linux, antoine.tenart, miquel.raynal, linux-arm-kernel,
jason, andrew, sebastian.hesselbarth, gregory.clement, nadavh,
hannah, yehuday, stefanc, mw
In-Reply-To: <20170725155509.10574-1-thomas.petazzoni@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Tue, 25 Jul 2017 17:55:01 +0200
> Hello,
>
> So far, the mvpp2 driver was using an hrtimer to handle TX
> completion. This patch series adds support for using TX interrupts
> (for each CPU) on PPv2.2, the variant of the IP used on Marvell Armada
> 7K/8K.
>
> This series has been tested on Marvell Armada 7K (PPv2.2) and Armada
> 375 (PPv2.1).
>
> Dave:
>
> - This series depends on the previous series sent by Antoine Ténart
> "net: mvpp2: MAC/GoP configuration and optional PHYs". Functionally
> speaking there is no real dependency, but we touch in a few areas
> the same piece of code, so I based my patch series on top of
> Antoine's.
>
> - Please do not apply the last patch of this series "arm64: dts:
> marvell: add TX interrupts for PPv2.2", it will be taken by the ARM
> mvebu maintainers.
Please don't do things this way.
Patiently wait for Antione's series to make it into my tree, then
submit your's.
Also, if we're continually going to elide the DTS file patches, just
don't bother adding them to the series. That way you don't have to
give me special instructions, and I don't have the possibility of
making a mistake and applying it accidently.
Thanks.
^ 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