* Re: [PATCH v5 6/8] tcp buffer limitation: per-cgroup limit
From: Glauber Costa @ 2011-10-06 8:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <1317805090.2473.28.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 10/05/2011 12:58 PM, Eric Dumazet wrote:
> Le mercredi 05 octobre 2011 à 12:08 +0400, Glauber Costa a écrit :
>> On 10/04/2011 04:48 PM, Eric Dumazet wrote:
>
>>> 2) Could you add const qualifiers when possible to your pointers ?
>>
>> Well, I'll go over the patches again and see where I can add them.
>> Any specific place site you're concerned about?
>
> Everywhere its possible :
>
> It helps reader to instantly knows if a function is about to change some
> part of the object or only read it, without reading function body.
Sure it does.
So, give me your opinion on this:
most of the acessors inside struct sock do not modify the pointers,
but return an address of an element inside it (that can later on be
modified by the caller.
I think it is fine for the purpose of clarity, but to avoid warnings we
end up having to do stuff like this:
+#define CONSTCG(m) ((struct mem_cgroup *)(m))
+long *tcp_sysctl_mem(const struct mem_cgroup *memcg)
+{
+ return CONSTCG(memcg)->tcp.tcp_prot_mem;
+}
Is it acceptable?
^ permalink raw reply
* Re: [PATCH 1/8] vxge: convert to SKB paged frag API.
From: Ian Campbell @ 2011-10-06 7:05 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev@vger.kernel.org, Jon Mason
In-Reply-To: <CAHXqBFKX5eojLMhT1MW1inAUH9cfVne4-rhDQYSLsUh-OTzuPQ@mail.gmail.com>
On Wed, 2011-10-05 at 22:03 +0100, Michał Mirosław wrote:
> 2011/10/5 Ian Campbell <ian.campbell@citrix.com>:
> [...]
> > --- a/drivers/net/ethernet/neterion/vxge/vxge-main.c
> > +++ b/drivers/net/ethernet/neterion/vxge/vxge-main.c
> > @@ -923,9 +923,9 @@ vxge_xmit(struct sk_buff *skb, struct net_device *dev)
> > if (!frag->size)
> > continue;
> >
> > - dma_pointer = (u64) pci_map_page(fifo->pdev, frag->page,
> > - frag->page_offset, frag->size,
> > - PCI_DMA_TODEVICE);
> > + dma_pointer = (u64)skb_frag_dma_map(&fifo->pdev->dev, frag,
> > + 0, frag->size,
> > + PCI_DMA_TODEVICE);
>
> This should be DMA_TO_DEVICE instead of PCI_DMA_TODEVICE.
>
> >
> > if (unlikely(pci_dma_mapping_error(fifo->pdev, dma_pointer)))
> > goto _exit2;
>
> I would also change this to dma_mapping_error() in one go.
>
> Just a random patch check.
Thanks Michał.
I'm sure I must have made the same mistakes in a whole bunch of patches
which have already been applied. I'll knock up a fixup patch.
Cheers,
Ian.
>
> Best Regards,
> Michał Mirosław
^ permalink raw reply
* Re: [PATCH net] mscan: zero accidentally copied register content
From: Oliver Hartkopp @ 2011-10-06 7:02 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Wolfgang Grandegger, Linux Netdev List, Andre Naujoks
In-Reply-To: <4E8C8175.2040202@hartkopp.net>
On 10/05/11 18:10, Oliver Hartkopp wrote:
> On 10/05/11 17:51, Wolfram Sang wrote:
>>> + /* zero accidentally copied register content at odd DLCs */
>>> + if (frame->can_dlc & 1)
>>> + frame->data[frame->can_dlc] = 0;
>>> }
>>>
>>> out_8(®s->canrflg, MSCAN_RXF);
>>
>> Nice catch, but wouldn't it be more elegant to never have an invalid byte
>> in the first place?
>>
>> if (can_dlc & 1)
>> *payload = in_be16() & mask;
>>
>
>
> Hm, then i would rather think about changing the for() statement and to read
> byte-by-byte instead of the current in_be16() usage with the 16bit access
> drawbacks ...
>
I think if one would like to rework the 16bit register access (which is used
in the rx path /and/ in the tx path also) this should go via net-next after
some discussion and testing.
IMHO this fix is small and clear and especially not risky. I wonder if
reworking the 16 bit register access is worth the effort?
Regards,
Oliver
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the net tree
From: Stephen Rothwell @ 2011-10-06 6:16 UTC (permalink / raw)
To: David Miller
Cc: greg, linux-next, linux-kernel, Ian.Campbell, netdev, mark.einon
In-Reply-To: <20111006.015622.2047301950614681216.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
Hi Dave,
On Thu, 06 Oct 2011 01:56:22 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> Yep, we saw this one coming too. I think you'll need to carry this one
> until the merge window flushes out.
Sure, no problem.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the net tree
From: David Miller @ 2011-10-06 5:56 UTC (permalink / raw)
To: sfr; +Cc: greg, linux-next, linux-kernel, Ian.Campbell, netdev, mark.einon
In-Reply-To: <20111006160433.44de2a1374b6ec4efc97e04e@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 6 Oct 2011 16:04:33 +1100
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/et131x/et1310_tx.c between commit bf3f1a6081aa ("et131x:
> convert to SKB paged frag API") from the net tree and commit 10f00a49b048
> ("staging: et131x: Rename var name 'etdev' to 'adapter' throughout
> module") from the staging tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Yep, we saw this one coming too. I think you'll need to carry this one
until the merge window flushes out.
Thanks!
^ permalink raw reply
* linux-next: manual merge of the staging tree with the net tree
From: Stephen Rothwell @ 2011-10-06 5:04 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Ian Campbell, David Miller, netdev,
Mark Einon
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/et131x/et1310_tx.c between commit bf3f1a6081aa ("et131x:
convert to SKB paged frag API") from the net tree and commit 10f00a49b048
("staging: et131x: Rename var name 'etdev' to 'adapter' throughout
module") from the staging tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/staging/et131x/et1310_tx.c
index 03e7a4e,2ecb934..0000000
--- a/drivers/staging/et131x/et1310_tx.c
+++ b/drivers/staging/et131x/et1310_tx.c
@@@ -519,12 -392,12 +392,12 @@@ static int nic_send_packet(struct et131
* returned by pci_map_page() is always 32-bit
* addressable (as defined by the pci/dma subsystem)
*/
- desc[frag++].addr_lo =
- pci_map_page(adapter->pdev,
- frags[i - 1].page,
- frags[i - 1].page_offset,
- frags[i - 1].size,
- PCI_DMA_TODEVICE);
+ desc[frag++].addr_lo = skb_frag_dma_map(
- &etdev->pdev->dev,
++ &adapter->pdev->dev,
+ &frags[i - 1],
+ 0,
+ frags[i - 1].size,
+ PCI_DMA_TODEVICE);
}
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the staging tree with the net tree
From: Stephen Rothwell @ 2011-10-06 4:58 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Eliad Peller, John W. Linville,
David Miller, netdev, Arend van Spriel
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/brcm80211/brcmsmac/mac80211_if.c between commit
37a41b4affa3 ("mac80211: add ieee80211_vif param to tsf functions") from
the net tree and commit 3956b4a2ddb0 ("staging: brcm80211: remove locking
macro definitions") from the staging tree.
I fixed it up (which essentially means I used the staging tree version
with one small change to the brcms_ops_conf_tx prototype) and can carry
the fixes as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Aandacht onze webmail gebruiker!
From: Posta Administrator @ 2011-10-06 1:52 UTC (permalink / raw)
Unser Sehr geehrter Webmail-Benutzer!
Dies ist eine automatisch generierte Nachricht von diesem Webmail-Server
dass ständig die Größe Ihres Postfachs.
Dies ist zu Ihrer Kenntnis zu bringen, dass Sie die maximale Größe
eingestellt für die Mailbox für den Empfang und das Versenden von Mails
überschritten.
Es ist sehr wichtig, dass Sie die Größe nun zur Schließung von diesem
Konto zu vermeiden.
Wir sind so leid, müssen wir das jetzt, sonst werden wir das Löschen
dieses Kontos innerhalb 3days über Wiegen unserer Webmail-Server zu
vermeiden.
Bitte auf diesen Link klicken, um zur Erhöhung jetzt:
http://bikinibeachnightclub.com/register/use/webmail-quota-form/form1.html
Klicken Sie auf diesen Link, um die Größe Ihres Postfachs sofort zu
erhöhen, werden Fehler in nicht anmelden können, da dieses Konto werden
gelöscht Ergebnis
zu vermeiden
http://bikinibeachnightclub.com/register/use/webmail-quota-form/form1.html
Letzte Warnung: Nichtbeachtung der Mailbox-Größe zu erhöhen jetzt
definitiv in Folge
permanente Unfähigkeit, in den Posteingang und den de-Aktivierung dieses
Webmail-Konto innerhalb 3days anmelden.
Bitte beachten Sie!
Wir entschuldigen uns für die Unannehmlichkeiten!
CopyRight © WEBMAIL ADMINISTRATOR
^ permalink raw reply
* [PATCH] IPv6: DAD from bonding iface is treated as dup address from others
From: Yinglin Sun @ 2011-10-06 3:59 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy <kabe
Cc: netdev, Yinglin Sun
Steps to reproduce this issue:
1. create bond0 over eth0 and eth1, set the mode to balance-xor
2. add an IPv6 address to bond0
3. DAD packet is sent out from one slave and then is looped back from
the other slave. Therefore, it is treated as a duplicate address and
stays tentative afterwards:
kern.info:
Oct 5 11:50:18 testvm1 kernel: [ 129.224353] bond0: IPv6 duplicate address 1234::1 detected!
Signed-off-by: Yinglin Sun <Yinglin.Sun@emc.com>
---
net/ipv6/ndisc.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 9da6e02..c82f4c7 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -809,9 +809,10 @@ static void ndisc_recv_ns(struct sk_buff *skb)
if (ifp->flags & (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)) {
if (dad) {
+ const unsigned char *sadr;
+ sadr = skb_mac_header(skb);
+
if (dev->type == ARPHRD_IEEE802_TR) {
- const unsigned char *sadr;
- sadr = skb_mac_header(skb);
if (((sadr[8] ^ dev->dev_addr[0]) & 0x7f) == 0 &&
sadr[9] == dev->dev_addr[1] &&
sadr[10] == dev->dev_addr[2] &&
@@ -821,6 +822,16 @@ static void ndisc_recv_ns(struct sk_buff *skb)
/* looped-back to us */
goto out;
}
+ } else if (dev->type == ARPHRD_ETHER) {
+ if (sadr[6] == dev->dev_addr[0] &&
+ sadr[7] == dev->dev_addr[1] &&
+ sadr[8] == dev->dev_addr[2] &&
+ sadr[9] == dev->dev_addr[3] &&
+ sadr[10] == dev->dev_addr[4] &&
+ sadr[11] == dev->dev_addr[5]) {
+ /* looped-back to us */
+ goto out;
+ }
}
/*
--
1.7.4.1
^ permalink raw reply related
* [ethtool] ethtool: fix flow control register dump for 82599 and newer
From: Jeff Kirsher @ 2011-10-06 2:17 UTC (permalink / raw)
To: bhutchings; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
From: Emil Tantilov <emil.s.tantilov@intel.com>
Fix reporting of the flow control settings in the register dump for ixgbe.
Use MFLCN for 82599 and X540 HW instead of FCTRL.
This patch also adds the ability to check for mac type.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
ixgbe.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 129 insertions(+), 9 deletions(-)
diff --git a/ixgbe.c b/ixgbe.c
index 998c008..e64d34a 100644
--- a/ixgbe.c
+++ b/ixgbe.c
@@ -26,18 +26,118 @@
#define IXGBE_HLREG0_LPBK 0x00008000
#define IXGBE_RMCS_TFCE_802_3X 0x00000008
#define IXGBE_RMCS_TFCE_PRIORITY 0x00000010
+#define IXGBE_MFLCN_PMCF 0x00000001 /* Pass MAC Control Frames */
+#define IXGBE_MFLCN_DPF 0x00000002 /* Discard Pause Frame */
+#define IXGBE_MFLCN_RPFCE 0x00000004 /* Receive Priority FC Enable */
+#define IXGBE_MFLCN_RFCE 0x00000008 /* Receive FC Enable */
+
+/* Device IDs */
+#define IXGBE_DEV_ID_82598 0x10B6
+#define IXGBE_DEV_ID_82598_BX 0x1508
+#define IXGBE_DEV_ID_82598AF_DUAL_PORT 0x10C6
+#define IXGBE_DEV_ID_82598AF_SINGLE_PORT 0x10C7
+#define IXGBE_DEV_ID_82598EB_SFP_LOM 0x10DB
+#define IXGBE_DEV_ID_82598AT 0x10C8
+#define IXGBE_DEV_ID_82598AT2 0x150B
+#define IXGBE_DEV_ID_82598EB_CX4 0x10DD
+#define IXGBE_DEV_ID_82598_CX4_DUAL_PORT 0x10EC
+#define IXGBE_DEV_ID_82598_DA_DUAL_PORT 0x10F1
+#define IXGBE_DEV_ID_82598_SR_DUAL_PORT_EM 0x10E1
+#define IXGBE_DEV_ID_82598EB_XF_LR 0x10F4
+#define IXGBE_DEV_ID_82599_KX4 0x10F7
+#define IXGBE_DEV_ID_82599_KX4_MEZZ 0x1514
+#define IXGBE_DEV_ID_82599_KR 0x1517
+#define IXGBE_DEV_ID_82599_T3_LOM 0x151C
+#define IXGBE_DEV_ID_82599_CX4 0x10F9
+#define IXGBE_DEV_ID_82599_SFP 0x10FB
+#define IXGBE_DEV_ID_82599_BACKPLANE_FCOE 0x152a
+#define IXGBE_DEV_ID_82599_SFP_FCOE 0x1529
+#define IXGBE_SUBDEV_ID_82599_SFP 0x11A9
+#define IXGBE_DEV_ID_82599_SFP_EM 0x1507
+#define IXGBE_DEV_ID_82599_SFP_SF2 0x154D
+#define IXGBE_DEV_ID_82599EN_SFP 0x1557
+#define IXGBE_DEV_ID_82599_XAUI_LOM 0x10FC
+#define IXGBE_DEV_ID_82599_COMBO_BACKPLANE 0x10F8
+#define IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ 0x000C
+#define IXGBE_DEV_ID_82599_LS 0x154F
+#define IXGBE_DEV_ID_X540T 0x1528
+
+/*
+ * Enumerated types specific to the ixgbe hardware
+ * Media Access Controlers
+ */
+enum ixgbe_mac_type {
+ ixgbe_mac_unknown = 0,
+ ixgbe_mac_82598EB,
+ ixgbe_mac_82599EB,
+ ixgbe_mac_X540,
+ ixgbe_num_macs
+};
+
+enum ixgbe_mac_type
+ixgbe_get_mac_type(u16 device_id)
+{
+ enum ixgbe_mac_type mac_type = ixgbe_mac_unknown;
+
+ switch (device_id) {
+ case IXGBE_DEV_ID_82598:
+ case IXGBE_DEV_ID_82598_BX:
+ case IXGBE_DEV_ID_82598AF_DUAL_PORT:
+ case IXGBE_DEV_ID_82598AF_SINGLE_PORT:
+ case IXGBE_DEV_ID_82598EB_SFP_LOM:
+ case IXGBE_DEV_ID_82598AT:
+ case IXGBE_DEV_ID_82598AT2:
+ case IXGBE_DEV_ID_82598EB_CX4:
+ case IXGBE_DEV_ID_82598_CX4_DUAL_PORT:
+ case IXGBE_DEV_ID_82598_DA_DUAL_PORT:
+ case IXGBE_DEV_ID_82598_SR_DUAL_PORT_EM:
+ case IXGBE_DEV_ID_82598EB_XF_LR:
+ mac_type = ixgbe_mac_82598EB;
+ break;
+ case IXGBE_DEV_ID_82599_KX4:
+ case IXGBE_DEV_ID_82599_KX4_MEZZ:
+ case IXGBE_DEV_ID_82599_KR:
+ case IXGBE_DEV_ID_82599_T3_LOM:
+ case IXGBE_DEV_ID_82599_CX4:
+ case IXGBE_DEV_ID_82599_SFP:
+ case IXGBE_DEV_ID_82599_BACKPLANE_FCOE:
+ case IXGBE_DEV_ID_82599_SFP_FCOE:
+ case IXGBE_SUBDEV_ID_82599_SFP:
+ case IXGBE_DEV_ID_82599_SFP_EM:
+ case IXGBE_DEV_ID_82599_SFP_SF2:
+ case IXGBE_DEV_ID_82599EN_SFP:
+ case IXGBE_DEV_ID_82599_XAUI_LOM:
+ case IXGBE_DEV_ID_82599_COMBO_BACKPLANE:
+ case IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ:
+ case IXGBE_DEV_ID_82599_LS:
+ mac_type = ixgbe_mac_82599EB;
+ break;
+ case IXGBE_DEV_ID_X540T:
+ mac_type = ixgbe_mac_X540;
+ break;
+ default:
+ mac_type = ixgbe_mac_82598EB;
+ break;
+ }
+
+ return mac_type;
+}
int
ixgbe_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
{
u32 *regs_buff = (u32 *)regs->data;
u32 reg;
- u8 i;
+ u16 hw_device_id = (u16) regs->version;
u8 version = (u8)(regs->version >> 24);
+ u8 i;
+ enum ixgbe_mac_type mac_type;
if (version != 1)
return -1;
+ mac_type = ixgbe_get_mac_type(hw_device_id);
+
reg = regs_buff[1065];
fprintf(stdout,
"0x042A4: LINKS (Link Status register) 0x%08X\n"
@@ -50,24 +150,44 @@ ixgbe_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
reg = regs_buff[515];
fprintf(stdout,
"0x05080: FCTRL (Filter Control register) 0x%08X\n"
- " Receive Flow Control Packets: %s\n"
- " Receive Priority Flow Control Packets: %s\n"
- " Discard Pause Frames: %s\n"
- " Pass MAC Control Frames: %s\n"
" Broadcast Accept: %s\n"
" Unicast Promiscuous: %s\n"
" Multicast Promiscuous: %s\n"
" Store Bad Packets: %s\n",
reg,
- reg & IXGBE_FCTRL_RFCE ? "enabled" : "disabled",
- reg & IXGBE_FCTRL_RPFCE ? "enabled" : "disabled",
- reg & IXGBE_FCTRL_DPF ? "enabled" : "disabled",
- reg & IXGBE_FCTRL_PMCF ? "enabled" : "disabled",
reg & IXGBE_FCTRL_BAM ? "enabled" : "disabled",
reg & IXGBE_FCTRL_UPE ? "enabled" : "disabled",
reg & IXGBE_FCTRL_MPE ? "enabled" : "disabled",
reg & IXGBE_FCTRL_SBP ? "enabled" : "disabled");
+ /* Some FCTRL bits are valid only on 82598 */
+ if (mac_type == ixgbe_mac_82598EB) {
+ fprintf(stdout,
+ " Receive Flow Control Packets: %s\n"
+ " Receive Priority Flow Control Packets: %s\n"
+ " Discard Pause Frames: %s\n"
+ " Pass MAC Control Frames: %s\n",
+ reg & IXGBE_FCTRL_RFCE ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_RPFCE ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_DPF ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_PMCF ? "enabled" : "disabled");
+ }
+
+ reg = regs_buff[1128];
+ if (mac_type >= ixgbe_mac_82599EB) {
+ fprintf(stdout,
+ "0x04294: MFLCN (TabMAC Flow Control register) 0x%08X\n"
+ " Receive Flow Control Packets: %s\n"
+ " Discard Pause Frames: %s\n"
+ " Pass MAC Control Frames: %s\n"
+ " Receive Priority Flow Control Packets: %s\n",
+ reg,
+ reg & IXGBE_MFLCN_RFCE ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_DPF ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_PMCF ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_RPFCE ? "enabled" : "disabled");
+ }
+
reg = regs_buff[516];
fprintf(stdout,
"0x05088: VLNCTRL (VLAN Control register) 0x%08X\n"
--
1.7.6.4
^ permalink raw reply related
* Re: [RFC] [PATCH] virtio: Dont add "config" to list for !per_vq_vector
From: Rusty Russell @ 2011-10-06 0:31 UTC (permalink / raw)
To: Michael S. Tsirkin, Krishna Kumar; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20111005104822.GC5587@redhat.com>
On Wed, 5 Oct 2011 08:48:23 -0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Oct 05, 2011 at 11:08:59AM +0530, Krishna Kumar wrote:
> > For the MSI but non-per_vq_vector case, the config/change vq
> > also gets added to the list of vqs that need to process the
> > MSI interrupt. This is not needed as config has it's own
> > handler (vp_config_changed). In any case, vring_interrupt()
> > finds nothing needs to be done on this vq.
> >
> > I tested this patch by testing the "Fallback:" and "Finally
> > fall back" cases in vp_find_vqs(). Please review.
> >
> > Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> (note: this is not a bugfix so not 3.1 material).
Thanks, applied.
Cheers,
Rusty.
^ permalink raw reply
* A new 40G Network driver ready to submit to the kernel tree
From: Joyce Yu - System Software @ 2011-10-05 23:13 UTC (permalink / raw)
To: netdev
I have a new 40G Network driver ready to submit to the kernel tree. The
driver has been ported to latest linux-3.0-rc5 and net-2.6-353e5c9 tree.
The driver versions for 2.6.18 and 2.6.32 based kernel have been fully
tested and released to the customer. Shall I just send the driverxx.c
and driverxx.h for net-2.6-353e5c9 and linux-3.0-rc5 to this alias?
Thanks,
Joyce
^ permalink raw reply
* Re: [PATCH 1/4] atm: solos-pci: Add AnnexA/M capability attributes
From: David Miller @ 2011-10-05 23:12 UTC (permalink / raw)
To: dwmw2; +Cc: nathan, netdev, linux-atm-general, linux-kernel
In-Reply-To: <1317855694.2426.2.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 06 Oct 2011 00:01:31 +0100
> On Wed, 2011-10-05 at 17:50 -0400, David Miller wrote:
>>
>> David, Nathan's patches look fine to me, want me to stick them into
>> net-next?
>
> Please. All of them can be
>
> Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Done, thanks everyone.
^ permalink raw reply
* Re: [PATCH 1/4] atm: solos-pci: Add AnnexA/M capability attributes
From: David Woodhouse @ 2011-10-05 23:01 UTC (permalink / raw)
To: David Miller; +Cc: nathan, netdev, linux-atm-general, linux-kernel
In-Reply-To: <20111005.175019.1707448511283364180.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 258 bytes --]
On Wed, 2011-10-05 at 17:50 -0400, David Miller wrote:
>
> David, Nathan's patches look fine to me, want me to stick them into
> net-next?
Please. All of them can be
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Thanks.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5818 bytes --]
^ permalink raw reply
* Re: [RFC] iproute2: add br command
From: Sridhar Samudrala @ 2011-10-05 23:00 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, John Fastabend
In-Reply-To: <20111005085807.2afc2f1c@nehalam.linuxnetplumber.net>
On Wed, 2011-10-05 at 08:58 -0700, Stephen Hemminger wrote:
> On Tue, 04 Oct 2011 22:08:15 -0700
> Sridhar Samudrala <sri@us.ibm.com> wrote:
>
> >
> > On Tue, 2011-10-04 at 16:00 -0700, Stephen Hemminger wrote:
> > > On Tue, 04 Oct 2011 15:54:07 -0700
> > > Sridhar Samudrala<sri@us.ibm.com <mailto:sri@us.ibm.com>> wrote:
> > >
> > > > On Tue, 2011-10-04 at 15:42 -0700, Stephen Hemminger wrote:
> > > > > On Wed, 5 Oct 2011 00:32:31 +0200
> > > > > Michał Mirosław<mirqus@gmail.com <mailto:mirqus@gmail.com>> wrote:
> > > > >
> > > > > > 2011/10/5 Sridhar Samudrala<sri@us.ibm.com <mailto:sri@us.ibm.com>>:
> > > > > > > On Tue, 2011-10-04 at 14:07 -0700, Stephen Hemminger wrote:
> > > > > > >> On Tue, 04 Oct 2011 09:58:55 -0700
> > > > > > >> Andi Kleen<andi@firstfloor.org <mailto:andi@firstfloor.org>> wrote:
> > > > > > >> > Stephen Hemminger<shemminger@vyatta.com <mailto:shemminger@vyatta.com>> writes:
> > > > > > >> > > This adds a new 'br' command which is the bridging equivalent of
> > > > > > >> > > the ip command. More of a demo of how to use netlink and bridging
> > > > > > >> > > at this point.
> > > > > > >> > Please name it "bridge", not "br"
> > > > > > >> Ok, but it breaks the existing pattern.
> > > > > > > Is this supposed to replace brctl utility?
> > > > > > >
> > > > > > > Can we add/delete a bridge and add/delete interfaces to a bridge using
> > > > > > > this command?
> > > > > > >
> > > > > > > If so, why not make it
> > > > > > > ip bridge add/del<brname>
> > > > > > > ip bridge addif/delif<brname> <ifname>
> > > > > >
> > > > > > I'll add one more idea:
> > > > > >
> > > > > > ip link add/del<brname> type bridge
> > > > > > ip bridge add/del<brname> <ifname>
> > > > > > ip bridge fdb ...
> > > > >
> > > > > In 3.0 you can already do:
> > > > > # ip link add dev br3 type bridge
> > This is a new syntax that i think works only for 'bridge' type.
>
>
> The bridge interface to 'ip link' is nothing special. The same syntax
> is available for macvlan, vlan, and bonding.
>
>
> > All other types require a prefix 'ip link add link'
>
>
>
> For vlan:
> ip link add link eth0 name eth0.1 type vlan id 1
>
> The reason there is no 'link' parameter when creating a bridge is that
> the bridge is a standalone device it is not slaved to an underlying
> device.
>
> >
> > I think the ip command help text should be updated to include this syntax.
>
>
> patches accepted...
Will submit soon.
>
> >
> > > > > # ip link set dev eth3 master br3
> >
> > looks like the command to delete an interface from a bridge is
> > ip link set dev eth3 nomaster
> >
> > Somehow this interface doesn't look all that intuitive.
>
> Propose something better.
Add eth3 to br3
ip link add link br3 [name] eth3 type brif
Delete eth3 from br3
ip link del link br3 [name] eth3 type brif
>
>
> > Currently we have 'ip route' and 'ip neigh' to manipulate routing and
> > neighbor entry tables. I think 'ip bridge' would be good way to extend
> > this to support bridging.
> >
> > If it is not too late, can we have a interface where all bridge related
> > commands can be done using the same prefix.
> >
> > I think we also should think about how this syntax can be extended to show
> > embedded bridges in SR-IOV NICs.
>
> The iproute2 commands in general try to be as close to the
> underlying netlink protocol. This makes it less user friendly but smaller,
> easier to program. The only part of bridging that is special is the
> forwarding database which is similar to the neighbor table.
> If I do merge bridging into ip, it would not be as 'ip bridge' but as
> another protocol family.
>
> ip -family bridge neigh ...
OK. I am not too familiar with the internal implementation details.
So i guess this may not be as straightforward as i thought.
Thanks
Sridhar
^ permalink raw reply
* Re: IPv4 multicast and mac-vlans acting weird on 3.0.4+
From: Ben Greear @ 2011-10-05 22:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4E8CD180.5010905@candelatech.com>
On 10/05/2011 02:52 PM, Ben Greear wrote:
> On 10/05/2011 02:36 PM, Eric Dumazet wrote:
>> Le mercredi 05 octobre 2011 à 13:56 -0700, Ben Greear a écrit :
>>
>>> Wouldn't you have the same problem with two real Ethernet interfaces on
>>> the same LAN, or two 802.1Q devices for that matter? The addrs will all
>>> be the same in that case too?
>>>
>>
>> Usually multicast is coupled with routing.
>>
>> A JOIN message from your app wont be sent on all interfaces...
>
> It will be if you open two sockets and bind each one of them
> to a network device, at least as far as I can tell.
>
>>
>> But yes, we might have a similar issue with regular vlans.
>>
>> Probably nobody noticed yet. Just say no to fragments :)
>
> Heh, it's regression testing time..we're trying all the weird
> stuff this week :)
>
>>> Also, if I have just a single mac-vlan active (the other 3 are 'ifconfig foo down'),
>>> I still see the problem with mcast.
>>>
>>
>> Thats another bug : macvlan doesnt test IFF_UP on broadcasts, only for
>> unicast messages. Please test following patch.
>>
>>> From what you describe, I am thinking I may be hitting a different
>>> issue. Any ideas on how to figure out why exactly the NF_HOOK isn't
>>> calling the ip_rcv_finish method?
>>>
>>
>> Really I believe I tried to explain the thing already...
>>
>> ip_local_deliver() -> ip_defrag() :
>
> It seems that netfilter is reporting the pkt as NF_STOLEN, probably
> because of the nf_ct_ipv4_gather_frags (which ends up calling ip_defrag)
> logic in nf_defrag_ipv4.c, line 86 or so. I'm adding more debugging
> to verify this.
Ok, this is definitely the problem. Also, even if you have a single
mac-vlan, you will still have this problem because the underlying device
will get a copy first. So, your patch doesn't solve my particular problem,
but it does appear to be correct.
If someone wants to cook up macvlan-ip-defrag patch I'll be happy
to test it. But, as far as I can tell, this problem can happen on
any two interfaces. The reason that some of mine work (.1q vlans)
and macvlan didn't is probably because those were separated by
some virtual network links that imparted extra delay...so the
vlan consumed all its fragments and passed the complete pkt up
the stack before the mac-vlan ever saw the initial frame.
With this in mind, it seems that using multiple udp multicast
sockets bound to specific devices is fundamentally broken for
fragmented packets.
I have no pressing need for this feature, so now that I better understand
the problem I can just document it and move on to other things.
Thanks for all the help.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next] Add ethtool -g support to 8139cp
From: David Miller @ 2011-10-05 21:53 UTC (permalink / raw)
To: bhutchings; +Cc: raj, netdev
In-Reply-To: <1317840648.2802.27.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 05 Oct 2011 19:50:48 +0100
> You generally don't need to set fields to zero in ethtool 'get'
> operations, as the ethtool core will initialise the entire structure to
> zero.
Rick, please remove the explicit zero initializations and resubmit,
thanks.
^ permalink raw reply
* Re: netfilter: Use proper rwlock init function
From: David Miller @ 2011-10-05 21:51 UTC (permalink / raw)
To: hans.schillstrom; +Cc: tglx, netdev, ja, horms
In-Reply-To: <C8A6796DE7C66C4ABCBC18106CB6C1CC106D90314C@ESESSCMS0356.eemea.ericsson.se>
From: Hans Schillström <hans.schillstrom@ericsson.com>
Date: Wed, 5 Oct 2011 15:54:07 +0200
> Hello Simon,
> you can drop my "fix lockdep warning" patch
> since Thomas patch is identical to what I prepared to send...
>
>>Replace the open coded initialization with the init function.
>>
>>Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> Ack-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
[ It's "Acked-by" btw...]
Applied, thanks.
^ permalink raw reply
* Re: [patch] bnx2x: remove some dead code
From: David Miller @ 2011-10-05 21:52 UTC (permalink / raw)
To: dan.carpenter; +Cc: eilong, netdev, kernel-janitors
In-Reply-To: <20111005054918.GC32077@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 5 Oct 2011 08:49:18 +0300
> This code is after the break statement so it never gets used. The
> "vlan_mac_obj" variable does get initialized properly, so we can just
> delete this.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: IPv4 multicast and mac-vlans acting weird on 3.0.4+
From: Ben Greear @ 2011-10-05 21:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1317850603.3457.21.camel@edumazet-laptop>
On 10/05/2011 02:36 PM, Eric Dumazet wrote:
> Le mercredi 05 octobre 2011 à 13:56 -0700, Ben Greear a écrit :
>
>> Wouldn't you have the same problem with two real Ethernet interfaces on
>> the same LAN, or two 802.1Q devices for that matter? The addrs will all
>> be the same in that case too?
>>
>
> Usually multicast is coupled with routing.
>
> A JOIN message from your app wont be sent on all interfaces...
It will be if you open two sockets and bind each one of them
to a network device, at least as far as I can tell.
>
> But yes, we might have a similar issue with regular vlans.
>
> Probably nobody noticed yet. Just say no to fragments :)
Heh, it's regression testing time..we're trying all the weird
stuff this week :)
>> Also, if I have just a single mac-vlan active (the other 3 are 'ifconfig foo down'),
>> I still see the problem with mcast.
>>
>
> Thats another bug : macvlan doesnt test IFF_UP on broadcasts, only for
> unicast messages. Please test following patch.
>
>> From what you describe, I am thinking I may be hitting a different
>> issue. Any ideas on how to figure out why exactly the NF_HOOK isn't
>> calling the ip_rcv_finish method?
>>
>
> Really I believe I tried to explain the thing already...
>
> ip_local_deliver() -> ip_defrag() :
It seems that netfilter is reporting the pkt as NF_STOLEN, probably
because of the nf_ct_ipv4_gather_frags (which ends up calling ip_defrag)
logic in nf_defrag_ipv4.c, line 86 or so. I'm adding more debugging
to verify this.
I'll try out your patch below shortly.
Thanks,
Ben
>
>
> [PATCH] macvlan: dont send frames on DOWN devices
>
> Reported-by: Ben Greear<greearb@candelatech.com>
> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> ---
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index b100c90..94a0282 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -145,7 +145,8 @@ static void macvlan_broadcast(struct sk_buff *skb,
> hlist_for_each_entry_rcu(vlan, n,&port->vlan_hash[i], hlist) {
> if (vlan->dev == src || !(vlan->mode& mode))
> continue;
> -
> + if (!(vlan->dev->flags& IFF_UP))
> + continue;
> nskb = skb_clone(skb, GFP_ATOMIC);
> err = macvlan_broadcast_one(nskb, vlan, eth,
> mode == MACVLAN_MODE_BRIDGE);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/4] atm: solos-pci: Add AnnexA/M capability attributes
From: David Miller @ 2011-10-05 21:50 UTC (permalink / raw)
To: nathan; +Cc: netdev, linux-atm-general, dwmw2, linux-kernel
In-Reply-To: <1317789810.2424.82.camel@dualcore.traverse>
From: Nathan Williams <nathan@traverse.com.au>
Date: Wed, 05 Oct 2011 15:43:30 +1100
> BisACapability and BisMCapability allow users to
> force either Annex A or Annex M.
>
> Signed-off-by: Nathan Williams <nathan@traverse.com.au>
David, Nathan's patches look fine to me, want me to stick them into
net-next?
^ permalink raw reply
* Re: IPv4 multicast and mac-vlans acting weird on 3.0.4+
From: Eric Dumazet @ 2011-10-05 21:36 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4E8CC474.7050803@candelatech.com>
Le mercredi 05 octobre 2011 à 13:56 -0700, Ben Greear a écrit :
> Wouldn't you have the same problem with two real Ethernet interfaces on
> the same LAN, or two 802.1Q devices for that matter? The addrs will all
> be the same in that case too?
>
Usually multicast is coupled with routing.
A JOIN message from your app wont be sent on all interfaces...
But yes, we might have a similar issue with regular vlans.
Probably nobody noticed yet. Just say no to fragments :)
> Also, if I have just a single mac-vlan active (the other 3 are 'ifconfig foo down'),
> I still see the problem with mcast.
>
Thats another bug : macvlan doesnt test IFF_UP on broadcasts, only for
unicast messages. Please test following patch.
> From what you describe, I am thinking I may be hitting a different
> issue. Any ideas on how to figure out why exactly the NF_HOOK isn't
> calling the ip_rcv_finish method?
>
Really I believe I tried to explain the thing already...
ip_local_deliver() -> ip_defrag() :
[PATCH] macvlan: dont send frames on DOWN devices
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index b100c90..94a0282 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -145,7 +145,8 @@ static void macvlan_broadcast(struct sk_buff *skb,
hlist_for_each_entry_rcu(vlan, n, &port->vlan_hash[i], hlist) {
if (vlan->dev == src || !(vlan->mode & mode))
continue;
-
+ if (!(vlan->dev->flags & IFF_UP))
+ continue;
nskb = skb_clone(skb, GFP_ATOMIC);
err = macvlan_broadcast_one(nskb, vlan, eth,
mode == MACVLAN_MODE_BRIDGE);
^ permalink raw reply related
* Re: [PATCH 0/8] skb fragment API: convert network drivers (part IV)
From: David Miller @ 2011-10-05 21:36 UTC (permalink / raw)
To: Ian.Campbell; +Cc: netdev, gregkh
In-Reply-To: <1317810511.21903.204.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 5 Oct 2011 11:28:30 +0100
> The following series converts a forth batch of network drivers to the
> SKB pages fragment API introduced in 131ea6675c76.
>
> There are two drivers/staging patches in here. I'm not sure who normally
> takes these, I'm sure you guys know though.
>
> After this batch there are ~4 drivers which need a little more thought
> (the inevitable fifth out of four series...). Specifically these drivers
> will switch from skb_frag_t -> struct subpage (which I am going to
> introduce shortly) in their internal data structures, this will isolate
> them from changes to skb_frag_t coming from the network core.
All applied with the mentioned vxge adjustments, thanks Ian.
^ permalink raw reply
* Re: [PATCH 1/8] vxge: convert to SKB paged frag API.
From: David Miller @ 2011-10-05 21:32 UTC (permalink / raw)
To: mirqus; +Cc: ian.campbell, netdev, jdmason
In-Reply-To: <CAHXqBFKX5eojLMhT1MW1inAUH9cfVne4-rhDQYSLsUh-OTzuPQ@mail.gmail.com>
From: Michał Mirosław <mirqus@gmail.com>
Date: Wed, 5 Oct 2011 23:03:27 +0200
> 2011/10/5 Ian Campbell <ian.campbell@citrix.com>:
> [...]
>> --- a/drivers/net/ethernet/neterion/vxge/vxge-main.c
>> +++ b/drivers/net/ethernet/neterion/vxge/vxge-main.c
>> @@ -923,9 +923,9 @@ vxge_xmit(struct sk_buff *skb, struct net_device *dev)
>> if (!frag->size)
>> continue;
>>
>> - dma_pointer = (u64) pci_map_page(fifo->pdev, frag->page,
>> - frag->page_offset, frag->size,
>> - PCI_DMA_TODEVICE);
>> + dma_pointer = (u64)skb_frag_dma_map(&fifo->pdev->dev, frag,
>> + 0, frag->size,
>> + PCI_DMA_TODEVICE);
>
> This should be DMA_TO_DEVICE instead of PCI_DMA_TODEVICE.
>
>>
>> if (unlikely(pci_dma_mapping_error(fifo->pdev, dma_pointer)))
>> goto _exit2;
>
> I would also change this to dma_mapping_error() in one go.
>
> Just a random patch check.
I'll make these adjustments when I apply this patch, thanks.
^ permalink raw reply
* [PATCH v2 1/2] PCI: Add Solarflare vendor ID and SFC4000 device IDs
From: Ben Hutchings @ 2011-10-05 21:28 UTC (permalink / raw)
To: Jesse Barnes; +Cc: netdev, linux-pci, linux-net-drivers
These will be shared between the sfc driver and a PCI quirk.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/efx.c | 10 ++++++----
drivers/net/sfc/efx.h | 4 ----
drivers/net/sfc/falcon.c | 3 ++-
drivers/net/sfc/falcon_boards.c | 3 ++-
include/linux/pci_ids.h | 5 +++++
5 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index b59abc7..f8b9be3 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -2197,13 +2197,15 @@ void efx_schedule_reset(struct efx_nic *efx, enum reset_type type)
/* PCI device ID table */
static DEFINE_PCI_DEVICE_TABLE(efx_pci_table) = {
- {PCI_DEVICE(EFX_VENDID_SFC, FALCON_A_P_DEVID),
+ {PCI_DEVICE(PCI_VENDOR_ID_SOLARFLARE,
+ PCI_DEVICE_ID_SOLARFLARE_SFC4000A_0),
.driver_data = (unsigned long) &falcon_a1_nic_type},
- {PCI_DEVICE(EFX_VENDID_SFC, FALCON_B_P_DEVID),
+ {PCI_DEVICE(PCI_VENDOR_ID_SOLARFLARE,
+ PCI_DEVICE_ID_SOLARFLARE_SFC4000B),
.driver_data = (unsigned long) &falcon_b0_nic_type},
- {PCI_DEVICE(EFX_VENDID_SFC, BETHPAGE_A_P_DEVID),
+ {PCI_DEVICE(PCI_VENDOR_ID_SOLARFLARE, BETHPAGE_A_P_DEVID),
.driver_data = (unsigned long) &siena_a0_nic_type},
- {PCI_DEVICE(EFX_VENDID_SFC, SIENA_A_P_DEVID),
+ {PCI_DEVICE(PCI_VENDOR_ID_SOLARFLARE, SIENA_A_P_DEVID),
.driver_data = (unsigned long) &siena_a0_nic_type},
{0} /* end of list */
};
diff --git a/drivers/net/sfc/efx.h b/drivers/net/sfc/efx.h
index b0d1209..c7e7523 100644
--- a/drivers/net/sfc/efx.h
+++ b/drivers/net/sfc/efx.h
@@ -15,10 +15,6 @@
#include "filter.h"
/* PCI IDs */
-#define EFX_VENDID_SFC 0x1924
-#define FALCON_A_P_DEVID 0x0703
-#define FALCON_A_S_DEVID 0x6703
-#define FALCON_B_P_DEVID 0x0710
#define BETHPAGE_A_P_DEVID 0x0803
#define SIENA_A_P_DEVID 0x0813
diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index 94bf4aa..9334b59 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -1424,7 +1424,8 @@ static int falcon_probe_nic(struct efx_nic *efx)
}
dev = pci_dev_get(efx->pci_dev);
- while ((dev = pci_get_device(EFX_VENDID_SFC, FALCON_A_S_DEVID,
+ while ((dev = pci_get_device(PCI_VENDOR_ID_SOLARFLARE,
+ PCI_DEVICE_ID_SOLARFLARE_SFC4000A_1,
dev))) {
if (dev->bus == efx->pci_dev->bus &&
dev->devfn == efx->pci_dev->devfn + 1) {
diff --git a/drivers/net/sfc/falcon_boards.c b/drivers/net/sfc/falcon_boards.c
index b9cc846..6cc16b8 100644
--- a/drivers/net/sfc/falcon_boards.c
+++ b/drivers/net/sfc/falcon_boards.c
@@ -764,7 +764,8 @@ int falcon_probe_board(struct efx_nic *efx, u16 revision_info)
if (board->type) {
netif_info(efx, probe, efx->net_dev, "board is %s rev %c%d\n",
- (efx->pci_dev->subsystem_vendor == EFX_VENDID_SFC)
+ (efx->pci_dev->subsystem_vendor ==
+ PCI_VENDOR_ID_SOLARFLARE)
? board->type->ref_model : board->type->gen_type,
'A' + board->major, board->minor);
return 0;
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ae96bbe..1679ff6 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2302,6 +2302,11 @@
#define PCI_DEVICE_ID_RENESAS_SH7785 0x0007
#define PCI_DEVICE_ID_RENESAS_SH7786 0x0010
+#define PCI_VENDOR_ID_SOLARFLARE 0x1924
+#define PCI_DEVICE_ID_SOLARFLARE_SFC4000A_0 0x0703
+#define PCI_DEVICE_ID_SOLARFLARE_SFC4000A_1 0x6703
+#define PCI_DEVICE_ID_SOLARFLARE_SFC4000B 0x0710
+
#define PCI_VENDOR_ID_TDI 0x192E
#define PCI_DEVICE_ID_TDI_EHCI 0x0101
--
1.7.4.4
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ 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