* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Stephen Hemminger @ 2012-05-24 17:16 UTC (permalink / raw)
To: Arvid Brodin
Cc: netdev@vger.kernel.org, David S. Miller, Bruno Ferreira,
Christian Borntraeger, Herbert Xu
In-Reply-To: <4FBE6B5E.3060403@xdin.com>
On Thu, 24 May 2012 17:09:53 +0000
Arvid Brodin <Arvid.Brodin@xdin.com> wrote:
> On 2012-05-14 20:28, Stephen Hemminger wrote:
> > On Mon, 14 May 2012 18:11:44 +0000
> > Arvid Brodin <Arvid.Brodin@xdin.com> wrote:
> >
> >> On 2012-03-27 15:20, Arvid Brodin wrote:
> >>> Hi!
> >>
> >> *snip*
> >>>
> >>> 2) I have a locking problem that I haven't managed to figure out. This happens
> >>> the first time I send any packet (hsr_dev_xmit() in hsr_device.c:121, called
> >>> from hsr_device.c:147). It happens even if I set skb2 to NULL (i.e. only send
> >>> one copy):
> >>>
> >>> =============================================
> >>> [ INFO: possible recursive locking detected ]
> >>> 2.6.37 #118
> >>> ---------------------------------------------
> >>> swapper/0 is trying to acquire lock:
> >>> (_xmit_ETHER#2){+.-...}, at: [<901bf38e>] sch_direct_xmit+0x24/0x152
> >>>
> >>> but task is already holding lock:
> >>> (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
> >>>
> >>> other info that might help us debug this:
> >>> 4 locks held by swapper/0:
> >>> #0: (&n->timer){+.-...}, at: [<9002bc20>] run_timer_softirq+0x98/0x184
> >>> #1: (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
> >>> #2: (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
> >>> #3: (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
> >>>
> >>> stack backtrace:
> >>> Call trace:
> >>> [<9001c640>] dump_stack+0x18/0x20
> >>> [<90040eac>] validate_chain+0x40c/0x9ac
> >>> [<90041a58>] __lock_acquire+0x60c/0x670
> >>> [<90042f32>] lock_acquire+0x3a/0x48
> >>> [<902201a4>] _raw_spin_lock+0x20/0x44
> >>> [<901bf38e>] sch_direct_xmit+0x24/0x152
> >>> [<901b4c14>] dev_queue_xmit+0x218/0x3cc
> >>> [<9021c2e0>] slave_xmit+0x10/0x14
> >>> [<9021c540>] hsr_dev_xmit+0x88/0x8c
> >>> [<901b4942>] dev_hard_start_xmit+0x3c6/0x480
> >>> [<901b4d34>] dev_queue_xmit+0x338/0x3cc
> >>> [<901e3cd8>] arp_xmit+0x8/0xc
> >>> [<901e4436>] arp_send+0x2a/0x2c
> >>> [<901e4e74>] arp_solicit+0x15c/0x170
> >>> [<901bad0c>] neigh_timer_handler+0x1c0/0x204
> >>> [<9002bc8a>] run_timer_softirq+0x102/0x184
> >>> [<900287d8>] __do_softirq+0x64/0xe0
> >>> [<9002896a>] do_softirq+0x26/0x48
> >>> [<90028a66>] irq_exit+0x2e/0x64
> >>> [<90019f16>] do_IRQ+0x46/0x5c
> >>> [<90018428>] irq_level0+0x18/0x60
> >>> [<9021cc16>] rest_init+0x72/0x98
> >>> [<9000063c>] start_kernel+0x21c/0x258
> >>> [<00000000>] 0x0
> >>>
> >>> Any idea why this happens? I need help!
> >>
> >>
> >> I've spent a few days digging into this and the key apparently is NETIF_F_LLTX.
> >>
> >> The problem seems to be that HARD_TX_LOCK is called more than once, first for my virtual
> >> hsr device and then, recursively, for each of the slaves in turn. (At least that's where
> >> lockdep complains - at __netif_tx_lock(), that is.)
> >>
> >> At first I just could not understand why both the VLAN and the bonding code got away with
> >> recursive calls to dev_queue_xmit() but I didn't. After some gooling (a lot, actually) I
> >> found some references to the NETIF_F_LLTX flag (here's one:
> >> http://lwn.net/Articles/121566/). I realised both VLAN and bonding code set this flag. And
> >> sure enough, if I set it for my hsr device lockdep does not complain any more.
> >>
> >> But NETIF_F_LLTX is described as deprecated in both netdevice.h and in
> >> Documentation/networking/netdevices.txt. Is there an alternative solution that I should
> >> use instead?
> >>
> >> (To recap, a hsr device is a virtual device which uses two Ethernet devices as slaves.
> >> This gives redundancy with instant failover, and since nodes are connected in a ring
> >> topology, uses less cabling than duplication.)
> >>
> >
> > LLTX is deprecated (ie should not be used) for physical devices.
> >
> > Also, for virtual devices, there should be non transmit queue, this
> > causes mulit-queue lockless semantics to be preserved as the call passes
> > through the virtual device.
>
> (First: apologies for my late reply; your emails doesn't get through to me for some reason.)
>
> So does this mean that it is OK to use LLTX for virtual devices? My virtual device has
> zero queue length (no transmit queue), but since it calls dev_queue_xmit for its slaves, I
> still get recursive locking if I don't set LLTX (just like vlan and bonding does).
Yes LLTX is fine for virtual devices.
^ permalink raw reply
* Re: [RFC PATCH] tcp: Fast/early SYN handling to mitigate SYN floods
From: Jesper Dangaard Brouer @ 2012-05-24 17:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: christoph.paasch, David Miller, Martin Topholm, netdev,
Tom Herbert
In-Reply-To: <1337871077.3140.12.camel@edumazet-glaptop>
On Thu, 2012-05-24 at 16:51 +0200, Eric Dumazet wrote:
> On Thu, 2012-05-24 at 15:26 +0200, Christoph Paasch wrote:
> > Hello,
> >
> > On 05/24/2012 03:01 PM, Jesper Dangaard Brouer wrote:
> > > I have been doing some TCP performance measurements with SYN flooding,
> > > and have found that, we don't handle this case well.
> > >
> > > I have made a patch for fast/early SYN handling in tcp_v4_rcv() in
> > > net/ipv4/tcp_ipv4.c. This increases SYN performance from 130 kpps to
> > > 750 kpps (max of the generator), with idle CPU cycles.
> > >
> > > Current locking:
> > > During a SYN flood (against a single port) all CPUs are spinning on
> > > the same spinlock, namely bh_lock_sock_nested(sk), in tcp_ipv4.c. The
> > > lock dates back to a commit by DaveM in May 1999, see historic
> > > commit[1]. It seem that TCP runs fully locked, per sock.
> > >
> > > I need some help with locking, as the patch seems to work fine, with
> > > NO-PREEMPT, but with PREEMPT enabled I start to see warnings (in
> > > reqsk_queue_destroy) and oopses (in inet_csk_reqsk_queue_prune).
> > >
> > > What am I missing?
> >
> > For each retransmission of a SYN you will add a request-sock to the
> > syn_table, because you do not pass by tcp_v4_hnd_req(), which checks
> > this by calling inet_csk_search_req().
Thanks that's good hint. I was suspecting that tcp_v4_hnd_req() was
somehow needed (as noted in the comment in the patch)
> > And your warning in reqsk_queue_destroy is because the access to the the
> > request_sock_queue is no more protected by a lock.
Yes, I was suspecting that.
> > The request_sock_queue is a shared resource, which must be protect by a
> > lock. As you allow "parallel" SYN-processing, the queue will get corrupted.
> >
>
> Hi guys, that's a very interesting subject.
>
> I began work on fully converting this stuff to RCU some weeks ago but
> got distracted by codel / fq_codel and other cool stuff (TCP coalescing
> and skb->frag_head)
>
> I dont know if you remember the SO_REUSEPORT patch(s) posted by Tom
> Herbert in the past. The remaining issue was about adding/removing a new
> listener to a pool of listeners to same port, and hash function was
> changed so we could lost some connexions in SYN_RECV state at this
> stage.
Sorry, don't remember.
> So I was working having a shared table, and not anymore using a central
> spinlock, but an array of spinlock, as done elsewhere
> (ESTABLISHED/TIMEWAIT hash tables)
>
> My work is probably a ~500 LOC target, allowing concurrent processing by
> all cpus of the host.
Sounds really promising, especially coming from the network-ninja :-)
> Jesper, my goals are probably different than yours, unless I
> misunderstood your intention.
>
> I feel you want to have an emergency mode, when listener is overflowed
> to immediately send a SYNCOOKIE ?
Yes, this is more an emergency mode.
I was thinking of only handling the SYN cookie case in parallel.
That should be easier locking wise, right.
I'm also considering writing a netfilter/iptables syn-cookie module, as
this would allow people to use it in combination with IPset, to e.g
create a whitelist feature of known-good-hosts (which have completed the
TCP handshake). But it would be nicer if the base kernel was just fast
enough to handle these SYN floods.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [RFC PATCH] tcp: Fast/early SYN handling to mitigate SYN floods
From: Eric Dumazet @ 2012-05-24 17:27 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: christoph.paasch, David Miller, Martin Topholm, netdev,
Tom Herbert
In-Reply-To: <1337880065.2388.15.camel@localhost>
On Thu, 2012-05-24 at 19:21 +0200, Jesper Dangaard Brouer wrote:
> Sorry, don't remember.
http://kerneltrap.org/mailarchive/linux-netdev/2010/4/19/6274993
> Sounds really promising, especially coming from the network-ninja :-)
;)
> Yes, this is more an emergency mode.
>
> I was thinking of only handling the SYN cookie case in parallel.
> That should be easier locking wise, right.
>
> I'm also considering writing a netfilter/iptables syn-cookie module, as
> this would allow people to use it in combination with IPset, to e.g
> create a whitelist feature of known-good-hosts (which have completed the
> TCP handshake). But it would be nicer if the base kernel was just fast
> enough to handle these SYN floods.
>
Indeed, I believe I can make this happen eventually in a short term.
^ permalink raw reply
* Re: [RFC PATCH] tcp: Fast/early SYN handling to mitigate SYN floods
From: Jesper Dangaard Brouer @ 2012-05-24 17:32 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: Eric Dumazet, David Miller, Martin Topholm, netdev
In-Reply-To: <201205241529.37684.hans.schillstrom@ericsson.com>
On Thu, 2012-05-24 at 15:20 +0200, Hans Schillstrom wrote:
> Hi Jesper
> We are also working with this issue right now,
>
[..]
> > [RFC PATCH] tcp: Fast/early SYN handling to mitigate SYN floods
> >
> > TCP SYN handling is on the slow path via tcp_v4_rcv(), and is
> > performed while holding spinlock bh_lock_sock().
> >
> > Real-life and testlab experiments show, that the kernel choks
> > when reaching 130Kpps SYN floods (powerful Nehalem 16 cores).
> > Measuring with perf reveals, that its caused by
> > bh_lock_sock_nested() call in tcp_v4_rcv().
>
> I can confirm this too, and it doesn't scale with more cores
>
> >
> > With this patch, the machine can handle 750Kpps (max of the SYN
> > flood generator) with cycles to spare.
>
> This looks great.
Yes, its definitely shows that there is huge performance gain hidden
here! But we still have to handle locking (which will affect perf).
> I'm also working with a solution that not trash conntack
> i.e. have conntrack working during a heavy SYN attack
Sounds interesting, but that's a separate problem. In this case I have
disabled conntracking (I even disabled flow-control and drop the syn-ack
responses on the generator).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] gianfar:don't add FCB length to hard_header_len
From: Jan Ceuleers @ 2012-05-24 18:03 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, b06378, netdev, linuxppc-dev
In-Reply-To: <1337876210.5070.4.camel@joe2Laptop>
On 05/24/2012 06:16 PM, Joe Perches wrote:
> On Thu, 2012-05-24 at 17:04 +0200, Jan Ceuleers wrote:
>> On 05/22/2012 09:18 PM, David Miller wrote:
>>> Someone needs to go through this driver when net-next opens up
>>> and fix all of the indentation in this driver.
>>
>> May I give that a go?
>
> I have scripts that automate most of this.
> I don't have the card though.
>
> Maybe this is a starting point?
> It doesn't fix most 80 column warnings.
Thanks Joe.
I also don't have the card; the kinds of changes I was proposing to make
are code-neutral, whose correctness I was intending to prove by a binary
compare of the before-and-after .o.
Still happy to do that taking your contribution as a starting point.
Thanks, Jan
^ permalink raw reply
* Re: [PATCH IPROUTE2] tc-codel: Add manpage
From: Vijay Subramanian @ 2012-05-24 18:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stephen Hemminger, Dave Taht
In-Reply-To: <1337835239.3361.3954.camel@edumazet-glaptop>
>> +.SS target
>> +Default and recommended value is 5ms.
>
> Although I can tell I prefer lower values on hosts.
>
> On 10Gbe links, I used 500us target
>
>> +.SS interval
>> +give endpoints sufficient time to react. Default value is 100ms.
>
> Same here. In a datacenter, you might reduce this to 20ms or so...
>
Thanks for the insight. The paper does claim that codel can be run
with the same setting, regardless of link rate.
I guess reality is different.
Thanks,
Vijay
^ permalink raw reply
* Re: [PATCH IPROUTE2] tc-codel: Add manpage
From: Dave Taht @ 2012-05-24 18:28 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: Eric Dumazet, netdev, Stephen Hemminger
In-Reply-To: <CAGK4HS8_O94rQZmvxeNjeYtbT3_a2C1FsZ9O=b9_n0vV2putdA@mail.gmail.com>
well, it would be nice if codel could sense it was on 10gigE or
greater, and self adjust.
On Thu, May 24, 2012 at 7:19 PM, Vijay Subramanian
<subramanian.vijay@gmail.com> wrote:
>>> +.SS target
>>> +Default and recommended value is 5ms.
>>
>> Although I can tell I prefer lower values on hosts.
>>
>> On 10Gbe links, I used 500us target
>>
>>> +.SS interval
>>> +give endpoints sufficient time to react. Default value is 100ms.
>>
>> Same here. In a datacenter, you might reduce this to 20ms or so...
>>
>
> Thanks for the insight. The paper does claim that codel can be run
> with the same setting, regardless of link rate.
> I guess reality is different.
>
> Thanks,
> Vijay
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
^ permalink raw reply
* [PATCH net-next 0/2] qlcnic: Bug fixes
From: Anirban Chakraborty @ 2012-05-24 18:06 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver
Please apply to net-next.
Thanks,
Anirban
^ permalink raw reply
* [PATCH 2/2] qlcnic: Fix unsupported CDRP command error message.
From: Anirban Chakraborty @ 2012-05-24 18:06 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Jitendra Kalsaria
In-Reply-To: <1337882816-2097-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
- Added proper error messages for unsupported FW commands
- Bumped up version to 5.0.29
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 8 ++++-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 34 +++++++++++++++++++---
2 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 520ff03..eaa1db9 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -36,8 +36,8 @@
#define _QLCNIC_LINUX_MAJOR 5
#define _QLCNIC_LINUX_MINOR 0
-#define _QLCNIC_LINUX_SUBVERSION 28
-#define QLCNIC_LINUX_VERSIONID "5.0.28"
+#define _QLCNIC_LINUX_SUBVERSION 29
+#define QLCNIC_LINUX_VERSIONID "5.0.29"
#define QLCNIC_DRV_IDC_VER 0x01
#define QLCNIC_DRIVER_VERSION ((_QLCNIC_LINUX_MAJOR << 16) |\
(_QLCNIC_LINUX_MINOR << 8) | (_QLCNIC_LINUX_SUBVERSION))
@@ -612,7 +612,11 @@ struct qlcnic_recv_context {
#define QLCNIC_CDRP_CMD_GET_MAC_STATS 0x00000037
#define QLCNIC_RCODE_SUCCESS 0
+#define QLCNIC_RCODE_INVALID_ARGS 6
#define QLCNIC_RCODE_NOT_SUPPORTED 9
+#define QLCNIC_RCODE_NOT_PERMITTED 10
+#define QLCNIC_RCODE_NOT_IMPL 15
+#define QLCNIC_RCODE_INVALID 16
#define QLCNIC_RCODE_TIMEOUT 17
#define QLCNIC_DESTROY_CTX_RESET 0
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index cfa174d..b8ead69 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -53,12 +53,39 @@ qlcnic_issue_cmd(struct qlcnic_adapter *adapter, struct qlcnic_cmd_args *cmd)
rsp = qlcnic_poll_rsp(adapter);
if (rsp == QLCNIC_CDRP_RSP_TIMEOUT) {
- dev_err(&pdev->dev, "card response timeout.\n");
+ dev_err(&pdev->dev, "CDRP response timeout.\n");
cmd->rsp.cmd = QLCNIC_RCODE_TIMEOUT;
} else if (rsp == QLCNIC_CDRP_RSP_FAIL) {
cmd->rsp.cmd = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
- dev_err(&pdev->dev, "failed card response code:0x%x\n",
+ switch (cmd->rsp.cmd) {
+ case QLCNIC_RCODE_INVALID_ARGS:
+ dev_err(&pdev->dev, "CDRP invalid args: 0x%x.\n",
cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_NOT_SUPPORTED:
+ case QLCNIC_RCODE_NOT_IMPL:
+ dev_err(&pdev->dev,
+ "CDRP command not supported: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_NOT_PERMITTED:
+ dev_err(&pdev->dev,
+ "CDRP requested action not permitted: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_INVALID:
+ dev_err(&pdev->dev,
+ "CDRP invalid or unknown cmd received: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_TIMEOUT:
+ dev_err(&pdev->dev, "CDRP command timeout: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ default:
+ dev_err(&pdev->dev, "CDRP command failed: 0x%x.\n",
+ cmd->rsp.cmd);
+ }
} else if (rsp == QLCNIC_CDRP_RSP_OK) {
cmd->rsp.cmd = QLCNIC_RCODE_SUCCESS;
if (cmd->rsp.arg2)
@@ -957,9 +984,6 @@ int qlcnic_get_mac_stats(struct qlcnic_adapter *adapter,
mac_stats->mac_rx_jabber = le64_to_cpu(stats->mac_rx_jabber);
mac_stats->mac_rx_dropped = le64_to_cpu(stats->mac_rx_dropped);
mac_stats->mac_rx_crc_error = le64_to_cpu(stats->mac_rx_crc_error);
- } else {
- dev_info(&adapter->pdev->dev,
- "%s: Get mac stats failed =%d.\n", __func__, err);
}
dma_free_coherent(&adapter->pdev->dev, stats_size, stats_addr,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: Timur Tabi @ 2012-05-24 18:28 UTC (permalink / raw)
To: David Daney
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FB6CBF1.40300@gmail.com>
David Daney wrote:
> Yes. You may note in the DTS file I attached in the parent (sorry for
> the fubar mime types), that there are two, almost identical, MDIO
> masters. smi0 has two directly attached PHYs. smi1 goes to the mux,
> and each child of the mux has four attached PHYs.
I'm till have trouble understanding all this. I'm just hacking things up
in order to help me understand it, but it's a slow and painful process.
This call in mdio_mux_init() is failing:
parent_bus = of_mdio_find_bus(parent_bus_node);
It returns NULL. Here is my MDIO node:
fman0: fman@400000 {
enet0: ethernet@e0000 {
tbi-handle = <&tbi0>;
phy-handle = <&phy0>;
phy-connection-type = "sgmii";
};
mdio0: mdio@e1120 {
gpios = <&gpio0 0 0
&gpio0 1 0>;
tbi0: tbi-phy@8 {
reg = <0x8>;
device_type = "tbi-phy";
};
phy0: ethernet-phy@1c {
reg = <0x1c>;
};
};
};
What am I missing? What do I need to do in order to get
of_mdio_find_bus() to return a real value?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH 1/2] qlcnic: Fix estimation of recv MSS in case of LRO
From: Anirban Chakraborty @ 2012-05-24 18:06 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Rajesh Borundia
In-Reply-To: <1337882816-2097-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
o Linux stack estimates MSS from skb->len or skb_shinfo(skb)->gso_size.
In case of LRO skb->len is aggregate of len of number of packets hence MSS
obtained using skb->len would be incorrect. Incorrect estimation of recv MSS
would lead to delayed acks in some traffic patterns (which sends two or three
packets and wait for ack and only then send remaining packets). This leads to
drop in performance. Hence we need to set gso_size to MSS obtained from firmware.
o This is fixed recently in firmware hence the MSS is obtained based on
capability. If fw is capable of sending the MSS then only driver sets the gso_size.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 7 +++++++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 3 +++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h | 1 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 3 +++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 9 +++++++++
5 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 8680a5d..520ff03 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -258,6 +258,8 @@ struct rcv_desc {
(((sts_data) >> 52) & 0x1)
#define qlcnic_get_lro_sts_seq_number(sts_data) \
((sts_data) & 0x0FFFFFFFF)
+#define qlcnic_get_lro_sts_mss(sts_data1) \
+ ((sts_data1 >> 32) & 0x0FFFF)
struct status_desc {
@@ -623,6 +625,7 @@ struct qlcnic_recv_context {
#define QLCNIC_CAP0_JUMBO_CONTIGUOUS (1 << 7)
#define QLCNIC_CAP0_LRO_CONTIGUOUS (1 << 8)
#define QLCNIC_CAP0_VALIDOFF (1 << 11)
+#define QLCNIC_CAP0_LRO_MSS (1 << 21)
/*
* Context state
@@ -829,6 +832,9 @@ struct qlcnic_mac_list_s {
#define QLCNIC_FW_CAPABILITY_FVLANTX BIT_9
#define QLCNIC_FW_CAPABILITY_HW_LRO BIT_10
#define QLCNIC_FW_CAPABILITY_MULTI_LOOPBACK BIT_27
+#define QLCNIC_FW_CAPABILITY_MORE_CAPS BIT_31
+
+#define QLCNIC_FW_CAPABILITY_2_LRO_MAX_TCP_SEG BIT_2
/* module types */
#define LINKEVENT_MODULE_NOT_PRESENT 1
@@ -918,6 +924,7 @@ struct qlcnic_ipaddr {
#define QLCNIC_NEED_FLR 0x1000
#define QLCNIC_FW_RESET_OWNER 0x2000
#define QLCNIC_FW_HANG 0x4000
+#define QLCNIC_FW_LRO_MSS_CAP 0x8000
#define QLCNIC_IS_MSI_FAMILY(adapter) \
((adapter)->flags & (QLCNIC_MSI_ENABLED | QLCNIC_MSIX_ENABLED))
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index 8db8524..cfa174d 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -237,6 +237,9 @@ qlcnic_fw_cmd_create_rx_ctx(struct qlcnic_adapter *adapter)
| QLCNIC_CAP0_VALIDOFF);
cap |= (QLCNIC_CAP0_JUMBO_CONTIGUOUS | QLCNIC_CAP0_LRO_CONTIGUOUS);
+ if (adapter->flags & QLCNIC_FW_LRO_MSS_CAP)
+ cap |= QLCNIC_CAP0_LRO_MSS;
+
prq->valid_field_offset = offsetof(struct qlcnic_hostrq_rx_ctx,
msix_handler);
prq->txrx_sds_binding = nsds_rings - 1;
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
index 6ced319..28a6b28 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
@@ -588,6 +588,7 @@ enum {
#define CRB_DRIVER_VERSION (QLCNIC_REG(0x2a0))
#define CRB_FW_CAPABILITIES_1 (QLCNIC_CAM_RAM(0x128))
+#define CRB_FW_CAPABILITIES_2 (QLCNIC_CAM_RAM(0x12c))
#define CRB_MAC_BLOCK_START (QLCNIC_CAM_RAM(0x1c0))
/*
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index d32cf0d..f5a0ddc 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -1654,6 +1654,9 @@ qlcnic_process_lro(struct qlcnic_adapter *adapter,
length = skb->len;
+ if (adapter->flags & QLCNIC_FW_LRO_MSS_CAP)
+ skb_shinfo(skb)->gso_size = qlcnic_get_lro_sts_mss(sts_data1);
+
if (vid != 0xffff)
__vlan_hwaccel_put_tag(skb, vid);
netif_receive_skb(skb);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 46e77a2..707b5ca 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -1136,6 +1136,8 @@ static int
__qlcnic_up(struct qlcnic_adapter *adapter, struct net_device *netdev)
{
int ring;
+ u32 capab2;
+
struct qlcnic_host_rds_ring *rds_ring;
if (adapter->is_up != QLCNIC_ADAPTER_UP_MAGIC)
@@ -1146,6 +1148,12 @@ __qlcnic_up(struct qlcnic_adapter *adapter, struct net_device *netdev)
if (qlcnic_set_eswitch_port_config(adapter))
return -EIO;
+ if (adapter->capabilities & QLCNIC_FW_CAPABILITY_MORE_CAPS) {
+ capab2 = QLCRD32(adapter, CRB_FW_CAPABILITIES_2);
+ if (capab2 & QLCNIC_FW_CAPABILITY_2_LRO_MAX_TCP_SEG)
+ adapter->flags |= QLCNIC_FW_LRO_MSS_CAP;
+ }
+
if (qlcnic_fw_create_ctx(adapter))
return -EIO;
@@ -1215,6 +1223,7 @@ __qlcnic_down(struct qlcnic_adapter *adapter, struct net_device *netdev)
qlcnic_napi_disable(adapter);
qlcnic_fw_destroy_ctx(adapter);
+ adapter->flags &= ~QLCNIC_FW_LRO_MSS_CAP;
qlcnic_reset_rx_buffers_list(adapter);
qlcnic_release_tx_buffers(adapter);
--
1.7.1
^ permalink raw reply related
* [PATCH IPROUTE2] tc-codel: Update usage text
From: Vijay Subramanian @ 2012-05-24 18:48 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Eric Dumazet, Dave Taht, Vijay Subramanian
codel can take 'noecn' as an option. This also makes it consistent with the
manpage.
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
tc/q_codel.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tc/q_codel.c b/tc/q_codel.c
index 826285a..dc4b3f6 100644
--- a/tc/q_codel.c
+++ b/tc/q_codel.c
@@ -54,7 +54,7 @@
static void explain(void)
{
fprintf(stderr, "Usage: ... codel [ limit PACKETS ] [ target TIME]\n");
- fprintf(stderr, " [ interval TIME ] [ ecn ]\n");
+ fprintf(stderr, " [ interval TIME ] [ ecn | noecn ]\n");
}
static int codel_parse_opt(struct qdisc_util *qu, int argc, char **argv,
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Daney @ 2012-05-24 18:50 UTC (permalink / raw)
To: Timur Tabi
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FBE7DD8.509@freescale.com>
On 05/24/2012 11:28 AM, Timur Tabi wrote:
> David Daney wrote:
>> Yes. You may note in the DTS file I attached in the parent (sorry for
>> the fubar mime types), that there are two, almost identical, MDIO
>> masters. smi0 has two directly attached PHYs. smi1 goes to the mux,
>> and each child of the mux has four attached PHYs.
>
> I'm till have trouble understanding all this. I'm just hacking things up
> in order to help me understand it, but it's a slow and painful process.
>
> This call in mdio_mux_init() is failing:
>
> parent_bus = of_mdio_find_bus(parent_bus_node);
>
Well, the MDIO bus must have an associated device tree node.
For my OCTEON code, the MDIO bus device is created as a result of the
call to of_platform_bus_probe(), which takes care of filling in all the
device tree nodes of the devices it finds and creates.
> It returns NULL. Here is my MDIO node:
>
> fman0: fman@400000 {
> enet0: ethernet@e0000 {
> tbi-handle =<&tbi0>;
> phy-handle =<&phy0>;
> phy-connection-type = "sgmii";
> };
>
> mdio0: mdio@e1120 {
> gpios =<&gpio0 0 0
> &gpio0 1 0>;
>
> tbi0: tbi-phy@8 {
> reg =<0x8>;
> device_type = "tbi-phy";
> };
>
> phy0: ethernet-phy@1c {
> reg =<0x1c>;
> };
> };
> };
>
> What am I missing?
For starters, I do not see any compatible properties that would allow
the proper drivers to be bound to anything.
Also I see no MDIO mux node there, so it is unclear why you are even
asking these questions.
David Daney
^ permalink raw reply
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: Timur Tabi @ 2012-05-24 19:03 UTC (permalink / raw)
To: David Daney
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FBE82F2.6080100@gmail.com>
David Daney wrote:
> Well, the MDIO bus must have an associated device tree node.
>
> For my OCTEON code, the MDIO bus device is created as a result of the
> call to of_platform_bus_probe(), which takes care of filling in all the
> device tree nodes of the devices it finds and creates.
Ok, let me give you some background. We actually already have MDIO muxing
code in-house, but it's different from yours. So now I'm rewriting it to
use your design instead.
So our current code looks for "virtual MDIO nodes", and we call
mdiobus_alloc() and then of_mdiobus_register(). I think this is what I'm
missing now.
I just don't know what to do next. Part of the problem is that I don't
have much experience with MDIO drivers.
>> It returns NULL. Here is my MDIO node:
>>
>> fman0: fman@400000 {
>> enet0: ethernet@e0000 {
>> tbi-handle =<&tbi0>;
>> phy-handle =<&phy0>;
>> phy-connection-type = "sgmii";
>> };
>>
>> mdio0: mdio@e1120 {
>> gpios =<&gpio0 0 0
>> &gpio0 1 0>;
>>
>> tbi0: tbi-phy@8 {
>> reg =<0x8>;
>> device_type = "tbi-phy";
>> };
>>
>> phy0: ethernet-phy@1c {
>> reg =<0x1c>;
>> };
>> };
>> };
>>
>> What am I missing?
>
> For starters, I do not see any compatible properties that would allow
> the proper drivers to be bound to anything.
Ok, that makes sense.
> Also I see no MDIO mux node there, so it is unclear why you are even
> asking these questions.
I only gave you part of the device tree. Here's my mdio mux node:
mdio-mux {
compatible = "mdio-mux-gpio";
gpios = <&gpio0 0 0>, <&gpio0 1 0>;
mdio-parent-bus = <&mdio0>;
#address-cells = <1>;
#size-cells = <0>;
mdio@2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
phy21: ethernet-phy@1 {
reg = <1>;
// compatible = "marvell,88e1149r", "ethernet-phy-ieee802.3-c22";
marvell,reg-init = <3 0x10 0 0x5777>,
<3 0x11 0 0x00aa>,
<3 0x12 0 0x4105>,
<3 0x13 0 0x0a60>;
interrupt-parent = <&gpio0>;
// interrupts = <10 8>; /* Pin 10, active low */
};
};
};
};
>
> David Daney
>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Daney @ 2012-05-24 19:19 UTC (permalink / raw)
To: Timur Tabi
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <4FBE8605.2020507-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
On 05/24/2012 12:03 PM, Timur Tabi wrote:
> David Daney wrote:
>
>> Well, the MDIO bus must have an associated device tree node.
>>
>> For my OCTEON code, the MDIO bus device is created as a result of the
>> call to of_platform_bus_probe(), which takes care of filling in all the
>> device tree nodes of the devices it finds and creates.
>
> Ok, let me give you some background. We actually already have MDIO muxing
> code in-house, but it's different from yours. So now I'm rewriting it to
> use your design instead.
>
> So our current code looks for "virtual MDIO nodes", and we call
> mdiobus_alloc() and then of_mdiobus_register(). I think this is what I'm
> missing now.
>
> I just don't know what to do next.
You will have to debug it and find out why the device match is failing,
then fix it.
David Daney
^ permalink raw reply
* Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label
From: Paul Gortmaker @ 2012-05-24 19:58 UTC (permalink / raw)
To: David Miller; +Cc: jon.maloy, netdev, tipc-discussion, allan.stephens, maloy
In-Reply-To: <20120521.023926.548567931208958037.davem@davemloft.net>
[Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label] On 21/05/2012 (Mon 02:39) David Miller wrote:
> From: Jon Maloy <jon.maloy@ericsson.com>
> Date: Mon, 21 May 2012 01:59:12 -0400
>
> > With the latest series of patches from Paul Gortmaker and Allan
> > Stephens TIPC is now functionally mature and stable enough to
> > justify removal of the EXPERIMENTAL label.
> >
> > Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
>
> I'll let Paul Gortmaker decide whether this is warranted or
> not.
The EXPERIMENTAL thing has always been rather subjective, but
I'd like to see some level of confidence that a crafted up bogus
TIPC message can't be used to DOS a machine with active TIPC
connections before removing EXPERIMENTAL. Maybe the current code
is OK as-is in this respect but I'd feel better knowing that it
had been audited with this exact kind of thing in mind.
>
> I don't really want to all of a sudden start seeing patches from
> people like you and the windriver folks, who effectively wrote off
> upstream and left poor Paul Gortmaker holding the bag and having to
> take care of EVERYTHING.
To be fair, I should note that Al did a lot of work in the background
getting commits onto a modern baseline and answering all my questions
since the out of tree sourceforge mess was highlighted here on netdev.
>
> You can't just do nothing for years, end up making someone else
> do it, then say "Hey here I am, I feel like submitting upstream
> patches now" after I've spent this entire time starting to trust
> Paul for TIPC patches.
I've been thinking about this off and on, and I'm wondering what to
suggest going forward. Dealing with the backlog was largely going over
maintenance and bugfix type patches and sanitizing them for integration
upstream. It largely boiled down to being able to tell a crap patch
from a good one that matched upstream expectations. I figured I could
manage to not screw that up too badly, hence why I volunteered to assist
with the backlog.
But for new TIPC development features, future direction, and things like
that -- making the right call requires intimate understanding of TIPC
and its users, which is something that a maintainer should have but
something I know I don't have. (A man has to know his limitations.)
In this context, I'm not talking about these three trivial patches; but
more complicated stuff that I imagine will be floated in the future.
To that end, I can still review and call out issues in a crap patch when
I see them. But I'd like to see new stuff sent to netdev, so that folks
smarter than me have a chance to catch when a patch appears generally OK
but is architecturally the wrong direction etc.
Paul.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply
* pch_gbe: backport fails to start sending
From: Andy Cress @ 2012-05-24 20:05 UTC (permalink / raw)
To: netdev
Folks,
I now have a different case where the pch_gbe driver needs help.
I have backported the pch_gbe git head (v1.00) to kernel 2.6.32
(RHEL6.2) and when it loads, after the open completes and the link is
up, it fails to start sending and receiving.
I also took the pch_gbe source which runs fine on 2.6.38 (Fedora 15) and
backported it, and get the same results.
The much bulkier pch_gbe 0.91-NAPI driver does run on 2.6.32 (RHEL6.2)
but is not maintained.
I also tried backporting the mii.c from the 2.6.38 kernel, but that
didn't help, got the same symptoms.
After adding -DDEBUG to the 1.00 driver, I can see that it seems to get
just DMA Complete interrupts when it should be getting Transmit
complete, etc. I'm not sure why it gets stuck there.
Any ideas/input is welcome.
Andy
https://sendfile.kontron.com/message/KJKmrf171EhsuvbyhjnXpe
Attached at this link are two files:
pch_gbe-100a.tar.gz = the backported pch_gbe 1.00 head source, includes
patches that were applied.
dmesg.tar.gz = Some dmesg output from test cases with debug:
dmesg-pch10a-kern2632-bad.txt = backported 1.00 from git head on
kernel 2.6.32, fails
dmesg-pch10-kern2632-bad.txt = backported 1.00 from Fedora 15 on
kernel 2.6.32, fails
dmesg-pch10-kern2638-good.txt = same 1.00 source from Fedora 15 on
kernel 2.6.38, works
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Bug fixes
From: David Miller @ 2012-05-24 20:06 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1337882816-2097-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Thu, 24 May 2012 14:06:54 -0400
> Please apply to net-next.
As I've stated at least 10 times this week, net-next is not open
and therefore submitting patches for net-next is not appropriate.
If people are not going to even read my announcements and
notifications of the states of the various GIT trees, I might as well
not make them at all.
^ permalink raw reply
* Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label
From: David Miller @ 2012-05-24 20:12 UTC (permalink / raw)
To: paul.gortmaker; +Cc: jon.maloy, netdev, tipc-discussion, allan.stephens, maloy
In-Reply-To: <20120524195816.GA6487@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 24 May 2012 15:58:16 -0400
> But for new TIPC development features, future direction, and things like
> that -- making the right call requires intimate understanding of TIPC
> and its users, which is something that a maintainer should have but
> something I know I don't have. (A man has to know his limitations.)
>
> In this context, I'm not talking about these three trivial patches; but
> more complicated stuff that I imagine will be floated in the future.
>
> To that end, I can still review and call out issues in a crap patch when
> I see them. But I'd like to see new stuff sent to netdev, so that folks
> smarter than me have a chance to catch when a patch appears generally OK
> but is architecturally the wrong direction etc.
For maintainership, taste is more important than deep knowledge of the
specific technology. Worst case you ask the submitter to explain the
background of their change more thoroughly and that information is an
absolutely requirement in the commit message and code comments
anyways.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply
* Re: pch_gbe: backport fails to start sending
From: David Miller @ 2012-05-24 20:13 UTC (permalink / raw)
To: andy.cress; +Cc: netdev
In-Reply-To: <40680C535D6FE6498883F1640FACD44DEA6714@ka-exchange-1.kontronamerica.local>
From: "Andy Cress" <andy.cress@us.kontron.com>
Date: Thu, 24 May 2012 13:05:05 -0700
> I have backported the pch_gbe git head (v1.00) to kernel 2.6.32
> (RHEL6.2) and when it loads, after the open completes and the link is
> up, it fails to start sending and receiving.
Nobody here is going to help you with a vendor kernel backport,
sorry. You're on your own.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: jhs, hadi; +Cc: netdev
In-Reply-To: <1337863502.3513.15.camel@mojatatu>
From: jamal <hadi@cyberus.ca>
Date: Thu, 24 May 2012 08:45:02 -0400
> After about two decades, I am giving up on cyberus.
> Nabwaga Manyanga.
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xen/netback: Calculate the number of SKB slots required correctly
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: simon.graham
Cc: Ian.Campbell, konrad.wilk, xen-devel, netdev, bhutchings,
adnan.misherfi
In-Reply-To: <1337876767-16041-1-git-send-email-simon.graham@citrix.com>
From: Simon Graham <simon.graham@citrix.com>
Date: Thu, 24 May 2012 12:26:07 -0400
> When calculating the number of slots required for a packet header, the code
> was reserving too many slots if the header crossed a page boundary. Since
> netbk_gop_skb copies the header to the start of the page, the count of
> slots required for the header should be based solely on the header size.
>
> This problem is easy to reproduce if a VIF is bridged to a USB 3G modem
> device as the skb->data value always starts near the end of the first page.
>
> Signed-off-by: Simon Graham <simon.graham@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/wanrouter: Deprecate and schedule for removal
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: joe; +Cc: shemminger, greearb, jan.ceuleers, netdev
In-Reply-To: <1337879610.5070.17.camel@joe2Laptop>
From: Joe Perches <joe@perches.com>
Date: Thu, 24 May 2012 10:13:30 -0700
> No one uses this on current kernels anymore.
>
> Let it be known it's going to be removed eventually.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: Add Sierra Wireless device IDs
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb
In-Reply-To: <1337851172-28549-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 24 May 2012 11:19:32 +0200
> Some additional Gobi3K IDs found in the BSD/GPL licensed
> out-of-tree GobiNet driver from Sierra Wireless.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* Re: [PATCH] solos-pci: Fix DMA support
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, nathan
In-Reply-To: <1337871507.26314.132.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 24 May 2012 15:58:27 +0100
> DMA support has finally made its way to the top of the TODO list, having
> realised that a Geode using MMIO can't keep up with two ADSL2+ lines
> each running at 21Mb/s.
>
> This patch fixes a couple of bugs in the DMA support in the driver, so
> once the corresponding FPGA update is complete and tested everything
> should work properly.
>
> We weren't storing the currently-transmitting skb, so we were never
> unmapping it and never freeing/popping it when the TX was done.
> And the addition of pci_set_master() is fairly self-explanatory.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.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