* Re: [PATCH 03/16] wl1251: add sysfs interface for bluetooth coexistence mode configuration
From: Luca Coelho @ 2013-10-29 7:09 UTC (permalink / raw)
To: Ben Hutchings
Cc: Pali Rohár, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen, David Gnedt
In-Reply-To: <1383003587.3779.49.camel@bwh-desktop.uk.level5networks.com>
On Mon, 2013-10-28 at 23:39 +0000, Ben Hutchings wrote:
> On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> > From: David Gnedt <david.gnedt@davizone.at>
> >
> > Port the bt_coex_mode sysfs interface from wl1251 driver version included
> > in the Maemo Fremantle kernel to allow bt-coexistence mode configuration.
> > This enables userspace applications to set one of the modes
> > WL1251_BT_COEX_OFF, WL1251_BT_COEX_ENABLE and WL1251_BT_COEX_MONOAUDIO.
> > The default mode is WL1251_BT_COEX_OFF.
> > It should be noted that this driver always enabled bt-coexistence before
> > and enabled bt-coexistence directly affects the receiving performance,
> > rendering it unusable in some low-signal situations. Especially monitor
> > mode is affected very badly with bt-coexistence enabled.
> [...]
>
> This should be implemented consistently with other drivers:
>
> drivers/net/wireless/ath/ath9k/htc_drv_init.c:module_param_named(btcoex_enable, ath9k_htc_btcoex_enable, int, 0444);
> drivers/net/wireless/ath/ath9k/init.c:module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
> drivers/net/wireless/b43/main.c:module_param_named(btcoex, modparam_btcoex, int, 0444);
> drivers/net/wireless/ipw2x00/ipw2200.c:module_param(bt_coexist, int, 0444);
> drivers/net/wireless/iwlegacy/common.c:module_param(bt_coex_active, bool, S_IRUGO);
> drivers/net/wireless/iwlwifi/iwl-drv.c:module_param_named(bt_coex_active, iwlwifi_mod_params.bt_coex_active,
> drivers/net/wireless/ti/wlcore/sysfs.c:static DEVICE_ATTR(bt_coex_state, S_IRUGO | S_IWUSR,
>
> Oh, hmm, I see a problem here.
With so many drivers doing the same thing, isn't it about time to add
this to nl80211?
--
Luca.
^ permalink raw reply
* [PATCH net] virtio-net: correctly handle cpu hotplug notifier during resuming
From: Jason Wang @ 2013-10-29 7:11 UTC (permalink / raw)
To: rusty, mst, virtualization, netdev, linux-kernel
commit 3ab098df35f8b98b6553edc2e40234af512ba877 (virtio-net: don't respond to
cpu hotplug notifier if we're not ready) tries to bypass the cpu hotplug
notifier by checking the config_enable and does nothing is it was false. So it
need to try to hold the config_lock mutex which may happen in atomic
environment which leads the following warnings:
[ 622.944441] CPU0 attaching NULL sched-domain.
[ 622.944446] CPU1 attaching NULL sched-domain.
[ 622.944485] CPU0 attaching NULL sched-domain.
[ 622.950795] BUG: sleeping function called from invalid context at kernel/mutex.c:616
[ 622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: migration/1
[ 622.950796] no locks held by migration/1/10.
[ 622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.12.0-rc5-wl-01249-gb91e82d #317
[ 622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 622.950802] 0000000000000000 ffff88001d42dba0 ffffffff81a32f22 ffff88001bfb9c70
[ 622.950803] ffff88001d42dbb0 ffffffff810edb02 ffff88001d42dc38 ffffffff81a396ed
[ 622.950805] 0000000000000046 ffff88001d42dbe8 ffffffff810e861d 0000000000000000
[ 622.950805] Call Trace:
[ 622.950810] [<ffffffff81a32f22>] dump_stack+0x54/0x74
[ 622.950815] [<ffffffff810edb02>] __might_sleep+0x112/0x114
[ 622.950817] [<ffffffff81a396ed>] mutex_lock_nested+0x3c/0x3c6
[ 622.950818] [<ffffffff810e861d>] ? up+0x39/0x3e
[ 622.950821] [<ffffffff8153ea7c>] ? acpi_os_signal_semaphore+0x21/0x2d
[ 622.950824] [<ffffffff81565ed1>] ? acpi_ut_release_mutex+0x5e/0x62
[ 622.950828] [<ffffffff816d04ec>] virtnet_cpu_callback+0x33/0x87
[ 622.950830] [<ffffffff81a42576>] notifier_call_chain+0x3c/0x5e
[ 622.950832] [<ffffffff810e86a8>] __raw_notifier_call_chain+0xe/0x10
[ 622.950835] [<ffffffff810c5556>] __cpu_notify+0x20/0x37
[ 622.950836] [<ffffffff810c5580>] cpu_notify+0x13/0x15
[ 622.950838] [<ffffffff81a237cd>] take_cpu_down+0x27/0x3a
[ 622.950841] [<ffffffff81136289>] stop_machine_cpu_stop+0x93/0xf1
[ 622.950842] [<ffffffff81136167>] cpu_stopper_thread+0xa0/0x12f
[ 622.950844] [<ffffffff811361f6>] ? cpu_stopper_thread+0x12f/0x12f
[ 622.950847] [<ffffffff81119710>] ? lock_release_holdtime.part.7+0xa3/0xa8
[ 622.950848] [<ffffffff81135e4b>] ? cpu_stop_should_run+0x3f/0x47
[ 622.950850] [<ffffffff810ea9b0>] smpboot_thread_fn+0x1c5/0x1e3
[ 622.950852] [<ffffffff810ea7eb>] ? lg_global_unlock+0x67/0x67
[ 622.950854] [<ffffffff810e36b7>] kthread+0xd8/0xe0
[ 622.950857] [<ffffffff81a3bfad>] ? wait_for_common+0x12f/0x164
[ 622.950859] [<ffffffff810e35df>] ? kthread_create_on_node+0x124/0x124
[ 622.950861] [<ffffffff81a45ffc>] ret_from_fork+0x7c/0xb0
[ 622.950862] [<ffffffff810e35df>] ? kthread_create_on_node+0x124/0x124
[ 622.950876] smpboot: CPU 1 is now offline
[ 623.194556] SMP alternatives: lockdep: fixing up alternatives
[ 623.194559] smpboot: Booting Node 0 Processor 1 APIC 0x1
...
A correct fix is to unregister the hotcpu notifier during restore and register a
new one in resume.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
This patch is needed for 3.8 and above.
---
drivers/net/virtio_net.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 9fbdfcd..bbc9cb8 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1118,11 +1118,6 @@ static int virtnet_cpu_callback(struct notifier_block *nfb,
{
struct virtnet_info *vi = container_of(nfb, struct virtnet_info, nb);
- mutex_lock(&vi->config_lock);
-
- if (!vi->config_enable)
- goto done;
-
switch(action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
case CPU_DOWN_FAILED:
@@ -1136,8 +1131,6 @@ static int virtnet_cpu_callback(struct notifier_block *nfb,
break;
}
-done:
- mutex_unlock(&vi->config_lock);
return NOTIFY_OK;
}
@@ -1699,6 +1692,8 @@ static int virtnet_freeze(struct virtio_device *vdev)
struct virtnet_info *vi = vdev->priv;
int i;
+ unregister_hotcpu_notifier(&vi->nb);
+
/* Prevent config work handler from accessing the device */
mutex_lock(&vi->config_lock);
vi->config_enable = false;
@@ -1747,6 +1742,10 @@ static int virtnet_restore(struct virtio_device *vdev)
virtnet_set_queues(vi, vi->curr_queue_pairs);
rtnl_unlock();
+ err = register_hotcpu_notifier(&vi->nb);
+ if (err)
+ return err;
+
return 0;
}
#endif
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH net-next] virtio_net: migrate mergeable rx buffers to page frag allocators
From: Daniel Borkmann @ 2013-10-29 7:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael Dalton, David S. Miller, netdev, Eric Dumazet,
Rusty Russell, Michael S. Tsirkin, virtualization,
Francesco Fusco
In-Reply-To: <1383002389.4344.7.camel@edumazet-glaptop.roam.corp.google.com>
On 10/29/2013 12:19 AM, Eric Dumazet wrote:
> On Mon, 2013-10-28 at 15:44 -0700, Michael Dalton wrote:
>> The virtio_net driver's mergeable receive buffer allocator
>> uses 4KB packet buffers. For MTU-sized traffic, SKB truesize
>> is > 4KB but only ~1500 bytes of the buffer is used to store
>> packet data, reducing the effective TCP window size
>> substantially. This patch addresses the performance concerns
>> with mergeable receive buffers by allocating MTU-sized packet
>> buffers using page frag allocators. If more than MAX_SKB_FRAGS
>> buffers are needed, the SKB frag_list is used.
>>
>> Signed-off-by: Michael Dalton <mwdalton@google.com>
>> ---
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Daniel & Francesco, this should address the performance problem you
> tried to address with ("tcp: rcvbuf autotuning improvements")
That's awesome, thanks everyone !
> ( http://www.spinics.net/lists/netdev/msg252642.html )
>
> Thanks !
^ permalink raw reply
* Re: [PATCH net] virtio-net: correctly handle cpu hotplug notifier during resuming
From: Michael S. Tsirkin @ 2013-10-29 7:36 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <1383030667-14343-1-git-send-email-jasowang@redhat.com>
On Tue, Oct 29, 2013 at 03:11:07PM +0800, Jason Wang wrote:
> commit 3ab098df35f8b98b6553edc2e40234af512ba877 (virtio-net: don't respond to
> cpu hotplug notifier if we're not ready) tries to bypass the cpu hotplug
> notifier by checking the config_enable and does nothing is it was false. So it
> need to try to hold the config_lock mutex which may happen in atomic
> environment which leads the following warnings:
>
> [ 622.944441] CPU0 attaching NULL sched-domain.
> [ 622.944446] CPU1 attaching NULL sched-domain.
> [ 622.944485] CPU0 attaching NULL sched-domain.
> [ 622.950795] BUG: sleeping function called from invalid context at kernel/mutex.c:616
> [ 622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: migration/1
> [ 622.950796] no locks held by migration/1/10.
> [ 622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.12.0-rc5-wl-01249-gb91e82d #317
> [ 622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 622.950802] 0000000000000000 ffff88001d42dba0 ffffffff81a32f22 ffff88001bfb9c70
> [ 622.950803] ffff88001d42dbb0 ffffffff810edb02 ffff88001d42dc38 ffffffff81a396ed
> [ 622.950805] 0000000000000046 ffff88001d42dbe8 ffffffff810e861d 0000000000000000
> [ 622.950805] Call Trace:
> [ 622.950810] [<ffffffff81a32f22>] dump_stack+0x54/0x74
> [ 622.950815] [<ffffffff810edb02>] __might_sleep+0x112/0x114
> [ 622.950817] [<ffffffff81a396ed>] mutex_lock_nested+0x3c/0x3c6
> [ 622.950818] [<ffffffff810e861d>] ? up+0x39/0x3e
> [ 622.950821] [<ffffffff8153ea7c>] ? acpi_os_signal_semaphore+0x21/0x2d
> [ 622.950824] [<ffffffff81565ed1>] ? acpi_ut_release_mutex+0x5e/0x62
> [ 622.950828] [<ffffffff816d04ec>] virtnet_cpu_callback+0x33/0x87
> [ 622.950830] [<ffffffff81a42576>] notifier_call_chain+0x3c/0x5e
> [ 622.950832] [<ffffffff810e86a8>] __raw_notifier_call_chain+0xe/0x10
> [ 622.950835] [<ffffffff810c5556>] __cpu_notify+0x20/0x37
> [ 622.950836] [<ffffffff810c5580>] cpu_notify+0x13/0x15
> [ 622.950838] [<ffffffff81a237cd>] take_cpu_down+0x27/0x3a
> [ 622.950841] [<ffffffff81136289>] stop_machine_cpu_stop+0x93/0xf1
> [ 622.950842] [<ffffffff81136167>] cpu_stopper_thread+0xa0/0x12f
> [ 622.950844] [<ffffffff811361f6>] ? cpu_stopper_thread+0x12f/0x12f
> [ 622.950847] [<ffffffff81119710>] ? lock_release_holdtime.part.7+0xa3/0xa8
> [ 622.950848] [<ffffffff81135e4b>] ? cpu_stop_should_run+0x3f/0x47
> [ 622.950850] [<ffffffff810ea9b0>] smpboot_thread_fn+0x1c5/0x1e3
> [ 622.950852] [<ffffffff810ea7eb>] ? lg_global_unlock+0x67/0x67
> [ 622.950854] [<ffffffff810e36b7>] kthread+0xd8/0xe0
> [ 622.950857] [<ffffffff81a3bfad>] ? wait_for_common+0x12f/0x164
> [ 622.950859] [<ffffffff810e35df>] ? kthread_create_on_node+0x124/0x124
> [ 622.950861] [<ffffffff81a45ffc>] ret_from_fork+0x7c/0xb0
> [ 622.950862] [<ffffffff810e35df>] ? kthread_create_on_node+0x124/0x124
> [ 622.950876] smpboot: CPU 1 is now offline
> [ 623.194556] SMP alternatives: lockdep: fixing up alternatives
> [ 623.194559] smpboot: Booting Node 0 Processor 1 APIC 0x1
> ...
>
> A correct fix is to unregister the hotcpu notifier during restore and register a
> new one in resume.
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Tested-by: Fengguang Wu <fengguang.wu@intel.com>
> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
BTW there's a new Fixes: tag, you might want to use it
in the future.
> ---
> This patch is needed for 3.8 and above.
> ---
> drivers/net/virtio_net.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 9fbdfcd..bbc9cb8 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1118,11 +1118,6 @@ static int virtnet_cpu_callback(struct notifier_block *nfb,
> {
> struct virtnet_info *vi = container_of(nfb, struct virtnet_info, nb);
>
> - mutex_lock(&vi->config_lock);
> -
> - if (!vi->config_enable)
> - goto done;
> -
> switch(action & ~CPU_TASKS_FROZEN) {
> case CPU_ONLINE:
> case CPU_DOWN_FAILED:
> @@ -1136,8 +1131,6 @@ static int virtnet_cpu_callback(struct notifier_block *nfb,
> break;
> }
>
> -done:
> - mutex_unlock(&vi->config_lock);
> return NOTIFY_OK;
> }
>
> @@ -1699,6 +1692,8 @@ static int virtnet_freeze(struct virtio_device *vdev)
> struct virtnet_info *vi = vdev->priv;
> int i;
>
> + unregister_hotcpu_notifier(&vi->nb);
> +
> /* Prevent config work handler from accessing the device */
> mutex_lock(&vi->config_lock);
> vi->config_enable = false;
> @@ -1747,6 +1742,10 @@ static int virtnet_restore(struct virtio_device *vdev)
> virtnet_set_queues(vi, vi->curr_queue_pairs);
> rtnl_unlock();
>
> + err = register_hotcpu_notifier(&vi->nb);
> + if (err)
> + return err;
> +
> return 0;
> }
> #endif
> --
> 1.8.1.2
^ permalink raw reply
* Re: [PATCH net-next] ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE
From: Florian Weimer @ 2013-10-29 7:36 UTC (permalink / raw)
To: David Miller, hannes; +Cc: netdev
In-Reply-To: <20131029.000844.1092862708536984032.davem@davemloft.net>
On 10/29/2013 05:08 AM, David Miller wrote:
> I do not like this reasoning. You have several more acceptable paths to take
> to resolve this problem:
>
> 1) "I don't trust path MTU information at all"
>
> Just turn it off globally, end of story. It has the same effect as your
> new per-application mode.
We can't push this as a security update. We could tell everyone running
DNS servers to reconfigure their systems in this way, but I always
consider this a bit of a cop-out.
A new knob to turn IP_PMTUDISC_DONT into something that behaves like
IP_PMTUDISC_INTERFACE would be more conservative and easier to deploy, I
think.
> 2) "I don't trust path MTU information unless the full socket ID is available
> in the ICMP packets quoted headers"
>
> Then simply implement a policy as such and submit it to me.
There are IP protocols where these bits aren't readily available and
where we don't want the kernel (outside the Netfilter code) to be aware
of the payload structure. Netfilter isn't a solution because it
requires state and doesn't work well with request-response UDP protocols
like DNS (even before source port randomization).
You could make the path MTU dependent on the protocol (which would even
be the correct solution from a technical point of view) and use
validation for TCP and UDP, but that's a fairly invasive change for such
relatively minor functionality.
--
Florian Weimer / Red Hat Product Security Team
^ permalink raw reply
* [PATCH net 0/3] r8152 bug fixes
From: Hayes Wang @ 2013-10-29 7:56 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
These could fix some driver issues.
Hayes Wang (3):
r8152: fix tx/rx memory overflow
r8152: modify the tx flow
r8152: fix incorrect type in assignment
drivers/net/usb/r8152.c | 100 +++++++++++++++++-------------------------------
1 file changed, 36 insertions(+), 64 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net 1/3] r8152: fix tx/rx memory overflow
From: Hayes Wang @ 2013-10-29 7:56 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1383033377-1178-1-git-send-email-hayeswang@realtek.com>
The tx/rx would access the memory which is out of the desired range.
Modify the method of checking the end of the memory to avoid it.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 30 +++++++++++++++++-------------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3fce41..5dbfe50 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,7 +24,7 @@
#include <linux/ipv6.h>
/* Version Information */
-#define DRIVER_VERSION "v1.01.0 (2013/08/12)"
+#define DRIVER_VERSION "v1.02.0 (2013/10/28)"
#define DRIVER_AUTHOR "Realtek linux nic maintainers <nic_swsd@realtek.com>"
#define DRIVER_DESC "Realtek RTL8152 Based USB 2.0 Ethernet Adapters"
#define MODULENAME "r8152"
@@ -1136,14 +1136,14 @@ r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc, struct sk_buff *skb)
static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
{
- u32 remain;
+ int remain;
u8 *tx_data;
tx_data = agg->head;
agg->skb_num = agg->skb_len = 0;
- remain = rx_buf_sz - sizeof(struct tx_desc);
+ remain = rx_buf_sz;
- while (remain >= ETH_ZLEN) {
+ while (remain >= ETH_ZLEN + sizeof(struct tx_desc)) {
struct tx_desc *tx_desc;
struct sk_buff *skb;
unsigned int len;
@@ -1152,12 +1152,14 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
if (!skb)
break;
+ remain -= sizeof(*tx_desc);
len = skb->len;
if (remain < len) {
skb_queue_head(&tp->tx_queue, skb);
break;
}
+ tx_data = tx_agg_align(tx_data);
tx_desc = (struct tx_desc *)tx_data;
tx_data += sizeof(*tx_desc);
@@ -1167,9 +1169,8 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
agg->skb_len += len;
dev_kfree_skb_any(skb);
- tx_data = tx_agg_align(tx_data + len);
- remain = rx_buf_sz - sizeof(*tx_desc) -
- (u32)((void *)tx_data - agg->head);
+ tx_data += len;
+ remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
}
usb_fill_bulk_urb(agg->urb, tp->udev, usb_sndbulkpipe(tp->udev, 2),
@@ -1188,7 +1189,6 @@ static void rx_bottom(struct r8152 *tp)
list_for_each_safe(cursor, next, &tp->rx_done) {
struct rx_desc *rx_desc;
struct rx_agg *agg;
- unsigned pkt_len;
int len_used = 0;
struct urb *urb;
u8 *rx_data;
@@ -1204,17 +1204,22 @@ static void rx_bottom(struct r8152 *tp)
rx_desc = agg->head;
rx_data = agg->head;
- pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
- len_used += sizeof(struct rx_desc) + pkt_len;
+ len_used += sizeof(struct rx_desc);
- while (urb->actual_length >= len_used) {
+ while (urb->actual_length > len_used) {
struct net_device *netdev = tp->netdev;
struct net_device_stats *stats;
+ unsigned pkt_len;
struct sk_buff *skb;
+ pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
if (pkt_len < ETH_ZLEN)
break;
+ len_used += pkt_len;
+ if (urb->actual_length < len_used)
+ break;
+
stats = rtl8152_get_stats(netdev);
pkt_len -= 4; /* CRC */
@@ -1234,9 +1239,8 @@ static void rx_bottom(struct r8152 *tp)
rx_data = rx_agg_align(rx_data + pkt_len + 4);
rx_desc = (struct rx_desc *)rx_data;
- pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
len_used = (int)(rx_data - (u8 *)agg->head);
- len_used += sizeof(struct rx_desc) + pkt_len;
+ len_used += sizeof(struct rx_desc);
}
submit:
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/3] r8152: modify the tx flow
From: Hayes Wang @ 2013-10-29 7:56 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1383033377-1178-1-git-send-email-hayeswang@realtek.com>
Let rtl8152_start_xmit() to queue packet only, and tx_bottom() would
send all of the packets. This simplify the code and make sure all the
packet would be sent by the original order.
Support stopping and waking tx queue. The maximum tx queue length
is 60.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 52 ++++++++++---------------------------------------
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5dbfe50..1647931 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -276,6 +276,8 @@ enum rtl_register_content {
#define INTR_LINK 0x0004
+#define TX_QLEN 60
+
#define RTL8152_REQT_READ 0xc0
#define RTL8152_REQT_WRITE 0x40
#define RTL8152_REQ_GET_REGS 0x05
@@ -1173,6 +1175,9 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
}
+ if (netif_queue_stopped(tp->netdev))
+ netif_wake_queue(tp->netdev);
+
usb_fill_bulk_urb(agg->urb, tp->udev, usb_sndbulkpipe(tp->udev, 2),
agg->head, (int)(tx_data - (u8 *)agg->head),
(usb_complete_t)write_bulk_callback, agg);
@@ -1388,53 +1393,16 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb,
struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
- struct net_device_stats *stats = rtl8152_get_stats(netdev);
- unsigned long flags;
- struct tx_agg *agg = NULL;
- struct tx_desc *tx_desc;
- unsigned int len;
- u8 *tx_data;
- int res;
skb_tx_timestamp(skb);
- /* If tx_queue is not empty, it means at least one previous packt */
- /* is waiting for sending. Don't send current one before it. */
- if (skb_queue_empty(&tp->tx_queue))
- agg = r8152_get_tx_agg(tp);
-
- if (!agg) {
- skb_queue_tail(&tp->tx_queue, skb);
- return NETDEV_TX_OK;
- }
+ skb_queue_tail(&tp->tx_queue, skb);
- tx_desc = (struct tx_desc *)agg->head;
- tx_data = agg->head + sizeof(*tx_desc);
- agg->skb_num = agg->skb_len = 0;
+ if (skb_queue_len(&tp->tx_queue) > TX_QLEN)
+ netif_stop_queue(netdev);
- len = skb->len;
- r8152_tx_csum(tp, tx_desc, skb);
- memcpy(tx_data, skb->data, len);
- dev_kfree_skb_any(skb);
- agg->skb_num++;
- agg->skb_len += len;
- usb_fill_bulk_urb(agg->urb, tp->udev, usb_sndbulkpipe(tp->udev, 2),
- agg->head, len + sizeof(*tx_desc),
- (usb_complete_t)write_bulk_callback, agg);
- res = usb_submit_urb(agg->urb, GFP_ATOMIC);
- if (res) {
- /* Can we get/handle EPIPE here? */
- if (res == -ENODEV) {
- netif_device_detach(tp->netdev);
- } else {
- netif_warn(tp, tx_err, netdev,
- "failed tx_urb %d\n", res);
- stats->tx_dropped++;
- spin_lock_irqsave(&tp->tx_lock, flags);
- list_add_tail(&agg->list, &tp->tx_free);
- spin_unlock_irqrestore(&tp->tx_lock, flags);
- }
- }
+ if (!list_empty(&tp->tx_free))
+ tasklet_schedule(&tp->tl);
return NETDEV_TX_OK;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 3/3] r8152: fix incorrect type in assignment
From: Hayes Wang @ 2013-10-29 7:56 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1383033377-1178-1-git-send-email-hayeswang@realtek.com>
Correct some declaration.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1647931..b92b7f4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -309,22 +309,22 @@ enum rtl8152_flags {
#define MCU_TYPE_USB 0x0000
struct rx_desc {
- u32 opts1;
+ __le32 opts1;
#define RX_LEN_MASK 0x7fff
- u32 opts2;
- u32 opts3;
- u32 opts4;
- u32 opts5;
- u32 opts6;
+ __le32 opts2;
+ __le32 opts3;
+ __le32 opts4;
+ __le32 opts5;
+ __le32 opts6;
};
struct tx_desc {
- u32 opts1;
+ __le32 opts1;
#define TX_FS (1 << 31) /* First segment of a packet */
#define TX_LS (1 << 30) /* Final segment of a packet */
#define TX_LEN_MASK 0x3ffff
- u32 opts2;
+ __le32 opts2;
#define UDP_CS (1 << 31) /* Calculate UDP/IP checksum */
#define TCP_CS (1 << 30) /* Calculate TCP/IP checksum */
#define IPV4_CS (1 << 29) /* Calculate IPv4 checksum */
@@ -878,7 +878,7 @@ static void write_bulk_callback(struct urb *urb)
static void intr_callback(struct urb *urb)
{
struct r8152 *tp;
- __u16 *d;
+ __le16 *d;
int status = urb->status;
int res;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] bgmac: don't update slot on skb alloc/dma mapping error
From: Nathan Hintz @ 2013-10-29 8:22 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Network Development
In-Reply-To: <CACna6rzxt2QMtLfD84pw7EtYqg1Qva4ah83hVQOKpeKy72bd5w@mail.gmail.com>
On Tue, 29 Oct 2013 07:52:58 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:
> 2013/10/29 Nathan Hintz <nlhintz@hotmail.com>:
> > Don't update the slot in "bgmac_dma_rx_skb_for_slot" unless both the
> > skb alloc and dma mapping are successful; and free the newly allocated
> > skb if a dma mapping error occurs. This will prevent an skb leak upon
> > returning when an error occurs.
>
> In case of bgmac_dma_rx_skb_for_slot failure we're giving up anyway
> (and freeing everything), but with your patch code is simpler to
> understand, so I'm OK with that.
>
> Acked-by: Rafał Miłecki <zajec5@gmail.com>
>
I might be misunderstanding; but it in the case of failure, it appeared to me
that the currently received packet was dropped and the old skb would continue
to be assigned to the slot and would be used to receive future packets (this
would continue until bgmac_dma_rx_skb_for_slot was successful).
--
Nathan
^ permalink raw reply
* Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
From: Ingo Molnar @ 2013-10-29 8:25 UTC (permalink / raw)
To: Neil Horman
Cc: Eric Dumazet, linux-kernel, sebastien.dugue, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86, netdev
In-Reply-To: <20131028182913.GD31048@hmsreliant.think-freely.org>
* Neil Horman <nhorman@tuxdriver.com> wrote:
> Heres my data for running the same test with taskset restricting
> execution to only cpu0. I'm not quite sure whats going on here,
> but doing so resulted in a 10x slowdown of the runtime of each
> iteration which I can't explain. As before however, both the
> parallel alu run and the prefetch run resulted in speedups, but
> the two together were not in any way addative. I'm going to keep
> playing with the prefetch stride, unless you have an alternate
> theory.
Could you please cite the exact command-line you used for running
the test?
Thanks,
Ingo
^ permalink raw reply
* [PATCH v2] can: c_can: Speed up rx_poll function
From: Markus Pargmann @ 2013-10-29 8:27 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger
Cc: Joe Perches, linux-can, netdev, linux-kernel, kernel,
Markus Pargmann
This patch speeds up the rx_poll function by reducing the number of
register reads.
Replace the 32bit register read by a 16bit register read. Currently
the 32bit register read is implemented by using 2 16bit reads. This is
inefficient as we only use the lower 16bit in rx_poll.
The for loop reads the pending interrupts in every iteration. This
leads up to 16 reads of pending interrupts. The patch introduces a new
outer loop to read the pending interrupts as long as 'quota' is above 0.
This reduces the total number of reads.
The third change is to replace the for-loop by a find_next_bit loop.
Tested on AM335x. I removed all 'static' and 'inline' from c_can.c to
see the timings for all functions. I used the function tracer with
trace_stats.
125kbit:
Function Hit Time Avg s^2
-------- --- ---- --- ---
c_can_do_rx_poll 63960 10168178 us 158.977 us 1493056 us
With patch:
c_can_do_rx_poll 63939 4268457 us 66.758 us 818790.9 us
1Mbit:
Function Hit Time Avg s^2
-------- --- ---- --- ---
c_can_do_rx_poll 69489 30049498 us 432.435 us 9271851 us
With patch:
c_can_do_rx_poll 103034 24220362 us 235.071 us 6016656 us
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
---
Notes:
Changes in v2:
- Small changes, find_next_bit -> ffs and other
drivers/net/can/c_can/c_can.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index a668cd4..428681e 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -798,17 +798,19 @@ static int c_can_do_rx_poll(struct net_device *dev, int quota)
u32 num_rx_pkts = 0;
unsigned int msg_obj, msg_ctrl_save;
struct c_can_priv *priv = netdev_priv(dev);
- u32 val = c_can_read_reg32(priv, C_CAN_INTPND1_REG);
+ u16 val;
+
+ /*
+ * It is faster to read only one 16bit register. This is only possible
+ * for a maximum number of 16 objects.
+ */
+ BUILD_BUG_ON_MSG(C_CAN_MSG_OBJ_RX_LAST > 16,
+ "Implementation does not support more message objects than 16");
+
+ while (quota > 0 && (val = priv->read_reg(priv, C_CAN_INTPND1_REG))) {
+ while ((msg_obj = ffs(val)) && quota > 0) {
+ val &= ~BIT(msg_obj - 1);
- for (msg_obj = C_CAN_MSG_OBJ_RX_FIRST;
- msg_obj <= C_CAN_MSG_OBJ_RX_LAST && quota > 0;
- val = c_can_read_reg32(priv, C_CAN_INTPND1_REG),
- msg_obj++) {
- /*
- * as interrupt pending register's bit n-1 corresponds to
- * message object n, we need to handle the same properly.
- */
- if (val & (1 << (msg_obj - 1))) {
c_can_object_get(dev, 0, msg_obj, IF_COMM_ALL &
~IF_COMM_TXRQST);
msg_ctrl_save = priv->read_reg(priv,
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH 4/4] wl1251: spi: add device tree support
From: Kumar Gala @ 2013-10-29 8:28 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, linux-doc, Tony Lindgren, Sebastian Reichel,
Russell King, Sachin Kamat, Stephen Warren, Sebastian Reichel,
Luciano Coelho, devicetree, Pawel Moll, Ian Campbell,
John W. Linville, Rob Herring, Bill Pemberton, linux-omap,
linux-arm-kernel, Greg Kroah-Hartman, linux-wireless,
linux-kernel, Felipe Balbi, Rob Landley, netdev
In-Reply-To: <4893578.SBstXOAcJY@flatron>
On Oct 28, 2013, at 5:38 PM, Tomasz Figa wrote:
> On Monday 28 of October 2013 01:37:34 Kumar Gala wrote:
>> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
>>> Add device tree support for the spi variant of wl1251
>>> and document the binding.
>>>
>>> Signed-off-by: Sebastian Reichel <sre@debian.org>
>>> ---
>>> .../devicetree/bindings/net/wireless/ti,wl1251.txt | 36
>>> ++++++++++++++++++++++ drivers/net/wireless/ti/wl1251/spi.c
>>> | 23 ++++++++++---- 2 files changed, 53 insertions(+), 6
>>> deletions(-)
>>> create mode 100644
>>> Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>>> b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt new
>>> file mode 100644
>>> index 0000000..5f8a154
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>>> @@ -0,0 +1,36 @@
>>> +* Texas Instruments wl1251 controller
>>> +
>>> +The wl1251 chip can be connected via SPI or via SDIO. The linux
>>> +kernel currently only supports device tree for the SPI variant.
>>> +
>>
>> From the binding I have no idea what this chip actually does, also we
>> don't normally reference linux kernel support in bindings specs (so
>> please remove it).
>>
>> However, what would expect the SDIO binding to look like? Or more
>> specifically, how would you distinguish the SPI vs SDIO
>> binding/connection? I'm wondering if the compatible should be
>> something like "ti,wl1251-spi" and than the sdio can be
>> "ti,wl1251-sdio"
>
> Well, you can easily distinguish an SDIO device from an SPI device by its
> parent node, but...
>
> The binding for SDIO might require different set of properties (other than
> ones inherited from generic SDIO or SPI bindings) than one for SPI. So
> probably different compatible values might be justified.
>
> Did we already have such case before? (maybe some I2C + SPI devices?)
>
>>> +Required properties:
>>> +- compatible : Should be "ti,wl1251"
>>
>> reg is not listed as a required prop.
>
> It is implied by SPI bindings, but it might be a good idea to have this
> stated here as well.
>
>>
>>> +- interrupts : Should contain interrupt line
>>> +- interrupt-parent : Should be the phandle for the interrupt
>>> + controller that services interrupts for this device
>>> +- vio-supply : phandle to regulator providing VIO
>>> +- power-gpio : GPIO connected to chip's PMEN pin
>>
>> should be vendor prefixed: ti,power-gpio
>
> Hmm, out of curiosity, is it a rule for this kind of properties? I can see
> both cases with and without prefixes when grepping for "-gpios" in
> Documentation/devicetree/bindings. We should really have such things
> written down somewhere.
Agreed, it should be part of the various docs we are suppose to produce for review and binding creation guidelines.
>>> +- For additional required properties on SPI, please consult
>>> + Documentation/devicetree/bindings/spi/spi-bus.txt
>>> +
>>> +Optional properties:
>>> +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>>
>> can you be a bit more specific on what cfg will be loaded. Also, is
>> this property a boolean, if so how do I know which eeprom the cfg is
>> loaded from (is it one that is directly connected to the wl1251?
>
> Maybe one from ti,has-eeprom or ti,config-eeprom would be better name for
> this property?
Probably, ti,wl1251-has-eeprom or something like that would be better. However, I'm not going to get too caught up on names of properties.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH] bgmac: don't update slot on skb alloc/dma mapping error
From: Rafał Miłecki @ 2013-10-29 8:28 UTC (permalink / raw)
To: Nathan Hintz; +Cc: Network Development
In-Reply-To: <BLU0-SMTP200803D333FF3A2F15AB82DAC090@phx.gbl>
2013/10/29 Nathan Hintz <nlhintz@hotmail.com>:
> On Tue, 29 Oct 2013 07:52:58 +0100
> Rafał Miłecki <zajec5@gmail.com> wrote:
>
>> 2013/10/29 Nathan Hintz <nlhintz@hotmail.com>:
>> > Don't update the slot in "bgmac_dma_rx_skb_for_slot" unless both the
>> > skb alloc and dma mapping are successful; and free the newly allocated
>> > skb if a dma mapping error occurs. This will prevent an skb leak upon
>> > returning when an error occurs.
>>
>> In case of bgmac_dma_rx_skb_for_slot failure we're giving up anyway
>> (and freeing everything), but with your patch code is simpler to
>> understand, so I'm OK with that.
>>
>> Acked-by: Rafał Miłecki <zajec5@gmail.com>
>>
>
> I might be misunderstanding; but it in the case of failure, it appeared to me
> that the currently received packet was dropped and the old skb would continue
> to be assigned to the slot and would be used to receive future packets (this
> would continue until bgmac_dma_rx_skb_for_slot was successful).
I was commenting on current usage (bgmac_dma_alloc), not my WIP patch
for bgmac_dma_rx_read :)
Your patch will be helpful for my bgmac_dma_rx_read rework.
^ permalink raw reply
* Re: [PATCH v2] can: c_can: Speed up rx_poll function
From: Joe Perches @ 2013-10-29 8:31 UTC (permalink / raw)
To: Markus Pargmann
Cc: Marc Kleine-Budde, Wolfgang Grandegger, linux-can, netdev,
linux-kernel, kernel
In-Reply-To: <1383035267-19604-1-git-send-email-mpa@pengutronix.de>
On Tue, 2013-10-29 at 09:27 +0100, Markus Pargmann wrote:
> This patch speeds up the rx_poll function by reducing the number of
> register reads.
[]
> The third change is to replace the for-loop by a find_next_bit loop.
You need to update the commit message.
> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
[]
> @@ -798,17 +798,19 @@ static int c_can_do_rx_poll(struct net_device *dev, int quota)
[]
> + while (quota > 0 && (val = priv->read_reg(priv, C_CAN_INTPND1_REG))) {
> + while ((msg_obj = ffs(val)) && quota > 0) {
> + val &= ~BIT(msg_obj - 1);
^ permalink raw reply
* Re: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
From: Bjørn Mork @ 2013-10-29 8:41 UTC (permalink / raw)
To: Du, ChangbinX
Cc: oliver@neukum.org, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <0C18FE92A7765D4EB9EE5D38D86A563A019F450F@SHSMSX103.ccr.corp.intel.com>
"Du, ChangbinX" <changbinx.du@intel.com> writes:
> From: "Du, Changbin" <changbinx.du@intel.com>
>
> In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
> But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
> be called which calls free_netdev(net).
I am sure you are right, but I really don't see how that can happen.
AFAICS, we ensure that the intfdata is set to NULL before calling
usb_driver_release_interface() in the error cleanup in
cdc_ncm_bind_common():
error2:
usb_set_intfdata(ctx->control, NULL);
usb_set_intfdata(ctx->data, NULL);
if (ctx->data != ctx->control)
usb_driver_release_interface(driver, ctx->data);
error:
cdc_ncm_free((struct cdc_ncm_ctx *)dev->data[0]);
dev->data[0] = 0;
dev_info(&dev->udev->dev, "bind() failure\n");
return -ENODEV;
Thus we hit the test in disconnect, and usbnet_disconnect() is never
called:
static void cdc_ncm_disconnect(struct usb_interface *intf)
{
struct usbnet *dev = usb_get_intfdata(intf);
if (dev == NULL)
return; /* already disconnected */
usbnet_disconnect(intf);
}
So we should really be OK, but we are not???? I would appreciate it if
anyone took the time to feed me why, with a very small spoon...
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index 43afde8..af37ecf 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -603,14 +603,15 @@ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
>
> /* NCM data altsetting is always 1 */
> ret = cdc_ncm_bind_common(dev, intf, 1);
> -
> - /*
> - * We should get an event when network connection is "connected" or
> - * "disconnected". Set network connection in "disconnected" state
> - * (carrier is OFF) during attach, so the IP network stack does not
> - * start IPv6 negotiation and more.
> - */
> - usbnet_link_change(dev, 0, 0);
> + if (!ret) {
> + /*
> + * We should get an event when network connection is "connected"
> + * or "disconnected". Set network connection in "disconnected"
> + * state (carrier is OFF) during attach, so the IP network stack
> + * does not start IPv6 negotiation and more.
> + */
> + usbnet_link_change(dev, 0, 0);
> + }
> return ret;
> }
This change does of course make sense in any case, so no objections
there. But maybe you could modify cdc_ncm to set the new FLAG_LINK_INTR
instead, and completely drop the usbnet_link_change() from this driver?
This will make usbnet_probe() handle the call, and it will avoid it if
cdc_ncm_bind() failed.
Bjørn
^ permalink raw reply
* Re: [PATCH net] virtio-net: correctly handle cpu hotplug notifier during resuming
From: Wanlong Gao @ 2013-10-29 8:42 UTC (permalink / raw)
To: Jason Wang, rusty, mst, virtualization, netdev, linux-kernel
In-Reply-To: <1383030667-14343-1-git-send-email-jasowang@redhat.com>
On 10/29/2013 03:11 PM, Jason Wang wrote:
> commit 3ab098df35f8b98b6553edc2e40234af512ba877 (virtio-net: don't respond to
> cpu hotplug notifier if we're not ready) tries to bypass the cpu hotplug
> notifier by checking the config_enable and does nothing is it was false. So it
> need to try to hold the config_lock mutex which may happen in atomic
> environment which leads the following warnings:
>
> [ 622.944441] CPU0 attaching NULL sched-domain.
> [ 622.944446] CPU1 attaching NULL sched-domain.
> [ 622.944485] CPU0 attaching NULL sched-domain.
> [ 622.950795] BUG: sleeping function called from invalid context at kernel/mutex.c:616
> [ 622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: migration/1
> [ 622.950796] no locks held by migration/1/10.
> [ 622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.12.0-rc5-wl-01249-gb91e82d #317
> [ 622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 622.950802] 0000000000000000 ffff88001d42dba0 ffffffff81a32f22 ffff88001bfb9c70
> [ 622.950803] ffff88001d42dbb0 ffffffff810edb02 ffff88001d42dc38 ffffffff81a396ed
> [ 622.950805] 0000000000000046 ffff88001d42dbe8 ffffffff810e861d 0000000000000000
> [ 622.950805] Call Trace:
> [ 622.950810] [<ffffffff81a32f22>] dump_stack+0x54/0x74
> [ 622.950815] [<ffffffff810edb02>] __might_sleep+0x112/0x114
> [ 622.950817] [<ffffffff81a396ed>] mutex_lock_nested+0x3c/0x3c6
> [ 622.950818] [<ffffffff810e861d>] ? up+0x39/0x3e
> [ 622.950821] [<ffffffff8153ea7c>] ? acpi_os_signal_semaphore+0x21/0x2d
> [ 622.950824] [<ffffffff81565ed1>] ? acpi_ut_release_mutex+0x5e/0x62
> [ 622.950828] [<ffffffff816d04ec>] virtnet_cpu_callback+0x33/0x87
> [ 622.950830] [<ffffffff81a42576>] notifier_call_chain+0x3c/0x5e
> [ 622.950832] [<ffffffff810e86a8>] __raw_notifier_call_chain+0xe/0x10
> [ 622.950835] [<ffffffff810c5556>] __cpu_notify+0x20/0x37
> [ 622.950836] [<ffffffff810c5580>] cpu_notify+0x13/0x15
> [ 622.950838] [<ffffffff81a237cd>] take_cpu_down+0x27/0x3a
> [ 622.950841] [<ffffffff81136289>] stop_machine_cpu_stop+0x93/0xf1
> [ 622.950842] [<ffffffff81136167>] cpu_stopper_thread+0xa0/0x12f
> [ 622.950844] [<ffffffff811361f6>] ? cpu_stopper_thread+0x12f/0x12f
> [ 622.950847] [<ffffffff81119710>] ? lock_release_holdtime.part.7+0xa3/0xa8
> [ 622.950848] [<ffffffff81135e4b>] ? cpu_stop_should_run+0x3f/0x47
> [ 622.950850] [<ffffffff810ea9b0>] smpboot_thread_fn+0x1c5/0x1e3
> [ 622.950852] [<ffffffff810ea7eb>] ? lg_global_unlock+0x67/0x67
> [ 622.950854] [<ffffffff810e36b7>] kthread+0xd8/0xe0
> [ 622.950857] [<ffffffff81a3bfad>] ? wait_for_common+0x12f/0x164
> [ 622.950859] [<ffffffff810e35df>] ? kthread_create_on_node+0x124/0x124
> [ 622.950861] [<ffffffff81a45ffc>] ret_from_fork+0x7c/0xb0
> [ 622.950862] [<ffffffff810e35df>] ? kthread_create_on_node+0x124/0x124
> [ 622.950876] smpboot: CPU 1 is now offline
> [ 623.194556] SMP alternatives: lockdep: fixing up alternatives
> [ 623.194559] smpboot: Booting Node 0 Processor 1 APIC 0x1
> ...
>
> A correct fix is to unregister the hotcpu notifier during restore and register a
> new one in resume.
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Tested-by: Fengguang Wu <fengguang.wu@intel.com>
> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Thank you for your fix.
Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> ---
> This patch is needed for 3.8 and above.
> ---
> drivers/net/virtio_net.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 9fbdfcd..bbc9cb8 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1118,11 +1118,6 @@ static int virtnet_cpu_callback(struct notifier_block *nfb,
> {
> struct virtnet_info *vi = container_of(nfb, struct virtnet_info, nb);
>
> - mutex_lock(&vi->config_lock);
> -
> - if (!vi->config_enable)
> - goto done;
> -
> switch(action & ~CPU_TASKS_FROZEN) {
> case CPU_ONLINE:
> case CPU_DOWN_FAILED:
> @@ -1136,8 +1131,6 @@ static int virtnet_cpu_callback(struct notifier_block *nfb,
> break;
> }
>
> -done:
> - mutex_unlock(&vi->config_lock);
> return NOTIFY_OK;
> }
>
> @@ -1699,6 +1692,8 @@ static int virtnet_freeze(struct virtio_device *vdev)
> struct virtnet_info *vi = vdev->priv;
> int i;
>
> + unregister_hotcpu_notifier(&vi->nb);
> +
> /* Prevent config work handler from accessing the device */
> mutex_lock(&vi->config_lock);
> vi->config_enable = false;
> @@ -1747,6 +1742,10 @@ static int virtnet_restore(struct virtio_device *vdev)
> virtnet_set_queues(vi, vi->curr_queue_pairs);
> rtnl_unlock();
>
> + err = register_hotcpu_notifier(&vi->nb);
> + if (err)
> + return err;
> +
> return 0;
> }
> #endif
>
^ permalink raw reply
* Re: [PATCH v2] can: c_can: Speed up rx_poll function
From: Markus Pargmann @ 2013-10-29 8:58 UTC (permalink / raw)
To: Joe Perches
Cc: Marc Kleine-Budde, Wolfgang Grandegger, linux-can, netdev,
linux-kernel, kernel
In-Reply-To: <1383035688.2713.2.camel@joe-AO722>
On Tue, Oct 29, 2013 at 01:34:48AM -0700, Joe Perches wrote:
> On Tue, 2013-10-29 at 09:27 +0100, Markus Pargmann wrote:
> > This patch speeds up the rx_poll function by reducing the number of
> > register reads.
> []
> > 125kbit:
> > Function Hit Time Avg s^2
> > -------- --- ---- --- ---
> > c_can_do_rx_poll 63960 10168178 us 158.977 us 1493056 us
> > With patch:
> > c_can_do_rx_poll 63939 4268457 us 66.758 us 818790.9 us
> >
> > 1Mbit:
> > Function Hit Time Avg s^2
> > -------- --- ---- --- ---
> > c_can_do_rx_poll 69489 30049498 us 432.435 us 9271851 us
> > With patch:
> > c_can_do_rx_poll 103034 24220362 us 235.071 us 6016656 us
>
> Also nicer if you updated the timings table
>
>
Yes I just measured the timings again:
./perf_can_test.sh 125000 30
Function Hit Time Avg s^2
-------- --- ---- --- ---
c_can_poll 127882 6178806 us 48.316 us 4393411 us
c_can_do_rx_poll 63941 3764057 us 58.867 us 776162.2 us
c_can_enable_all_interrupts 255764 2213697 us 8.655 us 1093934 us
c_can_plat_write_reg_aligned_t 807252 1607115 us 1.990 us 10053684 us
c_can_isr 127882 1220001 us 9.540 us 789.495 us
c_can_object_put 119887 1039222 us 8.668 us 1608.668 us
c_can_plat_read_reg_aligned_to 1015072 1033283 us 1.017 us 7021.465 us
c_can_read_msg_object 63943 1026159 us 16.048 us 718.464 us
c_can_activate_all_lower_rx_ms 7992 755782.4 us 94.567 us 55.270 us
c_can_mark_rx_msg_obj 55951 709072.1 us 12.673 us 39.974 us
c_can_object_get 63943 555669.2 us 8.690 us 96.211 us
c_can_msg_obj_is_busy 183830 527826.1 us 2.871 us 7289.221 us
alloc_can_skb 63943 170966.6 us 2.673 us 165.765 us
c_can_has_and_handle_berr 63941 47063.18 us 0.736 us 2.757 us
./perf_can_test.sh 1000000 30
Function Hit Time Avg s^2
-------- --- ---- --- ---
c_can_poll 270678 30290751 us 111.906 us 5809627 us
c_can_do_rx_poll 207109 24322185 us 117.436 us 171469047 us
c_can_object_put 841431 7278794 us 8.650 us 305841.0 us
c_can_plat_write_reg_aligned_t 4037180 6244636 us 1.546 us 4581066 us
c_can_read_msg_object 453988 6033464 us 13.289 us 128809.6 us
c_can_enable_all_interrupts 541342 5849826 us 10.806 us 22458900 us
c_can_activate_all_lower_rx_ms 55349 5237761 us 94.631 us 19004.79 us
c_can_mark_rx_msg_obj 387429 4865632 us 12.558 us 380606.4 us
c_can_plat_read_reg_aligned_to 4597629 4633247 us 1.007 us 315286.2 us
c_can_object_get 453988 3919692 us 8.633 us 59847.76 us
c_can_msg_obj_is_busy 1295419 3706862 us 2.861 us 316655.7 us
c_can_isr 270671 2496734 us 9.224 us 530.967 us
alloc_can_skb 453988 856917.4 us 1.887 us 18157.68 us
c_can_activate_rx_msg_obj 11210 141177.4 us 12.593 us 123.068 us
c_can_has_and_handle_berr 63569 44995.85 us 0.707 us 12.780 us
It is interesting that the number of hits for c_can_do_rx_poll is twice as much
as it was with find_next_bit. Unfortunately this reduces the overall benefit of
this patch. Any ideas how to increase the number of waiting message objects we
handle in one poll call?
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: Bug in skb_segment: fskb->len != len
From: Christoph Paasch @ 2013-10-29 9:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Herbert Xu, netdev
In-Reply-To: <1383009308.5464.2.camel@edumazet-glaptop.roam.corp.google.com>
On 28/10/13 - 18:15:08, Eric Dumazet wrote:
> On Mon, 2013-10-28 at 06:21 -0700, Eric Dumazet wrote:
>
> > But we also need to fix the skb_segment() bug anyway.
>
> Hi Christoph
>
> I cooked a minimal patch, could you please try it ?
>
> I'll refactor skb_segment() to be smarter for the next release
> (linux-3.14).
>
> Thanks !
>
> net/core/skbuff.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
Ok, my router does not crash anymore with my workload.
Thanks for fixing it!
Tested-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Cheers,
Christoph
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 0ab32faa520f..771946487a8d 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2761,7 +2761,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> unsigned int len;
> __be16 proto;
> bool csum;
> - int sg = !!(features & NETIF_F_SG);
> + bool sg = !!(features & NETIF_F_SG);
> int nfrags = skb_shinfo(skb)->nr_frags;
> int err = -ENOMEM;
> int i = 0;
> @@ -2793,7 +2793,11 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> hsize = len;
>
> if (!hsize && i >= nfrags) {
> - BUG_ON(fskb->len != len);
> + if (fskb->len != len) {
> + hsize = len;
> + sg = false;
> + goto do_linear;
> + }
>
> pos += len;
> nskb = skb_clone(fskb, GFP_ATOMIC);
> @@ -2812,6 +2816,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> skb_release_head_state(nskb);
> __skb_push(nskb, doffset);
> } else {
> +do_linear:
> nskb = __alloc_skb(hsize + doffset + headroom,
> GFP_ATOMIC, skb_alloc_rx_flag(skb),
> NUMA_NO_NODE);
> @@ -2838,9 +2843,6 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> nskb->data - tnl_hlen,
> doffset + tnl_hlen);
>
> - if (fskb != skb_shinfo(skb)->frag_list)
> - goto perform_csum_check;
> -
> if (!sg) {
> nskb->ip_summed = CHECKSUM_NONE;
> nskb->csum = skb_copy_and_csum_bits(skb, offset,
> @@ -2849,6 +2851,9 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> continue;
> }
>
> + if (fskb != skb_shinfo(skb)->frag_list)
> + goto perform_csum_check;
> +
> frag = skb_shinfo(nskb)->frags;
>
> skb_copy_from_linear_data_offset(skb, offset,
>
>
^ permalink raw reply
* Re: [PATCH] ethernet/arc/arc_emac: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 9:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, abrodkin
In-Reply-To: <20131028.234842.1406231268962965513.davem@davemloft.net>
Hi David,
On Mon, Oct 28, 2013 at 11:48:42PM -0400, David Miller wrote:
> I've seen you use three inconsistent Subject prefixes here, pick a scheme
> and stick to it please!
>
> First patch was:
>
> netdev: ${driver_name}:
>
> Second patch was:
>
> net: ${driver_name}:
>
> Third patch was:
>
> patch/to/driver/directory:
True. I have sent it that way because I've followed the commit
schematics of each driver individually.
> This is really not acceptable. Just using "${driver_name}: " is good
> enough.
It's not a problem to resend them... But I'm wondering should this be
squashed into one patch?
Luka
^ permalink raw reply
* Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Guennadi Liakhovetski @ 2013-10-29 9:12 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev, linux-sh, Linus Walleij, Guennadi Liakhovetski,
Thierry Reding, linux-mtd, linux-i2c, Vinod Koul, Joerg Roedel,
Wolfram Sang, Magnus Damm, Eduardo Valentin, Tomi Valkeinen,
linux-serial, linux-input, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard, linux-media, linux-pwm,
Samuel Ortiz, linux-pm, Ian Molton, Mark Brown, linux-arm-kernel,
Ser
In-Reply-To: <1383004027-25036-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent
On Tue, 29 Oct 2013, Laurent Pinchart wrote:
> Hello,
>
> This patch series, based on v3.12-rc7, prepares various Renesas drivers
> for migration to multiplatform kernels by enabling their compilation or
> otherwise fixing them on all ARM platforms. The patches are pretty
> straightforward and are described in their commit message.
>
> I'd like to get all these patches merged in v3.14. As they will need to go
> through their respective subsystems' trees, I would appreciate if all
> maintainers involved could notify me when they merge patches from this series
> in their tree to help me tracking the merge status. I don't plan to send pull
> requests individually for these patches, and I will repost patches
> individually if changes are requested during review.
>
> If you believe the issue should be solved in a different way (for instance by
> removing the architecture dependency completely) please reply to the cover
> letter to let other maintainers chime in.
Exactly this was my doubt. If we let these drivers build on all ARM
platforms... Maybe we should just let them build everywhere? Unless there
are real ARM dependencies. Maybe you could try to remove the restriction
and try to build them all on x86?
Thanks
Guennadi
>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: dmaengine@vger.kernel.org
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Eduardo Valentin <eduardo.valentin@ti.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
> Cc: Ian Molton <ian@mnementh.co.uk>
> Cc: iommu@lists.linux-foundation.org
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-i2c@vger.kernel.org
> Cc: linux-input@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> Cc: linux-mmc@vger.kernel.org
> Cc: linux-mtd@lists.infradead.org
> Cc: linux-pm@vger.kernel.org
> Cc: linux-pwm@vger.kernel.org
> Cc: linux-serial@vger.kernel.org
> Cc: linux-spi@vger.kernel.org
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: netdev@vger.kernel.org
> Cc: Samuel Ortiz <samuel@sortiz.org>
> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: Zhang Rui <rui.zhang@intel.com>
>
> Laurent Pinchart (19):
> serial: sh-sci: Enable the driver on all ARM platforms
> DMA: shdma: Enable the driver on all ARM platforms
> i2c: sh_mobile: Enable the driver on all ARM platforms
> input: sh_keysc: Enable the driver on all ARM platforms
> iommu: shmobile: Enable the driver on all ARM platforms
> i2c: rcar: Enable the driver on all ARM platforms
> v4l: sh_vou: Enable the driver on all ARM platforms
> mmc: sdhi: Enable the driver on all ARM platforms
> mmc: sh_mmcif: Enable the driver on all ARM platforms
> mtd: sh_flctl: Enable the driver on all ARM platforms
> net: sh_eth: Set receive alignment correctly on all ARM platforms
> irda: sh_irda: Enable the driver on all ARM platforms
> pinctrl: sh-pfc: Enable the driver on all ARM platforms
> pwm: pwm-renesas-tpu: Enable the driver on all ARM platforms
> sh: intc: Enable the driver on all ARM platforms
> spi: sh_msiof: Enable the driver on all ARM platforms
> spi: sh_hspi: Enable the driver on all ARM platforms
> thermal: rcar-thermal: Enable the driver on all ARM platforms
> fbdev: sh-mobile-lcdcfb: Enable the driver on all ARM platforms
>
> drivers/dma/sh/Kconfig | 2 +-
> drivers/dma/sh/shdmac.c | 6 +++---
> drivers/i2c/busses/Kconfig | 4 ++--
> drivers/input/keyboard/Kconfig | 2 +-
> drivers/iommu/Kconfig | 2 +-
> drivers/media/platform/Kconfig | 2 +-
> drivers/mmc/host/Kconfig | 4 ++--
> drivers/mmc/host/tmio_mmc_dma.c | 2 +-
> drivers/mtd/nand/Kconfig | 2 +-
> drivers/net/ethernet/renesas/sh_eth.c | 2 +-
> drivers/net/ethernet/renesas/sh_eth.h | 2 +-
> drivers/net/irda/Kconfig | 2 +-
> drivers/pinctrl/Makefile | 2 +-
> drivers/pinctrl/sh-pfc/Kconfig | 2 +-
> drivers/pwm/Kconfig | 2 +-
> drivers/sh/intc/Kconfig | 2 +-
> drivers/spi/Kconfig | 4 ++--
> drivers/thermal/Kconfig | 2 +-
> drivers/tty/serial/Kconfig | 2 +-
> drivers/video/Kconfig | 6 +++---
> 20 files changed, 27 insertions(+), 27 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH v2 2/2] net/benet: Make lancer_wait_ready() static
From: Gavin Shan @ 2013-10-29 9:30 UTC (permalink / raw)
To: netdev; +Cc: Sathya.Perla, davem, Gavin Shan
In-Reply-To: <1383039057-28164-1-git-send-email-shangw@linux.vnet.ibm.com>
The function needn't to be public, so to make it as static.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
drivers/net/ethernet/emulex/benet/be_cmds.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 2d55436..7fb0edf 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -522,7 +522,7 @@ static u16 be_POST_stage_get(struct be_adapter *adapter)
return sem & POST_STAGE_MASK;
}
-int lancer_wait_ready(struct be_adapter *adapter)
+static int lancer_wait_ready(struct be_adapter *adapter)
{
#define SLIPORT_READY_TIMEOUT 30
u32 sliport_status;
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 8870837..edf3e8a 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -2053,7 +2053,6 @@ int be_cmd_get_ext_fat_capabilites(struct be_adapter *adapter,
int be_cmd_set_ext_fat_capabilites(struct be_adapter *adapter,
struct be_dma_mem *cmd,
struct be_fat_conf_params *cfgs);
-int lancer_wait_ready(struct be_adapter *adapter);
int lancer_physdev_ctrl(struct be_adapter *adapter, u32 mask);
int lancer_initiate_dump(struct be_adapter *adapter);
bool dump_present(struct be_adapter *adapter);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/2] net/benet: Remove interface type
From: Gavin Shan @ 2013-10-29 9:30 UTC (permalink / raw)
To: netdev; +Cc: Sathya.Perla, davem, Gavin Shan
The interface type, which is being traced by "struct be_adapter::
if_type", isn't used currently. So we can remove that safely
according to Sathya's comments.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/net/ethernet/emulex/benet/be.h | 1 -
drivers/net/ethernet/emulex/benet/be_main.c | 5 -----
2 files changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index b2765eb..2c88ac2 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -470,7 +470,6 @@ struct be_adapter {
u32 rx_fc; /* Rx flow control */
u32 tx_fc; /* Tx flow control */
bool stats_cmd_sent;
- u32 if_type;
struct {
u32 size;
u32 total_size;
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 03e0c74..8080a1a 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4095,11 +4095,6 @@ static int be_roce_map_pci_bars(struct be_adapter *adapter)
static int be_map_pci_bars(struct be_adapter *adapter)
{
u8 __iomem *addr;
- u32 sli_intf;
-
- pci_read_config_dword(adapter->pdev, SLI_INTF_REG_OFFSET, &sli_intf);
- adapter->if_type = (sli_intf & SLI_INTF_IF_TYPE_MASK) >>
- SLI_INTF_IF_TYPE_SHIFT;
if (BEx_chip(adapter) && be_physfn(adapter)) {
adapter->csr = pci_iomap(adapter->pdev, 2, 0);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] net: mvneta: drop redundant mac address check
From: Thomas Petazzoni @ 2013-10-29 9:33 UTC (permalink / raw)
To: Luka Perkov; +Cc: netdev
In-Reply-To: <1383010161-25854-1-git-send-email-luka@openwrt.org>
Dear Luka Perkov,
On Tue, 29 Oct 2013 02:29:21 +0100, Luka Perkov wrote:
> Checking if MAC address is valid using is_valid_ether_addr() is already done in
> of_get_mac_address().
>
> Signed-off-by: Luka Perkov <luka@openwrt.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 4/4] net: mvmdio: doc: mvmdio now used by mv643xx_eth
From: Leigh Brown @ 2013-10-29 9:33 UTC (permalink / raw)
To: David S. Miller
Cc: Leigh Brown, Thomas Petazzoni, Sebastian Hesselbarth, netdev,
linux-arm-kernel, Jason Cooper
In-Reply-To: <cover.1383038973.git.leigh@solinno.co.uk>
Amend the documentation in the mvmdio driver to note the fact
that it is now used by both the mvneta and mv643xx_eth drivers.
Signed-off-by: Leigh Brown <leigh@solinno.co.uk>
---
drivers/net/ethernet/marvell/mvmdio.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 0cfa0c8..0d0311c 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -4,11 +4,9 @@
* Since the MDIO interface of Marvell network interfaces is shared
* between all network interfaces, having a single driver allows to
* handle concurrent accesses properly (you may have four Ethernet
- * ports, but they in fact share the same SMI interface to access the
- * MDIO bus). Moreover, this MDIO interface code is similar between
- * the mv643xx_eth driver and the mvneta driver. For now, it is only
- * used by the mvneta driver, but it could later be used by the
- * mv643xx_eth driver as well.
+ * ports, but they in fact share the same SMI interface to access
+ * the MDIO bus). This driver is currently used by the mvneta and
+ * mv643xx_eth drivers.
*
* Copyright (C) 2012 Marvell
*
--
1.8.4.rc3
^ permalink raw reply related
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