* Re: [PATCH 3/3] net: usb: cdc_ether: use usb.h macros whenever possible
From: Oliver Neukum @ 2013-09-16 11:23 UTC (permalink / raw)
To: Fabio Porcedda
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379324872-15944-4-git-send-email-fabio.porcedda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, 2013-09-16 at 11:47 +0200, Fabio Porcedda wrote:
> Use USB_DEVICE_AND_INTERFACE_INFO and USB_VENDOR_AND_INTERFACE_INFO
> macros to reduce boilerplate.
>
> Signed-off-by: Fabio Porcedda <fabio.porcedda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCH 2/3] net: usb: cdc_ether: fix checkpatch errors and warnings
From: Oliver Neukum @ 2013-09-16 11:21 UTC (permalink / raw)
To: Fabio Porcedda; +Cc: linux-usb, netdev
In-Reply-To: <1379324872-15944-3-git-send-email-fabio.porcedda@gmail.com>
On Mon, 2013-09-16 at 11:47 +0200, Fabio Porcedda wrote:
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Oliver Neukum <oliver@neukum.org>
^ permalink raw reply
* Re: [PATCH 1/3] net: usb: cdc_ether: Use wwan interface for Telit modules
From: Oliver Neukum @ 2013-09-16 11:20 UTC (permalink / raw)
To: Fabio Porcedda; +Cc: linux-usb, netdev, stable
In-Reply-To: <1379324872-15944-2-git-send-email-fabio.porcedda@gmail.com>
On Mon, 2013-09-16 at 11:47 +0200, Fabio Porcedda wrote:
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> Cc: <stable@vger.kernel.org> # 3.0+ as far back as it applies cleanly
Acked-by: Oliver Neukum <oliver@neukum.org>
^ permalink raw reply
* Re: [PATCH 1/1] net: race condition when removing virtual net_device
From: Eric W. Biederman @ 2013-09-16 10:45 UTC (permalink / raw)
To: Francesco Ruggeri
Cc: David S. Miller, Eric Dumazet, Jiri Pirko, Alexander Duyck,
Cong Wang, netdev
In-Reply-To: <CA+HUmGifVOs+d=hs2rTUmMyyK17xfBFFbO8sY=rjS2D=RxFLZg@mail.gmail.com>
Francesco Ruggeri <fruggeri@aristanetworks.com> writes:
> On Fri, Sep 13, 2013 at 6:46 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Francesco Ruggeri <fruggeri@aristanetworks.com> writes:
>>
>>> On Thu, Sep 12, 2013 at 10:50 PM, Eric W. Biederman
>>> <ebiederm@xmission.com> wrote:
>>>
>>> I do have some concerns about both correctness and feasibility of this approach.
>>>
>>> About 2), namespace dependent operations triggered by unregistering
>>> the virtual devices (eg rt_flush_dev, dst_dev_event/dst_ifdown and
>>> probably more) would not be done in the namespaces where they should.
>>
>> Yes they will. That is what dev_change_net_namespace does.
>
> You are right, I don't know what I was thinking.
>> It was worth a second look. I can not find anything wrong with your
>> patch but I can not convince myself that it is correct either. The
>> moving around the loopback device in the net dev todo list to prevent
>> deadlock I can't imagine why you are doing that.
>>
>
> That is in order not to introduce a potential deadlock when multiple
> namespaces are destroyed in default_device_exit_batch.
> Take the same veth scenario as before:
> v0 in namespace ns0 (loopback_dev lo0) and similarly for v1, ns1 and lo1.
> Assume two processes destroy ns0 and ns1. cleanup_net is executed in a
> workqueue and the two namespaces can end up being processed in the
> same instance of cleanup_net/ops_exit_list/default_device_exit_batch.
> default_device_exit_batch traverses each namespace's dev_base list and
> unregister_netdevice_queue is executed in this order:
> v0 v1 lo0 v1 v0 lo1.
> unregister_netdevice_queue is executed twice on v0 and v1 but that is
> ok because it uses list_move_tail and only the last one sticks.
> The resulting list for unregister_netdevice_many is:
> lo0 v1 v0 lo1.
> If v0 holds a reference to lo0 there will be a deadlock in
> netdev_run_todo if v0 does not come before lo0 in net_todo_list. By
> pushing all loopback_devs to the end of net_todo_list this situation
> is avoided.
>
> This is the sequence with today's (actually 3.4) code:
>
> unregister_netdevice_queue: v0 (ns ffff880037aecd00)
> unregister_netdevice_queue: v1 (ns ffff880037aed800)
> unregister_netdevice_queue: lo (ns ffff880037aecd00)
> unregister_netdevice_queue: v1 (ns ffff880037aed800)
> unregister_netdevice_queue: v0 (ns ffff880037aecd00)
> unregister_netdevice_queue: lo (ns ffff880037aed800)
> unregister_netdevice_many: lo (ns ffff880037aecd00) v1 (ns
> ffff880037aed800) v0 (ns ffff880037aecd00) lo (ns ffff880037aed800)
> netdev_run_todo: lo (ns ffff880037aecd00) v1 (ns ffff880037aed800) v0
> (ns ffff880037aecd00) lo (ns ffff880037aed800)
Interesting.
So we have a very small chance of hillarity ensuing with dst_ifdown.
But we probably won't notice because even if lo has been freed
the memory likely hasn't been recycled. So dst_hold likely does not
affect anyone.
So it seems real problems only happens when we send the rebroadcast.
Which explains why this has gone unnoticed for so long.
I really don't want to support concurrency during the network namespace
shutdown. That quickly becomes too crazy to think about.
I believe the weird reordering of veth devices is solved or largely
solved by:
commit f45a5c267da35174e22cec955093a7513dc1623d
Author: Eric Dumazet <edumazet@google.com>
Date: Fri Feb 8 20:10:49 2013 +0000
veth: fix NULL dereference in veth_dellink()
commit d0e2c55e7c940 (veth: avoid a NULL deref in veth_stats_one)
added another NULL deref in veth_dellink().
# ip link add name veth1 type veth peer name veth0
# rmmod veth
We crash because veth_dellink() is called twice, so we must
take care of NULL peer.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Which unfortunately means you really need to test 3.11 or 3.12-rc1
to make headway on this issue. If there is further veth specific
madness we can solve it by tweaking the veth driver.
> and this is the sequence after pushing the loopback_devs to the tail
> of net_todo_list:
>
> unregister_netdevice_queue: v0 (ns ffff8800379f8000)
> unregister_netdevice_queue: v1 (ns ffff8800378c0b00)
> unregister_netdevice_queue: lo (ns ffff8800379f8000)
> unregister_netdevice_queue: v1 (ns ffff8800378c0b00)
> unregister_netdevice_queue: v0 (ns ffff8800379f8000)
> unregister_netdevice_queue: lo (ns ffff8800378c0b00)
> unregister_netdevice_many: lo (ns ffff8800379f8000) v1 (ns
> ffff8800378c0b00) v0 (ns ffff8800379f8000) lo (ns ffff8800378c0b00)
> netdev_run_todo: v1 (ns ffff8800378c0b00) v0 (ns ffff8800379f8000) lo
> (ns ffff8800379f8000) lo (ns ffff8800378c0b00)
I am scratching my head. That isn't what I would expect from putting
loopback devices at the end of the list.
Even more I am not comfortable with any situation where preserving the
order in which the devices are unregistered is not sufficient to make
things work correctly. That quickly gets into fragile layering
problems, and I don't know how anyone would be able to maintain that.
I still don't see a better solution than dev_change_net_namespace,
for the network devices that have this problem. Network devices are not
supposed to be findable after the dance at the start of cleanup_net.
It might be possible to actually build asynchronous network device
unregistration and opportunistick batching. Aka cleanup network devices
much like we clean up network namespaces now, and by funnelling them all
into a single threaded work queue that would probably stop the races, as
well as improve performance. I don't have the energy to do that right
now unfortunately :(
> Should we take this discussion offline?
> I do appreciate your spending time on this.
If anyone complains we can drop them off of the CC but it is useful to
leave a record of the thought process that went into this, so we should
at the minimum keep netdev in the loop.
^ permalink raw reply
* [PATCH net] net: sctp: rfc4443: do not report ICMP redirects to user space
From: Daniel Borkmann @ 2013-09-16 10:36 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-sctp, hannes
Adapt the same behaviour for SCTP as present in TCP for ICMP redirect
messages. For IPv6, RFC4443, section 2.4. says:
...
(e) An ICMPv6 error message MUST NOT be originated as a result of
receiving the following:
...
(e.2) An ICMPv6 redirect message [IPv6-DISC].
...
Therefore, do not report an error to user space, just invoke dst's redirect
callback and leave, same for IPv4 as done in TCP as well. The implication
w/o having this patch could be that the reception of such packets would
generate a poll notification and in worst case it could even tear down the
whole connection. Therefore, stop updating sk_err on redirects.
Reported-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Suggested-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/sctp/input.c | 3 +--
net/sctp/ipv6.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 5f20686..98b69bb 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -634,8 +634,7 @@ void sctp_v4_err(struct sk_buff *skb, __u32 info)
break;
case ICMP_REDIRECT:
sctp_icmp_redirect(sk, transport, skb);
- err = 0;
- break;
+ /* Fall through to out_unlock. */
default:
goto out_unlock;
}
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index 4f52e2c..e7b2d4f 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -183,7 +183,7 @@ static void sctp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
break;
case NDISC_REDIRECT:
sctp_icmp_redirect(sk, transport, skb);
- break;
+ goto out_unlock;
default:
break;
}
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/3] net: usb: cdc_ether: use usb.h macros whenever possible
From: Fabio Porcedda @ 2013-09-16 9:47 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-usb, netdev
In-Reply-To: <1379324872-15944-1-git-send-email-fabio.porcedda@gmail.com>
Use USB_DEVICE_AND_INTERFACE_INFO and USB_VENDOR_AND_INTERFACE_INFO
macros to reduce boilerplate.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
drivers/net/usb/cdc_ether.c | 63 ++++++++++++---------------------------------
1 file changed, 17 insertions(+), 46 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index c36b1c3..2023f3e 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -665,58 +665,33 @@ static const struct usb_device_id products[] = {
*/
{
/* ZTE (Vodafone) K3805-Z */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = ZTE_VENDOR_ID,
- .idProduct = 0x1003,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1003, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&wwan_info,
}, {
/* ZTE (Vodafone) K3806-Z */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = ZTE_VENDOR_ID,
- .idProduct = 0x1015,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1015, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&wwan_info,
}, {
/* ZTE (Vodafone) K4510-Z */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = ZTE_VENDOR_ID,
- .idProduct = 0x1173,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1173, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&wwan_info,
}, {
/* ZTE (Vodafone) K3770-Z */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = ZTE_VENDOR_ID,
- .idProduct = 0x1177,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1177, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&wwan_info,
}, {
/* ZTE (Vodafone) K3772-Z */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = ZTE_VENDOR_ID,
- .idProduct = 0x1181,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1181, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&wwan_info,
}, {
/* Telit modules */
@@ -734,12 +709,8 @@ static const struct usb_device_id products[] = {
}, {
/* Various Huawei modems with a network port like the UMG1831 */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = HUAWEI_VENDOR_ID,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = 255,
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, 255),
.driver_info = (unsigned long)&wwan_info,
},
{ }, /* END */
--
1.8.4
^ permalink raw reply related
* [PATCH 2/3] net: usb: cdc_ether: fix checkpatch errors and warnings
From: Fabio Porcedda @ 2013-09-16 9:47 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-usb, netdev
In-Reply-To: <1379324872-15944-1-git-send-email-fabio.porcedda@gmail.com>
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
drivers/net/usb/cdc_ether.c | 47 +++++++++++++++++++--------------------------
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 98aef3b..c36b1c3 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -33,7 +33,7 @@
#include <linux/usb/usbnet.h>
-#if defined(CONFIG_USB_NET_RNDIS_HOST) || defined(CONFIG_USB_NET_RNDIS_HOST_MODULE)
+#if IS_ENABLED(CONFIG_USB_NET_RNDIS_HOST)
static int is_rndis(struct usb_interface_descriptor *desc)
{
@@ -69,8 +69,7 @@ static const u8 mbm_guid[16] = {
0xa6, 0x07, 0xc0, 0xff, 0xcb, 0x7e, 0x39, 0x2a,
};
-/*
- * probes control interface, claims data interface, collects the bulk
+/* probes control interface, claims data interface, collects the bulk
* endpoints, activates data interface (if needed), maybe sets MTU.
* all pure cdc, except for certain firmware workarounds, and knowing
* that rndis uses one different rule.
@@ -88,7 +87,7 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
struct usb_cdc_mdlm_desc *desc = NULL;
struct usb_cdc_mdlm_detail_desc *detail = NULL;
- if (sizeof dev->data < sizeof *info)
+ if (sizeof(dev->data) < sizeof(*info))
return -EDOM;
/* expect strict spec conformance for the descriptors, but
@@ -126,10 +125,10 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
is_activesync(&intf->cur_altsetting->desc) ||
is_wireless_rndis(&intf->cur_altsetting->desc));
- memset(info, 0, sizeof *info);
+ memset(info, 0, sizeof(*info));
info->control = intf;
while (len > 3) {
- if (buf [1] != USB_DT_CS_INTERFACE)
+ if (buf[1] != USB_DT_CS_INTERFACE)
goto next_desc;
/* use bDescriptorSubType to identify the CDC descriptors.
@@ -139,14 +138,14 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
* in favor of a complicated OID-based RPC scheme doing what
* CDC Ethernet achieves with a simple descriptor.
*/
- switch (buf [2]) {
+ switch (buf[2]) {
case USB_CDC_HEADER_TYPE:
if (info->header) {
dev_dbg(&intf->dev, "extra CDC header\n");
goto bad_desc;
}
info->header = (void *) buf;
- if (info->header->bLength != sizeof *info->header) {
+ if (info->header->bLength != sizeof(*info->header)) {
dev_dbg(&intf->dev, "CDC header len %u\n",
info->header->bLength);
goto bad_desc;
@@ -175,7 +174,7 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
goto bad_desc;
}
info->u = (void *) buf;
- if (info->u->bLength != sizeof *info->u) {
+ if (info->u->bLength != sizeof(*info->u)) {
dev_dbg(&intf->dev, "CDC union len %u\n",
info->u->bLength);
goto bad_desc;
@@ -233,7 +232,7 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
goto bad_desc;
}
info->ether = (void *) buf;
- if (info->ether->bLength != sizeof *info->ether) {
+ if (info->ether->bLength != sizeof(*info->ether)) {
dev_dbg(&intf->dev, "CDC ether len %u\n",
info->ether->bLength);
goto bad_desc;
@@ -274,8 +273,8 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
break;
}
next_desc:
- len -= buf [0]; /* bLength */
- buf += buf [0];
+ len -= buf[0]; /* bLength */
+ buf += buf[0];
}
/* Microsoft ActiveSync based and some regular RNDIS devices lack the
@@ -379,9 +378,7 @@ void usbnet_cdc_unbind(struct usbnet *dev, struct usb_interface *intf)
}
EXPORT_SYMBOL_GPL(usbnet_cdc_unbind);
-/*-------------------------------------------------------------------------
- *
- * Communications Device Class, Ethernet Control model
+/* Communications Device Class, Ethernet Control model
*
* Takes two interfaces. The DATA interface is inactive till an altsetting
* is selected. Configuration data includes class descriptors. There's
@@ -389,8 +386,7 @@ EXPORT_SYMBOL_GPL(usbnet_cdc_unbind);
*
* This should interop with whatever the 2.4 "CDCEther.c" driver
* (by Brad Hards) talked with, with more functionality.
- *
- *-------------------------------------------------------------------------*/
+ */
static void dumpspeed(struct usbnet *dev, __le32 *speeds)
{
@@ -404,7 +400,7 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
{
struct usb_cdc_notification *event;
- if (urb->actual_length < sizeof *event)
+ if (urb->actual_length < sizeof(*event))
return;
/* SPEED_CHANGE can get split into two 8-byte packets */
@@ -423,7 +419,7 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
case USB_CDC_NOTIFY_SPEED_CHANGE: /* tx/rx rates */
netif_dbg(dev, timer, dev->net, "CDC: speed change (len %d)\n",
urb->actual_length);
- if (urb->actual_length != (sizeof *event + 8))
+ if (urb->actual_length != (sizeof(*event) + 8))
set_bit(EVENT_STS_SPLIT, &dev->flags);
else
dumpspeed(dev, (__le32 *) &event[1]);
@@ -469,7 +465,6 @@ EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
static const struct driver_info cdc_info = {
.description = "CDC Ethernet Device",
.flags = FLAG_ETHER | FLAG_POINTTOPOINT,
- // .check_connect = cdc_check_connect,
.bind = usbnet_cdc_bind,
.unbind = usbnet_cdc_unbind,
.status = usbnet_cdc_status,
@@ -493,9 +488,8 @@ static const struct driver_info wwan_info = {
#define DELL_VENDOR_ID 0x413C
#define REALTEK_VENDOR_ID 0x0bda
-static const struct usb_device_id products [] = {
-/*
- * BLACKLIST !!
+static const struct usb_device_id products[] = {
+/* BLACKLIST !!
*
* First blacklist any products that are egregiously nonconformant
* with the CDC Ethernet specs. Minor braindamage we cope with; when
@@ -542,7 +536,7 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
}, {
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
- | USB_DEVICE_ID_MATCH_DEVICE,
+ | USB_DEVICE_ID_MATCH_DEVICE,
.idVendor = 0x04DD,
.idProduct = 0x8007, /* C-700 */
ZAURUS_MASTER_INTERFACE,
@@ -659,8 +653,7 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
},
-/*
- * WHITELIST!!!
+/* WHITELIST!!!
*
* CDC Ether uses two interfaces, not necessarily consecutive.
* We match the main interface, ignoring the optional device
@@ -749,7 +742,7 @@ static const struct usb_device_id products [] = {
.bInterfaceProtocol = 255,
.driver_info = (unsigned long)&wwan_info,
},
- { }, // END
+ { }, /* END */
};
MODULE_DEVICE_TABLE(usb, products);
--
1.8.4
^ permalink raw reply related
* [PATCH 1/3] net: usb: cdc_ether: Use wwan interface for Telit modules
From: Fabio Porcedda @ 2013-09-16 9:47 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-usb, netdev, stable
In-Reply-To: <1379324872-15944-1-git-send-email-fabio.porcedda@gmail.com>
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: <stable@vger.kernel.org> # 3.0+ as far back as it applies cleanly
---
drivers/net/usb/cdc_ether.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 03ad4dc..98aef3b 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -726,6 +726,11 @@ static const struct usb_device_id products [] = {
.bInterfaceProtocol = USB_CDC_PROTO_NONE,
.driver_info = (unsigned long)&wwan_info,
}, {
+ /* Telit modules */
+ USB_VENDOR_AND_INTERFACE_INFO(0x1bc7, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = (kernel_ulong_t) &wwan_info,
+}, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
--
1.8.4
^ permalink raw reply related
* [PATCH 0/3] net: usb: cdc_ether: improve telit support and code cleanups
From: Fabio Porcedda @ 2013-09-16 9:47 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-usb, netdev
Some patches to improve telit modules support and to cleanup the code.
Best regards
Fabio Porcedda (3):
net: usb: cdc_ether: Use wwan interface for Telit modules
net: usb: cdc_ether: fix checkpatch errors and warnings
net: usb: cdc_ether: use usb.h macros whenever possible
drivers/net/usb/cdc_ether.c | 115 ++++++++++++++++----------------------------
1 file changed, 42 insertions(+), 73 deletions(-)
--
1.8.4
^ permalink raw reply
* [PATCH net] ip6_tunnels: raddr and laddr are inverted in nl msg
From: Nicolas Dichtel @ 2013-09-16 9:31 UTC (permalink / raw)
To: davem; +Cc: netdev, Ding Zhi, Nicolas Dichtel
From: Ding Zhi <zhi.ding@6wind.com>
IFLA_IPTUN_LOCAL and IFLA_IPTUN_REMOTE were inverted.
Introduced by c075b13098b3 (ip6tnl: advertise tunnel param via rtnl).
Signed-off-by: Ding Zhi <zhi.ding@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/ip6_tunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 61355f7f4da5..2d8f4829575b 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1656,9 +1656,9 @@ static int ip6_tnl_fill_info(struct sk_buff *skb, const struct net_device *dev)
if (nla_put_u32(skb, IFLA_IPTUN_LINK, parm->link) ||
nla_put(skb, IFLA_IPTUN_LOCAL, sizeof(struct in6_addr),
- &parm->raddr) ||
- nla_put(skb, IFLA_IPTUN_REMOTE, sizeof(struct in6_addr),
&parm->laddr) ||
+ nla_put(skb, IFLA_IPTUN_REMOTE, sizeof(struct in6_addr),
+ &parm->raddr) ||
nla_put_u8(skb, IFLA_IPTUN_TTL, parm->hop_limit) ||
nla_put_u8(skb, IFLA_IPTUN_ENCAP_LIMIT, parm->encap_limit) ||
nla_put_be32(skb, IFLA_IPTUN_FLOWINFO, parm->flowinfo) ||
--
1.8.2.1
^ permalink raw reply related
* RE: [PATCH 5/7: rtlwifi: Fix smatch warning in pci.c
From: David Laight @ 2013-09-16 9:26 UTC (permalink / raw)
To: Larry Finger, linville; +Cc: linux-wireless, netdev
In-Reply-To: <1379094304-22041-6-git-send-email-Larry.Finger@lwfinger.net>
> Smatch reports the following:
> CHECK drivers/net/wireless/rtlwifi/pci.c
> drivers/net/wireless/rtlwifi/pci.c:739 _rtl_pci_rx_interrupt() warn: assigning (-98) to unsigned
> variable 'stats.noise'
>
> This problem is fixed by changing the value to 256 - 98.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/net/wireless/rtlwifi/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
> index 703f839..bf498f5 100644
> --- a/drivers/net/wireless/rtlwifi/pci.c
> +++ b/drivers/net/wireless/rtlwifi/pci.c
> @@ -736,7 +736,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
>
> struct rtl_stats stats = {
> .signal = 0,
> - .noise = -98,
> + .noise = 158, /* -98 dBm */
> .rate = 0,
> };
> int index = rtlpci->rx_ring[rx_queue_idx].idx;
That doesn't look nice at all.
Something like (unsigned int)-98 would be slightly better,
but it looks as though something is actually wrong with
the type of 'noise' itself.
David
^ permalink raw reply
* RE: [PATCH] net, mellanox mlx4 Fix compile warnings
From: David Laight @ 2013-09-16 8:59 UTC (permalink / raw)
To: Jack Morgenstein, Or Gerlitz
Cc: Prarit Bhargava, netdev, Doug Ledford, Amir Vadai, Or Gerlitz
In-Reply-To: <20130915091400.49f90bc4@jpm-OptiPlex-GX620>
> On Sat, 14 Sep 2013 22:10:19 +0300
> Or Gerlitz <or.gerlitz@gmail.com> wrote:
>
> > > + struct res_cq *uninitialized_var(cq);
> > >
> > > err = cq_res_start_move_to(dev, slave, cqn,
> > > RES_CQ_ALLOCATED, &cq);
>
> I have no objection. However, I don't know if the compiler is being too
> clever here or too stupid. The cq variable is initialized in
> cq_res_start_move_to(), but the compiler is ignoring this -- or maybe
> it is simply not assuming that cq will in fact be
> initialized by the called procedure?
Possibly cq_res_start_move_to() got inlined - and the analysis
of the inlined code found a path where it wasn't initialised.
Most likely one of the paths where the return value is non-zero.
> In any event, this change cannot hurt.
It could hide a real 'used but not initialised' error later on...
David
^ permalink raw reply
* Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
From: Thomas Gleixner @ 2013-09-16 9:01 UTC (permalink / raw)
To: Fan Du
Cc: David Miller, herbert, steffen.klassert, dborkman, linux-kernel,
netdev, John Stultz
In-Reply-To: <52365021.8040906@windriver.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2076 bytes --]
On Mon, 16 Sep 2013, Fan Du wrote:
> On 2013年09月13日 22:32, Thomas Gleixner wrote:
> > On Fri, 13 Sep 2013, Fan Du wrote:
> > > (2) What I have been bugging you around here for this long time is really
> > > the
> > > second
> > > problem, I'm sorry I didn't make it clearly to you and others, which
> > > is
> > > below:
> > >
> > > Why using wall clock time to calculate soft/hard IPsec events when
> > > xfrm_state timer
> > > out happens in its timeout handler? Because even if xfrm_state using
> > > CLOCK_BOOTTIME,
> > > system wall clock time changing will surely disturb soft/hard IPsec
> > > events, which
> > > you raised your concern about in (*a*).
> >
> > No CLOCK_BOOTTIME is not affected by wall clock time changes. It's
> > basically CLOCK_MONOTONIC, it just keeps counting the suspend time as
> > well. So without a suspend/resume cycle CLOCK_MONOTONIC and
> > CLOCK_BOOTTIME are the same. After a suspend/resume cycle
> > CLOCK_BOOTTIME will be N seconds ahead of CLOCK_MONOTONIC, where N is
> > the number of seconds spent in suspend.
>
> Sorry for the ambiguity. Yes, CLOCK_BOOTTIME is monotonic *and* counting
> suspend/resume time as well as not affected by wall clock time change.
>
> Using CLOCK_BOOTTIME guarantees b- will timeout in a right manner, i.e., not
> affected by wall clock time change, as well as keep the timer valid when
> suspend/resume.
>
> A classic way of using timer is:
> a- Arm a timer with specified interval
> b- Wait for the timer to timeout
> c- After the timeout, notify the event to other place in the timer handler.
>
> IPsec key lifetime timer does its this way:
> a- Arm a timer with specified interval
> b- Wait for the timer to timeout
> c- After timeout, in the timer handler, using wall clock time to calculate
> which kind of event to notify user(soft or hard for both key use time,
> and key created time). So the problem arises at this stage if wall clock
> time changed.
And why on earth must it use wall clock time for selecting the event
type?
Thanks,
tglx
^ permalink raw reply
* Re: mvneta: oops in __rcu_read_lock on mirabox
From: Ethan Tuttle @ 2013-09-16 8:56 UTC (permalink / raw)
To: Willy Tarreau
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, netdev,
Ezequiel Garcia, Gregory Clément, linux-arm-kernel
In-Reply-To: <20130916065047.GH27487@1wt.eu>
Hi guys. Here's the config I was building with:
https://gist.github.com/anonymous/6578139
It's based on the one I found in archlinuxarm's git repo. I didn't
change any of the options - at least, not manually.
Thanks for the follow up!
Ethan
On Sun, Sep 15, 2013 at 11:50 PM, Willy Tarreau <w@1wt.eu> wrote:
> Hi Thomas,
>
> On Sun, Sep 15, 2013 at 08:57:01PM +0200, Thomas Petazzoni wrote:
>> Hello Ethan,
>>
>> On Sat, 14 Sep 2013 18:05:32 -0700, Ethan Tuttle wrote:
>> > When I upgraded my mirabox from 3.11-rc4 to 3.11, I started seeing
>> > oopses while receiving network traffic (see below). Sending a flood
>> > ping will trigger the oops within a few minutes.
>> >
>> > The stack looks similar, but not identical to, the one reported
>> > earlier by Jochen De Smet[1]. In my case the PC is always
>> > __rcu_read_lock.
>> >
>> > A git bisect found a878764 "Merge
>> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net" to be the
>> > first bad commit... interesting, because neither of the merge parents
>> > produce the oops. I rebased the net changes onto the other merge
>> > parent and bisected that series, which identified 702821f "net: revert
>> > 8728c544a9c ("net: dev_pick_tx() fix")" as the first bad commit.
>> > Indeed, reverting 702821f from 3.11 produces a kernel which stands up
>> > to a ping flood for hours.
>> >
>> > Each of the times I reproduced this, it was identified as "Unhandled
>> > prefetch abort: unknown 25 (0x409) at 0xc0036ea0", except once when I
>> > got "unknown 16 (0x400)".
>> >
>> > I'm assuming this is an mvneta bug that was exposed by 702821f.
>> > That's just a guess, and I don't have the skills to debug this any
>> > further. In any case, I figured the maintainers would want to know
>> > about it.
>>
>> Thanks a lot for the report and the detailed investigation.
>> Unfortunately, I don't have Armada 370 hardware with me this week, so
>> I'm unable to test and reproduce the issue.
>>
>> However, I've added a bunch of Armada 370 people/maintainers in Cc,
>> hopefully they can at least try to reproduce and confirm that reverting
>> this patch makes the problem go away, which would confirm that we
>> should look for a bug in the mvneta driver around this problem.
>
> I'm currently testing on 3.11.1 (which I had here) and am not getting
> any issue after 50M packets. My kernel is running in thumb mode and
> without SMP.
>
> Ethan, we'll need your config I guess.
>
> Thanks,
> Willy
>
^ permalink raw reply
* Re: usbnet transmit path problems
From: Oliver Neukum @ 2013-09-16 8:13 UTC (permalink / raw)
To: Ming Lei; +Cc: David Laight, Network Development, linux-usb
In-Reply-To: <CACVXFVNrbeEthBH0vGKN2gymoSwu3jTkcGicKNU1-Oez8bNhvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2013-09-12 at 09:56 +0800, Ming Lei wrote:
> On Thu, Sep 12, 2013 at 12:05 AM, David Laight <David.Laight-JxhZ9S5GRejQT0dZR+AlfA@public.gmane.org> wrote:
> Patches are always welcome, :-)
Indeed, I think your patch, if no better alternatives come up soon,
should be taken.
> > None of this is helping me sort out why netperf udp rr tests with
> > burst 19 are losing all the packets at once :-(
>
> If you can share your test case, guys in list may help you to troubleshoot
> it, :-)
Indeed.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: mvneta: oops in __rcu_read_lock on mirabox
From: Willy Tarreau @ 2013-09-16 6:50 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Ethan Tuttle, Andrew Lunn, Jason Cooper, netdev, Ezequiel Garcia,
Gregory Clément, linux-arm-kernel
In-Reply-To: <20130915205701.5c61a444@skate>
Hi Thomas,
On Sun, Sep 15, 2013 at 08:57:01PM +0200, Thomas Petazzoni wrote:
> Hello Ethan,
>
> On Sat, 14 Sep 2013 18:05:32 -0700, Ethan Tuttle wrote:
> > When I upgraded my mirabox from 3.11-rc4 to 3.11, I started seeing
> > oopses while receiving network traffic (see below). Sending a flood
> > ping will trigger the oops within a few minutes.
> >
> > The stack looks similar, but not identical to, the one reported
> > earlier by Jochen De Smet[1]. In my case the PC is always
> > __rcu_read_lock.
> >
> > A git bisect found a878764 "Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net" to be the
> > first bad commit... interesting, because neither of the merge parents
> > produce the oops. I rebased the net changes onto the other merge
> > parent and bisected that series, which identified 702821f "net: revert
> > 8728c544a9c ("net: dev_pick_tx() fix")" as the first bad commit.
> > Indeed, reverting 702821f from 3.11 produces a kernel which stands up
> > to a ping flood for hours.
> >
> > Each of the times I reproduced this, it was identified as "Unhandled
> > prefetch abort: unknown 25 (0x409) at 0xc0036ea0", except once when I
> > got "unknown 16 (0x400)".
> >
> > I'm assuming this is an mvneta bug that was exposed by 702821f.
> > That's just a guess, and I don't have the skills to debug this any
> > further. In any case, I figured the maintainers would want to know
> > about it.
>
> Thanks a lot for the report and the detailed investigation.
> Unfortunately, I don't have Armada 370 hardware with me this week, so
> I'm unable to test and reproduce the issue.
>
> However, I've added a bunch of Armada 370 people/maintainers in Cc,
> hopefully they can at least try to reproduce and confirm that reverting
> this patch makes the problem go away, which would confirm that we
> should look for a bug in the mvneta driver around this problem.
I'm currently testing on 3.11.1 (which I had here) and am not getting
any issue after 50M packets. My kernel is running in thumb mode and
without SMP.
Ethan, we'll need your config I guess.
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH] ethernet/arc/arc_emac: Fix huge delays in large file copies
From: Vineet Gupta @ 2013-09-16 5:43 UTC (permalink / raw)
To: greg Kroah-Hartman
Cc: David Miller, netdev, Alexey.Brodkin, linux-kernel,
stable@vger.kernel.org
In-Reply-To: <522EBBD2.1060003@synopsys.com>
On 09/10/2013 11:57 AM, Vineet Gupta wrote:
> On 09/05/2013 11:55 PM, David Miller wrote:
>> From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
>> Date: Wed, 4 Sep 2013 17:17:15 +0530
>>
>>> copying large files to a NFS mounted host was taking absurdly large
>>> time.
>>>
>>> Turns out that TX BD reclaim had a sublte bug.
>>>
>>> Loop starts off from @txbd_dirty cursor and stops when it hits a BD
>>> still in use by controller. However when it stops it needs to keep the
>>> cursor at that very BD to resume scanning in next iteration. However it
>>> was erroneously incrementing the cursor, causing the next scan(s) to
>>> fail too, unless the BD chain was completely drained out.
>>>
>>> [ARCLinux]$ ls -l -sh /disk/log.txt
>>> 17976 -rw-r--r-- 1 root root 17.5M Sep /disk/log.txt
>>>
>>> ========== Before =====================
>>> [ARCLinux]$ time cp /disk/log.txt /mnt/.
>>> real 31m 7.95s
>>> user 0m 0.00s
>>> sys 0m 0.10s
>>>
>>> ========== After =====================
>>> [ARCLinux]$ time cp /disk/log.txt /mnt/.
>>> real 0m 24.33s
>>> user 0m 0.00s
>>> sys 0m 0.19s
>>>
>>> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>>
>> Applied.
>>
>
> Hi Greg,
>
> This needs a stable backport (3.11).
> Mainline commit 27082ee1b92f4d41e78b85
>
> Thx,
> -Vineet
Hi Greg,
I didn't spot this one in your stable-queue for 3.11.
Please apply.
Thx,
Vineet
^ permalink raw reply
* Re: [PATCH] cxgb4: remove workqueue when driver registration fails
From: Wei Yang @ 2013-09-16 5:28 UTC (permalink / raw)
To: David Miller; +Cc: weiyang, dm, netdev
In-Reply-To: <20130916.005324.187580687457026092.davem@davemloft.net>
On Mon, Sep 16, 2013 at 12:53:24AM -0400, David Miller wrote:
>From: Wei Yang <weiyang@linux.vnet.ibm.com>
>Date: Sun, 15 Sep 2013 21:53:00 +0800
>
>> When driver registration fails, we need to clean up the resources allocated
>> before. cxgb4 missed to destroy the workqueue allocated at the very beginning.
>>
>> This patch destroies the workqueue when registration fails.
>>
>> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>
>Applied.
Thanks~
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH] net: ps3_gelic: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:56 UTC (permalink / raw)
To: michael.opdenacker; +Cc: geoff, netdev, cbe-oss-dev, linux-kernel
In-Reply-To: <1379046798-7192-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:33:18 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/toshiba/ps3_gelic_net.c
>
> It's a NOOP since 2.6.35 and I will remove it one day ;)
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: smsc: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:56 UTC (permalink / raw)
To: michael.opdenacker; +Cc: steve.glendinning, netdev, linux-kernel, will.deacon
In-Reply-To: <1379046467-6900-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:27:47 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> code in drivers/net/ethernet/smsc/
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: pasemi: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: olof, netdev, linux-kernel
In-Reply-To: <1379046084-6825-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:21:24 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/pasemi/pasemi_mac.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: natsemi: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: netdev, linux-kernel
In-Reply-To: <1379045813-6762-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:16:53 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> code in drivers/net/ethernet/natsemi/
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ks8851-ml: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: netdev, linux-kernel
In-Reply-To: <1379045410-6687-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:10:10 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/micrel/ks8851_mll.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: pxa168_eth: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: netdev, linux-kernel
In-Reply-To: <1379045063-6604-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:04:23 +0200
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: lantiq_etop: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: netdev, linux-kernel
In-Reply-To: <1379044782-6542-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 05:59:42 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/lantiq_etop.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ 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