* [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
* Re: [PATCH] net: hp100: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: perex, netdev, linux-kernel
In-Reply-To: <1379044284-6448-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 05:51:24 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/hp/hp100.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: fec: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker
Cc: fabio.estevam, frank.li, B38611, jim_baxter, netdev, linux-kernel
In-Reply-To: <1379043878-6376-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 05:44:38 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/freescale/fec_main.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-next 0/2] bridge: fix NULL pointer deref of br_port_get_rcu
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: honkiko; +Cc: netdev, eric.dumazet, vyasevic, zhiguohong
In-Reply-To: <1379169748-767-1-git-send-email-zhiguohong@tencent.com>
From: Hong Zhiguo <honkiko@gmail.com>
Date: Sat, 14 Sep 2013 22:42:26 +0800
> Hong Zhiguo (2):
> bridge: use br_port_get_rtnl within rtnl lock
> bridge: fix NULL pointer deref of br_port_get_rcu
Both applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net 1/1] qlcnic: Fix VF reset recovery
From: David Miller @ 2013-09-16 4:54 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, Dept-HSGLinuxNICDev
In-Reply-To: <1379067227-10362-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Fri, 13 Sep 2013 06:13:47 -0400
> o At the time of firmware hang "adapter->need_fw_reset" variable gets
> set but after re-initialization of firmware OR at the time of VF
> re-initialization that variable was not getting cleared which
> was leading to failure in VF reset recovery.Fix it by clearing
> this variable before re-initializing VF
>
> Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Applied.
^ permalink raw reply
* Re: [net] vxlan: Fix sparse warnings
From: David Miller @ 2013-09-16 4:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: joseph.gasparakis, netdev, gospo, sassmann
In-Reply-To: <1379082853-28172-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 13 Sep 2013 07:34:13 -0700
> From: Joseph Gasparakis <joseph.gasparakis@intel.com>
>
> This patch fixes sparse warnings when incorrectly handling the port number
> and using int instead of unsigned int iterating through &vn->sock_list[].
> Keeping the port as __be16 also makes things clearer wrt endianess.
> Also, it was pointed out that vxlan_get_rx_port() had unnecessary checks
> which got removed.
>
> Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: nicstar: fix regression made by previous patch
From: David Miller @ 2013-09-16 4:54 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: chas, linux-atm-general, netdev
In-Reply-To: <1379084458-23793-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri, 13 Sep 2013 18:00:58 +0300
> The commit 8390f814 "atm: nicstar: re-use native mac_pton() helper" did a
> usefull thing. However, mac_pton() returns 1 in the case of the successfully
> parsed input. This patch fixes a typo.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3] bonding: Make alb learning packet interval configurable
From: David Miller @ 2013-09-16 4:53 UTC (permalink / raw)
To: nhorman; +Cc: netdev, vfalico, fubar, andy
In-Reply-To: <1379084733-9219-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 13 Sep 2013 11:05:33 -0400
> running bonding in ALB mode requires that learning packets be sent periodically,
> so that the switch knows where to send responding traffic. However, depending
> on switch configuration, there may not be any need to send traffic at the
> default rate of 3 packets per second, which represents little more than wasted
> data. Allow the ALB learning packet interval to be made configurable via sysfs
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Acked-by: Acked-by: Veaceslav Falico <vfalico@redhat.com>
Applied, thanks Neil.
^ permalink raw reply
* Re: [PATCH 1/1] isdn: hfcpci_softirq: get func return to suppress compiler warning
From: David Miller @ 2013-09-16 4:53 UTC (permalink / raw)
To: antonio.alecrim; +Cc: isdn, standby24x7, netdev, linux-kernel
In-Reply-To: <1379179240-21927-1-git-send-email-antonio.alecrim@gmail.com>
From: Antonio Alecrim Jr <antonio.alecrim@gmail.com>
Date: Sat, 14 Sep 2013 14:20:40 -0300
> Signed-off-by: Antonio Alecrim Jr <antonio.alecrim@gmail.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