* Re: [PATCH net_test_tools] route_bench: Fix bug in DST_ITERATE option
From: Vijay Subramanian @ 2014-11-25 1:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141124.160932.1535765335085310139.davem@davemloft.net>
>> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
>
> This does not apply to the 'net' tree.
David,
The patch was targeted not against 'net' tree but against test suite
at https://git.kernel.org/pub/scm/linux/kernel/git/davem/net_test_tools.git
as indicated in subject. Would you like me to resubmit this making it
clear in commit log too?
-vijay
^ permalink raw reply
* RE: [PATCH] net: fec: init maximum receive buffer size for ring1 and ring2
From: fugang.duan @ 2014-11-25 1:27 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
stephen@networkplumber.org, festevam@gmail.com
In-Reply-To: <20141124.152250.380142287256307570.davem@davemloft.net>
From: David Miller <davem@davemloft.net> Sent: Tuesday, November 25, 2014 4:23 AM
>To: Duan Fugang-B38611
>Cc: netdev@vger.kernel.org; bhutchings@solarflare.com;
>stephen@networkplumber.org; festevam@gmail.com
>Subject: Re: [PATCH] net: fec: init maximum receive buffer size for ring1
>and ring2
>
>From: Fugang Duan <b38611@freescale.com>
>Date: Sun, 23 Nov 2014 17:23:06 +0800
>
>> i.MX6SX fec support three rx ring1, the current driver lost to init
>> ring1 and ring2 maximum receive buffer size, that cause receving frame
>> date length error. The driver reports "rcv is not +last" error log in
>> user case.
>>
>> Signed-off-by: Fugang Duan <B38611@freescale.com>
>
>This patch does not apply to the 'net' tree, although it does apply
>cleanly to the net-next tree.
>
>Determining which tree a patch is for is not my job, it is your's.
>
>Therefore you must always explicitly state what tree your patch is
>intended to be added to, by starting your Subject line with "[PATCH net] "
>or "[PATCH net-next] ".
>
>I've applied this, but next time I will just ask you to properly submit
>the patch instead.
David, thanks. I note this the next time.
Regards,
Andy
^ permalink raw reply
* Re: [PATCH 1/2] sh_eth: Fix sleeping function called from invalid context
From: Simon Horman @ 2014-11-25 2:17 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Yoshihiro Kaneko, netdev, David S. Miller, Magnus Damm, linux-sh
In-Reply-To: <546531D6.3090009@cogentembedded.com>
Hi Sergei,
On Fri, Nov 14, 2014 at 01:33:58AM +0300, Sergei Shtylyov wrote:
> On 11/13/2014 10:02 AM, Yoshihiro Kaneko wrote:
>
> >From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>
> >Fix the bug as follows:
>
> >----
> >[ 1238.161349] BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:952
> >[ 1238.188279] in_atomic(): 1, irqs_disabled(): 0, pid: 1388, name: cat
> >[ 1238.207425] CPU: 0 PID: 1388 Comm: cat Not tainted 3.10.31-ltsi-00046-gefa0b46 #1087
> >[ 1238.230737] Backtrace:
> >[ 1238.238123] [<c0012e64>] (dump_backtrace+0x0/0x10c) from [<c0013000>] (show_stack+0x18/0x1c)
> >[ 1238.263499] r6:000003b8 r5:c06160c0 r4:c0669e00 r3:00404000
> >[ 1238.280583] [<c0012fe8>] (show_stack+0x0/0x1c) from [<c04515a4>] (dump_stack+0x20/0x28)
> >[ 1238.304631] [<c0451584>] (dump_stack+0x0/0x28) from [<c004970c>] (__might_sleep+0xf8/0x118)
> >[ 1238.329734] [<c0049614>] (__might_sleep+0x0/0x118) from [<c02465ac>] (__pm_runtime_resume+0x38/0x90)
> >[ 1238.357170] r7:d616f000 r6:c049c458 r5:00000004 r4:d6a17210
> >[ 1238.374251] [<c0246574>] (__pm_runtime_resume+0x0/0x90) from [<c029b1c4>] (sh_eth_get_stats+0x44/0x280)
> >[ 1238.402468] r7:d616f000 r6:c049c458 r5:d5c21000 r4:d5c21000
> >[ 1238.419552] [<c029b180>] (sh_eth_get_stats+0x0/0x280) from [<c03ae39c>] (dev_get_stats+0x54/0x88)
> >[ 1238.446204] r5:d5c21000 r4:d5ed7e08
> >[ 1238.456980] [<c03ae348>] (dev_get_stats+0x0/0x88) from [<c03c677c>] (netstat_show.isra.15+0x54/0x9c)
> >[ 1238.484413] r6:d5c21000 r5:d5c21238 r4:00000028 r3:00000001
> >[ 1238.501495] [<c03c6728>] (netstat_show.isra.15+0x0/0x9c) from [<c03c69b8>] (show_tx_errors+0x18/0x1c)
> >[ 1238.529196] r7:d5f945d8 r6:d5f945c0 r5:c049716c r4:c0650e7c
> >[ 1238.546279] [<c03c69a0>] (show_tx_errors+0x0/0x1c) from [<c023963c>] (dev_attr_show+0x24/0x50)
> >[ 1238.572157] [<c0239618>] (dev_attr_show+0x0/0x50) from [<c010c148>] (sysfs_read_file+0xb0/0x140)
> >[ 1238.598554] r5:c049716c r4:d5c21240
> >[ 1238.609326] [<c010c098>] (sysfs_read_file+0x0/0x140) from [<c00b9ee4>] (vfs_read+0xb0/0x13c)
> >[ 1238.634679] [<c00b9e34>] (vfs_read+0x0/0x13c) from [<c00ba0ac>] (SyS_read+0x44/0x74)
> >[ 1238.657944] r8:bef45bf0 r7:00000000 r6:d6ac0600 r5:00000000 r4:00000000
> >[ 1238.678172] [<c00ba068>] (SyS_read+0x0/0x74) from [<c000eec0>] (ret_fast_syscall+0x0/0x30)
> >----
>
> How to reproduce this?
I have spoken with Kimura-san and the problem may be reproduced by
building the kernel with CONFIG_DEBUG_ATOMIC_SLEEP=y and reading network
statistics while the network interface is down.
e.g.:
ifconfig eth0 down
cat /sys/class/net/eth0/statistics/tx_errors
I have confirmed that the problem above appears in net-next
and appears to be resolved by this patch.
Would you be happy with this patch if the changelog was enhanced
and the minor issue you point our below was resolved?
> >Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
> >Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>
> [...]
>
> >diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
> >index b37c427..9a1c550 100644
> >--- a/drivers/net/ethernet/renesas/sh_eth.h
> >+++ b/drivers/net/ethernet/renesas/sh_eth.h
> >@@ -508,6 +508,7 @@ struct sh_eth_private {
> > u32 rx_buf_sz; /* Based on MTU+slack. */
> > int edmac_endian;
> > struct napi_struct napi;
> >+ bool is_opened;
>
> Placing it after 'vlan_num_ids' (and making it a bitfield?) would
> probably allow to save some space.
>
> WBR, Sergei
>
^ permalink raw reply
* Re: [RFC] situation with csum_and_copy_... API
From: Al Viro @ 2014-11-25 2:40 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, netdev, linux-kernel, target-devel, nab, hch
In-Reply-To: <20141122.022444.425003630662787798.davem@davemloft.net>
On Sat, Nov 22, 2014 at 02:24:44AM -0500, David Miller wrote:
> From: Al Viro <viro@ZenIV.linux.org.uk>
> Date: Sat, 22 Nov 2014 04:28:57 +0000
>
> > OK, here's the next bunch. Sorry about the delay, iov_iter.c stuff
> > took most of the day (and it's not included in this pile). Please, review.
>
> I read over this stuff twice and this series looks fine to me.
>
> Since this is the weekend... maybe wait until Monday for other feedback
> then give me a pull request?
I'll probably repost the patches with updates folded in first...
FWIW, the current situation is
* all but one ->recvmsg() instances switched to iov_iter primitives
(the exception is one of the AF_ALG instances and I know what to do with it).
Consequently, they do not drain iovecs anymore and simply advance ->msg_iter.
* kvec-based iov_iter work just fine without set_fs(KERNEL_DS). And
so do ->recvmsg() instances that had received such iov_iter.
* memcpy_to_iovec() and skb_copy_datagram_iovec() are gone - no users
left.
I'm about to start on ->sendmsg() side of the things. The interesting
question is whether tcp_send_syn_data() is doing the right thing if it
runs into EFAULT when copying iovec from userland.
As it is, it gives up on the skb it has allocated and falls back to normal
handshake. I can duplicate that behaviour, all right, but why not simply
do skb_trim(syn_data, <actually copied>) and do fallback only if nothing
got copied at all? Is there any problem with that?
The reason why I'm asking is that it's easier to just use copy_from_iter()
and let the damn thing advance. Not a lot of pain to preserve the original
iov_iter (all 5 words of it) and copy it back in case of failure, but I'd
rather understood what's wrong with simpler approach...
Anyway, the current branch is in vfs.git#iov_iter-net. Current balance is
about -0.5KLoC and that's not counting the simplifications that will become
possible in callers of kernel_sendmg/kernel_recvmsg... I'll post the beginning
of that queue (the same 17 commits in the beginning) later tonight and wait
for review...
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the vfs tree
From: Stephen Rothwell @ 2014-11-25 2:42 UTC (permalink / raw)
To: David Miller, netdev, Al Viro
Cc: linux-next, linux-kernel, Steven Rostedt (Red Hat),
Marcelo Leitner, Pablo Neira Ayuso
[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/netfilter/nf_log.c between commit e71456ae9871 ("netfilter: Remove
checks of seq_printf() return values") from the vfs tree and commit
0c26ed1c07f1 ("netfilter: nf_log: Introduce nft_log_dereference()
macro") 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 net/netfilter/nf_log.c
index 6e3b9117db1f,49a64174f3f1..000000000000
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@@ -294,39 -303,35 +303,37 @@@ static int seq_show(struct seq_file *s
{
loff_t *pos = v;
const struct nf_logger *logger;
- int i, ret;
+ int i;
struct net *net = seq_file_net(s);
- logger = rcu_dereference_protected(net->nf.nf_loggers[*pos],
- lockdep_is_held(&nf_log_mutex));
+ logger = nft_log_dereference(net->nf.nf_loggers[*pos]);
if (!logger)
- ret = seq_printf(s, "%2lld NONE (", *pos);
+ seq_printf(s, "%2lld NONE (", *pos);
else
- ret = seq_printf(s, "%2lld %s (", *pos, logger->name);
+ seq_printf(s, "%2lld %s (", *pos, logger->name);
- if (ret < 0)
- return ret;
+ if (seq_has_overflowed(s))
+ return -ENOSPC;
for (i = 0; i < NF_LOG_TYPE_MAX; i++) {
if (loggers[*pos][i] == NULL)
continue;
- logger = rcu_dereference_protected(loggers[*pos][i],
- lockdep_is_held(&nf_log_mutex));
+ logger = nft_log_dereference(loggers[*pos][i]);
- ret = seq_printf(s, "%s", logger->name);
- if (ret < 0)
- return ret;
- if (i == 0 && loggers[*pos][i + 1] != NULL) {
- ret = seq_printf(s, ",");
- if (ret < 0)
- return ret;
- }
+ seq_printf(s, "%s", logger->name);
+ if (i == 0 && loggers[*pos][i + 1] != NULL)
+ seq_printf(s, ",");
+
+ if (seq_has_overflowed(s))
+ return -ENOSPC;
}
- return seq_printf(s, ")\n");
+ seq_printf(s, ")\n");
+
+ if (seq_has_overflowed(s))
+ return -ENOSPC;
+ return 0;
}
static const struct seq_operations nflog_seq_ops = {
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Fix Me in htc.c
From: nick @ 2014-11-25 2:45 UTC (permalink / raw)
To: kvalo; +Cc: netdev, linux-wireless, linville, ath10k, linux-kernel
Greetings Kalle and John,
I am wondering about what amount we need to reserve for amount of bytes needed for the function, ath10k_htc_build_tx_ctrl_skb in htc.c If one of you can send me the amount of bytes we need to
reserve for this to function correctly, I will gladly write a patch for this :).
Nick
^ permalink raw reply
* Re: [PATCH net-next 3/3] vxlan: Remote checksum offload
From: Tom Herbert @ 2014-11-25 2:50 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev
In-Reply-To: <CAEP_g=9_6Rq9Ssr_2q4MKfSDxeL23rbExP5ziHbeCL0Nx-VTvw@mail.gmail.com>
On Mon, Nov 24, 2014 at 5:06 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Mon, Nov 24, 2014 at 3:52 PM, Tom Herbert <therbert@google.com> wrote:
>> Add support for remote checksum offload in VXLAN. This commandeers a
>> reserved bit to indicate that RCO is being done, and uses the low order
>> reserved eight bits of the VNI to hold the start and offset values in a
>> compressed manner.
>
> Why do you think that this is OK for you to do? It's clear that there
> is no consensus for this (and in fact there are other proposals that
> use that bit in a different way).
I asked on nvo3 list (which I believe is the appropriate forum) what
the best way to do this is but haven't gotten any response. I will ask
again-- I would assume that with an implementation and data in hand
that might be better basis for discussion.
The flag bit is currently unused in the Linux implementation, so I
don't think it can break anything as of now. I suppose we could make
RCO for VXLAN a config option and possibly change to use a different
if consensus is reached on the right approach in the future.
Tom
^ permalink raw reply
* Charity Work
From: luv2charitys @ 2014-11-25 2:57 UTC (permalink / raw)
To: netdev
Hello,this is Mr Paul N,i sent you an email on charity work but i am yet to hear fom you,do reply with this code CHA-2015 to my email address paulcharity@qq.com i Look forward to hearing from you this time,God bless Brother Paul
^ permalink raw reply
* [PATCH net-next] cxgb4/cxgb4vf/csiostor: Add T4/T5 PCI ID Table
From: Hariprasad Shenai @ 2014-11-25 3:03 UTC (permalink / raw)
To: netdev, linux-scsi
Cc: davem, JBottomley, hch, leedom, anish, nirranjan, kumaras,
praveenm, varun, Hariprasad Shenai
Add a new file t4_pci_id_tbl.h that contains T4/T5 PCI ID Table so that for all
drivers that uses T4/T5 PCI functions changes can be done in one place.
checkpatch.pl script reports following error, which if tried to fix ends up in
compilation error.
ERROR: Macros with complex values should be enclosed in parentheses
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \
+ { 0, } \
+ }
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
new file mode 100644
ERROR: Macros with complex values should be enclosed in parentheses
+#define CH_PCI_ID_TABLE_FENTRY(devid) \
+ CH_PCI_ID_TABLE_ENTRY((devid) | \
+ ((CH_PCI_DEVICE_ID_FUNCTION) << 8)), \
+ CH_PCI_ID_TABLE_ENTRY((devid) | \
+ ((CH_PCI_DEVICE_ID_FUNCTION2) << 8))
ERROR: Macros with complex values should be enclosed in parentheses
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { 0, } }
ERROR: Macros with complex values should be enclosed in parentheses
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { 0, } }
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 125 +++-------------
drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 160 ++++++++++++++++++++
.../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 73 ++--------
drivers/scsi/csiostor/csio_hw_chip.h | 49 +------
drivers/scsi/csiostor/csio_init.c | 64 +++------
5 files changed, 209 insertions(+), 262 deletions(-)
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index a576da1..3aea82b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -210,114 +210,25 @@ struct filter_entry {
NETIF_MSG_TIMER | NETIF_MSG_IFDOWN | NETIF_MSG_IFUP |\
NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
-#define CH_DEVICE(devid, data) { PCI_VDEVICE(CHELSIO, devid), (data) }
-
-static const struct pci_device_id cxgb4_pci_tbl[] = {
- CH_DEVICE(0xa000, 0), /* PE10K */
- CH_DEVICE(0x4001, -1),
- CH_DEVICE(0x4002, -1),
- CH_DEVICE(0x4003, -1),
- CH_DEVICE(0x4004, -1),
- CH_DEVICE(0x4005, -1),
- CH_DEVICE(0x4006, -1),
- CH_DEVICE(0x4007, -1),
- CH_DEVICE(0x4008, -1),
- CH_DEVICE(0x4009, -1),
- CH_DEVICE(0x400a, -1),
- CH_DEVICE(0x400d, -1),
- CH_DEVICE(0x400e, -1),
- CH_DEVICE(0x4080, -1),
- CH_DEVICE(0x4081, -1),
- CH_DEVICE(0x4082, -1),
- CH_DEVICE(0x4083, -1),
- CH_DEVICE(0x4084, -1),
- CH_DEVICE(0x4085, -1),
- CH_DEVICE(0x4086, -1),
- CH_DEVICE(0x4087, -1),
- CH_DEVICE(0x4088, -1),
- CH_DEVICE(0x4401, 4),
- CH_DEVICE(0x4402, 4),
- CH_DEVICE(0x4403, 4),
- CH_DEVICE(0x4404, 4),
- CH_DEVICE(0x4405, 4),
- CH_DEVICE(0x4406, 4),
- CH_DEVICE(0x4407, 4),
- CH_DEVICE(0x4408, 4),
- CH_DEVICE(0x4409, 4),
- CH_DEVICE(0x440a, 4),
- CH_DEVICE(0x440d, 4),
- CH_DEVICE(0x440e, 4),
- CH_DEVICE(0x4480, 4),
- CH_DEVICE(0x4481, 4),
- CH_DEVICE(0x4482, 4),
- CH_DEVICE(0x4483, 4),
- CH_DEVICE(0x4484, 4),
- CH_DEVICE(0x4485, 4),
- CH_DEVICE(0x4486, 4),
- CH_DEVICE(0x4487, 4),
- CH_DEVICE(0x4488, 4),
- CH_DEVICE(0x5001, 4),
- CH_DEVICE(0x5002, 4),
- CH_DEVICE(0x5003, 4),
- CH_DEVICE(0x5004, 4),
- CH_DEVICE(0x5005, 4),
- CH_DEVICE(0x5006, 4),
- CH_DEVICE(0x5007, 4),
- CH_DEVICE(0x5008, 4),
- CH_DEVICE(0x5009, 4),
- CH_DEVICE(0x500A, 4),
- CH_DEVICE(0x500B, 4),
- CH_DEVICE(0x500C, 4),
- CH_DEVICE(0x500D, 4),
- CH_DEVICE(0x500E, 4),
- CH_DEVICE(0x500F, 4),
- CH_DEVICE(0x5010, 4),
- CH_DEVICE(0x5011, 4),
- CH_DEVICE(0x5012, 4),
- CH_DEVICE(0x5013, 4),
- CH_DEVICE(0x5014, 4),
- CH_DEVICE(0x5015, 4),
- CH_DEVICE(0x5080, 4),
- CH_DEVICE(0x5081, 4),
- CH_DEVICE(0x5082, 4),
- CH_DEVICE(0x5083, 4),
- CH_DEVICE(0x5084, 4),
- CH_DEVICE(0x5085, 4),
- CH_DEVICE(0x5086, 4),
- CH_DEVICE(0x5087, 4),
- CH_DEVICE(0x5088, 4),
- CH_DEVICE(0x5401, 4),
- CH_DEVICE(0x5402, 4),
- CH_DEVICE(0x5403, 4),
- CH_DEVICE(0x5404, 4),
- CH_DEVICE(0x5405, 4),
- CH_DEVICE(0x5406, 4),
- CH_DEVICE(0x5407, 4),
- CH_DEVICE(0x5408, 4),
- CH_DEVICE(0x5409, 4),
- CH_DEVICE(0x540A, 4),
- CH_DEVICE(0x540B, 4),
- CH_DEVICE(0x540C, 4),
- CH_DEVICE(0x540D, 4),
- CH_DEVICE(0x540E, 4),
- CH_DEVICE(0x540F, 4),
- CH_DEVICE(0x5410, 4),
- CH_DEVICE(0x5411, 4),
- CH_DEVICE(0x5412, 4),
- CH_DEVICE(0x5413, 4),
- CH_DEVICE(0x5414, 4),
- CH_DEVICE(0x5415, 4),
- CH_DEVICE(0x5480, 4),
- CH_DEVICE(0x5481, 4),
- CH_DEVICE(0x5482, 4),
- CH_DEVICE(0x5483, 4),
- CH_DEVICE(0x5484, 4),
- CH_DEVICE(0x5485, 4),
- CH_DEVICE(0x5486, 4),
- CH_DEVICE(0x5487, 4),
- CH_DEVICE(0x5488, 4),
- { 0, }
-};
+/* Macros needed to support the PCI Device ID Table ...
+ */
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN \
+ static struct pci_device_id cxgb4_pci_tbl[] = {
+#define CH_PCI_DEVICE_ID_FUNCTION 0x4
+
+/* Include PCI Device IDs for both PF4 and PF0-3 so our PCI probe() routine is
+ * called for both.
+ */
+#define CH_PCI_DEVICE_ID_FUNCTION2 0x0
+
+#define CH_PCI_ID_TABLE_ENTRY(devid) \
+ {PCI_VDEVICE(CHELSIO, (devid)), 4}
+
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \
+ { 0, } \
+ }
+
+#include "t4_pci_id_tbl.h"
#define FW4_FNAME "cxgb4/t4fw.bin"
#define FW5_FNAME "cxgb4/t5fw.bin"
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
new file mode 100644
index 0000000..9e4f95a
--- /dev/null
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
@@ -0,0 +1,160 @@
+/*
+ * This file is part of the Chelsio T4/T5 Ethernet driver for Linux.
+ *
+ * Copyright (c) 2003-2014 Chelsio Communications, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#ifndef __T4_PCI_ID_TBL_H__
+#define __T4_PCI_ID_TBL_H__
+
+/* The code can defined cpp macros for creating a PCI Device ID Table. This is
+ * useful because it allows the PCI ID Table to be maintained in a single place.
+ *
+ * The macros are:
+ *
+ * CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
+ * -- Used to start the definition of the PCI ID Table.
+ *
+ * CH_PCI_DEVICE_ID_FUNCTION
+ * -- The PCI Function Number to use in the PCI Device ID Table. "0"
+ * -- for drivers attaching to PF0-3, "4" for drivers attaching to PF4,
+ * -- "8" for drivers attaching to SR-IOV Virtual Functions, etc.
+ *
+ * CH_PCI_DEVICE_ID_FUNCTION2 [optional]
+ * -- If defined, create a PCI Device ID Table with both
+ * -- CH_PCI_DEVICE_ID_FUNCTION and CH_PCI_DEVICE_ID_FUNCTION2 populated.
+ *
+ * CH_PCI_ID_TABLE_ENTRY(DeviceID)
+ * -- Used for the individual PCI Device ID entries. Note that we will
+ * -- be adding a trailing comma (",") after all of the entries (and
+ * -- between the pairs of entries if CH_PCI_DEVICE_ID_FUNCTION2 is defined).
+ *
+ * CH_PCI_DEVICE_ID_TABLE_DEFINE_END
+ * -- Used to finish the definition of the PCI ID Table. Note that we
+ * -- will be adding a trailing semi-colon (";") here.
+ */
+#ifdef CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
+
+#ifndef CH_PCI_DEVICE_ID_FUNCTION
+#error CH_PCI_DEVICE_ID_FUNCTION not defined!
+#endif
+#ifndef CH_PCI_ID_TABLE_ENTRY
+#error CH_PCI_ID_TABLE_ENTRY not defined!
+#endif
+#ifndef CH_PCI_DEVICE_ID_TABLE_DEFINE_END
+#error CH_PCI_DEVICE_ID_TABLE_DEFINE_END not defined!
+#endif
+
+/* T4 and later ASICs use a PCI Device ID scheme of 0xVFPP where:
+ *
+ * V = "4" for T4; "5" for T5, etc.
+ * F = "0" for PF 0..3; "4".."7" for PF4..7; and "8" for VFs
+ * PP = adapter product designation
+ *
+ * We use this consistency in order to create the proper PCI Device IDs
+ * for the specified CH_PCI_DEVICE_ID_FUNCTION.
+ */
+#ifndef CH_PCI_DEVICE_ID_FUNCTION2
+#define CH_PCI_ID_TABLE_FENTRY(devid) \
+ CH_PCI_ID_TABLE_ENTRY((devid) | \
+ ((CH_PCI_DEVICE_ID_FUNCTION) << 8))
+#else
+#define CH_PCI_ID_TABLE_FENTRY(devid) \
+ CH_PCI_ID_TABLE_ENTRY((devid) | \
+ ((CH_PCI_DEVICE_ID_FUNCTION) << 8)), \
+ CH_PCI_ID_TABLE_ENTRY((devid) | \
+ ((CH_PCI_DEVICE_ID_FUNCTION2) << 8))
+#endif
+
+CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
+ /* T4 adapters:
+ */
+ CH_PCI_ID_TABLE_FENTRY(0x4000), /* T440-dbg */
+ CH_PCI_ID_TABLE_FENTRY(0x4001), /* T420-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4002), /* T422-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4003), /* T440-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4004), /* T420-bch */
+ CH_PCI_ID_TABLE_FENTRY(0x4005), /* T440-bch */
+ CH_PCI_ID_TABLE_FENTRY(0x4006), /* T440-ch */
+ CH_PCI_ID_TABLE_FENTRY(0x4007), /* T420-so */
+ CH_PCI_ID_TABLE_FENTRY(0x4008), /* T420-cx */
+ CH_PCI_ID_TABLE_FENTRY(0x4009), /* T420-bt */
+ CH_PCI_ID_TABLE_FENTRY(0x400a), /* T404-bt */
+ CH_PCI_ID_TABLE_FENTRY(0x400b), /* B420-sr */
+ CH_PCI_ID_TABLE_FENTRY(0x400c), /* B404-bt */
+ CH_PCI_ID_TABLE_FENTRY(0x400d), /* T480-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x400e), /* T440-LP-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4080), /* Custom T480-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4081), /* Custom T440-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4082), /* Custom T420-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4083), /* Custom T420-xaui */
+ CH_PCI_ID_TABLE_FENTRY(0x4084), /* Custom T440-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4085), /* Custom T420-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4086), /* Custom T440-bt */
+ CH_PCI_ID_TABLE_FENTRY(0x4087), /* Custom T440-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x4088), /* Custom T440 2-xaui, 2-xfi */
+
+ /* T5 adapters:
+ */
+ CH_PCI_ID_TABLE_FENTRY(0x5000), /* T580-dbg */
+ CH_PCI_ID_TABLE_FENTRY(0x5001), /* T520-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5002), /* T522-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5003), /* T540-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5004), /* T520-bch */
+ CH_PCI_ID_TABLE_FENTRY(0x5005), /* T540-bch */
+ CH_PCI_ID_TABLE_FENTRY(0x5006), /* T540-ch */
+ CH_PCI_ID_TABLE_FENTRY(0x5007), /* T520-so */
+ CH_PCI_ID_TABLE_FENTRY(0x5008), /* T520-cx */
+ CH_PCI_ID_TABLE_FENTRY(0x5009), /* T520-bt */
+ CH_PCI_ID_TABLE_FENTRY(0x500a), /* T504-bt */
+ CH_PCI_ID_TABLE_FENTRY(0x500b), /* B520-sr */
+ CH_PCI_ID_TABLE_FENTRY(0x500c), /* B504-bt */
+ CH_PCI_ID_TABLE_FENTRY(0x500d), /* T580-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x500e), /* T540-LP-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5010), /* T580-LP-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5011), /* T520-LL-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5012), /* T560-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5013), /* T580-chr */
+ CH_PCI_ID_TABLE_FENTRY(0x5014), /* T580-so */
+ CH_PCI_ID_TABLE_FENTRY(0x5015), /* T502-bt */
+ CH_PCI_ID_TABLE_FENTRY(0x5080), /* Custom T540-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5081), /* Custom T540-LL-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5082), /* Custom T504-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5083), /* Custom T540-LP-CR */
+ CH_PCI_ID_TABLE_FENTRY(0x5084), /* Custom T580-cr */
+ CH_PCI_ID_TABLE_FENTRY(0x5085), /* Custom 3x T580-CR */
+ CH_PCI_ID_TABLE_FENTRY(0x5086), /* Custom 2x T580-CR */
+ CH_PCI_ID_TABLE_FENTRY(0x5087), /* Custom T580-CR */
+ CH_PCI_ID_TABLE_FENTRY(0x5088), /* Custom T570-CR */
+CH_PCI_DEVICE_ID_TABLE_DEFINE_END;
+
+#endif /* CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN */
+
+#endif /* __T4_PCI_ID_TBL_H__ */
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index 099f7ce..ad88246 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2908,67 +2908,18 @@ static void cxgb4vf_pci_shutdown(struct pci_dev *pdev)
pci_set_drvdata(pdev, NULL);
}
-/*
- * PCI Device registration data structures.
- */
-#define CH_DEVICE(devid) \
- { PCI_VENDOR_ID_CHELSIO, devid, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }
-
-static const struct pci_device_id cxgb4vf_pci_tbl[] = {
- CH_DEVICE(0xb000), /* PE10K FPGA */
- CH_DEVICE(0x4801), /* T420-cr */
- CH_DEVICE(0x4802), /* T422-cr */
- CH_DEVICE(0x4803), /* T440-cr */
- CH_DEVICE(0x4804), /* T420-bch */
- CH_DEVICE(0x4805), /* T440-bch */
- CH_DEVICE(0x4806), /* T460-ch */
- CH_DEVICE(0x4807), /* T420-so */
- CH_DEVICE(0x4808), /* T420-cx */
- CH_DEVICE(0x4809), /* T420-bt */
- CH_DEVICE(0x480a), /* T404-bt */
- CH_DEVICE(0x480d), /* T480-cr */
- CH_DEVICE(0x480e), /* T440-lp-cr */
- CH_DEVICE(0x4880),
- CH_DEVICE(0x4881),
- CH_DEVICE(0x4882),
- CH_DEVICE(0x4883),
- CH_DEVICE(0x4884),
- CH_DEVICE(0x4885),
- CH_DEVICE(0x4886),
- CH_DEVICE(0x4887),
- CH_DEVICE(0x4888),
- CH_DEVICE(0x5801), /* T520-cr */
- CH_DEVICE(0x5802), /* T522-cr */
- CH_DEVICE(0x5803), /* T540-cr */
- CH_DEVICE(0x5804), /* T520-bch */
- CH_DEVICE(0x5805), /* T540-bch */
- CH_DEVICE(0x5806), /* T540-ch */
- CH_DEVICE(0x5807), /* T520-so */
- CH_DEVICE(0x5808), /* T520-cx */
- CH_DEVICE(0x5809), /* T520-bt */
- CH_DEVICE(0x580a), /* T504-bt */
- CH_DEVICE(0x580b), /* T520-sr */
- CH_DEVICE(0x580c), /* T504-bt */
- CH_DEVICE(0x580d), /* T580-cr */
- CH_DEVICE(0x580e), /* T540-lp-cr */
- CH_DEVICE(0x580f), /* Amsterdam */
- CH_DEVICE(0x5810), /* T580-lp-cr */
- CH_DEVICE(0x5811), /* T520-lp-cr */
- CH_DEVICE(0x5812), /* T560-cr */
- CH_DEVICE(0x5813), /* T580-cr */
- CH_DEVICE(0x5814), /* T580-so-cr */
- CH_DEVICE(0x5815), /* T502-bt */
- CH_DEVICE(0x5880),
- CH_DEVICE(0x5881),
- CH_DEVICE(0x5882),
- CH_DEVICE(0x5883),
- CH_DEVICE(0x5884),
- CH_DEVICE(0x5885),
- CH_DEVICE(0x5886),
- CH_DEVICE(0x5887),
- CH_DEVICE(0x5888),
- { 0, }
-};
+/* Macros needed to support the PCI Device ID Table ...
+ */
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN \
+ static struct pci_device_id cxgb4vf_pci_tbl[] = {
+#define CH_PCI_DEVICE_ID_FUNCTION 0x8
+
+#define CH_PCI_ID_TABLE_ENTRY(devid) \
+ { PCI_VDEVICE(CHELSIO, (devid)), 0 }
+
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { 0, } }
+
+#include "../cxgb4/t4_pci_id_tbl.h"
MODULE_DESCRIPTION(DRV_DESC);
MODULE_AUTHOR("Chelsio Communications");
diff --git a/drivers/scsi/csiostor/csio_hw_chip.h b/drivers/scsi/csiostor/csio_hw_chip.h
index bca0de6..4752fed 100644
--- a/drivers/scsi/csiostor/csio_hw_chip.h
+++ b/drivers/scsi/csiostor/csio_hw_chip.h
@@ -36,60 +36,13 @@
#include "csio_defs.h"
-/* FCoE device IDs for T4 */
-#define CSIO_DEVID_T440DBG_FCOE 0x4600
-#define CSIO_DEVID_T420CR_FCOE 0x4601
-#define CSIO_DEVID_T422CR_FCOE 0x4602
-#define CSIO_DEVID_T440CR_FCOE 0x4603
-#define CSIO_DEVID_T420BCH_FCOE 0x4604
-#define CSIO_DEVID_T440BCH_FCOE 0x4605
-#define CSIO_DEVID_T440CH_FCOE 0x4606
-#define CSIO_DEVID_T420SO_FCOE 0x4607
-#define CSIO_DEVID_T420CX_FCOE 0x4608
-#define CSIO_DEVID_T420BT_FCOE 0x4609
-#define CSIO_DEVID_T404BT_FCOE 0x460A
-#define CSIO_DEVID_B420_FCOE 0x460B
-#define CSIO_DEVID_B404_FCOE 0x460C
-#define CSIO_DEVID_T480CR_FCOE 0x460D
-#define CSIO_DEVID_T440LPCR_FCOE 0x460E
-#define CSIO_DEVID_AMSTERDAM_T4_FCOE 0x460F
-#define CSIO_DEVID_HUAWEI_T480_FCOE 0x4680
-#define CSIO_DEVID_HUAWEI_T440_FCOE 0x4681
-#define CSIO_DEVID_HUAWEI_STG310_FCOE 0x4682
-#define CSIO_DEVID_ACROMAG_XMC_XAUI 0x4683
-#define CSIO_DEVID_ACROMAG_XMC_SFP_FCOE 0x4684
-#define CSIO_DEVID_QUANTA_MEZZ_SFP_FCOE 0x4685
-#define CSIO_DEVID_HUAWEI_10GT_FCOE 0x4686
-#define CSIO_DEVID_HUAWEI_T440_TOE_FCOE 0x4687
-
-/* FCoE device IDs for T5 */
-#define CSIO_DEVID_T580DBG_FCOE 0x5600
-#define CSIO_DEVID_T520CR_FCOE 0x5601
-#define CSIO_DEVID_T522CR_FCOE 0x5602
-#define CSIO_DEVID_T540CR_FCOE 0x5603
-#define CSIO_DEVID_T520BCH_FCOE 0x5604
-#define CSIO_DEVID_T540BCH_FCOE 0x5605
-#define CSIO_DEVID_T540CH_FCOE 0x5606
-#define CSIO_DEVID_T520SO_FCOE 0x5607
-#define CSIO_DEVID_T520CX_FCOE 0x5608
-#define CSIO_DEVID_T520BT_FCOE 0x5609
-#define CSIO_DEVID_T504BT_FCOE 0x560A
-#define CSIO_DEVID_B520_FCOE 0x560B
-#define CSIO_DEVID_B504_FCOE 0x560C
-#define CSIO_DEVID_T580CR2_FCOE 0x560D
-#define CSIO_DEVID_T540LPCR_FCOE 0x560E
-#define CSIO_DEVID_AMSTERDAM_T5_FCOE 0x560F
-#define CSIO_DEVID_T580LPCR_FCOE 0x5610
-#define CSIO_DEVID_T520LLCR_FCOE 0x5611
-#define CSIO_DEVID_T560CR_FCOE 0x5612
-#define CSIO_DEVID_T580CR_FCOE 0x5613
-
/* Define MACRO values */
#define CSIO_HW_T4 0x4000
#define CSIO_T4_FCOE_ASIC 0x4600
#define CSIO_HW_T5 0x5000
#define CSIO_T5_FCOE_ASIC 0x5600
#define CSIO_HW_CHIP_MASK 0xF000
+
#define T4_REGMAP_SIZE (160 * 1024)
#define T5_REGMAP_SIZE (332 * 1024)
#define FW_FNAME_T4 "cxgb4/t4fw.bin"
diff --git a/drivers/scsi/csiostor/csio_init.c b/drivers/scsi/csiostor/csio_init.c
index 1ed5b21..34d20cc 100644
--- a/drivers/scsi/csiostor/csio_init.c
+++ b/drivers/scsi/csiostor/csio_init.c
@@ -955,6 +955,10 @@ static int csio_probe_one(struct pci_dev *pdev, const struct pci_device_id *id)
struct csio_hw *hw;
struct csio_lnode *ln;
+ /* probe only T5 cards */
+ if (!csio_is_t5((pdev->device & CSIO_HW_CHIP_MASK)))
+ return -ENODEV;
+
rv = csio_pci_init(pdev, &bars);
if (rv)
goto err;
@@ -1167,53 +1171,21 @@ static struct pci_error_handlers csio_err_handler = {
.resume = csio_pci_resume,
};
-static const struct pci_device_id csio_pci_tbl[] = {
- CSIO_DEVICE(CSIO_DEVID_T440DBG_FCOE, 0), /* T4 DEBUG FCOE */
- CSIO_DEVICE(CSIO_DEVID_T420CR_FCOE, 0), /* T420CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T422CR_FCOE, 0), /* T422CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T440CR_FCOE, 0), /* T440CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T420BCH_FCOE, 0), /* T420BCH FCOE */
- CSIO_DEVICE(CSIO_DEVID_T440BCH_FCOE, 0), /* T440BCH FCOE */
- CSIO_DEVICE(CSIO_DEVID_T440CH_FCOE, 0), /* T440CH FCOE */
- CSIO_DEVICE(CSIO_DEVID_T420SO_FCOE, 0), /* T420SO FCOE */
- CSIO_DEVICE(CSIO_DEVID_T420CX_FCOE, 0), /* T420CX FCOE */
- CSIO_DEVICE(CSIO_DEVID_T420BT_FCOE, 0), /* T420BT FCOE */
- CSIO_DEVICE(CSIO_DEVID_T404BT_FCOE, 0), /* T404BT FCOE */
- CSIO_DEVICE(CSIO_DEVID_B420_FCOE, 0), /* B420 FCOE */
- CSIO_DEVICE(CSIO_DEVID_B404_FCOE, 0), /* B404 FCOE */
- CSIO_DEVICE(CSIO_DEVID_T480CR_FCOE, 0), /* T480 CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T440LPCR_FCOE, 0), /* T440 LP-CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_AMSTERDAM_T4_FCOE, 0), /* AMSTERDAM T4 FCOE */
- CSIO_DEVICE(CSIO_DEVID_HUAWEI_T480_FCOE, 0), /* HUAWEI T480 FCOE */
- CSIO_DEVICE(CSIO_DEVID_HUAWEI_T440_FCOE, 0), /* HUAWEI T440 FCOE */
- CSIO_DEVICE(CSIO_DEVID_HUAWEI_STG310_FCOE, 0), /* HUAWEI STG FCOE */
- CSIO_DEVICE(CSIO_DEVID_ACROMAG_XMC_XAUI, 0), /* ACROMAG XAUI FCOE */
- CSIO_DEVICE(CSIO_DEVID_QUANTA_MEZZ_SFP_FCOE, 0),/* QUANTA MEZZ FCOE */
- CSIO_DEVICE(CSIO_DEVID_HUAWEI_10GT_FCOE, 0), /* HUAWEI 10GT FCOE */
- CSIO_DEVICE(CSIO_DEVID_HUAWEI_T440_TOE_FCOE, 0),/* HUAWEI T4 TOE FCOE */
- CSIO_DEVICE(CSIO_DEVID_T580DBG_FCOE, 0), /* T5 DEBUG FCOE */
- CSIO_DEVICE(CSIO_DEVID_T520CR_FCOE, 0), /* T520CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T522CR_FCOE, 0), /* T522CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T540CR_FCOE, 0), /* T540CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T520BCH_FCOE, 0), /* T520BCH FCOE */
- CSIO_DEVICE(CSIO_DEVID_T540BCH_FCOE, 0), /* T540BCH FCOE */
- CSIO_DEVICE(CSIO_DEVID_T540CH_FCOE, 0), /* T540CH FCOE */
- CSIO_DEVICE(CSIO_DEVID_T520SO_FCOE, 0), /* T520SO FCOE */
- CSIO_DEVICE(CSIO_DEVID_T520CX_FCOE, 0), /* T520CX FCOE */
- CSIO_DEVICE(CSIO_DEVID_T520BT_FCOE, 0), /* T520BT FCOE */
- CSIO_DEVICE(CSIO_DEVID_T504BT_FCOE, 0), /* T504BT FCOE */
- CSIO_DEVICE(CSIO_DEVID_B520_FCOE, 0), /* B520 FCOE */
- CSIO_DEVICE(CSIO_DEVID_B504_FCOE, 0), /* B504 FCOE */
- CSIO_DEVICE(CSIO_DEVID_T580CR2_FCOE, 0), /* T580 CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T540LPCR_FCOE, 0), /* T540 LP-CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_AMSTERDAM_T5_FCOE, 0), /* AMSTERDAM T5 FCOE */
- CSIO_DEVICE(CSIO_DEVID_T580LPCR_FCOE, 0), /* T580 LP-CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T520LLCR_FCOE, 0), /* T520 LL-CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T560CR_FCOE, 0), /* T560 CR FCOE */
- CSIO_DEVICE(CSIO_DEVID_T580CR_FCOE, 0), /* T580 CR FCOE */
- { 0, 0, 0, 0, 0, 0, 0 }
-};
+/*
+ * Macros needed to support the PCI Device ID Table ...
+ */
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN \
+ static struct pci_device_id csio_pci_tbl[] = {
+/* Define for iSCSI uses PF5, FCoE uses PF6 */
+#define CH_PCI_DEVICE_ID_FUNCTION 0x5
+#define CH_PCI_DEVICE_ID_FUNCTION2 0x6
+
+#define CH_PCI_ID_TABLE_ENTRY(devid) \
+ { PCI_VDEVICE(CHELSIO, (devid)), 0 }
+
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { 0, } }
+#include "t4_pci_id_tbl.h"
static struct pci_driver csio_pci_driver = {
.name = KBUILD_MODNAME,
--
1.7.1
^ permalink raw reply related
* Re: [RFC PATCH 0/4] switch device: offload policy attributes
From: Ronen Arad @ 2014-11-25 3:10 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAE4R7bAY2zMy4SiuwhdXyH2Swqv1KfkrBJ_ZwU_RYdCW3k+Mvg@mail.gmail.com>
Scott Feldman <sfeldma <at> gmail.com> writes:
>
> On Mon, Nov 24, 2014 at 4:55 AM, Roopa Prabhu <roopa <at>
cumulusnetworks.com> wrote:
> > On 11/24/14, 2:18 AM, Scott Feldman wrote:
> >>
> >> Hi Roopa,
> >>
> >> I have a patch pending against Jiri's v2 that's uses existing
> >> ndo_bridge_setlink/getlink to push policy settings down to port driver
> >> for controlling HW offload. I had to make a few tweaks, but for the
> >> most part setlink/getlink already has the master/self semantics so
> >> users can set policy flags on bridge's SW version of the port (master)
> >> or on the offloaded version of the port (self).
> >> I added the new
> >> hwmode option "swdev" to the existing "vepa"|"veb" choices. When you
> >> specify hwmode, SELF is set and the port driver's setlink get's
> >> called. Did you look at setlink/getlink? It looks like the kernel
> >> and iproute2 where going down this route of using setlink/getlink for
> >> SELF policy, so I'm wondering if we need more?
> >
> > If i understand you correctly, this will mean the port driver implements
the
> > setlink/getlink with the bridge port flags and attributes. And, it also
> > means
> > the port driver will parse the netlink msg instead of the bridge driver
> > parsing all attributes and then calling offloads.
>
> Yes, exactly, the port driver parses/fills bridge_setlink/getlink
> netlink msg to set/get port settings. It's basically a passthru for
> rtnl_bridge_setlink/getlink handling RTM_GETLNK/RTM_SETLINK on
> PF_BRIDGE.
>
> > But, in cases where we want bridge port flags and attributes set both in
hw
> > and sw,
> > the user (iproute2) will have to set both MASTER and SELF flags, and the
> > netlink parsing will now happen in two places, the bridge driver and the
> > bridge port
> > driver ?
>
How does VLAN filtering is expected to work with an HW-offloaded bridge?
When MASTER flag is set by iproute2 in the netlink message (or no flag is
set), br_setlink - the ndo_bridge_setlink function of the port's master
bridge is called. It takes care of setting the VLAN policy in the
net_port_vlans of the net_bridge_port. During this sequence the
ndo_vlan_rx_add_vid function of the port dev is called. However, it only gets
the vid. It does not have access to the flags (PVID, UNTAGGED) and those are
not set in the net_port_vlans struct at that time.
Giving the port driver access to the VLAN policy requires both MASTER and
SLAVE flags to be set in the IFLA_BRIDGE_FLAGS attribute.
Is the end user is expected to set both flags in the "bridge vlan add"
command (Failing to do that will prevent the bridge and HW from being in
sync)?
Even with both MASTER and SLAVE flags being set in a single netlink request,
the HW and bridge could get out of sync if adding the VLAN policy to the port
driver would fail after it was added to the bridge netdev.
Is there any mechanism for keeping both software and HW in-sync?
-Ronen
^ permalink raw reply
* Re: [PATCH] mdio-mux-gpio: Use GPIO descriptor interface and new gpiod_set_array function
From: Alexandre Courbot @ 2014-11-25 3:39 UTC (permalink / raw)
To: Rojhalat Ibrahim
Cc: Florian Fainelli, netdev, David Daney, linux-gpio@vger.kernel.org,
Linus Walleij, Alexandre Courbot
In-Reply-To: <6441674.xrJo8HXDvD@pcimr>
On Thu, Nov 20, 2014 at 9:24 PM, Rojhalat Ibrahim <imr@rtschenk.de> wrote:
> Convert mdio-mux-gpio to the GPIO descriptor interface and use the new
> gpiod_set_array function to set all output signals simultaneously.
>
> Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
> --
> This patch depends on the gpiod_set_array function, which is available in
> the linux-gpio devel tree.
>
> drivers/net/phy/mdio-mux-gpio.c | 35 +++++++++++++++--------------------
> 1 file changed, 15 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio-mux-gpio.c
> index 0966951..3fdea96 100644
> --- a/drivers/net/phy/mdio-mux-gpio.c
> +++ b/drivers/net/phy/mdio-mux-gpio.c
> @@ -14,13 +14,13 @@
> #include <linux/mdio-mux.h>
> #include <linux/of_gpio.h>
>
> -#define DRV_VERSION "1.0"
> +#define DRV_VERSION "1.1"
> #define DRV_DESCRIPTION "GPIO controlled MDIO bus multiplexer driver"
>
> #define MDIO_MUX_GPIO_MAX_BITS 8
>
> struct mdio_mux_gpio_state {
> - int gpio[MDIO_MUX_GPIO_MAX_BITS];
> + struct gpio_desc *gpio[MDIO_MUX_GPIO_MAX_BITS];
> unsigned int num_gpios;
> void *mux_handle;
> };
> @@ -28,29 +28,23 @@ struct mdio_mux_gpio_state {
> static int mdio_mux_gpio_switch_fn(int current_child, int desired_child,
> void *data)
> {
> - int change;
> + int values[MDIO_MUX_GPIO_MAX_BITS];
> unsigned int n;
> struct mdio_mux_gpio_state *s = data;
>
> if (current_child == desired_child)
> return 0;
>
> - change = current_child == -1 ? -1 : current_child ^ desired_child;
> -
> for (n = 0; n < s->num_gpios; n++) {
> - if (change & 1)
> - gpio_set_value_cansleep(s->gpio[n],
> - (desired_child & 1) != 0);
> - change >>= 1;
> - desired_child >>= 1;
> + values[n] = (desired_child >> n) & 1;
> }
> + gpiod_set_array_cansleep(s->num_gpios, s->gpio, values);
>
> return 0;
> }
>
> static int mdio_mux_gpio_probe(struct platform_device *pdev)
> {
> - enum of_gpio_flags f;
> struct mdio_mux_gpio_state *s;
> int num_gpios;
> unsigned int n;
> @@ -70,20 +64,17 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
> s->num_gpios = num_gpios;
>
> for (n = 0; n < num_gpios; ) {
> - int gpio = of_get_gpio_flags(pdev->dev.of_node, n, &f);
> - if (gpio < 0) {
> - r = (gpio == -ENODEV) ? -EPROBE_DEFER : gpio;
> + struct gpio_desc *gpio = gpiod_get_index(&pdev->dev,
> + "mdio-mux-gpio", n);
Doesn't this change introduce some incompatibility against the current
DT bindings? of_get_gpio_flags() looks for a "gpios" property, while
your call to gpiod_get_index() will look for "mdio-mux-gpio-gpios". It
should probably be changed to gpiod_get_index(&pdev->dev, NULL, n).
... or even be changed to gpiod_get_index(&pdev->dev, NULL, n,
GPIOD_OUT_LOW) as the calls to gpiod_get() functions are being updated
to take an initial state (both variants are currently usable but the
former one will disappear in the future). This will also allow you to
get rid of your call to gpiod_direction_output().
Side-note: it would be nice to have a gpiod_get_array() call that does
exactly what this loop does, and returns an array of gpios directly
usable by gpiod_set_array*(). And a matching gpiod_put_array() of
course.
^ permalink raw reply
* [net PATCH 0/2] Fix outer UDP checksums for IPv6 VXLAN tunnels
From: alexander.duyck @ 2014-11-25 4:08 UTC (permalink / raw)
To: netdev; +Cc: davem
In testing against an older kernel I found a couple issues in the IPv6
VXLAN tunnel checksum logic for the outer UDP checksum.
First the default transitioned from using an outer checksum to not using
one. Second, sometime after that the checksum inputs were changed
resulting the checksum not being correct if it were computed.
These two issues prevented a ping from the newer kernel to the older one.
With these two changes applied I verified I was able to send traffic over
the VXLAN tunnel to a link partner on an older kernel.
The boolean flip fix can be submitted for 3.17 stable as well since the
patch that introduced the issue was included in that kernel.
---
Alexander Duyck (2):
ip6_udp_tunnel: Fix checksum calculation
vxlan: Fix boolean flip in VXLAN_F_UDP_ZERO_CSUM6_[TX|RX]
drivers/net/vxlan.c | 4 ++--
net/ipv6/ip6_udp_tunnel.c | 4 +---
2 files changed, 3 insertions(+), 5 deletions(-)
--
^ permalink raw reply
* [net PATCH 1/2] ip6_udp_tunnel: Fix checksum calculation
From: alexander.duyck @ 2014-11-25 4:08 UTC (permalink / raw)
To: netdev; +Cc: Alexander Duyck, Andy Zhou, davem
In-Reply-To: <20141125035808.13612.52556.stgit@ahduyck-workstation.home>
From: Alexander Duyck <alexander.h.duyck@redhat.com>
The UDP checksum calculation for VXLAN tunnels is currently using the
socket addresses instead of the actual packet source and destination
addresses. As a result the checksum calculated is incorrect in some
cases.
Also uh->check was being set twice, first it was set to 0, and then it is
set again in udp6_set_csum. This change removes the redundant assignment
to 0.
Fixes: acbf74a7 ("vxlan: Refactor vxlan driver to make use of the common UDP tunnel functions.")
Cc: Andy Zhou <azhou@nicira.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
net/ipv6/ip6_udp_tunnel.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c
index b04ed72..8db6c98 100644
--- a/net/ipv6/ip6_udp_tunnel.c
+++ b/net/ipv6/ip6_udp_tunnel.c
@@ -79,15 +79,13 @@ int udp_tunnel6_xmit_skb(struct socket *sock, struct dst_entry *dst,
uh->source = src_port;
uh->len = htons(skb->len);
- uh->check = 0;
memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
IPCB(skb)->flags &= ~(IPSKB_XFRM_TUNNEL_SIZE | IPSKB_XFRM_TRANSFORMED
| IPSKB_REROUTED);
skb_dst_set(skb, dst);
- udp6_set_csum(udp_get_no_check6_tx(sk), skb, &inet6_sk(sk)->saddr,
- &sk->sk_v6_daddr, skb->len);
+ udp6_set_csum(udp_get_no_check6_tx(sk), skb, saddr, daddr, skb->len);
__skb_push(skb, sizeof(*ip6h));
skb_reset_network_header(skb);
^ permalink raw reply related
* [net PATCH 2/2] vxlan: Fix boolean flip in VXLAN_F_UDP_ZERO_CSUM6_[TX|RX]
From: alexander.duyck @ 2014-11-25 4:08 UTC (permalink / raw)
To: netdev; +Cc: Alexander Duyck, davem, Tom Herbert
In-Reply-To: <20141125035808.13612.52556.stgit@ahduyck-workstation.home>
From: Alexander Duyck <alexander.h.duyck@redhat.com>
In "vxlan: Call udp_sock_create" there was a logic error that resulted in
the default for IPv6 VXLAN tunnels going from using checksums to not using
checksums. Since there is currently no support in iproute2 for setting
these values it means that a kernel after the change cannot talk over a IPv6
VXLAN tunnel to a kernel prior the change.
Fixes: 3ee64f3 ("vxlan: Call udp_sock_create")
Cc: Tom Herbert <therbert@google.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/vxlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index e1e335c..be4649a 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2306,9 +2306,9 @@ static struct socket *vxlan_create_sock(struct net *net, bool ipv6,
if (ipv6) {
udp_conf.family = AF_INET6;
udp_conf.use_udp6_tx_checksums =
- !!(flags & VXLAN_F_UDP_ZERO_CSUM6_TX);
+ !(flags & VXLAN_F_UDP_ZERO_CSUM6_TX);
udp_conf.use_udp6_rx_checksums =
- !!(flags & VXLAN_F_UDP_ZERO_CSUM6_RX);
+ !(flags & VXLAN_F_UDP_ZERO_CSUM6_RX);
} else {
udp_conf.family = AF_INET;
udp_conf.local_ip.s_addr = INADDR_ANY;
^ permalink raw reply related
* Re: [net PATCH 2/2] vxlan: Fix boolean flip in VXLAN_F_UDP_ZERO_CSUM6_[TX|RX]
From: Tom Herbert @ 2014-11-25 4:20 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Linux Netdev List, Alexander Duyck, David Miller
In-Reply-To: <20141125040838.13612.54674.stgit@ahduyck-workstation.home>
On Mon, Nov 24, 2014 at 8:08 PM, <alexander.duyck@gmail.com> wrote:
> From: Alexander Duyck <alexander.h.duyck@redhat.com>
>
> In "vxlan: Call udp_sock_create" there was a logic error that resulted in
> the default for IPv6 VXLAN tunnels going from using checksums to not using
> checksums. Since there is currently no support in iproute2 for setting
> these values it means that a kernel after the change cannot talk over a IPv6
> VXLAN tunnel to a kernel prior the change.
>
> Fixes: 3ee64f3 ("vxlan: Call udp_sock_create")
>
> Cc: Tom Herbert <therbert@google.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> drivers/net/vxlan.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index e1e335c..be4649a 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -2306,9 +2306,9 @@ static struct socket *vxlan_create_sock(struct net *net, bool ipv6,
> if (ipv6) {
> udp_conf.family = AF_INET6;
> udp_conf.use_udp6_tx_checksums =
> - !!(flags & VXLAN_F_UDP_ZERO_CSUM6_TX);
> + !(flags & VXLAN_F_UDP_ZERO_CSUM6_TX);
> udp_conf.use_udp6_rx_checksums =
> - !!(flags & VXLAN_F_UDP_ZERO_CSUM6_RX);
> + !(flags & VXLAN_F_UDP_ZERO_CSUM6_RX);
> } else {
> udp_conf.family = AF_INET;
> udp_conf.local_ip.s_addr = INADDR_ANY;
>
Acked-by: Tom Herbert <therbert@google.com>
^ permalink raw reply
* [PATCH] bonding: move ipoib_header_ops to vmlinux
From: Wengang Wang @ 2014-11-25 5:36 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA
When last slave of a bonding master is removed, the bonding then does not work.
At the time if packet_snd is called against with a master net_device, it calls
then header_ops->create which points to slave's header_ops. In case the slave
is ipoib and the module is unloaded, header_ops would point to invalid address.
Accessing it will cause problem.
This patch tries to fix this issue by moving ipoib_header_ops to vmlinux to keep
it valid even when ipoib module is unloaded.
Signed-off-by: Wengang Wang <wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 10 ---------
drivers/infiniband/ulp/ipoib/ipoib_main.c | 28 +------------------------
include/linux/ibdevice.h | 15 ++++++++++++++
include/linux/if_infiniband.h | 11 ++++++++++
include/uapi/linux/if_infiniband.h | 16 ++++++++++++---
net/Makefile | 2 +-
net/infiniband/Makefile | 5 +++++
net/infiniband/infiniband.c | 34 +++++++++++++++++++++++++++++++
8 files changed, 80 insertions(+), 41 deletions(-)
create mode 100644 include/linux/ibdevice.h
create mode 100644 include/linux/if_infiniband.h
create mode 100644 net/infiniband/Makefile
create mode 100644 net/infiniband/infiniband.c
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index d7562be..7c25670 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -121,16 +121,6 @@ enum {
/* structs */
-struct ipoib_header {
- __be16 proto;
- u16 reserved;
-};
-
-struct ipoib_cb {
- struct qdisc_skb_cb qdisc_cb;
- u8 hwaddr[INFINIBAND_ALEN];
-};
-
static inline struct ipoib_cb *ipoib_skb_cb(const struct sk_buff *skb)
{
BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct ipoib_cb));
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 58b5aa3..9233085 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -34,6 +34,7 @@
#include "ipoib.h"
+#include <linux/ibdevice.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -807,29 +808,6 @@ static void ipoib_timeout(struct net_device *dev)
/* XXX reset QP, etc. */
}
-static int ipoib_hard_header(struct sk_buff *skb,
- struct net_device *dev,
- unsigned short type,
- const void *daddr, const void *saddr, unsigned len)
-{
- struct ipoib_header *header;
- struct ipoib_cb *cb = ipoib_skb_cb(skb);
-
- header = (struct ipoib_header *) skb_push(skb, sizeof *header);
-
- header->proto = htons(type);
- header->reserved = 0;
-
- /*
- * we don't rely on dst_entry structure, always stuff the
- * destination address into skb->cb so we can figure out where
- * to send the packet later.
- */
- memcpy(cb->hwaddr, daddr, INFINIBAND_ALEN);
-
- return sizeof *header;
-}
-
static void ipoib_set_mcast_list(struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
@@ -1328,10 +1306,6 @@ void ipoib_dev_cleanup(struct net_device *dev)
ipoib_neigh_hash_uninit(dev);
}
-static const struct header_ops ipoib_header_ops = {
- .create = ipoib_hard_header,
-};
-
static const struct net_device_ops ipoib_netdev_ops = {
.ndo_uninit = ipoib_uninit,
.ndo_open = ipoib_open,
diff --git a/include/linux/ibdevice.h b/include/linux/ibdevice.h
new file mode 100644
index 0000000..8418974
--- /dev/null
+++ b/include/linux/ibdevice.h
@@ -0,0 +1,15 @@
+/*
+ * ipoib Implementation of ipoib_header_ops here.
+ *
+ * Authors: Wengang Wang <wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
+ */
+#ifndef _LINUX_IBDEVICE_H
+#define _LINUX_IBDEVICE_H
+
+#include <linux/netdevice.h>
+
+#ifdef __KERNEL__
+extern const struct header_ops ipoib_header_ops;
+#endif /* __KERNEL__ */
+
+#endif /* _LINUX_IBDEVICE_H */
diff --git a/include/linux/if_infiniband.h b/include/linux/if_infiniband.h
new file mode 100644
index 0000000..9f2d0cf
--- /dev/null
+++ b/include/linux/if_infiniband.h
@@ -0,0 +1,11 @@
+/*
+ * ipoib Implementation of ipoib_header_ops here.
+ *
+ * Authors: Wengang Wang <wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
+ */
+#ifndef _LINUX_IF_INFINIBAND_H
+#define _LINUX_IF_INFINIBAND_H
+
+#include <uapi/linux/if_infiniband.h>
+
+#endif /* _LINUX_IF_INFINIBAND_H */
diff --git a/include/uapi/linux/if_infiniband.h b/include/uapi/linux/if_infiniband.h
index 7d958475..9190ee3 100644
--- a/include/uapi/linux/if_infiniband.h
+++ b/include/uapi/linux/if_infiniband.h
@@ -21,9 +21,19 @@
* $Id$
*/
-#ifndef _LINUX_IF_INFINIBAND_H
-#define _LINUX_IF_INFINIBAND_H
+#ifndef _UAPI_LINUX_IF_INFINIBAND_H
+#define _UAPI_LINUX_IF_INFINIBAND_H
+#include <net/sch_generic.h>
#define INFINIBAND_ALEN 20 /* Octets in IPoIB HW addr */
-#endif /* _LINUX_IF_INFINIBAND_H */
+struct ipoib_header {
+ __be16 proto;
+ u16 reserved;
+};
+
+struct ipoib_cb {
+ struct qdisc_skb_cb qdisc_cb;
+ u8 hwaddr[INFINIBAND_ALEN];
+};
+#endif /* _UAPI_LINUX_IF_INFINIBAND_H */
diff --git a/net/Makefile b/net/Makefile
index 7ed1970..5d00a13 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_NET) += $(tmp-y)
# LLC has to be linked before the files in net/802/
obj-$(CONFIG_LLC) += llc/
-obj-$(CONFIG_NET) += ethernet/ 802/ sched/ netlink/
+obj-$(CONFIG_NET) += ethernet/ 802/ sched/ netlink/ infiniband/
obj-$(CONFIG_NETFILTER) += netfilter/
obj-$(CONFIG_INET) += ipv4/
obj-$(CONFIG_XFRM) += xfrm/
diff --git a/net/infiniband/Makefile b/net/infiniband/Makefile
new file mode 100644
index 0000000..c8a5be0
--- /dev/null
+++ b/net/infiniband/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the Linux ip over infiniband layer.
+#
+
+obj-y += infiniband.o
diff --git a/net/infiniband/infiniband.c b/net/infiniband/infiniband.c
new file mode 100644
index 0000000..a458ec5
--- /dev/null
+++ b/net/infiniband/infiniband.c
@@ -0,0 +1,34 @@
+/*
+ * ipoib Implementation of ipoib_header_ops here.
+ *
+ * Authors: Wengang Wang <wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
+ */
+
+#include <linux/if_infiniband.h>
+
+static int ipoib_hard_header(struct sk_buff *skb,
+ struct net_device *dev,
+ unsigned short type,
+ const void *daddr, const void *saddr, unsigned len)
+{
+ struct ipoib_header *header;
+ struct ipoib_cb *cb = (struct ipoib_cb *)skb->cb;
+
+ header = (struct ipoib_header *)skb_push(skb, sizeof(*header));
+
+ header->proto = htons(type);
+ header->reserved = 0;
+
+ /* we don't rely on dst_entry structure, always stuff the
+ * destination address into skb->cb so we can figure out where
+ * to send the packet later.
+ */
+ memcpy(cb->hwaddr, daddr, INFINIBAND_ALEN);
+
+ return sizeof(*header);
+}
+
+const struct header_ops ipoib_header_ops = {
+ .create = ipoib_hard_header,
+};
+EXPORT_SYMBOL(ipoib_header_ops);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* Re: [PATCH] ip_tunnel: the lack of vti_link_ops' dellink() cause kernel panic
From: lucien xin @ 2014-11-25 5:53 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: network dev, Steffen Klassert, Cong Wang
In-Reply-To: <54733E3E.7070702@6wind.com>
>
> Nitpicking: please, use a tab instead of space to align the '=', like other
> lines.
ok, I will repost it.
^ permalink raw reply
* [PATCH] [net]ip_tunnel: the lack of vti_link_ops' dellink() cause kernel panic
From: Xin Long @ 2014-11-25 5:55 UTC (permalink / raw)
To: network dev, Steffen Klassert; +Cc: Nicolas Dichtel, Xin Long, Cong Wang
Now the vti_link_ops do not point the .dellink, for fb tunnel device
(ip_vti0), the net_device will be removed as the default .dellink is
unregister_netdevice_queue,but the tunnel still in the tunnel list,
then if we add a new vti tunnel, in ip_tunnel_find():
hlist_for_each_entry_rcu(t, head, hash_node) {
if (local == t->parms.iph.saddr &&
remote == t->parms.iph.daddr &&
link == t->parms.link &&
==> type == t->dev->type &&
ip_tunnel_key_match(&t->parms, flags, key))
break;
}
the panic will happen, cause dev of ip_tunnel *t is null:
[ 3835.072977] IP: [<ffffffffa04103fd>] ip_tunnel_find+0x9d/0xc0 [ip_tunnel]
[ 3835.073008] PGD b2c21067 PUD b7277067 PMD 0
[ 3835.073008] Oops: 0000 [#1] SMP
.....
[ 3835.073008] Stack:
[ 3835.073008] ffff8800b72d77f0 ffffffffa0411924 ffff8800bb956000 ffff8800b72d78e0
[ 3835.073008] ffff8800b72d78a0 0000000000000000 ffffffffa040d100 ffff8800b72d7858
[ 3835.073008] ffffffffa040b2e3 0000000000000000 0000000000000000 0000000000000000
[ 3835.073008] Call Trace:
[ 3835.073008] [<ffffffffa0411924>] ip_tunnel_newlink+0x64/0x160 [ip_tunnel]
[ 3835.073008] [<ffffffffa040b2e3>] vti_newlink+0x43/0x70 [ip_vti]
[ 3835.073008] [<ffffffff8150d4da>] rtnl_newlink+0x4fa/0x5f0
[ 3835.073008] [<ffffffff812f68bb>] ? nla_strlcpy+0x5b/0x70
[ 3835.073008] [<ffffffff81508fb0>] ? rtnl_link_ops_get+0x40/0x60
[ 3835.073008] [<ffffffff8150d11f>] ? rtnl_newlink+0x13f/0x5f0
[ 3835.073008] [<ffffffff81509cf4>] rtnetlink_rcv_msg+0xa4/0x270
[ 3835.073008] [<ffffffff8126adf5>] ? sock_has_perm+0x75/0x90
[ 3835.073008] [<ffffffff81509c50>] ? rtnetlink_rcv+0x30/0x30
[ 3835.073008] [<ffffffff81529e39>] netlink_rcv_skb+0xa9/0xc0
[ 3835.073008] [<ffffffff81509c48>] rtnetlink_rcv+0x28/0x30
....
modprobe ip_vti
ip link del ip_vti0 type vti
ip link add ip_vti0 type vti
rmmod ip_vti
do that one or more times, kernel will panic.
fix it by assigning ip_tunnel_dellink to vti_link_ops' dellink, in
which we skip the unregister of fb tunnel device. do the same on ip6_vti.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
---
net/ipv4/ip_vti.c | 1 +
net/ipv6/ip6_vti.c | 11 +++++++++++
2 files changed, 12 insertions(+)
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 3e86101..5f29e49 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -528,6 +528,7 @@ static struct rtnl_link_ops vti_link_ops __read_mostly = {
.validate = vti_tunnel_validate,
.newlink = vti_newlink,
.changelink = vti_changelink,
+ .dellink = ip_tunnel_dellink,
.get_size = vti_get_size,
.fill_info = vti_fill_info,
};
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 31089d1..bcda14d 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -905,6 +905,15 @@ static int vti6_newlink(struct net *src_net, struct net_device *dev,
return vti6_tnl_create2(dev);
}
+static void vti6_dellink(struct net_device *dev, struct list_head *head)
+{
+ struct net *net = dev_net(dev);
+ struct vti6_net *ip6n = net_generic(net, vti6_net_id);
+
+ if (dev != ip6n->fb_tnl_dev)
+ unregister_netdevice_queue(dev, head);
+}
+
static int vti6_changelink(struct net_device *dev, struct nlattr *tb[],
struct nlattr *data[])
{
@@ -980,6 +989,7 @@ static struct rtnl_link_ops vti6_link_ops __read_mostly = {
.setup = vti6_dev_setup,
.validate = vti6_validate,
.newlink = vti6_newlink,
+ .dellink = vti6_dellink,
.changelink = vti6_changelink,
.get_size = vti6_get_size,
.fill_info = vti6_fill_info,
@@ -1020,6 +1030,7 @@ static int __net_init vti6_init_net(struct net *net)
if (!ip6n->fb_tnl_dev)
goto err_alloc_dev;
dev_net_set(ip6n->fb_tnl_dev, net);
+ ip6n->fb_tnl_dev->rtnl_link_ops = &vti6_link_ops;
err = vti6_fb_tnl_dev_init(ip6n->fb_tnl_dev);
if (err < 0)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net_test_tools] route_bench: Fix bug in DST_ITERATE option
From: David Miller @ 2014-11-25 5:58 UTC (permalink / raw)
To: subramanian.vijay; +Cc: netdev
In-Reply-To: <CAGK4HS9Hs_3s=QALZKRFnH0b3v88mDVWDs5KSosn3D0smZvRBQ@mail.gmail.com>
From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: Mon, 24 Nov 2014 17:18:27 -0800
> The patch was targeted not against 'net' tree but against test suite
> at https://git.kernel.org/pub/scm/linux/kernel/git/davem/net_test_tools.git
> as indicated in subject. Would you like me to resubmit this making it
> clear in commit log too?
Sorry, my bad. I'll re-look at your patch, sorry :)
^ permalink raw reply
* Re: [PATCH] bonding: move ipoib_header_ops to vmlinux
From: David Miller @ 2014-11-25 6:07 UTC (permalink / raw)
To: wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1416893768-21369-1-git-send-email-wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
From: Wengang Wang <wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date: Tue, 25 Nov 2014 13:36:08 +0800
> When last slave of a bonding master is removed, the bonding then does not work.
> At the time if packet_snd is called against with a master net_device, it calls
> then header_ops->create which points to slave's header_ops. In case the slave
> is ipoib and the module is unloaded, header_ops would point to invalid address.
> Accessing it will cause problem.
> This patch tries to fix this issue by moving ipoib_header_ops to vmlinux to keep
> it valid even when ipoib module is unloaded.
>
> Signed-off-by: Wengang Wang <wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
IPOIB should not work over bonding as it requires that the device
use ARPHRD_ETHER.
Someone mentioned this, and I did not see any response.
Please show how a legitimate real bonding configuration can be
created, reproduce a stray memory access, and therefore potentially
cause a crash.
Using various debugging features of the kernel should allow you to
trigger an assertion quite easily if this bug really exists.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] ip_tunnel: the lack of vti_link_ops' dellink() cause kernel panic
From: David Miller @ 2014-11-25 6:08 UTC (permalink / raw)
To: lucien.xin; +Cc: nicolas.dichtel, netdev, steffen.klassert, cwang
In-Reply-To: <CADvbK_f31zM4B97r29jZuEE_fRbZY55SEWifjAFWg86wrfVFDg@mail.gmail.com>
From: lucien xin <lucien.xin@gmail.com>
Date: Tue, 25 Nov 2014 13:53:15 +0800
>> Nitpicking: please, use a tab instead of space to align the '=', like other
>> lines.
>
> ok, I will repost it.
That's pointless, as I already applied your original patch to
my tree.
^ permalink raw reply
* Re: [PATCH iproute2] iplink: allow to show ip addresses
From: Michal Kubecek @ 2014-11-25 6:10 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: shemminger, netdev
In-Reply-To: <1416847337-23661-1-git-send-email-nicolas.dichtel@6wind.com>
On Mon, Nov 24, 2014 at 05:42:17PM +0100, Nicolas Dichtel wrote:
> This patch adds a new option (-addresses) to the 'ip link' command so that the
> user can display link details and IP addresses with the same command.
>
> Example:
> $ ip -d -a l ls gre1
> 9: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1468 qdisc noqueue state UNKNOWN mode DEFAULT group default
> link/gre 10.16.0.249 peer 10.16.0.121 promiscuity 0
> gre remote 10.16.0.121 local 10.16.0.249 ttl inherit ikey 0.0.0.10 okey 0.0.0.10 icsum ocsum
> inet 192.168.0.249 peer 192.168.0.121/32 scope global gre1
> valid_lft forever preferred_lft forever
> inet6 fe80::5efe:a10:f9/64 scope link
> valid_lft forever preferred_lft forever
Perhaps it would be more consistent to add -d option to "ip addr show"
instead as we already have -s for statistics there (commit 5d5cf1b43).
Michal Kubecek
^ permalink raw reply
* Information needed
From: Skipton Financial Services® @ 2014-11-25 6:08 UTC (permalink / raw)
Good day
These are Skipton Financial Services, today we offer loans at interest rate of 3%, our type of loan are: - business loans, inter company loans individuals loans and family loans. If you have interest in our loan offer please fill out the form below.
Borrowers name in Full:
Amount Needed as Loan:
The purpose of the loan:
Loan Duration:
Phone:
gender:
We await your prompt response if you need financial assistance.
E-mail: skipton_fin-services@hotmail.com
Thank you,
Fulfill your financial needs is our goal!
Rebecca Allso
--
Esta mensagem foi verificada pelo sistema de antivirus e
acredita-se estar livre de perigo.
^ permalink raw reply
* Re: [RFC PATCH 0/4] switch device: offload policy attributes
From: John Fastabend @ 2014-11-25 6:39 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Scott Feldman, Jiří Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, stephen, John Linville, nhorman,
Nicolas Dichtel, vyasevic, Florian Fainelli, buytenh, Aviad Raveh,
Netdev, David S. Miller, Shrijeet Mukherjee, Andy Gospodarek
In-Reply-To: <5473B874.1010005@cumulusnetworks.com>
On 11/24/2014 03:00 PM, Roopa Prabhu wrote:
> On 11/24/14, 12:48 PM, Scott Feldman wrote:
>> On Mon, Nov 24, 2014 at 4:55 AM, Roopa Prabhu
>> <roopa@cumulusnetworks.com> wrote:
>>> On 11/24/14, 2:18 AM, Scott Feldman wrote:
>>>> Hi Roopa,
>>>>
>>>> I have a patch pending against Jiri's v2 that's uses existing
>>>> ndo_bridge_setlink/getlink to push policy settings down to port driver
>>>> for controlling HW offload. I had to make a few tweaks, but for the
>>>> most part setlink/getlink already has the master/self semantics so
>>>> users can set policy flags on bridge's SW version of the port (master)
>>>> or on the offloaded version of the port (self).
>>>> I added the new
>>>> hwmode option "swdev" to the existing "vepa"|"veb" choices. When you
>>>> specify hwmode, SELF is set and the port driver's setlink get's
>>>> called. Did you look at setlink/getlink? It looks like the kernel
>>>> and iproute2 where going down this route of using setlink/getlink for
>>>> SELF policy, so I'm wondering if we need more?
>>> If i understand you correctly, this will mean the port driver
>>> implements the
>>> setlink/getlink with the bridge port flags and attributes. And, it also
>>> means
>>> the port driver will parse the netlink msg instead of the bridge driver
>>> parsing all attributes and then calling offloads.
>> Yes, exactly, the port driver parses/fills bridge_setlink/getlink
>> netlink msg to set/get port settings. It's basically a passthru for
>> rtnl_bridge_setlink/getlink handling RTM_GETLNK/RTM_SETLINK on
>> PF_BRIDGE.
> This will duplicate msg parsing code and validation code in the kernel
> bridge driver and in all the port drivers.
> If this is the path we plan to go down on,...it will also mean we will
> do the same thing
> for bonds, vxlans and maybe others in the future.
>
Where it makes sense we can do the msg parsing in a common
location once right? The fdb hooks and setlink/getlink handlers should
probably be cleaned up for this as well. Or we can build a set of
utility functions _dflt_ handlers that drivers can call to do the
parsing. At least these are not exposed to the user API so we can
iterate over this as needed and as more attributes are needed.
> In the mode where kernel and hw state need to remain in sync,
> I am also concerned about how we handle failure cases.
>
> I think we will have cases where the kernel will set the attribute and
> hw will fail. In which case can we rollback ?
In the fdb cases we set a flag to indicate how far we got in the
command and then punt it back to user space where it can be rolled
back. We don't have any sort of reserve and commit or rollback on error
behaviour. It seems like a "nice" feature but perhaps the first
iteration can just return how far it got and let user space handle
the rollback.
At least this is how I planned to handle flow tables and flow updates
as Simon pointed out.
[...]
--
John Fastabend Intel Corporation
^ permalink raw reply
* [PATCH 1/1] ipv6: remove unnecessary condition judgement
From: Zhu Yanjun @ 2014-11-25 6:40 UTC (permalink / raw)
To: netdev, zyjzyj2000
Cc: Zhu Yanjun, Hong Zhiguo, Octavian Purdila, Pavel Emelyanov,
Cong Wang, David S. Miller
The "init_net" condition judgement in function addrconf_exit_net is introduced
in commit 44a6bd29 [Create ipv6 devconf-s for namespaces] to avoid freeing
init_net. In commit c900a800 [ipv6: fix bad free of addrconf_init_net],
function addrconf_init_net will allocate memory for every net regardless of
init_net. In this case, it is unnecessary to make "init_net" condition judgement.
CC: Hong Zhiguo <honkiko@gmail.com>
CC: Octavian Purdila <opurdila@ixiacom.com>
CC: Pavel Emelyanov <xemul@openvz.org>
CC: Cong Wang <cwang@twopensource.com>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
net/ipv6/addrconf.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 0169ccf..b8724fc 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -5336,10 +5336,8 @@ static void __net_exit addrconf_exit_net(struct net *net)
__addrconf_sysctl_unregister(net->ipv6.devconf_dflt);
__addrconf_sysctl_unregister(net->ipv6.devconf_all);
#endif
- if (!net_eq(net, &init_net)) {
- kfree(net->ipv6.devconf_dflt);
- kfree(net->ipv6.devconf_all);
- }
+ kfree(net->ipv6.devconf_dflt);
+ kfree(net->ipv6.devconf_all);
}
static struct pernet_operations addrconf_ops = {
--
1.9.1
^ permalink raw reply related
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