* Re: pull request: wireless 2012-08-03
From: David Miller @ 2012-08-03 23:41 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20120803145604.GA6372@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 3 Aug 2012 10:56:04 -0400
> This request covers a batch of fixes intended for the 3.6 stream.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH] emulex: benet: Add a missing CR in the end of message
From: David Miller @ 2012-08-03 23:43 UTC (permalink / raw)
To: standby24x7
Cc: linux-kernel, netdev, sathya.perla, subbu.seetharaman,
ajit.khaparde
In-Reply-To: <1343997411-10465-1-git-send-email-standby24x7@gmail.com>
From: Masanari Iida <standby24x7@gmail.com>
Date: Fri, 3 Aug 2012 21:36:51 +0900
> Missing a CR in printk causes 2 messages printed in one line.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-08-03 23:47 UTC (permalink / raw)
To: Tejun Heo
Cc: Sasha Levin, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <20120803223634.GO15477@google.com>
On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo <tj@kernel.org> wrote:
>
> I suppose you mean unsized. I remember this working. Maybe I'm
> confusing it with zero-sized array. Hmm... gcc doesn't complain about
> the following. --std=c99 seems happy too.
Ok, I'm surprised, but maybe it's supposed to work if you do it inside
another struct like that, exactly so that you can preallocate things..
Or maybe it's just a gcc bug. I do think this all is way hackier than
Sasha's original simple code that didn't need these kinds of games,
and didn't need a size member at all.
I really think all the extra complexity and overhead is just *bad*.
The first simple version was much nicer and likely generated better
code too.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net] net_sched: gact: Fix potential panic in tcf_gact().
From: David Miller @ 2012-08-03 23:47 UTC (permalink / raw)
To: shimoda.hiroaki; +Cc: netdev
In-Reply-To: <20120803195752.32410768d3d806cd241ac7a4@gmail.com>
From: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date: Fri, 3 Aug 2012 19:57:52 +0900
> gact_rand array is accessed by gact->tcfg_ptype whose value
> is assumed to less than MAX_RAND, but any range checks are
> not performed.
>
> So add a check in tcf_gact_init(). And in tcf_gact(), we can
> reduce a branch.
>
> Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH V1 1/3] net/mlx4_en: loopbacked packets are dropped when SMAC=DMAC
From: David Miller @ 2012-08-03 23:49 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev, amirv
In-Reply-To: <1343990318-10744-2-git-send-email-yevgenyp@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Fri, 3 Aug 2012 13:38:36 +0300
> From: Amir Vadai <amirv@mellanox.com>
>
> Should NOT check SMAC=DMAC when:
> 1. loopback is turned on
> 2. validate_loopback is true.
>
> Fixed it accordingly.
>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH V1 2/3] net/mlx4_en: Fixing TX queue stop/wake flow
From: David Miller @ 2012-08-03 23:49 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <1343990318-10744-3-git-send-email-yevgenyp@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Fri, 3 Aug 2012 13:38:37 +0300
> Removing the ring->blocked flag, it is redundant and leads to a race:
>
> We close the TX queue and then set the "blocked" flag.
> Between those 2 operations the completion function can check the "blocked"
> flag, sees that it is 0, and wouldn't open the TX queue.
>
> Using netif_tx_queue_stopped to check the state of the queue to avoid this race.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Applied.
^ permalink raw reply
* Re: [PATCH V1 3/3] net/mlx4_core: Remove port type restrictions
From: David Miller @ 2012-08-03 23:50 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <1343990318-10744-4-git-send-email-yevgenyp@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Fri, 3 Aug 2012 13:38:38 +0300
> Port1=Eth, Port2=IB restriction is no longer required.
> Having RoCE, there will always rdma port initialized over ConnectX
> physical port, no matter whether the link layer is IB or Ethernet.
> So we always have dual port IB device.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Applied.
^ permalink raw reply
* Re: [PATCH net-next,1/1] hyperv: Move wait completion msg code into rndis_filter_halt_device()
From: David Miller @ 2012-08-03 23:52 UTC (permalink / raw)
To: haiyangz; +Cc: netdev, kys, olaf, jasowang, linux-kernel, devel
In-Reply-To: <1344022338-3010-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Fri, 3 Aug 2012 12:32:18 -0700
> We need to wait for send_completion msg before put_rndis_request() at
> the end of rndis_filter_halt_device(). Otherwise, netvsc_send_completion()
> may reference freed memory which is overwritten, and cause panic.
>
> Reported-by: Long Li <longli@microsoft.com>
> Reported-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
This is a bug fix, so applied to 'net'. Please target your patches
properly.
Don't just be afraid that I'll reject the patch if you target it
at 'net', and therefore just target everything at 'net-next'. That
is certainly worse.
^ permalink raw reply
* Re: [PATCH] ipv4: remove parentheses in return statement
From: David Miller @ 2012-08-03 23:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: sakiwit, netdev
In-Reply-To: <1343987638.9299.912.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 03 Aug 2012 11:53:58 +0200
> We already have such thing in fact : net_hash_mix() which returns 0 if
> NS are not configured.
>
> (hash_ptr(net,8) is really overkill on 64bit arches)
>
> High order bits on "struct net *" have absolutely no entropy, unless you
> have a monster machine (more than 256 GB of ram)
>
> This is the patch I prepared :
Looks good to me.
^ permalink raw reply
* Re: [PATCH v3] isdnloop: fix and simplify isdnloop_init()
From: David Miller @ 2012-08-03 23:53 UTC (permalink / raw)
To: fengguang.wu
Cc: netdev, dan.carpenter, gregkh, devel, joe, isdn, linux-kernel
In-Reply-To: <20120803091001.GA15772@localhost>
From: Fengguang Wu <fengguang.wu@intel.com>
Date: Fri, 3 Aug 2012 17:10:01 +0800
> Fix a buffer overflow bug by removing the revision and printk.
>
> [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
> [ 22.097508] isdnloop: (loop0) virtual card added
> [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
> [ 22.174400]
> [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
> [ 22.624071] Call Trace:
> [ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
> [ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
> [ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
> [ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: David Miller @ 2012-08-03 23:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: ebiederm, xemul, netdev
In-Reply-To: <1343972729.9299.596.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 03 Aug 2012 07:45:29 +0200
> @@ -1587,13 +1587,11 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> if (ipv4_is_zeronet(daddr))
> goto martian_destination;
>
> - if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
> - if (ipv4_is_loopback(daddr))
> - goto martian_destination;
> + if (ipv4_is_loopback(daddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
> + goto martian_destination;
>
> - if (ipv4_is_loopback(saddr))
> - goto martian_source;
> - }
> + if (ipv4_is_loopback(saddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
> + goto martian_source;
Maybe clearer as:
if ((ipv4_is_loopback(daddr) || ipv4_is_loopback(saddr)) &&
!IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
goto martian_source;
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Ali Ayoub @ 2012-08-04 0:02 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, ogerlitz, roland, netdev, sean.hefty, erezsh
In-Reply-To: <501C5328.4060301@mellanox.com>
On 8/3/2012 3:39 PM, Ali Ayoub wrote:
> On 8/3/2012 2:33 PM, David Miller wrote:
>> From: Ali Ayoub <ali@mellanox.com>
>> Date: Fri, 03 Aug 2012 13:31:35 -0700
>>
>>> With eIPoIB architecture, the VM sees standard Ethernet emulator,
>>> allowing the administrator to enslave eIPoIB PIF to the vSwitch/vBridge
>>> as if it was standard Ethernet. Other approaches that exposes IB QP to
>>> the VM (with w/o bypassing the kernel) won't be possible with the
>>> current emulators and management tools.
>>
>> So then fix the emulators and management tools to handle IB instead
>> of adding this bogus new protocol?
>>
>> This new protocol seems to exist only because you don't want to have
>> to enhance the emulators and tools, and I'm sorry that isn't a valid
>> reason to do something like this.
>
> This driver exists to allow the user to have an Ethernet interface on
> top of a high-speed InfiniBand (IB) interconnect.
> Users would like to use sockets API from the VM without re-writing their
> applications on top of IB verbs, this driver meant to allow such a user
> to do so.
>
> Exposing IB emulators and having IB support in the management tools for
> the VM/Hypervisor won't address the usecases that this driver meant for.
>
> With this driver, existing VMs, and their existing IP applications, can
> run as-is on InfiniBand network.
This driver exists to allow the user to have an Ethernet interface on
top of a high-speed InfiniBand (IB) interconnect.
Users would like to use sockets API from the VM without re-writing their
applications on top of IB verbs, this driver meant to allow such a user
to do so.
Exposing IB emulators and having IB support in the management tools for
the VM/Hypervisor won't address the usecases that this driver meant for.
With this driver, existing VMs, and their existing IP applications, can
run as-is on InfiniBand network.
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-08-04 0:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tejun Heo, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <CA+55aFwTa_kYgmFwoWa6hwAAM6=2xTgQQf-vEx_gCzpEMnxodQ@mail.gmail.com>
Hi Linus,
On 08/04/2012 01:47 AM, Linus Torvalds wrote:
> Or maybe it's just a gcc bug. I do think this all is way hackier than
> Sasha's original simple code that didn't need these kinds of games,
> and didn't need a size member at all.
>
> I really think all the extra complexity and overhead is just *bad*.
> The first simple version was much nicer and likely generated better
> code too.
The problem with that code was that it doesn't work with dynamically allocated hashtables, or hashtables that grow/shrink.
The alternative to going down this path, is going back to the old code and saying that it only works for the simple case, and if you're interested in something more complex it should have it's own different implementation.
Does it make sense? We'll keep the simple & common case simple, and let anyone who needs something more complex than this write it as an extension?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-08-04 0:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sasha Levin, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <CA+55aFwTa_kYgmFwoWa6hwAAM6=2xTgQQf-vEx_gCzpEMnxodQ@mail.gmail.com>
Hello,
On Fri, Aug 03, 2012 at 04:47:47PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo <tj@kernel.org> wrote:
> >
> > I suppose you mean unsized. I remember this working. Maybe I'm
> > confusing it with zero-sized array. Hmm... gcc doesn't complain about
> > the following. --std=c99 seems happy too.
>
> Ok, I'm surprised, but maybe it's supposed to work if you do it inside
> another struct like that, exactly so that you can preallocate things..
Yeah, I think the rule is var array should be the last member of any
given struct definition. Once a struct is defined, its alignment and
size are fixed and it behaves like any other struct.
> Or maybe it's just a gcc bug. I do think this all is way hackier than
> Sasha's original simple code that didn't need these kinds of games,
> and didn't need a size member at all.
>
> I really think all the extra complexity and overhead is just *bad*.
> The first simple version was much nicer and likely generated better
> code too.
The size member could have performance impact in extreme cases. If
we're looking for something simple & fast, maybe just pass in @size as
argument and be done with it?
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-08-04 0:05 UTC (permalink / raw)
To: Sasha Levin
Cc: Tejun Heo, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <501C66C2.2020706@gmail.com>
On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
>
> The problem with that code was that it doesn't work with dynamically allocated hashtables, or hashtables that grow/shrink.
Sure. But once you have that kind of complexity, why would you care
about the trivial cases?
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: David Miller @ 2012-08-04 0:05 UTC (permalink / raw)
To: ali; +Cc: ebiederm, ogerlitz, roland, netdev, sean.hefty, erezsh
In-Reply-To: <501C669B.2030303@mellanox.com>
From: Ali Ayoub <ali@mellanox.com>
Date: Fri, 03 Aug 2012 17:02:35 -0700
> On 8/3/2012 3:39 PM, Ali Ayoub wrote:
>> On 8/3/2012 2:33 PM, David Miller wrote:
>>> From: Ali Ayoub <ali@mellanox.com>
>>> Date: Fri, 03 Aug 2012 13:31:35 -0700
>>>
>>>> With eIPoIB architecture, the VM sees standard Ethernet emulator,
>>>> allowing the administrator to enslave eIPoIB PIF to the vSwitch/vBridge
>>>> as if it was standard Ethernet. Other approaches that exposes IB QP to
>>>> the VM (with w/o bypassing the kernel) won't be possible with the
>>>> current emulators and management tools.
>>>
>>> So then fix the emulators and management tools to handle IB instead
>>> of adding this bogus new protocol?
>>>
>>> This new protocol seems to exist only because you don't want to have
>>> to enhance the emulators and tools, and I'm sorry that isn't a valid
>>> reason to do something like this.
>>
>> This driver exists to allow the user to have an Ethernet interface on
>> top of a high-speed InfiniBand (IB) interconnect.
>> Users would like to use sockets API from the VM without re-writing their
>> applications on top of IB verbs, this driver meant to allow such a user
>> to do so.
>>
>> Exposing IB emulators and having IB support in the management tools for
>> the VM/Hypervisor won't address the usecases that this driver meant for.
>>
>> With this driver, existing VMs, and their existing IP applications, can
>> run as-is on InfiniBand network.
>
> This driver exists to allow the user to have an Ethernet interface on
> top of a high-speed InfiniBand (IB) interconnect.
> Users would like to use sockets API from the VM without re-writing their
> applications on top of IB verbs, this driver meant to allow such a user
> to do so.
>
> Exposing IB emulators and having IB support in the management tools for
> the VM/Hypervisor won't address the usecases that this driver meant for.
>
> With this driver, existing VMs, and their existing IP applications, can
> run as-is on InfiniBand network.
Just saying the same thing twice doesn't make your argument stronger.
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-08-04 0:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tejun Heo, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <CA+55aFziVRRBoTnm2zASGR39W1AB+0=4Sa7qO8e6_hN06ZY8wg@mail.gmail.com>
On 08/04/2012 02:05 AM, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
>>
>> The problem with that code was that it doesn't work with dynamically allocated hashtables, or hashtables that grow/shrink.
>
> Sure. But once you have that kind of complexity, why would you care
> about the trivial cases?
Because there are far more trivial cases than complex ones - I've counted 50+ of these "trivial" cases.
None of them need the complexity we're trying to deal with at the moment.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] cris: fix eth_v10.c build error
From: Randy Dunlap @ 2012-08-04 0:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel, Mikael Starvik, Jesper Nilsson, linux-cris-kernel,
netdev, David Miller
In-Reply-To: <1344002771-21072-1-git-send-email-geert@linux-m68k.org>
From: Randy Dunlap <rdunlap@xenotime.net>
Fix build error on cris (not tested, no toolchain here):
drivers/net/cris/eth_v10.c: error: too many arguments to function 'e100rxtx_interrupt'
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: linux-cris-kernel@axis.com
---
drivers/net/cris/eth_v10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-36-rc1.orig/drivers/net/cris/eth_v10.c
+++ lnx-36-rc1/drivers/net/cris/eth_v10.c
@@ -1712,7 +1712,7 @@ e100_set_network_leds(int active)
static void
e100_netpoll(struct net_device* netdev)
{
- e100rxtx_interrupt(NETWORK_DMA_TX_IRQ_NBR, netdev, NULL);
+ e100rxtx_interrupt(NETWORK_DMA_TX_IRQ_NBR, netdev);
}
#endif
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Eric W. Biederman @ 2012-08-04 1:34 UTC (permalink / raw)
To: Ali Ayoub, David Miller; +Cc: ogerlitz, roland, netdev, sean.hefty, erezsh
In-Reply-To: <501C669B.2030303@mellanox.com>
Ali Ayoub <ali@mellanox.com> wrote:
>
>With this driver, existing VMs, and their existing IP applications, can
>run as-is on InfiniBand network.
Actually it doesn't work like that.
If my application really needs ethernet it will not work with your driver. I can not run decnet or appletalk or ATAoE or PPPoE or LACP or use VLANs or any of a thousand other things that require real live ethernet to function.
Most VMs will talk to linux with a tap interface, and the output of a tap interface can be routed just fine, and that works with existing tools, and existing already deployed kernels.
Alternatively if you are silly you can implement a tap interface on top of IPoIB and have the same interface you do now, and it works with existing already deployed kernels.
So eIPoIB does not make sense from a time to market perspective.
Similarly eIPoIB does not make sense from a performance standpoint because the best performance requires the applications and hypervisors are infiniband and teaching the apps to cope.
eIPoIB also has considerable maintenance overhead as it is complex code doing some crazy things.
Now personally NAPT44 just about made the internet unusable for peer to peer appications. NAT66 aka network prefix translation introduces much less breakage but it still requires someone to run STUN on IPv6 to keep applications working, ick. NATEIB aka eIPoIB just looks complex and already breaks most of ethernet and history says that kind of breakage actually matters a lot. I think everyone who suggests any kind of NAT is a good idea should have to implement RFC 5245 Interacive Connectivity Establishment. It takes 2 100+ page rfcs to come up with a way that allows applications to with the address munging over the open internet. That way takes 3000+ lines of code in each application. That is the kind of complexity you are asking people up stream of you to deal with your NATTing o
f ethernet to infiniband. So I totally think eIPoIB stinks, and that it does not at all let existing applications work without modification.
Eric
^ permalink raw reply
* Re: [PATCH] cdc-ncm: tag Ericsson WWAN devices (eg F5521gw) with FLAG_WWAN
From: David Miller @ 2012-08-04 3:32 UTC (permalink / raw)
To: meiser-rJBqYz9TEJZKTQ5g00o1eQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <501A72DC.7070306-rJBqYz9TEJZKTQ5g00o1eQ@public.gmane.org>
From: Peter Meiser <meiser-rJBqYz9TEJZKTQ5g00o1eQ@public.gmane.org>
Date: Thu, 02 Aug 2012 14:30:20 +0200
> looking at http://sourceforge.net/apps/mediawiki/mbm/index.php?title=Main_Page#Supported_devices, there are branded Ericsson devices from Dell and Toshiba.
>
> The to-be-added vendor IDs are 0x413c for Dell and 0x0930 for Toshiba.
>
> Please find attached a patch to add these vendor IDs.
>
> Signed-off-by: Peter Meiser <meiser-rJBqYz9TEJZKTQ5g00o1eQ@public.gmane.org>
Applied, thanks.
--
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] cris: fix eth_v10.c build error
From: David Miller @ 2012-08-04 3:33 UTC (permalink / raw)
To: rdunlap
Cc: geert, linux-kernel, starvik, jesper.nilsson, linux-cris-kernel,
netdev
In-Reply-To: <501C6EEF.3030100@xenotime.net>
From: Randy Dunlap <rdunlap@xenotime.net>
Date: Fri, 03 Aug 2012 17:38:07 -0700
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Fix build error on cris (not tested, no toolchain here):
>
> drivers/net/cris/eth_v10.c: error: too many arguments to function 'e100rxtx_interrupt'
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH] firmware: Remove obsolete Chelsio cxgb3 firmware
From: David Miller @ 2012-08-04 3:41 UTC (permalink / raw)
To: tim.gardner
Cc: linux-kernel, paul.gortmaker, ben, JBottomley, dan.j.williams,
divy, netdev
In-Reply-To: <501A728A.2070905@canonical.com>
From: Tim Gardner <tim.gardner@canonical.com>
Date: Thu, 02 Aug 2012 06:28:58 -0600
> git://kernel.ubuntu.com/rtg/net-next.git master
>
> for you to fetch changes up to 044b722f36a17bc5f7f472cc3246cb15a430bb0e:
>
> firmware: Remove obsolete Chelsio cxgb3 firmware (2012-08-02 06:23:25
> -0600)
Pulled, thanks.
^ permalink raw reply
* Re: [patch net-next 0/4] add support for queue override by setting queue_id for port
From: David Miller @ 2012-08-04 3:41 UTC (permalink / raw)
To: jiri; +Cc: netdev, edumazet
In-Reply-To: <1343406535-22388-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 27 Jul 2012 18:28:51 +0200
> Jiri Pirko (4):
> netlink: add signed types
> team: add signed 32-bit team option type
> team: add per port priority option
> team: add support for queue override by setting queue_id for port
All applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] ppp: add 64 bit stats
From: David Miller @ 2012-08-04 3:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: kgroeneveld, netdev
In-Reply-To: <1343461141.2626.13122.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 28 Jul 2012 09:39:01 +0200
> On Fri, 2012-07-27 at 23:38 -0400, Kevin Groeneveld wrote:
>> Add 64 bit stats to ppp driver. The 64 bit stats include tx_bytes,
>> rx_bytes, tx_packets and rx_packets. Other stats are still 32 bit.
>> The 64 bit stats can be retrieved via the ndo_get_stats operation. The
>> SIOCGPPPSTATS ioctl is still 32 bit stats only.
>>
>> Signed-off-by: Kevin Groeneveld <kgroeneveld@gmail.com>
>> ---
>> v2: - do not use percpu variables for stats
>> - use ppp_recv_lock/ppp_xmit_lock when reading 64 bit stats
>>
>
> Seems fine to me this time ;)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] Add device tree support and resolving SOC dependency to cpsw driver
From: David Miller @ 2012-08-04 3:42 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev
In-Reply-To: <1343679434-2369-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Tue, 31 Jul 2012 01:47:12 +0530
> This patch set adds SOC dependency for CPSW dependent modules and adds support
> for device tree for CPSW driver
>
> Mugunthan V N (2):
> drivers: net: ethernet: cpsw: Add SOC dependency support for cpsw
> dependent modules
> drivers: net: ethernet: cpsw: Add device tree support to CPSW
Both applied to net-next, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox