* Re: [PATCHv3 1/2] net: stmmac: Add SOCFPGA glue driver
From: David Miller @ 2014-02-13 4:47 UTC (permalink / raw)
To: dinh.linux
Cc: dinguyen, netdev, devicetree, peppe.cavallaro, robh+dt,
pawel.moll, mark.rutland, ijc+devicetree, galak, vbridgers2013
In-Reply-To: <52FC4B0A.4010406@gmail.com>
From: Dinh Nguyen <dinh.linux@gmail.com>
Date: Wed, 12 Feb 2014 22:33:14 -0600
> On 2/12/14 6:35 PM, David Miller wrote:
>> From: <dinguyen@altera.com>
>> Date: Mon, 10 Feb 2014 13:48:16 -0600
>> Why don't you push both of these patches through whatever tree that
>> file is maintained under. You can add my ack:
> I'm not sure if Peppe has a tree, but it should go into his tree
> if there is one. If not, can you apply patch 1 to your tree?
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
You're going to have to send patch #2 somewhere, so for the second
time I'm going to ask you to please send #1 to the same place.
Thanks.
^ permalink raw reply
* [PATCH net-next] net: remove unnecessary return's
From: Stephen Hemminger @ 2014-02-13 4:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
One of my pet coding style peeves is the practice of
adding extra return; at the end of function.
Kill several instances of this in network code.
I suppose some coccinelle wizardy could do this automatically.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
net/batman-adv/gateway_client.c | 2 --
net/ceph/osd_client.c | 2 --
net/core/request_sock.c | 1 -
net/ipv4/route.c | 1 -
net/ipv4/tcp_output.c | 1 -
net/l2tp/l2tp_core.c | 2 --
net/l2tp/l2tp_ppp.c | 3 ---
net/mac802154/mib.c | 4 ----
net/mac802154/rx.c | 1 -
net/sctp/transport.c | 1 -
net/wireless/chan.c | 2 --
11 files changed, 20 deletions(-)
--- a/net/core/request_sock.c 2014-02-12 08:21:56.742857227 -0800
+++ b/net/core/request_sock.c 2014-02-12 20:42:04.914745631 -0800
@@ -221,5 +221,4 @@ void reqsk_fastopen_remove(struct sock *
out:
spin_unlock_bh(&fastopenq->lock);
sock_put(lsk);
- return;
}
--- a/net/ipv4/route.c 2014-02-12 08:21:56.764856910 -0800
+++ b/net/ipv4/route.c 2014-02-12 20:42:26.498457902 -0800
@@ -697,7 +697,6 @@ static void update_or_create_fnhe(struct
out_unlock:
spin_unlock_bh(&fnhe_lock);
- return;
}
static void __ip_do_redirect(struct rtable *rt, struct sk_buff *skb, struct flowi4 *fl4,
--- a/net/ipv4/tcp_output.c 2014-02-12 08:21:56.768856853 -0800
+++ b/net/ipv4/tcp_output.c 2014-02-12 20:42:46.905185882 -0800
@@ -2071,7 +2071,6 @@ rearm_timer:
if (likely(!err))
NET_INC_STATS_BH(sock_net(sk),
LINUX_MIB_TCPLOSSPROBES);
- return;
}
/* Push out any pending frames which were held back due to
--- a/net/l2tp/l2tp_core.c 2014-02-12 08:21:56.787856580 -0800
+++ b/net/l2tp/l2tp_core.c 2014-02-12 20:43:53.049304122 -0800
@@ -1809,8 +1809,6 @@ void l2tp_session_free(struct l2tp_sessi
}
kfree(session);
-
- return;
}
EXPORT_SYMBOL_GPL(l2tp_session_free);
--- a/net/sctp/transport.c 2014-02-12 08:21:56.848855704 -0800
+++ b/net/sctp/transport.c 2014-02-12 20:41:15.051410364 -0800
@@ -652,5 +652,4 @@ void sctp_transport_immediate_rtx(struct
if (!mod_timer(&t->T3_rtx_timer, jiffies + t->rto))
sctp_transport_hold(t);
}
- return;
}
--- a/net/wireless/chan.c 2014-02-12 08:21:56.864855473 -0800
+++ b/net/wireless/chan.c 2014-02-12 20:44:22.519911266 -0800
@@ -701,6 +701,4 @@ cfg80211_get_chan_state(struct wireless_
case NUM_NL80211_IFTYPES:
WARN_ON(1);
}
-
- return;
}
--- a/net/batman-adv/gateway_client.c 2014-02-12 08:21:56.723857500 -0800
+++ b/net/batman-adv/gateway_client.c 2014-02-12 20:45:16.790187817 -0800
@@ -389,8 +389,6 @@ out:
batadv_neigh_ifinfo_free_ref(router_gw_tq);
if (router_orig_tq)
batadv_neigh_ifinfo_free_ref(router_orig_tq);
-
- return;
}
/**
--- a/net/ceph/osd_client.c 2014-02-12 08:21:56.738857284 -0800
+++ b/net/ceph/osd_client.c 2014-02-12 20:47:00.116810485 -0800
@@ -2082,7 +2082,6 @@ bad:
pr_err("osdc handle_map corrupt msg\n");
ceph_msg_dump(msg);
up_write(&osdc->map_sem);
- return;
}
/*
@@ -2281,7 +2280,6 @@ done_err:
bad:
pr_err("osdc handle_watch_notify corrupt msg\n");
- return;
}
/*
--- a/net/l2tp/l2tp_ppp.c 2014-02-12 08:21:56.788856566 -0800
+++ b/net/l2tp/l2tp_ppp.c 2014-02-12 20:47:27.828441095 -0800
@@ -454,13 +454,11 @@ static void pppol2tp_session_close(struc
BUG_ON(session->magic != L2TP_SESSION_MAGIC);
-
if (sock) {
inet_shutdown(sock, 2);
/* Don't let the session go away before our socket does */
l2tp_session_inc_refcount(session);
}
- return;
}
/* Really kill the session socket. (Called from sock_put() if
@@ -474,7 +472,6 @@ static void pppol2tp_session_destruct(st
BUG_ON(session->magic != L2TP_SESSION_MAGIC);
l2tp_session_dec_refcount(session);
}
- return;
}
/* Called when the PPPoX socket (session) is closed.
--- a/net/mac802154/mib.c 2014-02-12 08:21:56.801856379 -0800
+++ b/net/mac802154/mib.c 2014-02-12 20:46:11.533458098 -0800
@@ -62,8 +62,6 @@ static void hw_addr_notify(struct work_s
pr_debug("failed changed mask %lx\n", nw->changed);
kfree(nw);
-
- return;
}
static void set_hw_addr_filt(struct net_device *dev, unsigned long changed)
@@ -79,8 +77,6 @@ static void set_hw_addr_filt(struct net_
work->dev = dev;
work->changed = changed;
queue_work(priv->hw->dev_workqueue, &work->work);
-
- return;
}
void mac802154_dev_set_short_addr(struct net_device *dev, u16 val)
--- a/net/mac802154/rx.c 2014-02-12 08:21:56.801856379 -0800
+++ b/net/mac802154/rx.c 2014-02-12 20:46:30.229208880 -0800
@@ -80,7 +80,6 @@ mac802154_subif_rx(struct ieee802154_dev
mac802154_wpans_rx(priv, skb);
out:
dev_kfree_skb(skb);
- return;
}
static void mac802154_rx_worker(struct work_struct *work)
^ permalink raw reply
* Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address
From: Luis R. Rodriguez @ 2014-02-13 4:35 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, xen-devel, Paul Durrant, Wei Liu, kvm,
linux-kernel@vger.kernel.org
In-Reply-To: <CAB=NE6Vf4KHyMGiGZuuvZ8uWhw51UXbhHPt5RxqZaJbLHOU71w@mail.gmail.com>
On Wed, Feb 12, 2014 at 8:27 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> I have a test patch that now works that restricts xen-netback from
> getting any IPv4 and IPv6 addresses, and disables multicast. With this
> set in place the xen-frontend still gets IPv4 and IPv6 addresses and
> Multicast still works. This was tested under a shared physical
> environment, I'll have to test NAT next, and also see if we can enable
> this as an option for KVM for their TAP 'backend' interfaces.
Also perhaps a silly question, as I haven't yet looked carefully into
the qemu TAP usage / requirement yet, but has anyone considered just
having a dma-buf agent for us in userspace ? That'd remove any
redundant interfaces and do let qemu do DMA directly.
Luis
^ permalink raw reply
* Re: [PATCHv3 1/2] net: stmmac: Add SOCFPGA glue driver
From: Dinh Nguyen @ 2014-02-13 4:33 UTC (permalink / raw)
To: David Miller, dinguyen-EIB2kfCEclfQT0dZR+AlfA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
peppe.cavallaro-qxv4g6HH51o, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ,
vbridgers2013-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20140212.193539.38124529344029793.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 2/12/14 6:35 PM, David Miller wrote:
> From: <dinguyen-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
> Date: Mon, 10 Feb 2014 13:48:16 -0600
>
>> From: Dinh Nguyen <dinguyen-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
>>
>> Like the STi series SOCs, Altera's SOCFPGA also needs a glue layer on top of the
>> Synopsys gmac IP.
>>
>> This patch adds the platform driver for the glue layer which configures the IP
>> before the generic STMMAC driver takes over.
>>
>> Signed-off-by: Dinh Nguyen <dinguyen-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
>> Cc: Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Cc: Vince Bridgers <vbridgers2013-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> v3: Remove stray empty line at end of dwmac-socfpga.c.
>> v2: Use the dwmac-sti as an example for a glue layer and split patch up
>> to have dts as a separate patch. Also cc dts maintainers since there is
>> a new binding.
> The second patch for the DTS update doesn't apply cleanly at all to
> mainline.
Yes, I'm planning to take the DTS bindings patch through arm-soc/next-dt
tree, so that is where patch 2 is based on.
>
> Why don't you push both of these patches through whatever tree that
> file is maintained under. You can add my ack:
I'm not sure if Peppe has a tree, but it should go into his tree
if there is one. If not, can you apply patch 1 to your tree?
>
> Acked-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Thanks,
Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address
From: Luis R. Rodriguez @ 2014-02-13 4:27 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, xen-devel, Paul Durrant, Wei Liu, kvm,
linux-kernel@vger.kernel.org
In-Reply-To: <CAB=NE6WFDWW1faoCYJP9zh6rPPvET+dbHxjHnGkYXtRx6z2LOQ@mail.gmail.com>
On Wed, Feb 12, 2014 at 2:05 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> We have to be careful for sure, I'll try to test all cases including
> kvm, but architecturally as I see it so far these things are simply
> exchanging over data through their respective backend channels, I know
> ipv6 interfaces are unused and I'm going to dig further to see why at
> least one ipv4 interfaces is needed. I cannot fathom why either of
> these interfaces would be required. I'll do a bit more digging.
>
> The TAP interface requirements may be different, I haven't yet dug into that.
I have a test patch that now works that restricts xen-netback from
getting any IPv4 and IPv6 addresses, and disables multicast. With this
set in place the xen-frontend still gets IPv4 and IPv6 addresses and
Multicast still works. This was tested under a shared physical
environment, I'll have to test NAT next, and also see if we can enable
this as an option for KVM for their TAP 'backend' interfaces.
Luis
^ permalink raw reply
* Re: Re: [PATCH] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 DeviceDriver Support
From: liujunliang_ljl @ 2014-02-13 4:23 UTC (permalink / raw)
To: Thierry Reding
Cc: davem, horms, joe, romieu, gregkh, netdev, linux-usb,
linux-kernel, sunhecheng
In-Reply-To: <1392010419-5217-1-git-send-email-liujunliang_ljl@163.com>
Dear Thierry :
For this driver, we can set it as 'n', and There is no rule of thumb as to which should default to y.
Thanks for your advice.
Thanks again.
2014-02-13
liujunliang_ljl
发件人： Thierry Reding
发送时间： 2014-02-12 18:12:52
收件人： liujunliang_ljl
抄送： davem; horms; joe; romieu; gregkh; netdev; linux-usb; linux-kernel; sunhecheng
主题： Re: [PATCH] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 DeviceDriver Support
On Mon, Feb 10, 2014 at 01:33:39PM +0800, liujunliang_ljl@163.com wrote:
> From: Liu Junliang <liujunliang_ljl@163.com>
>
>
> Signed-off-by: Liu Junliang <liujunliang_ljl@163.com>
> ---
> drivers/net/usb/Kconfig | 16 +
> drivers/net/usb/Makefile | 1 +
> drivers/net/usb/sr9800.c | 873 ++++++++++++++++++++++++++++++++++++++++++++++
> drivers/net/usb/sr9800.h | 202 +++++++++++
> 4 files changed, 1092 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/usb/sr9800.c
> create mode 100644 drivers/net/usb/sr9800.h
>
> diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
> index 47b0f73..2551bf6 100644
> --- a/drivers/net/usb/Kconfig
> +++ b/drivers/net/usb/Kconfig
> @@ -291,6 +291,22 @@ config USB_NET_SR9700
> This option adds support for CoreChip-sz SR9700 based USB 1.1
> 10/100 Ethernet adapters.
>
> +config USB_NET_SR9800
> + tristate "CoreChip-sz SR9800 based USB 2.0 10/100 ethernet devices"
> + depends on USB_USBNET
> + select CRC32
> + default y
Why is this selected by default? I can see that some of the other USB
network drivers are also selected by default, but not all of them. Is
there some rule of thumb as to which should default to y and which
shouldn't?
Thierry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJS+0kdAAoJEN0jrNd/PrOhXvwQAJIW4vgv0NkyQVo5jSvzeLY4
9PFCrtd6N1n+O7P99x38JCCD9lWtfdin1EZfj+UicCanup2WzpyBWHeBhdSN4oZA
/+C+TgEIuX0+Be11IXeUOGMP9a3k/12HY3oHuz7BA2JjcK6PnfMxaEC7iGGJSjgz
q4Goa5kSqjvNgbP8h5bQPTNtMnRdsSytI7PMJbl4t1ho0V7H3pSo9zD7rxaPhmtE
v/18VQawGcY83Hr0B0Q18XAnNXaQMLZTvdhVfDUxB5VKT4Xhcri0m4adbAzMI9kR
K9CEChkDn68y13drJVILKqUjW+4LMQHAsQV07yl98Sqk7LYOedL9mQOnIL0crjWa
OAmLHwLv0ED25W1Hv3UdeSpBdIkO9cD0PCa7vHQnv7lpTlkaDyYelKLQ2D+GXrCw
1L/341ak9QEGiCU1TiOHDblnsN+OtCt0Pt+hijLHFl4TQKw3QIUoZLa4bQuDPM8M
juTSV63HRjiDlNGvtjBezlR9GFu5w3SJuNSNsFkZ7ADJwjz9On9JaDwH/Ad7AqmZ
ylE+zzbIpOWjyNToMH2dattpeVZkIfGkS02y6PcIx51EGMw5B8l6qKLB9YpkJpwR
7rhMYjpLKIn/6rRGlwmZKYnWYl7p/FdI0yOnVbtMYx406ivUNc+kgvmx5l1mXhT7
b8gKKYYA0pMEMXjgnkK1
=3y7X
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] Fix Default to 'y' for SR9800 Device Driver, setting to 'n'
From: liujunliang_ljl @ 2014-02-13 4:22 UTC (permalink / raw)
To: thierry.reding
Cc: davem, horms, joe, romieu, gregkh, netdev, linux-usb,
linux-kernel, sunhecheng, Liu Junliang
From: Liu Junliang <liujunliang_ljl@163.com>
Signed-off-by: Liu Junliang <liujunliang_ljl@163.com>
---
drivers/net/usb/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 2551bf6..82df7c3 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -295,7 +295,6 @@ config USB_NET_SR9800
tristate "CoreChip-sz SR9800 based USB 2.0 10/100 ethernet devices"
depends on USB_USBNET
select CRC32
- default y
---help---
Say Y if you want to use one of the following 100Mbps USB Ethernet
device based on the CoreChip-sz SR9800 chip.
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net 1/3] kref: add kref_sub_return
From: David Miller @ 2014-02-13 4:09 UTC (permalink / raw)
To: gregkh
Cc: virtio-dev, anatol.pomozov, mst, netdev, linux-kernel,
virtualization, qinchuanyu, joern
In-Reply-To: <20140212.230506.1305102368255894549.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 12 Feb 2014 23:05:06 -0500 (EST)
> From: Greg KH <gregkh@linuxfoundation.org>
> Date: Wed, 12 Feb 2014 17:39:02 -0800
>
>> Yes, that's horrible as well, but as was already pointed out in this
>> thread, you can't rely on that value to really be "1" after reading it
>> due to the way krefs work, what happened if someone else just grabbed
>> it?
>>
>> If all they want is a "count" for when to start polling, then use a
>> separate atomic count, but don't abuse the kref interface for this, I
>> don't think that will work properly at all.
>
> They want to know which thread of control decrements the count to "1"
> as buffers are released.
>
> That seems entirely reasonable to me.
>
> They could add another atomic counter for this, but that's rather
> silly since the kref already has an atomic they can use for this
> purpose.
If you still can't understand what they are trying to do, they want to
do something precisely when the number of pending buffers is dropped
to 1 or less.
They are using krefs to track how many buffers are attached at a given
moment.
The counter can re-increment after the decrement to 1 or less occurs,
they don't care.
But they want precisely the entity that drops it down to 1 or less to
perform that action.
Just reading the atomic value directly, they cannot do this.
^ permalink raw reply
* Re: [PATCH net 1/3] kref: add kref_sub_return
From: David Miller @ 2014-02-13 4:05 UTC (permalink / raw)
To: gregkh
Cc: virtio-dev, anatol.pomozov, mst, netdev, linux-kernel,
virtualization, qinchuanyu, joern
In-Reply-To: <20140213013902.GA21261@kroah.com>
From: Greg KH <gregkh@linuxfoundation.org>
Date: Wed, 12 Feb 2014 17:39:02 -0800
> Yes, that's horrible as well, but as was already pointed out in this
> thread, you can't rely on that value to really be "1" after reading it
> due to the way krefs work, what happened if someone else just grabbed
> it?
>
> If all they want is a "count" for when to start polling, then use a
> separate atomic count, but don't abuse the kref interface for this, I
> don't think that will work properly at all.
They want to know which thread of control decrements the count to "1"
as buffers are released.
That seems entirely reasonable to me.
They could add another atomic counter for this, but that's rather
silly since the kref already has an atomic they can use for this
purpose.
^ permalink raw reply
* Re: [PATCH net,v3] hyperv: Fix the carrier status setting
From: Jason Wang @ 2014-02-13 3:51 UTC (permalink / raw)
To: Haiyang Zhang, davem, netdev; +Cc: driverdev-devel, olaf, linux-kernel
In-Reply-To: <1392252867-21146-1-git-send-email-haiyangz@microsoft.com>
On 02/13/2014 08:54 AM, Haiyang Zhang wrote:
> Without this patch, the "cat /sys/class/net/ethN/operstate" shows
> "unknown", and "ethtool ethN" shows "Link detected: yes", when VM
> boots up with or without vNIC connected.
>
> This patch fixed the problem.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> drivers/net/hyperv/netvsc_drv.c | 53 ++++++++++++++++++++++++++++-----------
> 1 files changed, 38 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 7756118..7141a19 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -88,8 +88,12 @@ static int netvsc_open(struct net_device *net)
> {
> struct net_device_context *net_device_ctx = netdev_priv(net);
> struct hv_device *device_obj = net_device_ctx->device_ctx;
> + struct netvsc_device *nvdev;
> + struct rndis_device *rdev;
> int ret = 0;
>
> + netif_carrier_off(net);
> +
> /* Open up the device */
> ret = rndis_filter_open(device_obj);
> if (ret != 0) {
> @@ -99,6 +103,11 @@ static int netvsc_open(struct net_device *net)
>
> netif_start_queue(net);
>
> + nvdev = hv_get_drvdata(device_obj);
> + rdev = nvdev->extension;
> + if (!rdev->link_state)
> + netif_carrier_on(net);
> +
Maybe you can just schedule the work here and then you can drop the
rtnl_lock in netvsc_link_change() ?
> return ret;
> }
>
> @@ -229,23 +238,24 @@ void netvsc_linkstatus_callback(struct hv_device *device_obj,
> struct net_device *net;
> struct net_device_context *ndev_ctx;
> struct netvsc_device *net_device;
> + struct rndis_device *rdev;
>
> net_device = hv_get_drvdata(device_obj);
> + rdev = net_device->extension;
> +
> + rdev->link_state = status != 1;
> +
> net = net_device->ndev;
>
> - if (!net) {
> - netdev_err(net, "got link status but net device "
> - "not initialized yet\n");
> + if (!net || net->reg_state != NETREG_REGISTERED)
> return;
> - }
>
> + ndev_ctx = netdev_priv(net);
> if (status == 1) {
> - netif_carrier_on(net);
> - ndev_ctx = netdev_priv(net);
> schedule_delayed_work(&ndev_ctx->dwork, 0);
> schedule_delayed_work(&ndev_ctx->dwork, msecs_to_jiffies(20));
> } else {
> - netif_carrier_off(net);
> + schedule_delayed_work(&ndev_ctx->dwork, 0);
> }
> }
>
> @@ -388,17 +398,35 @@ static const struct net_device_ops device_ops = {
> * current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, add
> * another netif_notify_peers() into a delayed work, otherwise GARP packet
> * will not be sent after quick migration, and cause network disconnection.
> + * Also, we update the carrier status here.
> */
> -static void netvsc_send_garp(struct work_struct *w)
> +static void netvsc_link_change(struct work_struct *w)
> {
> struct net_device_context *ndev_ctx;
> struct net_device *net;
> struct netvsc_device *net_device;
> + struct rndis_device *rdev;
> + bool notify;
> +
> + rtnl_lock();
>
> ndev_ctx = container_of(w, struct net_device_context, dwork.work);
> net_device = hv_get_drvdata(ndev_ctx->device_ctx);
> + rdev = net_device->extension;
> net = net_device->ndev;
> - netdev_notify_peers(net);
> +
> + if (rdev->link_state) {
> + netif_carrier_off(net);
> + notify = false;
> + } else {
> + netif_carrier_on(net);
> + notify = true;
> + }
> +
> + rtnl_unlock();
> +
> + if (notify)
> + netdev_notify_peers(net);
> }
>
Looks like this forces arp_notify here. Is it expected?
Other looks good.
>
> @@ -414,13 +442,10 @@ static int netvsc_probe(struct hv_device *dev,
> if (!net)
> return -ENOMEM;
>
> - /* Set initial state */
> - netif_carrier_off(net);
> -
> net_device_ctx = netdev_priv(net);
> net_device_ctx->device_ctx = dev;
> hv_set_drvdata(dev, net);
> - INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_send_garp);
> + INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_link_change);
> INIT_WORK(&net_device_ctx->work, do_set_multicast);
>
> net->netdev_ops = &device_ops;
> @@ -443,8 +468,6 @@ static int netvsc_probe(struct hv_device *dev,
> }
> memcpy(net->dev_addr, device_info.mac_adr, ETH_ALEN);
>
> - netif_carrier_on(net);
> -
> ret = register_netdev(net);
> if (ret != 0) {
> pr_err("Unable to register netdev.\n");
^ permalink raw reply
* [PATCH net] net: sched: Cleanup PIE comments
From: Vijay Subramanian @ 2014-02-13 2:58 UTC (permalink / raw)
To: netdev; +Cc: davem, Vijay Subramanian, Mythili Prabhu, Norbert Kiesel
From: Vijay Subramanian <vijaynsu@cisco.com>
Fix incorrect comment reported by Norbert Kiesel. Edit another comment to add
more details. Also add references to algorithm (IETF draft and paper) to top of
file.
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
CC: Mythili Prabhu <mysuryan@cisco.com>
CC: Norbert Kiesel <nkiesel@gmail.com>
---
net/sched/sch_pie.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
index a255d02..fefeeb7 100644
--- a/net/sched/sch_pie.c
+++ b/net/sched/sch_pie.c
@@ -15,6 +15,11 @@
*
* ECN support is added by Naeem Khademi <naeemk@ifi.uio.no>
* University of Oslo, Norway.
+ *
+ * References:
+ * IETF draft submission: http://tools.ietf.org/html/draft-pan-aqm-pie-00
+ * IEEE Conference on High Performance Switching and Routing 2013 :
+ * "PIE: A * Lightweight Control Scheme to Address the Bufferbloat Problem"
*/
#include <linux/module.h>
@@ -36,7 +41,7 @@ struct pie_params {
psched_time_t target; /* user specified target delay in pschedtime */
u32 tupdate; /* timer frequency (in jiffies) */
u32 limit; /* number of packets that can be enqueued */
- u32 alpha; /* alpha and beta are between -4 and 4 */
+ u32 alpha; /* alpha and beta are between 0 and 32 */
u32 beta; /* and are used for shift relative to 1 */
bool ecn; /* true if ecn is enabled */
bool bytemode; /* to scale drop early prob based on pkt size */
@@ -326,10 +331,16 @@ static void calculate_probability(struct Qdisc *sch)
if (qdelay == 0 && qlen != 0)
update_prob = false;
- /* Add ranges for alpha and beta, more aggressive for high dropping
- * mode and gentle steps for light dropping mode
- * In light dropping mode, take gentle steps; in medium dropping mode,
- * take medium steps; in high dropping mode, take big steps.
+ /* In the algorithm, alpha and beta are between 0 and 2 with typical
+ * value for alpha as 0.125. In this implementation, we use values 0-32
+ * passed from user space to represent this. Also, alpha and beta have
+ * unit of HZ and need to be scaled before they can used to update
+ * probability. alpha/beta are updated locally below by 1) scaling them
+ * appropriately 2) scaling down by 16 to come to 0-2 range.
+ * Please see paper for details.
+ *
+ * We scale alpha and beta differently depending on whether we are in
+ * light, medium or high dropping mode.
*/
if (q->vars.prob < MAX_PROB / 100) {
alpha =
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net] virtio-net: alloc big buffers also when guest can receive UFO
From: Jason Wang @ 2014-02-13 3:02 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: rusty, virtio-dev, virtualization, netdev, linux-kernel,
Sridhar Samudrala
In-Reply-To: <20140212115901.GC23006@redhat.com>
On 02/12/2014 07:59 PM, Michael S. Tsirkin wrote:
> On Wed, Feb 12, 2014 at 01:43:28PM +0800, Jason Wang wrote:
>> > We should alloc big buffers also when guest can receive UFO
>> > pakcets. Otherwise the big packets will be truncated when mergeable rx
>> > buffer is disabled.
> Not truncated, they will be dropped.
>
Why dropped? We enable the ufo on tap0 if VIRTIO_NET_F_GUEST_UFO is
negotiated. So skb was queued on the receive queue. But since the
receive buffer is small, it will be truncated during tun_put_user().
^ permalink raw reply
* RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel
From: hayeswang @ 2014-02-13 2:55 UTC (permalink / raw)
To: 'Grant Grundler'
Cc: 'Inki Yoo', 'netdev', 'David Miller'
In-Reply-To: <CANEJEGtj5b6z3L1AeiqTPgVs0qCe=pv=cyRHYi04_yNXpPMOCA@mail.gmail.com>
Grant Grundler [mailto:grundler@google.com]
> Sent: Thursday, February 13, 2014 7:58 AM
> To: hayeswang
> Cc: Inki Yoo; netdev; David Miller
> Subject: Re: RTL8153 fails to get link after applying
> c7de7dec2 to 3.8 kernel
[...]
> > # ethtool -i eth0
> > driver: r815x
> > version: 22-Aug-2005
>
> BTW, can you please update the version number to match adding
> RTL8153 support?
> Makes life easier for anyone maintaining older kernels.
The information is from ecm driver, maybe cdc_ether or usbnet. I don't
think I could modify it.
> > Is your dangle from Samsung?
>
> It's labeled "Realtek USB 3.0 Gigabit Ethernet" externally. I'm not
> sure if we got these from Samsung or directly from RealTek.
>
> What's notable is this device has no link or activity LEDs visible.
> Normally I'd expect those near the RJ45 port.
>
> Also no MAC address or serial number or anything to further identify
> the devices. just the "rectangular black plastic" enclosure with a
> silver sticker carrying the Realtek logo + text.
According to the information from our FAE about the dangles for samsung,
the default values of some device power are disabled or off. I don't know
the history about this. However, it would cause the dangle no link, because
the ecm driver wouldn't enable them. That is, the dangle couldn't use the
ECM mode. I think you should create a udev rule to change the configuration
to 1 when the dangle is plugged. Then, it could load the vendor mode driver.
> > I would ask our PM to check if there is any difference
> between our devices.
> > Maybe it is not the driver issue.
>
> I don't think it's a r8152 or r815x driver issue either. It's much
> more likely related to chromeos-3.8 USB NET patches not matching 3.14
> kernel behaviors.
I don't think so. The reason is as above. Change the configuration of the
device to 1 (vendor mode) is what you have to do.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH] net: clear iflink when moving to a new netns
From: Eric W. Biederman @ 2014-02-13 2:01 UTC (permalink / raw)
To: Cong Wang
Cc: Stephen Hemminger, Cong Wang, netdev, David S. Miller,
Eric Dumazet, Hannes Frederic Sowa
In-Reply-To: <CAHA+R7NJ2uPbVdcdktD9R-_1QZnbwJXV+NP6jK0_ZTn=TF687g@mail.gmail.com>
Cong Wang <cwang@twopensource.com> writes:
> On Wed, Feb 12, 2014 at 8:33 AM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
>>
>> This also breaks propogation of state changes from lower device
>> to upper device. Things like carrier and up/down.
>>
>
> macvlan_device_event() handles this pretty well by using a pointer to
> net_device.
> I don't see it is a problem from the code.
A quick grep shows two uses of iflink in net/core/link_watch.c that are
likely broken by your proposed change.
Eric
^ permalink raw reply
* Re: [PATCH] net: clear iflink when moving to a new netns
From: Eric W. Biederman @ 2014-02-13 2:00 UTC (permalink / raw)
To: Cong Wang
Cc: Nicolas Dichtel, Cong Wang, netdev, David S. Miller, Eric Dumazet,
Hannes Frederic Sowa
In-Reply-To: <CAHA+R7Pd07-3-ikK9=o=6ZhwT1PY6iZTmLUnCCsJ2-e=KS5jOA@mail.gmail.com>
Cong Wang <cwang@twopensource.com> writes:
> On Wed, Feb 12, 2014 at 7:43 AM, Nicolas Dichtel
> <nicolas.dichtel@6wind.com> wrote:
>> Le 12/02/2014 00:51, Cong Wang a écrit :
>>
>>> From: Cong Wang <cwang@twopensource.com>
>>>
>>> BZ: https://bugzilla.kernel.org/show_bug.cgi?id=66691
>>>
>>> macvlan and vlan both use iflink to identify its lower device,
>>> however, after such device is moved to the new netns, its iflink
>>> would become meaningless as ifindex is per netns. So, instead of
>>> forbid them moving to another netns, just clear this field so that
>>> it will not be dumped at least.
>>>
>>> Cc: David S. Miller <davem@davemloft.net>
>>> Cc: Eric W. Biederman <ebiederm@xmission.com>
>>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>>> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>,
>>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>>> Signed-off-by: Cong Wang <cwang@twopensource.com>
>>
>> I wonder if this patch breaks things in ip tunnels.
>> For example, ip6_tunnel uses iflink to find tunnels that are bound to an
>> interface.
>> If you reset this field, ipip6_tunnel_lookup() will fail when the tunnel
>> moves
>> to another netns.
>
> Most tunnels set NETIF_F_NETNS_LOCAL, ip6_tunnel should set it too
> (need a patch). So this is not a problem.
There was an effort not long ago to make tunnels safe to pass between
namespaces. NETIF_F_NETNS_LOCAL was removed from ip6_tunnel in that
effort. Apparently something was overlooked.
Making iflink a netdevice reference or finding a way to remove it
entirely seems better that masking the problem.
Eric
^ permalink raw reply
* Re: [PATCH net 1/3] kref: add kref_sub_return
From: Greg KH @ 2014-02-13 1:39 UTC (permalink / raw)
To: David Miller
Cc: virtio-dev, anatol.pomozov, mst, netdev, linux-kernel,
virtualization, qinchuanyu, joern
In-Reply-To: <20140212.190637.328045386111912135.davem@davemloft.net>
On Wed, Feb 12, 2014 at 07:06:37PM -0500, David Miller wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Date: Wed, 12 Feb 2014 08:56:30 -0800
>
> > On Wed, Feb 12, 2014 at 06:38:21PM +0200, Michael S. Tsirkin wrote:
> >> It is sometimes useful to get the value of the reference count after
> >> decrement.
> >> For example, vhost wants to execute some periodic cleanup operations
> >> once number of references drops below a specific value, before it
> >> reaches zero (for efficiency).
> >
> > You should never care about what the value of the kref is, if you are
> > using it correctly :)
>
> It isn't being used to determine when to destroy things.
>
> They use it to as a heuristic of when to trigger polling.
>
> Each ubuf attached gets a kref to the higher level virtio_net buffer
> holding object, they want to trigger polling when that reference drops
> to 1 or lower.
>
> Right now they are reading the atomic refcount directly, which
> I think is much worse than this helper.
Yes, that's horrible as well, but as was already pointed out in this
thread, you can't rely on that value to really be "1" after reading it
due to the way krefs work, what happened if someone else just grabbed
it?
If all they want is a "count" for when to start polling, then use a
separate atomic count, but don't abuse the kref interface for this, I
don't think that will work properly at all.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] net: clear iflink when moving to a new netns
From: Cong Wang @ 2014-02-13 1:34 UTC (permalink / raw)
To: Ben Hutchings
Cc: Cong Wang, netdev, David S. Miller, Eric W. Biederman,
Eric Dumazet, Hannes Frederic Sowa
In-Reply-To: <1392247105.15615.41.camel@deadeye.wl.decadent.org.uk>
On Wed, Feb 12, 2014 at 3:18 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Tue, 2014-02-11 at 15:51 -0800, Cong Wang wrote:
>> From: Cong Wang <cwang@twopensource.com>
>>
>> BZ: https://bugzilla.kernel.org/show_bug.cgi?id=66691
>>
>> macvlan and vlan both use iflink to identify its lower device,
>> however, after such device is moved to the new netns, its iflink
>> would become meaningless as ifindex is per netns. So, instead of
>> forbid them moving to another netns, just clear this field so that
>> it will not be dumped at least.
> [...]
>
> And what if it's moved back into the same netns?
>
Good point!
> I think iflink should be changed to a net_device pointer, so it remains
> valid for in-kernel users but rtnetlink can do the netns check before
> revealing it to userland.
>
I will try this approach.
Thanks.
^ permalink raw reply
* Re: [PATCH net 1/3] kref: add kref_sub_return
From: Jörn Engel @ 2014-02-13 1:25 UTC (permalink / raw)
To: David Miller
Cc: virtio-dev, anatol.pomozov, mst, gregkh, linux-kernel,
virtualization, netdev, qinchuanyu
In-Reply-To: <20140212.190637.328045386111912135.davem@davemloft.net>
On Wed, 12 February 2014 19:06:37 -0500, David Miller wrote:
>
> It isn't being used to determine when to destroy things.
>
> They use it to as a heuristic of when to trigger polling.
>
> Each ubuf attached gets a kref to the higher level virtio_net buffer
> holding object, they want to trigger polling when that reference drops
> to 1 or lower.
>
> Right now they are reading the atomic refcount directly, which
> I think is much worse than this helper.
I disagree. Reading the refcount directly is leaving noone under any
illusion that this might be a good idea.
Jörn
--
Victory in war is not repetitious.
-- Sun Tzu
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] net: clear iflink when moving to a new netns
From: Cong Wang @ 2014-02-13 1:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Cong Wang, netdev, David S. Miller, Eric W. Biederman,
Eric Dumazet, Hannes Frederic Sowa
In-Reply-To: <20140212083322.1559f441@nehalam.linuxnetplumber.net>
On Wed, Feb 12, 2014 at 8:33 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> This also breaks propogation of state changes from lower device
> to upper device. Things like carrier and up/down.
>
macvlan_device_event() handles this pretty well by using a pointer to
net_device.
I don't see it is a problem from the code.
^ permalink raw reply
* Re: [PATCH v3 2/2] sctp: optimize the sctp_sysctl_net_register
From: Wang Weidong @ 2014-02-13 1:19 UTC (permalink / raw)
To: Neil Horman; +Cc: davem, vyasevich, dborkman, sergei.shtylyov, netdev
In-Reply-To: <20140212115344.GB4038@hmsreliant.think-freely.org>
On 2014/2/12 19:53, Neil Horman wrote:
> On Wed, Feb 12, 2014 at 09:44:44AM +0800, Wang Weidong wrote:
>> Here, when the net is init_net, we needn't to kmemdup the ctl_table
>> again. So add a check for net. Also we can save some memory.
>>
>> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
>> ---
>> net/sctp/sysctl.c | 17 ++++++++++-------
>> 1 file changed, 10 insertions(+), 7 deletions(-)
>>
>> diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
>> index d354de5..35c8923 100644
>> --- a/net/sctp/sysctl.c
>> +++ b/net/sctp/sysctl.c
>> @@ -402,15 +402,18 @@ static int proc_sctp_do_rto_max(struct ctl_table *ctl, int write,
>>
>> int sctp_sysctl_net_register(struct net *net)
>> {
>> - struct ctl_table *table;
>> - int i;
>> + struct ctl_table *table = sctp_net_table;
>> +
>> + if (!net_eq(net, &init_net)) {
>> + int i;
>>
>> - table = kmemdup(sctp_net_table, sizeof(sctp_net_table), GFP_KERNEL);
>> - if (!table)
>> - return -ENOMEM;
>> + table = kmemdup(sctp_net_table, sizeof(sctp_net_table), GFP_KERNEL);
>> + if (!table)
>> + return -ENOMEM;
>>
>> - for (i = 0; table[i].data; i++)
>> - table[i].data += (char *)(&net->sctp) - (char *)&init_net.sctp;
>> + for (i = 0; table[i].data; i++)
>> + table[i].data += (char *)(&net->sctp) - (char *)&init_net.sctp;
>> + }
>>
> In the first version of this patch you complained about a lockdep issue. Did
> you figure out what that was, and if it related to these changes?
>
> Neil
>
>
Hi Neil,
The lockdep issue doesn't relate to these changes. I should send it
by the another email. Sorry for confusing you.
Regards
Wang
> .
>
^ permalink raw reply
* Re: [PATCH] net: clear iflink when moving to a new netns
From: Cong Wang @ 2014-02-13 1:18 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: Cong Wang, netdev, David S. Miller, Eric W. Biederman,
Eric Dumazet, Hannes Frederic Sowa
In-Reply-To: <52FB969A.607@6wind.com>
On Wed, Feb 12, 2014 at 7:43 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> Le 12/02/2014 00:51, Cong Wang a écrit :
>
>> From: Cong Wang <cwang@twopensource.com>
>>
>> BZ: https://bugzilla.kernel.org/show_bug.cgi?id=66691
>>
>> macvlan and vlan both use iflink to identify its lower device,
>> however, after such device is moved to the new netns, its iflink
>> would become meaningless as ifindex is per netns. So, instead of
>> forbid them moving to another netns, just clear this field so that
>> it will not be dumped at least.
>>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Eric W. Biederman <ebiederm@xmission.com>
>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>,
>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>> Signed-off-by: Cong Wang <cwang@twopensource.com>
>
> I wonder if this patch breaks things in ip tunnels.
> For example, ip6_tunnel uses iflink to find tunnels that are bound to an
> interface.
> If you reset this field, ipip6_tunnel_lookup() will fail when the tunnel
> moves
> to another netns.
Most tunnels set NETIF_F_NETNS_LOCAL, ip6_tunnel should set it too
(need a patch). So this is not a problem.
^ permalink raw reply
* [PATCH net,v3] hyperv: Fix the carrier status setting
From: Haiyang Zhang @ 2014-02-13 0:54 UTC (permalink / raw)
To: davem, netdev; +Cc: olaf, jasowang, driverdev-devel, linux-kernel, haiyangz
Without this patch, the "cat /sys/class/net/ethN/operstate" shows
"unknown", and "ethtool ethN" shows "Link detected: yes", when VM
boots up with or without vNIC connected.
This patch fixed the problem.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/net/hyperv/netvsc_drv.c | 53 ++++++++++++++++++++++++++++-----------
1 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 7756118..7141a19 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -88,8 +88,12 @@ static int netvsc_open(struct net_device *net)
{
struct net_device_context *net_device_ctx = netdev_priv(net);
struct hv_device *device_obj = net_device_ctx->device_ctx;
+ struct netvsc_device *nvdev;
+ struct rndis_device *rdev;
int ret = 0;
+ netif_carrier_off(net);
+
/* Open up the device */
ret = rndis_filter_open(device_obj);
if (ret != 0) {
@@ -99,6 +103,11 @@ static int netvsc_open(struct net_device *net)
netif_start_queue(net);
+ nvdev = hv_get_drvdata(device_obj);
+ rdev = nvdev->extension;
+ if (!rdev->link_state)
+ netif_carrier_on(net);
+
return ret;
}
@@ -229,23 +238,24 @@ void netvsc_linkstatus_callback(struct hv_device *device_obj,
struct net_device *net;
struct net_device_context *ndev_ctx;
struct netvsc_device *net_device;
+ struct rndis_device *rdev;
net_device = hv_get_drvdata(device_obj);
+ rdev = net_device->extension;
+
+ rdev->link_state = status != 1;
+
net = net_device->ndev;
- if (!net) {
- netdev_err(net, "got link status but net device "
- "not initialized yet\n");
+ if (!net || net->reg_state != NETREG_REGISTERED)
return;
- }
+ ndev_ctx = netdev_priv(net);
if (status == 1) {
- netif_carrier_on(net);
- ndev_ctx = netdev_priv(net);
schedule_delayed_work(&ndev_ctx->dwork, 0);
schedule_delayed_work(&ndev_ctx->dwork, msecs_to_jiffies(20));
} else {
- netif_carrier_off(net);
+ schedule_delayed_work(&ndev_ctx->dwork, 0);
}
}
@@ -388,17 +398,35 @@ static const struct net_device_ops device_ops = {
* current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, add
* another netif_notify_peers() into a delayed work, otherwise GARP packet
* will not be sent after quick migration, and cause network disconnection.
+ * Also, we update the carrier status here.
*/
-static void netvsc_send_garp(struct work_struct *w)
+static void netvsc_link_change(struct work_struct *w)
{
struct net_device_context *ndev_ctx;
struct net_device *net;
struct netvsc_device *net_device;
+ struct rndis_device *rdev;
+ bool notify;
+
+ rtnl_lock();
ndev_ctx = container_of(w, struct net_device_context, dwork.work);
net_device = hv_get_drvdata(ndev_ctx->device_ctx);
+ rdev = net_device->extension;
net = net_device->ndev;
- netdev_notify_peers(net);
+
+ if (rdev->link_state) {
+ netif_carrier_off(net);
+ notify = false;
+ } else {
+ netif_carrier_on(net);
+ notify = true;
+ }
+
+ rtnl_unlock();
+
+ if (notify)
+ netdev_notify_peers(net);
}
@@ -414,13 +442,10 @@ static int netvsc_probe(struct hv_device *dev,
if (!net)
return -ENOMEM;
- /* Set initial state */
- netif_carrier_off(net);
-
net_device_ctx = netdev_priv(net);
net_device_ctx->device_ctx = dev;
hv_set_drvdata(dev, net);
- INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_send_garp);
+ INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_link_change);
INIT_WORK(&net_device_ctx->work, do_set_multicast);
net->netdev_ops = &device_ops;
@@ -443,8 +468,6 @@ static int netvsc_probe(struct hv_device *dev,
}
memcpy(net->dev_addr, device_info.mac_adr, ETH_ALEN);
- netif_carrier_on(net);
-
ret = register_netdev(net);
if (ret != 0) {
pr_err("Unable to register netdev.\n");
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCHv3 1/2] net: stmmac: Add SOCFPGA glue driver
From: David Miller @ 2014-02-13 0:35 UTC (permalink / raw)
To: dinguyen
Cc: netdev, devicetree, dinh.linux, peppe.cavallaro, robh+dt,
pawel.moll, mark.rutland, ijc+devicetree, galak, vbridgers2013
In-Reply-To: <1392061697-20193-1-git-send-email-dinguyen@altera.com>
From: <dinguyen@altera.com>
Date: Mon, 10 Feb 2014 13:48:16 -0600
> From: Dinh Nguyen <dinguyen@altera.com>
>
> Like the STi series SOCs, Altera's SOCFPGA also needs a glue layer on top of the
> Synopsys gmac IP.
>
> This patch adds the platform driver for the glue layer which configures the IP
> before the generic STMMAC driver takes over.
>
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: Vince Bridgers <vbridgers2013@gmail.com>
> ---
> v3: Remove stray empty line at end of dwmac-socfpga.c.
> v2: Use the dwmac-sti as an example for a glue layer and split patch up
> to have dts as a separate patch. Also cc dts maintainers since there is
> a new binding.
The second patch for the DTS update doesn't apply cleanly at all to
mainline.
Why don't you push both of these patches through whatever tree that
file is maintained under. You can add my ack:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 08/14] net: axienet: Removed checkpatch errors/warnings
From: Joe Perches @ 2014-02-13 0:31 UTC (permalink / raw)
To: Michal Simek
Cc: netdev, Srikanth Thokala, Srikanth Thokala, Michal Simek,
Anirudha Sarangi, John Linn, linux-arm-kernel, linux-kernel
In-Reply-To: <75b669c0a947effe74b291093abfa8c71f83736a.1392220536.git.michal.simek@xilinx.com>
On Wed, 2014-02-12 at 16:55 +0100, Michal Simek wrote:
> From: Srikanth Thokala <srikanth.thokala@xilinx.com>
trivia:
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> + netdev_err(lp->ndev,
> + "axienet_device_reset DMA reset timeout!\n");
could you please align multi-line arguments to the
appropriate open parenthesis?
netdev_err(lp->ndev,
"axienet_device_reset DMA reset timeout!\n");
or maybe:
netdev_err(lp->ndev, "%s: "DMA reset timeout!\n",
__func__);
> @@ -484,8 +484,8 @@ static void axienet_device_reset(struct net_device *ndev)
> }
>
> if (axienet_dma_bd_init(ndev)) {
> - dev_err(&ndev->dev, "axienet_device_reset descriptor "
> - "allocation failed\n");
> + netdev_err(ndev,
> + "axienet_device_reset descriptor allocation failed\n");
etc, et al.
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
[]
> @@ -161,19 +161,19 @@ int axienet_mdio_setup(struct axienet_local *lp, struct device_node *np)
>
> np1 = of_find_node_by_name(NULL, "cpu");
> if (!np1) {
> - printk(KERN_WARNING "%s(): Could not find CPU device node.",
> - __func__);
> - printk(KERN_WARNING "Setting MDIO clock divisor to "
> - "default %d\n", DEFAULT_CLOCK_DIVISOR);
> + netdev_warn(lp->ndev, "Could not find CPU device node.");
missing trailing "\n" to terminate message.
> + netdev_warn(lp->ndev,
> + "Could not find clock ethernet controller property.");
here too. (and alignment)
^ permalink raw reply
* Re: [PATCH] ipv4: ipconfig.c: add parentheses in an if statement
From: David Miller @ 2014-02-13 0:29 UTC (permalink / raw)
To: fx.lebail; +Cc: netdev
In-Reply-To: <1392047214-21237-1-git-send-email-fx.lebail@yahoo.com>
From: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
Date: Mon, 10 Feb 2014 16:46:54 +0100
> Even if the 'time_before' macro expand with parentheses, the look is bad.
>
> Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
Applied, 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