* [PATCH 6/6] smsc75xx: don't enable remote wakeup directly
From: Steve Glendinning @ 2012-11-28 15:59 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning, Bjorn Mork
In-Reply-To: <1354118391-22666-1-git-send-email-steve.glendinning@shawell.net>
As pointed out by Bjorn Mork, the generic "usb" driver sets this
for us so no need to directly set it in this driver.
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Cc: Bjorn Mork <bjorn@mork.no>
---
drivers/net/usb/smsc75xx.c | 43 ++++++++-----------------------------------
1 file changed, 8 insertions(+), 35 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index b852c48..1823806 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -61,7 +61,6 @@
#define SUSPEND_SUSPEND1 (0x02)
#define SUSPEND_SUSPEND2 (0x04)
#define SUSPEND_SUSPEND3 (0x08)
-#define SUSPEND_REMOTEWAKE (0x10)
#define SUSPEND_ALLMODES (SUSPEND_SUSPEND0 | SUSPEND_SUSPEND1 | \
SUSPEND_SUSPEND2 | SUSPEND_SUSPEND3)
@@ -172,26 +171,6 @@ static int __must_check smsc75xx_write_reg(struct usbnet *dev, u32 index,
return __smsc75xx_write_reg(dev, index, data, 0);
}
-static int smsc75xx_set_feature(struct usbnet *dev, u32 feature)
-{
- if (WARN_ON_ONCE(!dev))
- return -EINVAL;
-
- return usbnet_write_cmd_nopm(dev, USB_REQ_SET_FEATURE,
- USB_DIR_OUT | USB_RECIP_DEVICE,
- feature, 0, NULL, 0);
-}
-
-static int smsc75xx_clear_feature(struct usbnet *dev, u32 feature)
-{
- if (WARN_ON_ONCE(!dev))
- return -EINVAL;
-
- return usbnet_write_cmd_nopm(dev, USB_REQ_CLEAR_FEATURE,
- USB_DIR_OUT | USB_RECIP_DEVICE,
- feature, 0, NULL, 0);
-}
-
/* Loop until the read is completed with timeout
* called with phy_mutex held */
static __must_check int __smsc75xx_phy_wait_not_busy(struct usbnet *dev,
@@ -674,8 +653,13 @@ static int smsc75xx_ethtool_set_wol(struct net_device *net,
{
struct usbnet *dev = netdev_priv(net);
struct smsc75xx_priv *pdata = (struct smsc75xx_priv *)(dev->data[0]);
+ int ret;
pdata->wolopts = wolinfo->wolopts & SUPPORTED_WAKE;
+
+ ret = device_set_wakeup_enable(&dev->udev->dev, pdata->wolopts);
+ check_warn_return(ret, "device_set_wakeup_enable error %d\n", ret);
+
return 0;
}
@@ -1263,9 +1247,7 @@ static int smsc75xx_enter_suspend0(struct usbnet *dev)
ret = smsc75xx_write_reg_nopm(dev, PMT_CTL, val);
check_warn_return(ret, "Error writing PMT_CTL\n");
- smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
-
- pdata->suspend_flags |= SUSPEND_SUSPEND0 | SUSPEND_REMOTEWAKE;
+ pdata->suspend_flags |= SUSPEND_SUSPEND0;
return 0;
}
@@ -1292,9 +1274,7 @@ static int smsc75xx_enter_suspend1(struct usbnet *dev)
ret = smsc75xx_write_reg_nopm(dev, PMT_CTL, val);
check_warn_return(ret, "Error writing PMT_CTL\n");
- smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
-
- pdata->suspend_flags |= SUSPEND_SUSPEND1 | SUSPEND_REMOTEWAKE;
+ pdata->suspend_flags |= SUSPEND_SUSPEND1;
return 0;
}
@@ -1349,9 +1329,7 @@ static int smsc75xx_enter_suspend3(struct usbnet *dev)
ret = smsc75xx_write_reg_nopm(dev, PMT_CTL, val);
check_warn_return(ret, "Error writing PMT_CTL\n");
- smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
-
- pdata->suspend_flags |= SUSPEND_SUSPEND3 | SUSPEND_REMOTEWAKE;
+ pdata->suspend_flags |= SUSPEND_SUSPEND3;
return 0;
}
@@ -1651,11 +1629,6 @@ static int smsc75xx_resume(struct usb_interface *intf)
/* do this first to ensure it's cleared even in error case */
pdata->suspend_flags = 0;
- if (suspend_flags & SUSPEND_REMOTEWAKE) {
- ret = smsc75xx_clear_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
- check_warn_return(ret, "Error disabling remote wakeup\n");
- }
-
if (suspend_flags & SUSPEND_ALLMODES) {
/* Disable wakeup sources */
ret = smsc75xx_read_reg_nopm(dev, WUCSR, &val);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net-next 0/9] bnx2x: Link changes
From: David Miller @ 2012-11-28 16:03 UTC (permalink / raw)
To: yanivr; +Cc: netdev
In-Reply-To: <1354023996-3512-1-git-send-email-yanivr@broadcom.com>
From: "Yaniv Rosner" <yanivr@broadcom.com>
Date: Tue, 27 Nov 2012 15:46:27 +0200
> The following patch series describe some link changes.
> Please consider applying it to net-next.
All applied, thank you.
^ permalink raw reply
* Re: [net-next 0/7][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-11-28 16:05 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1354107978-24731-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 28 Nov 2012 05:06:11 -0800
> This series contains updates to igb, igbvf and ixgbe.
>
> The following are changes since commit 03f52a0a554210d5049eeed9f1bb29047dc807cb:
> ip6mr: Add sizeof verification to MRT6_ASSERT and MT6_PIM
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: TCP and reordering
From: Eric Dumazet @ 2012-11-28 16:09 UTC (permalink / raw)
To: David Woodhouse
Cc: Vijay Subramanian, David Miller, saku, rick.jones2, netdev
In-Reply-To: <1354117635.21562.63.camel@shinybook.infradead.org>
On Wed, 2012-11-28 at 15:47 +0000, David Woodhouse wrote:
> On Wed, 2012-11-28 at 04:52 -0800, Eric Dumazet wrote:
> > BQL is nice for high speed adapters.
>
> For adapters with hugely deep queues, surely? There's a massive
> correlation between the two, of course — but PPP over L2TP or PPPoE
> ought to be included in the classification, right?
>
> > For slow one, you always can stop the queue for each packet given to
> > start_xmit()
> >
> > And restart the queue at TX completion.
>
> Well yes, but only if we get notified of TX completion.
>
> It's simple enough for the tty-based channels, and we can do it with a
> vcc->pop() function for PPPoATM. But for PPPoE and L2TP, how do we do
> it? We can install a skb destructor... but then we're stomping on TSQ's
> use of the destructor by orphaning it too soon.
>
> I'm pondering something along the lines of
>
> if (skb->destructor) {
> newskb = skb_clone(skb, GFP_KERNEL);
> if (newskb) {
> skb_shinfo(newskb) = skb;
> skb = newskb;
> }
> }
> skb_orphan(skb);
> skb->destructor = ppp_chan_tx_completed;
>
>
> ... and then ppp_chan_tx_completed can also destroy the original skb
> (and hence invoke TSQ's destructor too) when the time comes. And in the
> (common?) case where we don't have an existing destructor, we don't
> bother with the skb_clone.
>
> But I wish there was a nicer way to chain destructors. And no, I don't
> count what GSO does. We can't use the cb here anyway since we're passing
> it down the stack.
>
My point was that if you limit number of in flight packet to 1,
its relatively easy to add glue in the priv dev data, so that you chain
the destructor without adding yet another fields in all skbs.
At start_xmit() do the following instead of skb_orphan(skb)
if (skb->destructor) {
BUG_ON(priv->save_destructor);
priv->save_destructor = skb->destructor;
priv->save_sk = skb->sk;
skb->sk = &priv->fake_sk;
}
skb->destructor = my_destructor;
/* stop the queue */
...
}
void my_destructor(struct sk_buff *skb)
{
struct .... *priv = container_of(skb, struct ..., priv.fake_sk);
skb->sk = skb->save_sk;
priv->save_destructor(skb);
priv->save_destructor = NULL;
/* restart the queue */
...
}
Something like that.
^ permalink raw reply
* Re: [PATCH 0/6] qlcnic: refactor 82xx adapter driver
From: David Miller @ 2012-11-28 16:10 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1354113271-23850-1-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Wed, 28 Nov 2012 09:34:25 -0500
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> Refactor 82xx adapter driver to create new files for:
> Data path routines.
> Sysfs interface routines.
> Hardware register dump utility.
>
> We are refactoring the driver code to add support for a new adapter.
> Existing 82xx driver code has coding style issues.
> Each physical refactoring patch is followed by a seperate patch
> to fix the style issues in the newly created file.
>
> Patches in the series are listed below.
> 0001-qlcnic-create-file-qlcnic_io.c-for-datapath-routines.patch
> 0002-qlcnic-fix-coding-style-issues-in-qlcnic_io.c.patch
> 0003-qlcnic-create-file-qlcnic_sysfs.c-for-sysfs-routines.patch
> 0004-qlcnic-fix-style-issues-in-qlcnic_sysfs.c-file.patch
> 0005-qlcnic-create-file-qlcnic_minidump.c-for-dump-utilit.patch
> 0006-qlcnic-fix-coding-style-issues-in-qlcnic_minidump.c.patch
>
> Please apply to net-next.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: fix memory leak in sctp_datamsg_from_user() when copy from user space fails
From: David Miller @ 2012-11-28 16:11 UTC (permalink / raw)
To: tt.rantala; +Cc: linux-sctp, netdev, nhorman, vyasevich, sri, davej
In-Reply-To: <1354024906-1925-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Tue, 27 Nov 2012 16:01:46 +0200
> Trinity (the syscall fuzzer) discovered a memory leak in SCTP,
> reproducible e.g. with the sendto() syscall by passing invalid
> user space pointer in the second argument:
...
> As far as I can tell, the leak has been around since ~2003.
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sctp: fix -ENOMEM result with invalid user space pointer in sendto() syscall
From: David Miller @ 2012-11-28 16:12 UTC (permalink / raw)
To: tt.rantala; +Cc: linux-sctp, netdev, nhorman, vyasevich, sri, davej
In-Reply-To: <1353590596-12216-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Thu, 22 Nov 2012 15:23:16 +0200
> Consider the following program, that sets the second argument to the
> sendto() syscall incorrectly:
...
> We get -ENOMEM:
>
> $ strace -e sendto ./demo
> sendto(3, NULL, 1, 0, {sa_family=AF_INET, sin_port=htons(11111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ENOMEM (Cannot allocate memory)
>
> Propagate the error code from sctp_user_addto_chunk(), so that we will
> tell user space what actually went wrong:
>
> $ strace -e sendto ./demo
> sendto(3, NULL, 1, 0, {sa_family=AF_INET, sin_port=htons(11111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EFAULT (Bad address)
>
> Noticed while running Trinity (the syscall fuzzer).
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Applied.
^ permalink raw reply
* [patch net] team: fix hw_features setup
From: Jiri Pirko @ 2012-11-28 16:13 UTC (permalink / raw)
To: netdev; +Cc: davem
Do this in the same way bonding does. This fixed setup resolves performance
issues when using some cards with certain offloading.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/team/team.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index d44cca3..ad86660 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1794,10 +1794,12 @@ static void team_setup(struct net_device *dev)
dev->features |= NETIF_F_LLTX;
dev->features |= NETIF_F_GRO;
- dev->hw_features = NETIF_F_HW_VLAN_TX |
+ dev->hw_features = TEAM_VLAN_FEATURES |
+ NETIF_F_HW_VLAN_TX |
NETIF_F_HW_VLAN_RX |
NETIF_F_HW_VLAN_FILTER;
+ dev->hw_features &= ~(NETIF_F_ALL_CSUM & ~NETIF_F_HW_CSUM);
dev->features |= dev->hw_features;
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] sctp: Error in calculation of RTTvar
From: David Miller @ 2012-11-28 16:13 UTC (permalink / raw)
To: vyasevich; +Cc: netdev
In-Reply-To: <1354115909-24172-1-git-send-email-vyasevich@gmail.com>
From: vyasevich@gmail.com
Date: Wed, 28 Nov 2012 10:18:29 -0500
> From: Schoch Christian <e0326715@student.tuwien.ac.at>
>
> The calculation of RTTVAR involves the subtraction of two unsigned
> numbers which
> may causes rollover and results in very high values of RTTVAR when RTT > SRTT.
> With this patch it is possible to set RTOmin = 1 to get the minimum of RTO at
> 4 times the clock granularity.
>
> Change Notes:
>
> v2)
> *Replaced abs() by abs64() and long by __s64, changed patch
> description.
>
> Signed-off-by: Christian Schoch <e0326715@student.tuwien.ac.at>
> CC: Vlad Yasevich <vyasevich@gmail.com>
> CC: Sridhar Samudrala <sri@us.ibm.com>
> CC: Neil Horman <nhorman@tuxdriver.com>
> CC: linux-sctp@vger.kernel.org
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Can set maxrate only for TC0
From: David Miller @ 2012-11-28 16:16 UTC (permalink / raw)
To: amirv; +Cc: ogerlitz, oren, netdev
In-Reply-To: <1354102995-27305-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Wed, 28 Nov 2012 13:43:15 +0200
> Had a typo in memcpy.
>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/6] smsc75xx enhancements
From: David Miller @ 2012-11-28 16:17 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1354118391-22666-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Wed, 28 Nov 2012 15:59:44 +0000
> This patchset implements wake on PHY (link up or link down) and
> USB dynamic autosuspend for smsc75xx.
>
> Please consider all for net-next.
All applied, thanks Steve.
^ permalink raw reply
* Re: TCP and reordering
From: Benjamin LaHaise @ 2012-11-28 16:19 UTC (permalink / raw)
To: David Woodhouse
Cc: Eric Dumazet, Vijay Subramanian, David Miller, saku, rick.jones2,
netdev
In-Reply-To: <1354117635.21562.63.camel@shinybook.infradead.org>
On Wed, Nov 28, 2012 at 03:47:15PM +0000, David Woodhouse wrote:
> On Wed, 2012-11-28 at 04:52 -0800, Eric Dumazet wrote:
> > BQL is nice for high speed adapters.
>
> For adapters with hugely deep queues, surely? There's a massive
> correlation between the two, of course ??? but PPP over L2TP or PPPoE
> ought to be included in the classification, right?
Possibly, but there are many setups where PPPoE/L2TP do not connect to
the congested link directly.
> > For slow one, you always can stop the queue for each packet given to
> > start_xmit()
> >
> > And restart the queue at TX completion.
>
> Well yes, but only if we get notified of TX completion.
>
> It's simple enough for the tty-based channels, and we can do it with a
> vcc->pop() function for PPPoATM. But for PPPoE and L2TP, how do we do
> it? We can install a skb destructor... but then we're stomping on TSQ's
> use of the destructor by orphaning it too soon.
>
> I'm pondering something along the lines of
>
> if (skb->destructor) {
> newskb = skb_clone(skb, GFP_KERNEL);
> if (newskb) {
> skb_shinfo(newskb) = skb;
> skb = newskb;
> }
> }
> skb_orphan(skb);
> skb->destructor = ppp_chan_tx_completed;
>
>
> ... and then ppp_chan_tx_completed can also destroy the original skb
> (and hence invoke TSQ's destructor too) when the time comes. And in the
> (common?) case where we don't have an existing destructor, we don't
> bother with the skb_clone.
This sort of chaining of destructors is going to be very expensive in
terms of CPU cycles. If this does get implemented, please ensure there is
a way to turn it off. Specifically, I'm thinking of the access concetrator
roles for BRAS. In many wholesale ISP setups, there are many incoming
sessions coming in over a high speed link (gigabit or greater) for which
the access concentrator (LAC/LNS in L2TP speak) has no idea of the
bandwidth of the link actually facing the customer. Such systems are
usually operated in a way to avoid ever congesting the aggregation network.
In such setups, BQL on the L2TP/PPPoE interface only serves to increase CPU
overhead.
That said, if there is local congestion, the benefits of BQL would be
worthwhile to have.
> But I wish there was a nicer way to chain destructors. And no, I don't
> count what GSO does. We can't use the cb here anyway since we're passing
> it down the stack.
I think all the tunneling protocols are going to have the same problem
here, so it deserves some thought about how to tackle the issue in a
generic way without incurring a large amount of overhead. This exact
problem is one of the reasons multilink PPP often doesn't work well over
L2TP or PPPoE as compared to its behaviour over ttys.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [PATCH] pkt_sched: QFQ Plus: fair-queueing service at DRR cost
From: David Miller @ 2012-11-28 16:20 UTC (permalink / raw)
To: paolo.valente; +Cc: jhs, shemminger, linux-kernel, netdev, rizzo, fchecconi
In-Reply-To: <20121123210319.GA15775@paolo-ThinkPad-W520>
From: Paolo Valente <paolo.valente@unimore.it>
Date: Fri, 23 Nov 2012 22:03:19 +0100
> This patch turns QFQ into QFQ+, a variant of QFQ that provides the
> following two benefits: 1) QFQ+ is faster than QFQ, 2) differently
> from QFQ, QFQ+ correctly schedules also non-leaves classes in a
> hierarchical setting. A detailed description of QFQ+, plus a
> performance comparison with DRR and QFQ, can be found in [1].
>
> [1] P. Valente, "Reducing the Execution Time of Fair-Queueing Schedulers"
> http://algo.ing.unimo.it/people/paolo/agg-sched/agg-sched.pdf
>
> Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bonding: fix miimon and arp_interval delayed work race conditions
From: David Miller @ 2012-11-28 16:21 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar
In-Reply-To: <1353759471-30323-1-git-send-email-nikolay@redhat.com>
Bonding folks, please review.
^ permalink raw reply
* Re: [PATCH] bonding: fix race condition in bonding_store_slaves_active
From: David Miller @ 2012-11-28 16:21 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar
In-Reply-To: <1353759595-30452-1-git-send-email-nikolay@redhat.com>
Some bonding developer reviews would be appreciated.
^ permalink raw reply
* Re: TCP and reordering
From: David Woodhouse @ 2012-11-28 16:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vijay Subramanian, David Miller, saku, rick.jones2, netdev
In-Reply-To: <1354118982.14302.356.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
On Wed, 2012-11-28 at 08:09 -0800, Eric Dumazet wrote:
> My point was that if you limit number of in flight packet to 1,
> its relatively easy to add glue in the priv dev data, so that you chain
> the destructor without adding yet another fields in all skbs.
Hm, true. I do think we'll need to be able to have at least two packets
in-flight though. There's a fair amount of network stack to be navigated
by a skb once we release it, in the PPPoE and especially L2TP cases. The
latency involved in that, if we only allow one packet at a time, will
surely be noticeable. You're basically guaranteeing that a 'TX done' IRQ
won't have another packet in the device's queue ready to send, and you
won't be able to saturate the uplink.
I suppose your principle applies even for more than one skb at a time;
we can have an array of {skb, old_destructor} tuples in our per-channel
private state, rather than having to keep it with the skb itself... but
that's slightly less simple.
I'll go and knock something up...
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [PATCH] bonding: make arp_ip_target parameter checks consistent with sysfs
From: David Miller @ 2012-11-28 16:23 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar
In-Reply-To: <1353759675-30511-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Sat, 24 Nov 2012 13:21:15 +0100
> @@ -4706,12 +4706,14 @@ static int bond_check_params(struct bond_params *params)
> arp_ip_count++) {
> /* not complete check, but should be good enough to
> catch mistakes */
> - if (!isdigit(arp_ip_target[arp_ip_count][0])) {
> + __be32 ip = in_aton(arp_ip_target[arp_ip_count]);
> + if (!isdigit(arp_ip_target[arp_ip_count][0])
> + || ip == 0
> + || ip == htonl(INADDR_BROADCAST)) {
Please format this properly, put the connecting operators at the end,
not the beginning, of the lines of the if statement, like so:
if (!isdigit(arp_ip_target[arp_ip_count][0]) ||
ip == 0 ||
ip == htonl(INADDR_BROADCAST)) {
Where else did you see the layout you used? It's not a prevalent
construct, so as far as I can tell you came up with it on your own.
Please don't do this, and instead use existing practice as your guide.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: add Huawei E173
From: David Miller @ 2012-11-28 16:24 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, tschaefer
In-Reply-To: <1353859439-18260-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Sun, 25 Nov 2012 17:03:59 +0100
> The Huawei E173 is a QMI/wwan device which normally appear
> as 12d1:1436 in Linux. The descriptors displayed in that
> mode will be picked up by cdc_ether. But the modem has
> another mode with a different device ID and a slightly
> different set of descriptors. This is the mode used by
> Windows like this:
>
> 3Modem: USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
> Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001
> Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002
> PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003
>
> Reported-by: Thomas Schäfer <tschaefer@t-online.de>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* Re: [PATCH] irda: irttp: fix memory leak in irttp_open_tsap() error path
From: David Miller @ 2012-11-28 16:25 UTC (permalink / raw)
To: tt.rantala; +Cc: netdev, samuel, davej
In-Reply-To: <1353939404-19264-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Mon, 26 Nov 2012 16:16:44 +0200
> Cleanup the memory we allocated earlier in irttp_open_tsap() when we hit
> this error path. The leak goes back to at least 1da177e4
> ("Linux-2.6.12-rc2").
>
> Discovered with Trinity (the syscall fuzzer).
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] vhost: fix length for cross region descriptor
From: David Miller @ 2012-11-28 16:27 UTC (permalink / raw)
To: mst; +Cc: netdev, jasowang, linux-kernel
In-Reply-To: <20121126155727.GA21716@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 26 Nov 2012 17:57:27 +0200
> If a single descriptor crosses a region, the
> second chunk length should be decremented
> by size translated so far, instead it includes
> the full descriptor length.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: Move an interface to init_ne
From: Eric W. Biederman @ 2012-11-28 16:28 UTC (permalink / raw)
To: David Shwatrz; +Cc: Renato Westphal, netdev
In-Reply-To: <CAJJAcofHM+D8_2u-w5jPJZKfeA0A7QOxX1gxTQ2vOgx-L9aZhQ@mail.gmail.com>
David Shwatrz <dshwatrz@gmail.com> writes:
> But when I run "modprobe 8139too" on namespace1, a device named "eth1"
> is created on the initial network namespace and not on namesapce1.
> I expected that in such a case, a device named "eth0" will be created
> on namespace1, since it was called from namespace1. Or maybe modprobe
> does
> not consider the namespace from which it was called ?
modprobe has no concept of the namespace from which it was called.
Eric
^ permalink raw reply
* Re: [PATCH] netfilter updates for net (3.7-rc7)
From: David Miller @ 2012-11-28 16:30 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1353978185-3564-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Tue, 27 Nov 2012 02:03:04 +0100
> From: Pablo Neira Ayuso <pablo@netfilter.org>
>
> Hi David,
>
> This update contains one patch to fix an overflow via the interface
> name attribute in the ipset infrastructure, from Florian Westphal.
>
> You can pull this change from:
>
> git://1984.lsi.us.es/nf master
Pulled, thanks Pablo.
^ permalink raw reply
* Re: pull-request: can-next 2012-11-27
From: David Miller @ 2012-11-28 16:31 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <50B4807E.8010607@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 27 Nov 2012 09:57:34 +0100
> this is pull request is for net-next. Contains a patch by Andreas
> Larsson, which enables the sja1000 of driver to work under sparc.
> AnilKumar Ch contributed a patch to improve the c_can support under
> omap, Olivier Sobrie's patch brings support for the CAN/USB dongles
> from Kvaser. In a bunch of patches by me missing MODULE_ALIAS and/or
> MODULE_DEVICE_TABLE entries were added to the CAN drivers.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] bonding: make arp_ip_target parameter checks consistent with sysfs
From: Nikolay Aleksandrov @ 2012-11-28 16:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andy, fubar
In-Reply-To: <20121128.112316.33060261620694469.davem@davemloft.net>
Actually I did see it from kernel/module.c and didn't come up with it
myself.
Anyway I will re-post with the change and will take a note for the future.
Thanks for the review
On 28/11/12 17:23, David Miller wrote:
> From: Nikolay Aleksandrov<nikolay@redhat.com>
> Date: Sat, 24 Nov 2012 13:21:15 +0100
>
>> @@ -4706,12 +4706,14 @@ static int bond_check_params(struct bond_params *params)
>> arp_ip_count++) {
>> /* not complete check, but should be good enough to
>> catch mistakes */
>> - if (!isdigit(arp_ip_target[arp_ip_count][0])) {
>> + __be32 ip = in_aton(arp_ip_target[arp_ip_count]);
>> + if (!isdigit(arp_ip_target[arp_ip_count][0])
>> + || ip == 0
>> + || ip == htonl(INADDR_BROADCAST)) {
> Please format this properly, put the connecting operators at the end,
> not the beginning, of the lines of the if statement, like so:
>
> if (!isdigit(arp_ip_target[arp_ip_count][0]) ||
> ip == 0 ||
> ip == htonl(INADDR_BROADCAST)) {
>
> Where else did you see the layout you used? It's not a prevalent
> construct, so as far as I can tell you came up with it on your own.
>
> Please don't do this, and instead use existing practice as your guide.
>
> Thanks.
^ permalink raw reply
* Re: [PATCH net-next] be2net: fix INTx ISR for interrupt behaviour on BE2
From: David Miller @ 2012-11-28 16:35 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <d856540b-bacc-45e3-a7cc-49e7febafb95@CMEXHTCAS1.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Wed, 28 Nov 2012 11:20:02 +0530
> On BE2 chip, an interrupt may be raised even when EQ is in un-armed state.
> As a result be_intx()::events_get() and be_poll:events_get() can race and
> notify an EQ wrongly.
>
> Fix this by counting events only in be_poll(). Commit 0b545a629 fixes
> the same issue in the MSI-x path.
>
> But, on Lancer, INTx can be de-asserted only by notifying num evts. This
> is not an issue as the above BE2 behavior doesn't exist/has never been
> seen on Lancer.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.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