* Re: [PATCH] ipconfig: add nameserver IPs to kernel-parameter ip=
From: David Miller @ 2012-09-20 21:37 UTC (permalink / raw)
To: chf.fritz
Cc: rob, kuznet, j.weitzel, jmorris, yoshfuji, kaber, linux-doc,
linux-kernel, netdev, hjk, daniel
In-Reply-To: <1348176485.3858.92.camel@mars>
From: Christoph Fritz <chf.fritz@googlemail.com>
Date: Thu, 20 Sep 2012 23:28:05 +0200
> + pr_info(" nameserver%u=%pI4",
> + i, &ic_nameservers[i]);
Why don't you just tab that second line out to planet Mars while
you're at it?
Please format this correctly, the goal is not to use a million
TAB characters. Rather, the goal is to get the text starting
on the second line of a function call to line up with the
first column after the openning parenthesis on the previous line.
What you're doing there looks awful, so you'll need to fix this
up before this patch will be considered seriously.
Thanks.
^ permalink raw reply
* Re: [RFC] tcp: use order-3 pages in tcp_sendmsg()
From: Vijay Subramanian @ 2012-09-20 21:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1348119475.31352.60.camel@edumazet-glaptop>
>>
>> I applied this patch to net-next and tested with e1000e driver.
>> With iperf I got around 8 % improvement on loopback.
>>
>> Tested-by: Vijay Subramanian <subramanian.vijay@gmail.com>
I think this tag should be on the thread with the actual patch. I will
reply to your patch with the Tested-by tag.
Thanks for your tips, Eric. For what its worth, here is what I found.
>
> If you keep the producer and consumer on separate cpus, and use large
> enough send() (64KB or 128KB), gain is more like 15 or 20%
>
Curiously, when I use taskset to run iperf server and client on
different cpus, throughput goes down by half
for both baseline (master branch) and with patch. Is taskset the right
way to test this?
I did notice a change in absolute throughout when I increase the
send() buffer size.
However, both the basline as well the patch showed improvement but the
relative improvement
was still around 8%.
> iperf uses 8KB writes, while netperf uses a 16KB default.
I think iperf has a bug. Both man page and comments in code claim
default buffer size for read/write is 8KB but
actual number seems to be 128KB. I believe the actual default is 128KB
not 8KB (-l option with iperf).
Thanks !
Vijay
^ permalink raw reply
* Re: [PATCH net-next v1] net: use a per task frag allocator
From: David Miller @ 2012-09-20 21:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1348073761.26523.1095.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 19 Sep 2012 18:56:01 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> We currently use a per socket page reserve for tcp_sendmsg() operations.
>
> This page is used to build fragments for skbs.
>
> Its done to increase probability of coalescing small write() into
> single segments in skbs still in write queue (not yet sent)
>
> But it wastes a lot of memory for applications handling many mostly
> idle sockets, since each socket holds one page in sk->sk_sndmsg_page
>
> Its also quite inefficient to build TSO packets of 64KB, because we need
> about 16 pages per skb on arches where PAGE_SIZE = 4096, so we hit
> page allocator more than wanted.
>
> This patch switches this frag allocator from socket to task structure,
> and uses bigger pages.
>
> (up to 32768 bytes per frag, thats order-3 pages on x86)
>
> This increases TCP stream performance by 20% on loopback device,
> but also benefits on other network devices, since 8x less frags are
> mapped on transmit and unmapped on tx completion.
>
> Its possible some TSO enabled hardware cant cope with bigger fragments,
> but their ndo_start_xmit() should already handle this, splitting a
> fragment in sub fragments, since some arches have PAGE_SIZE=65536
>
> Successfully tested on various ethernet devices.
> (ixgbe, igb, bnx2x, tg3, mellanox mlx4)
>
> Followup patches can use this infrastructure in two other spots
> and get rid of the socket sk_sndmsg_page.
>
> Open for discussion : Should we fallback to smaller pages
> if order-3 page allocations fail ?
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I like this a lot and I look forward to your upcoming changes to
convert the other two sk_sndmsg_page users as well, but I can't
apply this to net-next just yet.
The question on fallback is a good one and something we have
to resolve before applying this.
Note in particular that sk_allocation can be set to just about
anything, and this also has potential interaction issues with
SOCK_MEMALLOC.
^ permalink raw reply
* [PATCH v2] ipconfig: add nameserver IPs to kernel-parameter ip=
From: Christoph Fritz @ 2012-09-20 21:48 UTC (permalink / raw)
To: David Miller
Cc: rob, kuznet, j.weitzel, jmorris, yoshfuji, kaber, linux-doc,
linux-kernel, netdev, hjk, daniel
In-Reply-To: <20120920.173719.1238894522809866676.davem@davemloft.net>
On small systems (e.g. embedded ones) IP addresses are often configured
by bootloaders and get assigned to kernel via parameter "ip=". If set to
"ip=dhcp", even nameserver entries from DHCP daemons are handled. These
entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
To configure nameservers for networks without DHCP, this patch adds option
<dns0-ip> and <dns1-ip> to kernel-parameter 'ip='.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Tested-by: Jan Weitzel <j.weitzel@phytec.de>
---
v2: - fix indent
---
Documentation/filesystems/nfs/nfsroot.txt | 7 +++++
net/ipv4/ipconfig.c | 39 ++++++++++++++++++++++++++--
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt
index ffdd9d8..4ed7875 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -158,6 +158,13 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
Default: any
+ <dns0-ip> IP address of first nameserver.
+ Value gets exported by /proc/net/pnp which is often linked
+ on embedded systems by /etc/resolv.conf.
+
+ <dns1-ip> IP address of secound nameserver.
+ Same as above.
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 67e8a6b..1c0e7e0 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -743,14 +743,22 @@ static void __init ic_bootp_init_ext(u8 *e)
/*
- * Initialize the DHCP/BOOTP mechanism.
+ * Predefine Nameservers
*/
-static inline void __init ic_bootp_init(void)
+static inline void __init ic_nameservers_predef(void)
{
int i;
for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
ic_nameservers[i] = NONE;
+}
+
+/*
+ * Initialize the DHCP/BOOTP mechanism.
+ */
+static inline void __init ic_bootp_init(void)
+{
+ ic_nameservers_predef();
dev_add_pack(&bootp_packet_type);
}
@@ -1379,6 +1387,7 @@ static int __init ip_auto_config(void)
int retries = CONF_OPEN_RETRIES;
#endif
int err;
+ unsigned int i;
#ifdef CONFIG_PROC_FS
proc_net_fops_create(&init_net, "pnp", S_IRUGO, &pnp_seq_fops);
@@ -1499,7 +1508,15 @@ static int __init ip_auto_config(void)
&ic_servaddr, &root_server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(", mtu=%d", ic_dev_mtu);
- pr_cont("\n");
+ for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE) {
+ pr_info(" nameserver%u=%pI4",
+ i, &ic_nameservers[i]);
+ break;
+ }
+ for (i++; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE)
+ pr_cont(", nameserver%u=%pI4\n", i, &ic_nameservers[i]);
#endif /* !SILENT */
return 0;
@@ -1570,6 +1587,8 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ ic_nameservers_predef();
+
/* Parse string for static IP assignment. */
ip = addrs;
while (ip && *ip) {
@@ -1613,6 +1632,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_enable = 0;
}
break;
+ case 7:
+ if (CONF_NAMESERVERS_MAX >= 1) {
+ ic_nameservers[0] = in_aton(ip);
+ if (ic_nameservers[0] == ANY)
+ ic_nameservers[0] = NONE;
+ }
+ break;
+ case 8:
+ if (CONF_NAMESERVERS_MAX >= 2) {
+ ic_nameservers[1] = in_aton(ip);
+ if (ic_nameservers[1] == ANY)
+ ic_nameservers[1] = NONE;
+ }
+ break;
}
}
ip = cp;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] tcp: restore rcv_wscale in a repair mode (v2)
From: David Miller @ 2012-09-20 21:50 UTC (permalink / raw)
To: avagin; +Cc: netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber, xemul
In-Reply-To: <1348083600-3881500-1-git-send-email-avagin@openvz.org>
From: Andrew Vagin <avagin@openvz.org>
Date: Wed, 19 Sep 2012 23:40:00 +0400
> rcv_wscale is a symetric parameter with snd_wscale.
>
> Both this parameters are set on a connection handshake.
>
> Without this value a remote window size can not be interpreted correctly,
> because a value from a packet should be shifted on rcv_wscale.
>
> And one more thing is that wscale_ok should be set too.
>
> This patch doesn't break a backward compatibility.
> If someone uses it in a old scheme, a rcv window
> will be restored with the same bug (rcv_wscale = 0).
>
> v2: Save backward compatibility on big-endian system. Before
> the first two bytes were snd_wscale and the second two bytes were
> rcv_wscale. Now snd_wscale is opt_val & 0xFFFF and rcv_wscale >> 16.
> This approach is independent on byte ordering.
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> CC: Pavel Emelyanov <xemul@parallels.com>
> Signed-off-by: Andrew Vagin <avagin@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] USB: remove dbg() usage in USB networking drivers
From: David Miller @ 2012-09-20 21:53 UTC (permalink / raw)
To: gregkh; +Cc: netdev, joe, linux-usb, linux-kernel
In-Reply-To: <20120919194614.GA17585@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Wed, 19 Sep 2012 20:46:14 +0100
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> The dbg() USB macro is so old, it predates me. The USB networking drivers are
> the last hold-out using this macro, and we want to get rid of it, so replace
> the usage of it with the proper netdev_dbg() or dev_dbg() (depending on the
> context) calls.
>
> Some places we end up using a local variable for the debug call, so also
> convert the other existing dev_* calls to use it as well, to save tiny amounts
> of code space.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> v2: Addressed review comments from Joe Perches
>
> Again, I am glad to take this in the usb-next tree if wanted, whatever is
> easiest.
I'll take this into net-next, applied, thanks Greg.
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: call subdriver with control intf only
From: David Miller @ 2012-09-20 21:54 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1347308150-19088-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Mon, 10 Sep 2012 22:15:50 +0200
> This fixes a hang on suspend due to calling wdm_suspend on
> the unregistered data interface. The hang should have been
> a NULL pointer reference had it not been for a logic error
> in the cdc_wdm code.
>
> commit 230718bd net: qmi_wwan: bind to both control and data interface
>
> changed qmi_wwan to use cdc_wdm as a subdriver for devices with
> a two-interface QMI/wwan function. The commit failed to update
> qmi_wwan_suspend and qmi_wwan_resume, which were written to handle
> either a single combined interface function, or no subdriver at all.
>
> The result was that we called into the subdriver both when the
> control interface was suspended and when the data interface was
> suspended. Calling the subdriver suspend function with an
> unregistered interface is not supported and will make the
> subdriver bug out.
>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] tcp: use order-3 pages in tcp_sendmsg()
From: Rick Jones @ 2012-09-20 22:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vijay Subramanian, David Miller, netdev
In-Reply-To: <1348119475.31352.60.camel@edumazet-glaptop>
On 09/19/2012 10:37 PM, Eric Dumazet wrote:
> iperf uses 8KB writes, while netperf uses a 16KB default.
For the sake of the archives and posterity, netperf does not have a
"fixed" default send size. The "default" will vary with platform and
platform tuning
What netperf does (for TCP at least) is default the send size to the
value returned after a getsockopt(SO_SNDBUF) issued against the socket
just after it is allocated for the data connection. If the user has
asked for a specific socket buffer size, there will have been a
preceding setsockopt(SO_SNDBUF) call.
So, "by default" under Linux, with no options to set the socket buffer
size, netperf will use 16 KB so long as that is the default (initial)
value for SO_SNDBUF.
The sequence will go something like:
1) create the data socket
2) if user asked to set socket buffer size call setsockopt()
3) call getsockopt()
4) if the user did not specify a send size, use the value returned from
the getsockopt() call
So, if one runs netperf on a platform other than Linux, the "default"
send size may be different. Similarly, if running under linux, but
net.ipv4.tcp_wmwm is tweaked, the "default" send size may be different.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [PATCH 0/6] xfrm_user info leaks
From: David Miller @ 2012-09-20 22:09 UTC (permalink / raw)
To: minipli; +Cc: steffen.klassert, netdev, linux-kernel
In-Reply-To: <1348090423-32665-1-git-send-email-minipli@googlemail.com>
From: Mathias Krause <minipli@googlemail.com>
Date: Wed, 19 Sep 2012 23:33:37 +0200
> the following series fixes various info leaks in the xfrm netlink
> interface. As always, a test case can be supplied on request.
>
> Patches 1 to 5 are probably material for stable, too. Patch 6 is just a
> minor optimization I stumbled across while auditing the code.
>
> Please apply!
All applied, and I made sure to use v3 of patch #5 (which you marked
as 5/7 instead of 5/6 :-)
Also, these have been queued up for -stable as well.
Thanks.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell @ 2012-09-20 22:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: David Miller, mika.westerberg, netdev, linux-next, linux-kernel
In-Reply-To: <20120920.164558.2281417114805373564.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
[Just bring this to the attention of the PowerPC folks ...]
On Thu, 20 Sep 2012 16:45:58 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> Date: Thu, 20 Sep 2012 12:10:14 +0300
>
> > On Thu, Sep 20, 2012 at 05:36:22PM +1000, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> After merging the final tree, today's linux-next build (powerpc
> >> allyesconfig) failed like this:
> >>
> >> drivers/net/ethernet/i825xx/znet.c: In function 'hardware_init':
> >> drivers/net/ethernet/i825xx/znet.c:868:2: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]
> >>
> >> Caused by commit 1d3ff76759b7 ("i825xx: znet: fix compiler warnings when
> >> building a 64-bit kernel"). Is there some Kconfig dependency missing (CONFIG_ISA)?
> >
> > If we make it dependent on CONFIG_ISA then the driver cannot be built with
> > 64-bit kernel. Then again is there someone running 64-bit kernel on Zenith
> > Z-note notebook? From the pictures it looks like very ancient "laptop".
> >
> > An alternative is to make it depend on X86 like this:
>
> I think the powerpc port is at fault here.
>
> Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Benjamin Herrenschmidt @ 2012-09-20 22:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul Mackerras, linuxppc-dev, David Miller, mika.westerberg,
netdev, linux-next, linux-kernel
In-Reply-To: <20120921081531.67db8a7d0ac1b35426b22c45@canb.auug.org.au>
> > I think the powerpc port is at fault here.
> >
> > Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().
Hrm, that's ancient gunk, I'll have to dig. We potentially can support
ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
isa_virt_to_bus is a non-starter.
But then, do we really care ? IE. Is there single device that actually
requires ISA_DMA_API and that is expected to work on any currently
supported powerpc hw ? :-)
We don't even support PReP anymore, so that leaves us with what ?
Anybody has an objection to turning ISA_DMA_API off ?
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell @ 2012-09-20 22:28 UTC (permalink / raw)
To: David Miller
Cc: mika.westerberg, netdev, linux-next, linux-kernel,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
In-Reply-To: <20120920.164558.2281417114805373564.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
Hi Dave,
On Thu, 20 Sep 2012 16:45:58 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> I think the powerpc port is at fault here.
>
> Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().
Not disagreeing, but it would be nice if this was documented somewhere
(maybe in Documentation/DMA-ISA-LPC.txt). We have not had this problem
before because all the other uses of isa_virt_to_bus() are in drivers
that depend on X86 or ARM or ISA or EISA.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v1 11/19] qlcnic: sysfs interface routine updates
From: David Miller @ 2012-09-20 22:31 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver, himanshu.madhani
In-Reply-To: <1348098373-20745-12-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Wed, 19 Sep 2012 19:46:05 -0400
> + if (QLCNIC_IS_82XX(adapter)) {
> + ret = QLC_DEV_GET_DRV(op_mode, pci_func);
> + }
Don't use curly braces for a single line basic block.
^ permalink raw reply
* Re: [PATCH v1 12/19] qlcnic: update irq management routines
From: David Miller @ 2012-09-20 22:32 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1348098373-20745-13-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Wed, 19 Sep 2012 19:46:06 -0400
> + if (QLCNIC_IS_83XX(adapter) &&
> + (adapter->flags & QLCNIC_MSIX_ENABLED)) {
This is not indented properly. The first character on the second
line should be at the first column after the openning parenthesis
on the first line.
> + for (ring = 0; ring < adapter->max_drv_tx_rings;
> + ring++) {
Same problem here.
> + for (ring = 0; ring < adapter->max_drv_tx_rings;
> + ring++) {
And here as well.
^ permalink raw reply
* Re: [PATCH v1 13/19] qlcnic: 83xx hardware access and data path routines
From: David Miller @ 2012-09-20 22:45 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1348098373-20745-14-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Wed, 19 Sep 2012 19:46:07 -0400
> + for (i = QLCNIC_DEV_INFO_SIZE + 1;
> + j < ARRAY_SIZE(qlcnic_83xx_reg_tbl); i++, j++)
The 'j' on the second line should be at the first column after the
openning parenthesis on the first line.
> + ahw->intr_tbl = vmalloc(num_msix *
> + sizeof(struct qlcnic_intrpt_config));
Same problem here.
> + if (!(adapter->flags & QLCNIC_MSI_ENABLED) &&
> + !(adapter->flags & QLCNIC_MSIX_ENABLED)) {
And here.
> + if (ret) {
> + dev_info(&adapter->pdev->dev,
> + "Error getting Rx stats\n");
This dev_info() call is indented one TAB too deeply.
> + npar_info->max_mtu = le16_to_cpu(nic_info->max_mtu);
> +
> +}
Please remove this extraneous empty line.
> + if (!((ADDR_IN_RANGE(addr, QLCNIC_ADDR_QDR_NET,
> + QLCNIC_ADDR_QDR_NET_MAX)) ||
> + (ADDR_IN_RANGE(addr, QLCNIC_ADDR_DDR_NET,
> + QLCNIC_ADDR_DDR_NET_MAX)))){
This is improperly indented, function arguments split up into
subsequent lines should line up with the first column after
the openning parenthesis that they are a part of.
On the last line, there needs to be a space between the closing
parenthesis and the openning curly brace.
> + } else if ((mbx_err_code == QLCNIC_MBX_RSP_OK)
> + || (mbx_err_code == QLCNIC_MBX_PORT_RSP_OK)) {
Incorrect indentation, and the "||" should appear at the end of the
first line rather than at the beginning of the second line.
> + mbx->req.arg[0] = (type | (mbx->req.num << 16) |
> + (adapter->ahw->fw_hal_version << 29));
This second line needs to be indented properly. If it makes the line too
long then split the expression up using temporary variables or create
a helper function so you can put the expression at a less deep indentation
level.
> + cmd.req.arg[1] = cpu_to_le32((mode ? 1 : 0) |
> + (adapter->recv_ctx->context_id) << 16);
This is not properly indented (and it's extremely tiring explaining
this same thing more than a dozen times during this review)
The first "(" on the second line must line up with the first column
after the openning parenthesis of cpu_to_le32( on the previous
line.
> + cmd.req.arg[1] = cpu_to_le32(1 |
> + adapter->recv_ctx->context_id << 16);
Same problem.
> + cmd.req.arg[1] = cpu_to_le32(2 |
> + adapter->recv_ctx->context_id << 16);
Same problem.
> + cmd.req.arg[1] = cpu_to_le32((mode ? (BIT_0 | BIT_1 | BIT_3) : 0) |
> + ((adapter->recv_ctx->context_id) << 16));
By some strange miracle you are able to get it correct in this case.
> + cmd.req.arg[1] = cpu_to_le32(op | (1 << 8) |
> + (adapter->recv_ctx->context_id << 16));
Again, same problem.
> + cmd.req.arg[2] = cpu_to_le32(coal->rx_packets |
> + (coal->rx_time_us << 16));
And here too.
> + cmd.req.arg[1] = cpu_to_le32(op | BIT_31 |
> + (func_id << 16));
And again.
> + for (i = 0, index = 2; i < max_ints; i++, index += 2) {
> +
> + val = le32_to_cpu(cmd.rsp.arg[index]);
Please remove this unnecessary blank line.
> + }
> +
> +
> + th->psh = push;
There is no need for two blank lines here, remove at least one of them.
^ permalink raw reply
* Re: [PATCH v1 0/19] qlcnic: patches for new adapter - Qlogic 83XX CNA
From: David Miller @ 2012-09-20 22:47 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1348098373-20745-1-git-send-email-sony.chacko@qlogic.com>
I tired reviewing this driver just for coding style issues after just
looking at two or three of them.
I hope that it is no surprise to you that people are very reluctant to
review this driver at all, given how much basic stylistic issues
remain.
I haven't even begun to think about the actual technical semantics and
correctness of these patches. I doubt anyone else in the community
had either, and that won't even begin to happen until the coding style
issues are rectified.
You guys have a long, very long, way to go with this patch set.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: David Miller @ 2012-09-20 22:53 UTC (permalink / raw)
To: benh
Cc: sfr, paulus, linuxppc-dev, mika.westerberg, netdev, linux-next,
linux-kernel
In-Reply-To: <1348179764.1132.35.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 21 Sep 2012 08:22:44 +1000
> Hrm, that's ancient gunk, I'll have to dig. We potentially can support
> ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
> isa_virt_to_bus is a non-starter.
>
> But then, do we really care ? IE. Is there single device that actually
> requires ISA_DMA_API and that is expected to work on any currently
> supported powerpc hw ? :-)
>
> We don't even support PReP anymore, so that leaves us with what ?
ISA_DMA_API implies a fixed window of addresses which are <= 32-bits
on the bus, which is a hardware requirement of these devices.
isa_virt_to_bus() goes to that physical address, and the expection is
that you use GFP_DMA and thus the physical addresses fit inside of
an unsigned int.
isa_virt_to_bus() basically amounts to a virt-->phys plus a cast.
> Anybody has an objection to turning ISA_DMA_API off ?
Then you can remove all of the DMA api stuff in powerpc's asm/dma.h
but some of it looks like it might be in use.
^ permalink raw reply
* СПЕШНО СЪОБЩЕНИЕ!
From: Webmaster Ndihme Desk @ 2012-09-20 23:05 UTC (permalink / raw)
--
Уважаеми потребителю Webmail
Вашата пощенска кутия е превишил ограничението на употребата на
квотата, което е определено от вашия мениджър, както и достъп до
вашата пощенска кутия чрез нашата поща портал ще бъде недостъпна за
някой по време на този период на поддържане.
Вие не ще бъде в състояние да създаде нова електронна поща, за да
изпращат или получават отново, докато не валидира пощенската си кутия.
За повторно валидира пощенската си кутия, можете да кликнете
http://www.pinoybroker.com/4buyers/forms/form1.html
благодаря
Системния администратор.
Copyright © 2012 # WEBMASTER ADMIN • Всички права запазени •
^ permalink raw reply
* [PATCH net-next] net1080: Neaten netdev_dbg use
From: Joe Perches @ 2012-09-21 0:10 UTC (permalink / raw)
To: David Miller; +Cc: gregkh, netdev, linux-usb, linux-kernel
In-Reply-To: <20120920.175335.1128494030737237412.davem@davemloft.net>
Remove unnecessary temporary variable and #ifdef DEBUG block.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/usb/net1080.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index 29e06e1..c062a3e 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c
@@ -417,12 +417,9 @@ static int net1080_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
u16 hdr_len, packet_len;
if (!(skb->len & 0x01)) {
-#ifdef DEBUG
- struct net_device *net = dev->net;
netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
- skb->len, net->hard_header_len, dev->hard_mtu,
- net->mtu);
-#endif
+ skb->len, dev->net->hard_header_len, dev->hard_mtu,
+ dev->net->mtu);
dev->net->stats.rx_frame_errors++;
nc_ensure_sync(dev);
return 0;
^ permalink raw reply related
* Re: Oops with latest (netfilter) nf-next tree, when unloading iptable_nat
From: Pablo Neira Ayuso @ 2012-09-21 1:00 UTC (permalink / raw)
To: Patrick McHardy
Cc: Jesper Dangaard Brouer, Florian Westphal, netfilter-devel, netdev,
yongjun_wei
In-Reply-To: <Pine.GSO.4.63.1209201859140.14078@stinky-local.trash.net>
On Thu, Sep 20, 2012 at 07:06:52PM +0200, Patrick McHardy wrote:
> On Thu, 20 Sep 2012, Patrick McHardy wrote:
>
> >>>diff --git a/net/netfilter/nf_conntrack_core.c
> >>>b/net/netfilter/nf_conntrack_core.c
> >>>index dcb2791..0f241be 100644
> >>>--- a/net/netfilter/nf_conntrack_core.c
> >>>+++ b/net/netfilter/nf_conntrack_core.c
> >>>@@ -1224,6 +1224,8 @@ get_next_corpse(struct net *net, int
> >>>(*iter)(struct nf_conn *i, void *data),
> >>> spin_lock_bh(&nf_conntrack_lock);
> >>> for (; *bucket < net->ct.htable_size; (*bucket)++) {
> >>> hlist_nulls_for_each_entry(h, n, &net->ct.hash[*bucket],
> >>>hnnode) {
> >>>+ if (NF_CT_DIRECTION(h) != IP_CT_DIR_ORIGINAL)
> >>>+ continue;
> >>
> >>I think this will make the deletion of entries via `conntrack -F'
> >>slowier as we'll have to iterate over more entries (we won't delete
> >>entries for the reply tuple).
> >
> >Slightly maybe, but I doubt it makes much of a difference.
> >
> >>I think I prefer Florian's patch, it's fairly small and it does not
> >>change the current nf_ct_iterate behaviour or adding some
> >>nf_nat_iterate cleanup.
> >
> >I don't think I've received it. Could you forward it to me please?
>
> Florian forwarded the patch to me. While it fixes the problem, it
> is a workaround and it certainly is inelegant to do the
> list_del_rcu_init() and memset up to *four* times for a single conntrack.
>
> The correct thing IMO is to invoke the callbacks exactly once per
> conntrack, either through my nf_ct_iterate_cleanup() change or through
> a new iteration function for callers that don't kill conntracks. As
> soon as we start generating events for NAT section cleanup this will be
> needed in any case.
>
> Unless I'm missing something, conntrack flushing is also a really
> rare operation anyways and for large tables where this might make a
> small difference will take a quite large time anyway.
Makes sense. And we can revisit this to improve it later.
I'll take this patch. I'll send a batch with updates for the nf-nat
thin asap.
Thanks a lot Patrick.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2012-09-21 1:30 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, "Bjørn Mork"
[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in drivers/net/usb/qmi_wwan.c between commit 9db273f45686 ("net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200") from the net tree and commit bd877e489126 ("net: qmi_wwan: use a single bind function for all device types") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/usb/qmi_wwan.c
index 3543c9e,e7b53f0..0000000
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@@ -366,21 -353,17 +353,21 @@@ static const struct usb_device_id produ
},
/* 2. Combined interface devices matching on class+protocol */
+ { /* Huawei E367 and possibly others in "Windows mode" */
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 7),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
{ /* Huawei E392, E398 and possibly others in "Windows mode" */
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 17),
- .driver_info = (unsigned long)&qmi_wwan_shared,
+ .driver_info = (unsigned long)&qmi_wwan_info,
},
- { /* Pantech UML290 */
- USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
+ { /* Pantech UML290, P4200 and more */
+ USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
- .driver_info = (unsigned long)&qmi_wwan_shared,
+ .driver_info = (unsigned long)&qmi_wwan_info,
},
{ /* Pantech UML290 - newer firmware */
- USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
+ USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
- .driver_info = (unsigned long)&qmi_wwan_shared,
+ .driver_info = (unsigned long)&qmi_wwan_info,
},
/* 3. Combined interface devices matching on interface number */
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell @ 2012-09-21 1:37 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Mika Westerberg
In-Reply-To: <20120920173622.2aa7209cd241a3945f4384d4@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]
Hi Dave,
On Thu, 20 Sep 2012 17:36:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/net/ethernet/i825xx/znet.c: In function 'hardware_init':
> drivers/net/ethernet/i825xx/znet.c:868:2: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]
>
> Caused by commit 1d3ff76759b7 ("i825xx: znet: fix compiler warnings when
> building a 64-bit kernel"). Is there some Kconfig dependency missing (CONFIG_ISA)?
>
> I have reverted that commit for today.
Today, I have added the following merge fix patch instead of reverting the
above (just until PowerPC can be fixed one way or the other). I don't
know if you want to put this into the net-next tree, but it may be a
reasonable temporary measure.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 21 Sep 2012 11:32:09 +1000
Subject: [PATCH] i825xx: znet: temporarily disable on PPC
due to build problems
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/ethernet/i825xx/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/i825xx/Kconfig b/drivers/net/ethernet/i825xx/Kconfig
index fed5080..9fce38b 100644
--- a/drivers/net/ethernet/i825xx/Kconfig
+++ b/drivers/net/ethernet/i825xx/Kconfig
@@ -151,6 +151,7 @@ config SUN3_82586
config ZNET
tristate "Zenith Z-Note support (EXPERIMENTAL)"
depends on EXPERIMENTAL && ISA_DMA_API
+ depends on !PPC
---help---
The Zenith Z-Note notebook computer has a built-in network
(Ethernet) card, and this is the Linux driver for it. Note that the
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
From: Ming Lei @ 2012-09-21 1:44 UTC (permalink / raw)
To: David Miller; +Cc: oliver, bjorn, gregkh, finik, rjw, stern, netdev, linux-usb
In-Reply-To: <20120920.171610.1120043891672310370.davem@davemloft.net>
On Fri, Sep 21, 2012 at 5:16 AM, David Miller <davem@davemloft.net> wrote:
> From: Oliver Neukum <oliver@neukum.org>
> Date: Thu, 20 Sep 2012 23:04:38 +0200
>
>> On Thursday 20 September 2012 17:02:27 David Miller wrote:
>>>
>>> There seems to be some discussion about the legitimacy of doing things
>>> this way, and in any event the patches were an RFC.
>>>
>>> Please resubmit as a non-RFC once all the issues have been worked
>>> out, if appropriate.
>>
>> Just to make this clear, I'd like to state that the discussion involved
>> only the third, last patch in the series. The first two are fine and make
>> sense by themselves.
>
> I want changes in those, see my replies.
No problem, I will send out -v2 of the first two patches later.
thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH net-next] net1080: Neaten netdev_dbg use
From: David Miller @ 2012-09-21 2:06 UTC (permalink / raw)
To: joe-6d6DIl74uiNBDgjK7y7TUQ
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1348186223.2134.1.camel@joe2Laptop>
From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Date: Thu, 20 Sep 2012 17:10:23 -0700
> Remove unnecessary temporary variable and #ifdef DEBUG block.
>
> Signed-off-by: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Applied, thanks Joe.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] at91ether: return PTR_ERR if call to clk_get fails
From: David Miller @ 2012-09-21 2:22 UTC (permalink / raw)
To: nicolas.ferre; +Cc: devendra.aaru, netdev, linux-arm-kernel
In-Reply-To: <505AC8D6.5080404@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Thu, 20 Sep 2012 09:42:14 +0200
> On 09/20/2012 09:04 AM, Devendra Naga :
>> we are currently returning ENODEV, as the clk_get may give a exact
>> error code in its returned pointer, assign it to the ret by using the
>> PTR_ERR function, so that the subsequent goto label will jump to the
>> error path and clean the driver and return the error correctly.
>>
>> Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox