* [PATCH 0/3 net-2.6] bnx2x: Backporting BE fixes from net-next
From: Vladislav Zolotarov @ 2010-12-12 14:11 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein, Ben Hutchings
Backporting the fix for a broken 57712 LSO code as for Ben's
suggestions. Also fixing the same compilation warning that has been
fixed in the net-next.
thanks,
vlad
^ permalink raw reply
* [PATCH net-2.6 1/3] bnx2x: LSO code was broken on BE platforms
From: Vladislav Zolotarov @ 2010-12-12 14:11 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein
Make the LSO code work on BE platforms: parsing_data field of
a parsing BD (PBD) for 57712 was improperly composed which made FW read wrong
values for TCP header's length and offset and, as a result, the corresponding
PCI device was performing bad DMA reads triggering EEH.
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 42 +++++++++++++++++++++++++---------------
1 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 94d5f59..0af361e 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -1782,15 +1782,15 @@ exit_lbl:
}
#endif
-static inline void bnx2x_set_pbd_gso_e2(struct sk_buff *skb,
- struct eth_tx_parse_bd_e2 *pbd,
- u32 xmit_type)
+static inline void bnx2x_set_pbd_gso_e2(struct sk_buff *skb, u32 *parsing_data,
+ u32 xmit_type)
{
- pbd->parsing_data |= cpu_to_le16(skb_shinfo(skb)->gso_size) <<
- ETH_TX_PARSE_BD_E2_LSO_MSS_SHIFT;
+ *parsing_data |= (skb_shinfo(skb)->gso_size <<
+ ETH_TX_PARSE_BD_E2_LSO_MSS_SHIFT) &
+ ETH_TX_PARSE_BD_E2_LSO_MSS;
if ((xmit_type & XMIT_GSO_V6) &&
(ipv6_hdr(skb)->nexthdr == NEXTHDR_IPV6))
- pbd->parsing_data |= ETH_TX_PARSE_BD_E2_IPV6_WITH_EXT_HDR;
+ *parsing_data |= ETH_TX_PARSE_BD_E2_IPV6_WITH_EXT_HDR;
}
/**
@@ -1835,15 +1835,15 @@ static inline void bnx2x_set_pbd_gso(struct sk_buff *skb,
* @return header len
*/
static inline u8 bnx2x_set_pbd_csum_e2(struct bnx2x *bp, struct sk_buff *skb,
- struct eth_tx_parse_bd_e2 *pbd,
- u32 xmit_type)
+ u32 *parsing_data, u32 xmit_type)
{
- pbd->parsing_data |= cpu_to_le16(tcp_hdrlen(skb)/4) <<
- ETH_TX_PARSE_BD_E2_TCP_HDR_LENGTH_DW_SHIFT;
+ *parsing_data |= ((tcp_hdrlen(skb)/4) <<
+ ETH_TX_PARSE_BD_E2_TCP_HDR_LENGTH_DW_SHIFT) &
+ ETH_TX_PARSE_BD_E2_TCP_HDR_LENGTH_DW;
- pbd->parsing_data |= cpu_to_le16(((unsigned char *)tcp_hdr(skb) -
- skb->data) / 2) <<
- ETH_TX_PARSE_BD_E2_TCP_HDR_START_OFFSET_W_SHIFT;
+ *parsing_data |= ((((u8 *)tcp_hdr(skb) - skb->data) / 2) <<
+ ETH_TX_PARSE_BD_E2_TCP_HDR_START_OFFSET_W_SHIFT) &
+ ETH_TX_PARSE_BD_E2_TCP_HDR_START_OFFSET_W;
return skb_transport_header(skb) + tcp_hdrlen(skb) - skb->data;
}
@@ -1912,6 +1912,7 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
struct eth_tx_bd *tx_data_bd, *total_pkt_bd = NULL;
struct eth_tx_parse_bd_e1x *pbd_e1x = NULL;
struct eth_tx_parse_bd_e2 *pbd_e2 = NULL;
+ u32 pbd_e2_parsing_data = 0;
u16 pkt_prod, bd_prod;
int nbd, fp_index;
dma_addr_t mapping;
@@ -2033,8 +2034,9 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
memset(pbd_e2, 0, sizeof(struct eth_tx_parse_bd_e2));
/* Set PBD in checksum offload case */
if (xmit_type & XMIT_CSUM)
- hlen = bnx2x_set_pbd_csum_e2(bp,
- skb, pbd_e2, xmit_type);
+ hlen = bnx2x_set_pbd_csum_e2(bp, skb,
+ &pbd_e2_parsing_data,
+ xmit_type);
} else {
pbd_e1x = &fp->tx_desc_ring[bd_prod].parse_bd_e1x;
memset(pbd_e1x, 0, sizeof(struct eth_tx_parse_bd_e1x));
@@ -2076,10 +2078,18 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
bd_prod = bnx2x_tx_split(bp, fp, tx_buf, &tx_start_bd,
hlen, bd_prod, ++nbd);
if (CHIP_IS_E2(bp))
- bnx2x_set_pbd_gso_e2(skb, pbd_e2, xmit_type);
+ bnx2x_set_pbd_gso_e2(skb, &pbd_e2_parsing_data,
+ xmit_type);
else
bnx2x_set_pbd_gso(skb, pbd_e1x, xmit_type);
}
+
+ /* Set the PBD's parsing_data field if not zero
+ * (for the chips newer than 57711).
+ */
+ if (pbd_e2_parsing_data)
+ pbd_e2->parsing_data = cpu_to_le32(pbd_e2_parsing_data);
+
tx_data_bd = (struct eth_tx_bd *)tx_start_bd;
/* Handle fragmented skb */
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC][PATCH] Export DNSSL RA option to userspace
From: Pierre Ossman @ 2010-12-12 14:07 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <20101212144300.68e0fb16@mjolnir.ossman.eu>
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
I've also noticed a problem in the nduseropt code that I'm not sure how
to solve (given that this is now a stable userspace interface). Both
RFC5006 and RFC6106 state the following:
Note: An RDNSS address or a DNSSL domain name MUST be used only as
long as both the RA router Lifetime (advertised by a Router
Advertisement message [RFC4861]) and the corresponding option
Lifetime have not expired.
But the RA router lifetime is not included in the information sent.
Normally this is probably not an issue as the RDNSS and DNSSL lifetime
will be shorter than the router lifetime. One exception is when the
router is disabled at which point it will send a RA with router
lifetime to 0 (RFC4861 section 6.2.5). That means userspace will not be
informed that the DNS information should be removed immediately*.
Is there any way we can safely extend the interface with this
information? I'm not familiar enough with it myself yet to determine if
it's possible...
* Unless the router has a workaround for this client bug and also sets
RDNSS and DNSSL lifetimes to 0 as part of the final message.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by FRA, a
Swedish intelligence agency. Make sure your server uses
encryption for SMTP traffic and consider using PGP for
end-to-end encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/4] bnx2x: LSO code was broken on BE platforms
From: Vladislav Zolotarov @ 2010-12-12 13:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Dave Miller, netdev list, Eilon Greenstein
In-Reply-To: <1292127293.3136.261.camel@localhost>
> This fix looks like it should go into the stable/longterm series. Since
> this driver has changed a lot since 2.6.32, you would need to provide a
> backported patch for that.
Ben, u r right. I'm preparing a similar patch series for net-2.6 at the
moment. Since the broken code was 57712 only, the only "stable" version
affected is a current net-2.6.
thanks,
vlad
^ permalink raw reply
* [RFC][PATCH] Export all RA options that we don't handle to userspace
From: Pierre Ossman @ 2010-12-12 13:47 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <20101212144300.68e0fb16@mjolnir.ossman.eu>
[-- Attachment #1.1: Type: text/plain, Size: 897 bytes --]
Second patch that exports everything. If noone objects to this model,
then merge the two patches and just use the commit message from the
second one.
Pros:
- Kernel doesn't need to be updated for every new RA option that might
show up.
Cons:
- Possible security issue if it requires less privilege to read these
netlink messages than to open a raw ICMPv6 socket.
- List of types the kernel is interested in is now in two places in the
code, creating a risk for getting out of sync. I tried to come up
with a structure that would prevent this, but couldn't think of
anything that wouldn't require large changes. Ideas welcome...
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by FRA, a
Swedish intelligence agency. Make sure your server uses
encryption for SMTP traffic and consider using PGP for
end-to-end encryption.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0002-ipv6-give-userspace-all-RA-options-that-we-do-not-ca.patch --]
[-- Type: text/x-patch, Size: 2561 bytes --]
From 00cdbb6f65ad4c8d71aec12a615a83aeedcf541c Mon Sep 17 00:00:00 2001
From: Pierre Ossman <pierre@ossman.eu>
Date: Sun, 12 Dec 2010 12:49:29 +0100
Subject: [PATCH 2/2] ipv6: give userspace all RA options that we do not care about
Instead of having to update the kernel for every new RA option that needs
to be dealt with in userspace, just send over everything that we don't
handle ourselves in the kernel.
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
---
net/ipv6/ndisc.c | 38 +++++++++++++++++++-------------------
1 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index c5b01e3..192e90b 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -233,12 +233,17 @@ static struct nd_opt_hdr *ndisc_next_option(struct nd_opt_hdr *cur,
static inline int ndisc_is_useropt(struct nd_opt_hdr *opt)
{
+ /* Keep in sync with ndisc_parse_options() ! */
switch (opt->nd_opt_type) {
- case ND_OPT_RDNSS:
- case ND_OPT_DNSSL:
- return 1;
- default:
+ case ND_OPT_SOURCE_LL_ADDR:
+ case ND_OPT_TARGET_LL_ADDR:
+ case ND_OPT_MTU:
+ case ND_OPT_REDIRECT_HDR:
+ case ND_OPT_PREFIX_INFO:
+ case ND_OPT_ROUTE_INFO:
return 0;
+ default:
+ return 1;
}
}
@@ -268,6 +273,7 @@ static struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
l = nd_opt->nd_opt_len << 3;
if (opt_len < l || l == 0)
return NULL;
+ /* Keep in sync with ndisc_is_useropt() ! */
switch (nd_opt->nd_opt_type) {
case ND_OPT_SOURCE_LL_ADDR:
case ND_OPT_TARGET_LL_ADDR:
@@ -295,21 +301,15 @@ static struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
break;
#endif
default:
- if (ndisc_is_useropt(nd_opt)) {
- ndopts->nd_useropts_end = nd_opt;
- if (!ndopts->nd_useropts)
- ndopts->nd_useropts = nd_opt;
- } else {
- /*
- * Unknown options must be silently ignored,
- * to accommodate future extension to the
- * protocol.
- */
- ND_PRINTK2(KERN_NOTICE
- "%s(): ignored unsupported option; type=%d, len=%d\n",
- __func__,
- nd_opt->nd_opt_type, nd_opt->nd_opt_len);
- }
+ /*
+ * Unknown options must be silently ignored,
+ * to accommodate future extension to the
+ * protocol. We also provide them to userspace
+ * for things like DNS configuration.
+ */
+ ndopts->nd_useropts_end = nd_opt;
+ if (!ndopts->nd_useropts)
+ ndopts->nd_useropts = nd_opt;
}
opt_len -= l;
nd_opt = ((void *)nd_opt) + l;
--
1.7.2.3
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]
^ permalink raw reply related
* [RFC][PATCH] Export DNSSL RA option to userspace
From: Pierre Ossman @ 2010-12-12 13:43 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]
RFC 6106 specifies a new RA option for DNS resolver configuration that
therefore needs to end up in userspace.
This first patch just exports the new option, but I started thinking
that this seems overly complex that the kernel needs to be updated
every time there is something new of interest to userspace in the RA.
So I also have a second patch that exports everything that the kernel
doesn't want.
Patches only compile tested so far as I'm still hacking away at
userspace. Comments very much welcome though.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by FRA, a
Swedish intelligence agency. Make sure your server uses
encryption for SMTP traffic and consider using PGP for
end-to-end encryption.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-ipv6-export-DNS-search-list-option-to-userspace.patch --]
[-- Type: text/x-patch, Size: 1544 bytes --]
From a5b60e80eeed87763c811ecfb0d7aa5695d0a2bf Mon Sep 17 00:00:00 2001
From: Pierre Ossman <pierre@ossman.eu>
Date: Sun, 12 Dec 2010 00:06:48 +0100
Subject: [PATCH 1/2] ipv6: export DNS search list option to userspace
Like DNS resolver addresses, the suffixes to be used in DNS lookups need
to be configured by userspace. Make sure userspace has access to the
option containing that information.
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
---
include/net/ndisc.h | 3 ++-
net/ipv6/ndisc.c | 8 +++++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/net/ndisc.h b/include/net/ndisc.h
index 895997b..9c8698a 100644
--- a/include/net/ndisc.h
+++ b/include/net/ndisc.h
@@ -33,7 +33,8 @@ enum {
ND_OPT_MTU = 5, /* RFC2461 */
__ND_OPT_ARRAY_MAX,
ND_OPT_ROUTE_INFO = 24, /* RFC4191 */
- ND_OPT_RDNSS = 25, /* RFC5006 */
+ ND_OPT_RDNSS = 25, /* RFC5006 / RFC6106 */
+ ND_OPT_DNSSL = 31, /* RFC6106 */
__ND_OPT_MAX
};
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 58841c4..c5b01e3 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -233,7 +233,13 @@ static struct nd_opt_hdr *ndisc_next_option(struct nd_opt_hdr *cur,
static inline int ndisc_is_useropt(struct nd_opt_hdr *opt)
{
- return (opt->nd_opt_type == ND_OPT_RDNSS);
+ switch (opt->nd_opt_type) {
+ case ND_OPT_RDNSS:
+ case ND_OPT_DNSSL:
+ return 1;
+ default:
+ return 0;
+ }
}
static struct nd_opt_hdr *ndisc_next_useropt(struct nd_opt_hdr *cur,
--
1.7.2.3
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]
^ permalink raw reply related
* [RFC PATCH net-next 6/6] ethernet: Move Sun Cassini cassini.[ch]
From: Joe Perches @ 2010-12-12 12:03 UTC (permalink / raw)
To: David Miller, linux-kernel; +Cc: Jeff Kirsher, Paul Gortmaker, netdev
In-Reply-To: <cover.1292154142.git.joe@perches.com>
Move Sun Cassini files to ethernet directory.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/Kconfig | 8 --------
drivers/net/Makefile | 1 -
drivers/net/ethernet/Kconfig.10-100 | 8 ++++++++
drivers/net/ethernet/Makefile | 1 +
drivers/net/{ => ethernet}/cassini.c | 0
drivers/net/{ => ethernet}/cassini.h | 0
6 files changed, 9 insertions(+), 9 deletions(-)
rename drivers/net/{ => ethernet}/cassini.c (100%)
rename drivers/net/{ => ethernet}/cassini.h (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index fbae645..847dfbe 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -581,14 +581,6 @@ config SUNQE
To compile this driver as a module, choose M here: the module
will be called sunqe.
-config CASSINI
- tristate "Sun Cassini support"
- depends on PCI
- select CRC32
- help
- Support for the Sun Cassini chip, aka Sun GigaSwift Ethernet. See also
- <http://www.sun.com/products-n-solutions/hardware/docs/pdf/817-4341-10.pdf>
-
config SUNVNET
tristate "Sun Virtual Network support"
depends on SUN_LDOMS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 129aa08..3972e16 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -60,7 +60,6 @@ obj-$(CONFIG_SUNLANCE) += sunlance.o
obj-$(CONFIG_SUNQE) += sunqe.o
obj-$(CONFIG_SUNBMAC) += sunbmac.o
obj-$(CONFIG_MYRI_SBUS) += myri_sbus.o
-obj-$(CONFIG_CASSINI) += cassini.o
obj-$(CONFIG_SUNVNET) += sunvnet.o
obj-$(CONFIG_MACE) += mace.o
diff --git a/drivers/net/ethernet/Kconfig.10-100 b/drivers/net/ethernet/Kconfig.10-100
index f0430da..2bb39fc 100644
--- a/drivers/net/ethernet/Kconfig.10-100
+++ b/drivers/net/ethernet/Kconfig.10-100
@@ -23,6 +23,14 @@ config ETHOC
help
Say Y here if you want to use the OpenCores 10/100 Mbps Ethernet MAC.
+config CASSINI
+ tristate "Sun Cassini support"
+ depends on PCI
+ select CRC32
+ help
+ Support for the Sun Cassini chip, aka Sun GigaSwift Ethernet. See also
+ <http://www.sun.com/products-n-solutions/hardware/docs/pdf/817-4341-10.pdf>
+
config HAPPYMEAL
tristate "Sun Happy Meal 10/100baseT support"
depends on SBUS || PCI
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index d7c6304..bba207a 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_ETHOC) += ethoc.o
obj-$(CONFIG_HAPPYMEAL) += sunhme.o
obj-$(CONFIG_SUNGEM) += sungem.o sungem_phy.o
+obj-$(CONFIG_CASSINI) += cassini.o
diff --git a/drivers/net/cassini.c b/drivers/net/ethernet/cassini.c
similarity index 100%
rename from drivers/net/cassini.c
rename to drivers/net/ethernet/cassini.c
diff --git a/drivers/net/cassini.h b/drivers/net/ethernet/cassini.h
similarity index 100%
rename from drivers/net/cassini.h
rename to drivers/net/ethernet/cassini.h
--
1.7.3.3.398.g0b0cd.dirty
^ permalink raw reply related
* [RFC PATCH net-next 5/6] ethernet: Move Sun GEM sungem*.[ch]
From: Joe Perches @ 2010-12-12 12:03 UTC (permalink / raw)
To: David Miller, linux-kernel; +Cc: Jeff Kirsher, Paul Gortmaker, netdev
In-Reply-To: <cover.1292154142.git.joe@perches.com>
Move Sun GEM files to ethernet directory.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/Kconfig | 8 --------
drivers/net/Makefile | 1 -
drivers/net/ethernet/Kconfig.10-100 | 8 ++++++++
drivers/net/ethernet/Makefile | 1 +
drivers/net/{ => ethernet}/sungem.c | 0
drivers/net/{ => ethernet}/sungem.h | 0
drivers/net/{ => ethernet}/sungem_phy.c | 0
drivers/net/{ => ethernet}/sungem_phy.h | 0
8 files changed, 9 insertions(+), 9 deletions(-)
rename drivers/net/{ => ethernet}/sungem.c (100%)
rename drivers/net/{ => ethernet}/sungem.h (100%)
rename drivers/net/{ => ethernet}/sungem_phy.c (100%)
rename drivers/net/{ => ethernet}/sungem_phy.h (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 926f090..fbae645 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -581,14 +581,6 @@ config SUNQE
To compile this driver as a module, choose M here: the module
will be called sunqe.
-config SUNGEM
- tristate "Sun GEM support"
- depends on PCI
- select CRC32
- help
- Support for the Sun GEM chip, aka Sun GigabitEthernet/P 2.0. See also
- <http://www.sun.com/products-n-solutions/hardware/docs/pdf/806-3985-10.pdf>.
-
config CASSINI
tristate "Sun Cassini support"
depends on PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 8f2c0ee..129aa08 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -60,7 +60,6 @@ obj-$(CONFIG_SUNLANCE) += sunlance.o
obj-$(CONFIG_SUNQE) += sunqe.o
obj-$(CONFIG_SUNBMAC) += sunbmac.o
obj-$(CONFIG_MYRI_SBUS) += myri_sbus.o
-obj-$(CONFIG_SUNGEM) += sungem.o sungem_phy.o
obj-$(CONFIG_CASSINI) += cassini.o
obj-$(CONFIG_SUNVNET) += sunvnet.o
diff --git a/drivers/net/ethernet/Kconfig.10-100 b/drivers/net/ethernet/Kconfig.10-100
index dbb95d3..f0430da 100644
--- a/drivers/net/ethernet/Kconfig.10-100
+++ b/drivers/net/ethernet/Kconfig.10-100
@@ -35,3 +35,11 @@ config HAPPYMEAL
To compile this driver as a module, choose M here: the module
will be called sunhme.
+
+config SUNGEM
+ tristate "Sun GEM support"
+ depends on PCI
+ select CRC32
+ help
+ Support for the Sun GEM chip, aka Sun GigabitEthernet/P 2.0. See also
+ <http://www.sun.com/products-n-solutions/hardware/docs/pdf/806-3985-10.pdf>.
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 0daa85c..d7c6304 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -5,3 +5,4 @@
obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_ETHOC) += ethoc.o
obj-$(CONFIG_HAPPYMEAL) += sunhme.o
+obj-$(CONFIG_SUNGEM) += sungem.o sungem_phy.o
diff --git a/drivers/net/sungem.c b/drivers/net/ethernet/sungem.c
similarity index 100%
rename from drivers/net/sungem.c
rename to drivers/net/ethernet/sungem.c
diff --git a/drivers/net/sungem.h b/drivers/net/ethernet/sungem.h
similarity index 100%
rename from drivers/net/sungem.h
rename to drivers/net/ethernet/sungem.h
diff --git a/drivers/net/sungem_phy.c b/drivers/net/ethernet/sungem_phy.c
similarity index 100%
rename from drivers/net/sungem_phy.c
rename to drivers/net/ethernet/sungem_phy.c
diff --git a/drivers/net/sungem_phy.h b/drivers/net/ethernet/sungem_phy.h
similarity index 100%
rename from drivers/net/sungem_phy.h
rename to drivers/net/ethernet/sungem_phy.h
--
1.7.3.3.398.g0b0cd.dirty
^ permalink raw reply related
* [RFC PATCH net-next 4/6] ethernet: Move Sun Happymeal sunhme.[ch]
From: Joe Perches @ 2010-12-12 12:03 UTC (permalink / raw)
To: David Miller, linux-kernel; +Cc: Jeff Kirsher, Paul Gortmaker, netdev
In-Reply-To: <cover.1292154142.git.joe@perches.com>
Move Sun Happymeal files to ethernet directory.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/Kconfig | 13 -------------
drivers/net/Makefile | 1 -
drivers/net/ethernet/Kconfig.10-100 | 13 +++++++++++++
drivers/net/ethernet/Makefile | 1 +
drivers/net/{ => ethernet}/sunhme.c | 0
drivers/net/{ => ethernet}/sunhme.h | 0
6 files changed, 14 insertions(+), 14 deletions(-)
rename drivers/net/{ => ethernet}/sunhme.c (100%)
rename drivers/net/{ => ethernet}/sunhme.h (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c0716d9..926f090 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -558,19 +558,6 @@ config SUNLANCE
To compile this driver as a module, choose M here: the module
will be called sunlance.
-config HAPPYMEAL
- tristate "Sun Happy Meal 10/100baseT support"
- depends on SBUS || PCI
- select CRC32
- help
- This driver supports the "hme" interface present on most Ultra
- systems and as an option on older Sbus systems. This driver supports
- both PCI and Sbus devices. This driver also supports the "qfe" quad
- 100baseT device available in both PCI and Sbus configurations.
-
- To compile this driver as a module, choose M here: the module
- will be called sunhme.
-
config SUNBMAC
tristate "Sun BigMAC 10/100baseT support (EXPERIMENTAL)"
depends on SBUS && EXPERIMENTAL
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 0379639..8f2c0ee 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -56,7 +56,6 @@ obj-$(CONFIG_PLIP) += plip.o
obj-$(CONFIG_ROADRUNNER) += rrunner.o
-obj-$(CONFIG_HAPPYMEAL) += sunhme.o
obj-$(CONFIG_SUNLANCE) += sunlance.o
obj-$(CONFIG_SUNQE) += sunqe.o
obj-$(CONFIG_SUNBMAC) += sunbmac.o
diff --git a/drivers/net/ethernet/Kconfig.10-100 b/drivers/net/ethernet/Kconfig.10-100
index e4fa897..dbb95d3 100644
--- a/drivers/net/ethernet/Kconfig.10-100
+++ b/drivers/net/ethernet/Kconfig.10-100
@@ -22,3 +22,16 @@ config ETHOC
select BITREVERSE
help
Say Y here if you want to use the OpenCores 10/100 Mbps Ethernet MAC.
+
+config HAPPYMEAL
+ tristate "Sun Happy Meal 10/100baseT support"
+ depends on SBUS || PCI
+ select CRC32
+ help
+ This driver supports the "hme" interface present on most Ultra
+ systems and as an option on older Sbus systems. This driver supports
+ both PCI and Sbus devices. This driver also supports the "qfe" quad
+ 100baseT device available in both PCI and Sbus configurations.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sunhme.
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 6e419ed..0daa85c 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_ETHOC) += ethoc.o
+obj-$(CONFIG_HAPPYMEAL) += sunhme.o
diff --git a/drivers/net/sunhme.c b/drivers/net/ethernet/sunhme.c
similarity index 100%
rename from drivers/net/sunhme.c
rename to drivers/net/ethernet/sunhme.c
diff --git a/drivers/net/sunhme.h b/drivers/net/ethernet/sunhme.h
similarity index 100%
rename from drivers/net/sunhme.h
rename to drivers/net/ethernet/sunhme.h
--
1.7.3.3.398.g0b0cd.dirty
^ permalink raw reply related
* [RFC PATCH net-next 3/6] ethernet: Move dnet.[ch]
From: Joe Perches @ 2010-12-12 12:03 UTC (permalink / raw)
To: David Miller, linux-kernel; +Cc: Jeff Kirsher, Paul Gortmaker, netdev
In-Reply-To: <cover.1292154142.git.joe@perches.com>
Move dnet files to ethernet directory.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/Kconfig | 11 -----------
drivers/net/Makefile | 1 -
drivers/net/ethernet/Kconfig.10-100 | 11 +++++++++++
drivers/net/ethernet/Makefile | 1 +
drivers/net/{ => ethernet}/dnet.c | 0
drivers/net/{ => ethernet}/dnet.h | 0
6 files changed, 12 insertions(+), 12 deletions(-)
rename drivers/net/{ => ethernet}/dnet.c (100%)
rename drivers/net/{ => ethernet}/dnet.h (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ea9dbaf..c0716d9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1114,17 +1114,6 @@ config NI65
To compile this driver as a module, choose M here. The module
will be called ni65.
-config DNET
- tristate "Dave ethernet support (DNET)"
- depends on NET_ETHERNET && HAS_IOMEM
- select PHYLIB
- help
- The Dave ethernet interface (DNET) is found on Qong Board FPGA.
- Say Y to include support for the DNET chip.
-
- To compile this driver as a module, choose M here: the module
- will be called dnet.
-
source "drivers/net/tulip/Kconfig"
config AT1700
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 1265d0e..0379639 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -261,7 +261,6 @@ obj-$(CONFIG_GRETH) += greth.o
obj-$(CONFIG_XTENSA_XT2000_SONIC) += xtsonic.o
-obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_MACB) += macb.o
obj-$(CONFIG_S6GMAC) += s6gmac.o
diff --git a/drivers/net/ethernet/Kconfig.10-100 b/drivers/net/ethernet/Kconfig.10-100
index a5c62bc..e4fa897 100644
--- a/drivers/net/ethernet/Kconfig.10-100
+++ b/drivers/net/ethernet/Kconfig.10-100
@@ -2,6 +2,17 @@
# 10 Mb and 100Mb ethernet device configuration
#
+config DNET
+ tristate "Dave ethernet support (DNET)"
+ depends on NET_ETHERNET && HAS_IOMEM
+ select PHYLIB
+ help
+ The Dave ethernet interface (DNET) is found on Qong Board FPGA.
+ Say Y to include support for the DNET chip.
+
+ To compile this driver as a module, choose M here: the module
+ will be called dnet.
+
config ETHOC
tristate "OpenCores 10/100 Mbps Ethernet MAC support"
depends on NET_ETHERNET && HAS_IOMEM && HAS_DMA
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index ad2afc1..6e419ed 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -2,4 +2,5 @@
# Makefile for ethernet device drivers
#
+obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_ETHOC) += ethoc.o
diff --git a/drivers/net/dnet.c b/drivers/net/ethernet/dnet.c
similarity index 100%
rename from drivers/net/dnet.c
rename to drivers/net/ethernet/dnet.c
diff --git a/drivers/net/dnet.h b/drivers/net/ethernet/dnet.h
similarity index 100%
rename from drivers/net/dnet.h
rename to drivers/net/ethernet/dnet.h
--
1.7.3.3.398.g0b0cd.dirty
^ permalink raw reply related
* [RFC PATCH net-next 2/6] ethernet: Move ethoc.c
From: Joe Perches @ 2010-12-12 12:03 UTC (permalink / raw)
To: David Miller, linux-kernel; +Cc: Jeff Kirsher, Paul Gortmaker, netdev
In-Reply-To: <cover.1292154142.git.joe@perches.com>
Move ethernet Open Core file to ethernet directory.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/Kconfig | 10 ----------
drivers/net/Makefile | 1 -
drivers/net/ethernet/Kconfig.10-100 | 10 ++++++++++
drivers/net/ethernet/Makefile | 6 +-----
drivers/net/{ => ethernet}/ethoc.c | 0
5 files changed, 11 insertions(+), 16 deletions(-)
rename drivers/net/{ => ethernet}/ethoc.c (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c1d1be8..ea9dbaf 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1021,16 +1021,6 @@ config ENC28J60_WRITEVERIFY
Enable the verify after the buffer write useful for debugging purpose.
If unsure, say N.
-config ETHOC
- tristate "OpenCores 10/100 Mbps Ethernet MAC support"
- depends on NET_ETHERNET && HAS_IOMEM && HAS_DMA
- select MII
- select PHYLIB
- select CRC32
- select BITREVERSE
- help
- Say Y here if you want to use the OpenCores 10/100 Mbps Ethernet MAC.
-
config GRETH
tristate "Aeroflex Gaisler GRETH Ethernet MAC support"
depends on SPARC
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index bfb5ade..1265d0e 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -257,7 +257,6 @@ obj-$(CONFIG_PASEMI_MAC) += pasemi_mac_driver.o
pasemi_mac_driver-objs := pasemi_mac.o pasemi_mac_ethtool.o
obj-$(CONFIG_MLX4_CORE) += mlx4/
obj-$(CONFIG_ENC28J60) += enc28j60.o
-obj-$(CONFIG_ETHOC) += ethoc.o
obj-$(CONFIG_GRETH) += greth.o
obj-$(CONFIG_XTENSA_XT2000_SONIC) += xtsonic.o
diff --git a/drivers/net/ethernet/Kconfig.10-100 b/drivers/net/ethernet/Kconfig.10-100
index 8b1ee80..a5c62bc 100644
--- a/drivers/net/ethernet/Kconfig.10-100
+++ b/drivers/net/ethernet/Kconfig.10-100
@@ -1,3 +1,13 @@
#
# 10 Mb and 100Mb ethernet device configuration
#
+
+config ETHOC
+ tristate "OpenCores 10/100 Mbps Ethernet MAC support"
+ depends on NET_ETHERNET && HAS_IOMEM && HAS_DMA
+ select MII
+ select PHYLIB
+ select CRC32
+ select BITREVERSE
+ help
+ Say Y here if you want to use the OpenCores 10/100 Mbps Ethernet MAC.
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index f2aebec..ad2afc1 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -2,8 +2,4 @@
# Makefile for ethernet device drivers
#
-# Dummy object just to avoid breaking build
-# These comments and the line below will be deleted on the
-# first addition to this file
-
-obj-$(CONFIG_ETHERNET_DUMMY_DRIVER) += /dev/null/dummy.o
+obj-$(CONFIG_ETHOC) += ethoc.o
diff --git a/drivers/net/ethoc.c b/drivers/net/ethernet/ethoc.c
similarity index 100%
rename from drivers/net/ethoc.c
rename to drivers/net/ethernet/ethoc.c
--
1.7.3.3.398.g0b0cd.dirty
^ permalink raw reply related
* [RFC PATCH net-next 1/6] drivers/net: Add directory ethernet
From: Joe Perches @ 2010-12-12 12:03 UTC (permalink / raw)
To: David Miller, linux-kernel; +Cc: Jeff Kirsher, Paul Gortmaker, netdev
In-Reply-To: <cover.1292154142.git.joe@perches.com>
Add empty Kconfig files for various speeds and a no effect Makefile.
Modify drivers/net Kconfig and Makefile to include these new files.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/Kconfig | 6 ++++++
drivers/net/Makefile | 2 ++
drivers/net/ethernet/Kconfig.10-100 | 3 +++
drivers/net/ethernet/Kconfig.1000 | 3 +++
drivers/net/ethernet/Kconfig.10000 | 3 +++
drivers/net/ethernet/Makefile | 9 +++++++++
6 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/ethernet/Kconfig.10-100
create mode 100644 drivers/net/ethernet/Kconfig.1000
create mode 100644 drivers/net/ethernet/Kconfig.10000
create mode 100644 drivers/net/ethernet/Makefile
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index a20693f..c1d1be8 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -222,6 +222,8 @@ menuconfig NET_ETHERNET
if NET_ETHERNET
+source "drivers/net/ethernet/Kconfig.10-100"
+
config MACB
tristate "Atmel MACB support"
depends on HAVE_NET_MACB
@@ -2041,6 +2043,8 @@ menuconfig NETDEV_1000
if NETDEV_1000
+source "drivers/net/ethernet/Kconfig.1000"
+
config ACENIC
tristate "Alteon AceNIC/3Com 3C985/NetGear GA620 Gigabit support"
depends on PCI
@@ -2569,6 +2573,8 @@ menuconfig NETDEV_10000
if NETDEV_10000
+source "drivers/net/ethernet/Kconfig.10000"
+
config MDIO
tristate
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 652fc6b..bfb5ade 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -2,6 +2,8 @@
# Makefile for the Linux network (ethercard) device drivers.
#
+obj-y += ethernet/
+
obj-$(CONFIG_MII) += mii.o
obj-$(CONFIG_MDIO) += mdio.o
obj-$(CONFIG_PHYLIB) += phy/
diff --git a/drivers/net/ethernet/Kconfig.10-100 b/drivers/net/ethernet/Kconfig.10-100
new file mode 100644
index 0000000..8b1ee80
--- /dev/null
+++ b/drivers/net/ethernet/Kconfig.10-100
@@ -0,0 +1,3 @@
+#
+# 10 Mb and 100Mb ethernet device configuration
+#
diff --git a/drivers/net/ethernet/Kconfig.1000 b/drivers/net/ethernet/Kconfig.1000
new file mode 100644
index 0000000..f51b97c
--- /dev/null
+++ b/drivers/net/ethernet/Kconfig.1000
@@ -0,0 +1,3 @@
+#
+# 1 Gb ethernet device configuration
+#
diff --git a/drivers/net/ethernet/Kconfig.10000 b/drivers/net/ethernet/Kconfig.10000
new file mode 100644
index 0000000..a8e28fe
--- /dev/null
+++ b/drivers/net/ethernet/Kconfig.10000
@@ -0,0 +1,3 @@
+#
+# 10 Gb ethernet device configuration
+#
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
new file mode 100644
index 0000000..f2aebec
--- /dev/null
+++ b/drivers/net/ethernet/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for ethernet device drivers
+#
+
+# Dummy object just to avoid breaking build
+# These comments and the line below will be deleted on the
+# first addition to this file
+
+obj-$(CONFIG_ETHERNET_DUMMY_DRIVER) += /dev/null/dummy.o
--
1.7.3.3.398.g0b0cd.dirty
^ permalink raw reply related
* [RFC PATCH net-next 0/6] Start moving ethernet drivers to new directory
From: Joe Perches @ 2010-12-12 12:03 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Jeff Kirsher, Paul Gortmaker, linux-kernel
As discussed a few times, here's a start at moving various files
around in drivers/net to a new drivers/net/ethernet directory.
The general idea is to move one at a time compilation units
associated to the various subsystems in drivers/net, updating
the Kconfig and Makefile files.
I think this is a form that doesn't break the build, is reviewable
and acceptable and makes the top level drivers/net directory much
cleaner.
The biggest downsides of this move style are:
o high number of trivial commits so:
o serialization: it's best done by one person because the likelihood
of commit clash will be also be high.
o the order the entries in Kconfig are changed, so the order of entries
in menuconfig/xconfig is also changed.
An alternative to the high commit count is to collect many of these patches
together into a single commit.
If this approach is acceptable, I'll do all the unmaintained ethernet
subsystems in drivers/net in this style, followed by adding separate
subdirectories for 3com and 8390, moving tulip, then onto the various
vendor directories as appropriate.
Moving bonding, ppp, and such to different directories will be done
separately.
David, the Sun GEM and Cassini files are currently selected under the
10/100 menu. Shouldn't these be presented under the 1000Mb menu?
I didn't move them to that menu so all current configs should work,
but it'd be logically sensible to move the selection for these subsystems
to the 1000 menu though maybe that's not practical.
Comments?
Joe Perches (6):
drivers/net: Add directory ethernet
ethernet: Move ethoc.c
ethernet: Move dnet.[ch]
ethernet: Move Sun Happymeal sunhme.[ch]
ethernet: Move Sun GEM sungem*.[ch]
ethernet: Move Sun Cassini cassini.[ch]
drivers/net/Kconfig | 56 +++---------------------------
drivers/net/Makefile | 7 +---
drivers/net/ethernet/Kconfig.10-100 | 53 +++++++++++++++++++++++++++++
drivers/net/ethernet/Kconfig.1000 | 3 ++
drivers/net/ethernet/Kconfig.10000 | 3 ++
drivers/net/ethernet/Makefile | 9 +++++
drivers/net/{ => ethernet}/cassini.c | 0
drivers/net/{ => ethernet}/cassini.h | 0
drivers/net/{ => ethernet}/dnet.c | 0
drivers/net/{ => ethernet}/dnet.h | 0
drivers/net/{ => ethernet}/ethoc.c | 0
drivers/net/{ => ethernet}/sungem.c | 0
drivers/net/{ => ethernet}/sungem.h | 0
drivers/net/{ => ethernet}/sungem_phy.c | 0
drivers/net/{ => ethernet}/sungem_phy.h | 0
drivers/net/{ => ethernet}/sunhme.c | 0
drivers/net/{ => ethernet}/sunhme.h | 0
17 files changed, 76 insertions(+), 55 deletions(-)
create mode 100644 drivers/net/ethernet/Kconfig.10-100
create mode 100644 drivers/net/ethernet/Kconfig.1000
create mode 100644 drivers/net/ethernet/Kconfig.10000
create mode 100644 drivers/net/ethernet/Makefile
rename drivers/net/{ => ethernet}/cassini.c (100%)
rename drivers/net/{ => ethernet}/cassini.h (100%)
rename drivers/net/{ => ethernet}/dnet.c (100%)
rename drivers/net/{ => ethernet}/dnet.h (100%)
rename drivers/net/{ => ethernet}/ethoc.c (100%)
rename drivers/net/{ => ethernet}/sungem.c (100%)
rename drivers/net/{ => ethernet}/sungem.h (100%)
rename drivers/net/{ => ethernet}/sungem_phy.c (100%)
rename drivers/net/{ => ethernet}/sungem_phy.h (100%)
rename drivers/net/{ => ethernet}/sunhme.c (100%)
rename drivers/net/{ => ethernet}/sunhme.h (100%)
--
1.7.3.3.398.g0b0cd.dirty
^ permalink raw reply
* Re: [net-next 2/8] bnx2x: add select queue callback
From: Eilon Greenstein @ 2010-12-12 10:25 UTC (permalink / raw)
To: David Miller; +Cc: Dmitry Kravkov, netdev@vger.kernel.org, vladz
In-Reply-To: <20101210.141131.241939045.davem@davemloft.net>
On Fri, 2010-12-10 at 14:11 -0800, David Miller wrote:
> From: "Dmitry Kravkov" <dmitry@broadcom.com>
> Date: Thu, 9 Dec 2010 14:09:16 +0200
>
> > +#endif
> > + /* Select queue (if defined) adjust for fcoe */
> > + fp_index = skb_tx_hash(dev, skb) - FCOE_CONTEXT_USE;
> > +
> > + return (fp_index >= 0 ? fp_index : 0);
>
> This doesn't make any sense, and it's one of the reasons I really
> hate the fact that drivers sometimes need to override the
> select_queue method.
>
> Because 9 times out of 10 they get it wrong.
>
> You're mapping queues 0 --> FCOE_CONTEXT_USE to zero.
>
> But that's not what you actually want.
>
> You're actually trying to make non-FCOE traffic hash only amongst the
> non-FCOE queues.
>
> So make your code actually do that instead of screwing up the
> distribution of the hash result.
>
Indeed, the current suggestion is giving queue 0 double weight compared
to all other queues just so the skb_tx_hash will be used as is to
benefit from future enhancement changes to it. We will re-spin this
patch and move the content of the skb_tx_hash to __skb_tx_hash that will
receive the netdev->skb_real_num_tx_queues as a parameter - this way, we
can call the __skb_tx_hash with a lower number.
Thanks,
Eilon
^ permalink raw reply
* [GIT PULL net-2.6] vhost-net: logging fixup
From: Michael S. Tsirkin @ 2010-12-12 10:09 UTC (permalink / raw)
To: David Miller; +Cc: kvm, virtualization, netdev, linux-kernel, stable
Please merge the following fix for 2.6.37.
It is also applicable to -stable.
Thanks!
The following changes since commit a19faf0250e09b16cac169354126404bc8aa342b:
net: fix skb_defer_rx_timestamp() (2010-12-10 16:20:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net
Michael S. Tsirkin (1):
vhost: correctly set bits of dirty pages
drivers/vhost/vhost.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] net/r8169: Remove the firmware of RTL8111D
From: Ben Hutchings @ 2010-12-12 4:25 UTC (permalink / raw)
To: Hayes Wang; +Cc: romieu, netdev, linux-kernel
In-Reply-To: <1291619474-3244-1-git-send-email-hayeswang@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]
On Tue, 2010-12-07 at 15:19 +0000, Hayes Wang wrote:
> Remove the firmware of RTL8111D from the kernel.
> The binary file of firmware would be moved to linux-firmware repository.
> The firmwares are rtl_nic/rtl8168d-1.fw and rtl_nic/rtl8168d-2.fw.
> The driver would load the firmware through request_firmware. The driver
> would just go along if the firmware couldn't be found. However, it is
> suggested to be done with the suitable firmware.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> drivers/net/r8169.c | 796 ++++++++-------------------------------------------
> 1 files changed, 117 insertions(+), 679 deletions(-)
> mode change 100644 => 100755 drivers/net/r8169.c
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> old mode 100644
> new mode 100755
Please do not make source files executable.
> index 7d33ef4..e0df607
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
[...]
> +static void
> +rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
> +{
> + void __iomem *ioaddr = tp->mmio_addr;
> + u32 *phytable = (u32 *)fw->data;
This line should use __le32 not u32 to make it clearer which byte order
is being used.
> + u32 action;
> + size_t len = fw->size / sizeof(*phytable);
> + u32 regno, data;
> +
> + while (len-- > 0 && *phytable != 0) {
> + action = le32_to_cpu(*phytable);
> + regno = (action & 0x0FFF0000) >> 16;
> + data = action & 0x0000FFFF;
> +
> + switch(action & 0xF0000000) {
> + case PHY_WRITE:
> + mdio_write(ioaddr, regno, data);
> + phytable++;
> + break;
> + default:
> + netif_err(tp, probe, tp->dev,
> + "Unknown action 0x%08x\n", action);
> + return;
> + }
> + }
[...]
I think should validate the action types before starting. Otherwise it
could begin loading the firmware and then abort (without even returning
an error code) which would be worse than not loading it at all.
Other than that, this is good, especially the addition of comments for
some of the register initialisation sequences.
Ben.
--
Ben Hutchings, Debian Developer and kernel team member
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/4] bnx2x: LSO code was broken on BE platforms
From: Ben Hutchings @ 2010-12-12 4:14 UTC (permalink / raw)
To: Vladislav Zolotarov; +Cc: Dave Miller, netdev list, Eilon Greenstein
In-Reply-To: <1291808589.30114.65.camel@lb-tlvb-vladz>
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
On Wed, 2010-12-08 at 13:43 +0200, Vladislav Zolotarov wrote:
> Make the LSO code work on BE platforms: parsing_data field of
> a parsing BD (PBD) for 57712 was improperly composed which made FW read wrong
> values for TCP header's length and offset and, as a result, the corresponding
> PCI device was performing bad DMA reads triggering EEH.
[...]
This fix looks like it should go into the stable/longterm series. Since
this driver has changed a lot since 2.6.32, you would need to provide a
backported patch for that.
Ben.
--
Ben Hutchings, Debian Developer and kernel team member
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [RFC][net-next-2.6 PATCH 0/2] rtnetlink: New IFLA_PORT_PROTO_* attr
From: Stefan Berger @ 2010-12-12 3:16 UTC (permalink / raw)
To: netdev
In-Reply-To: <184D23435BECB444AB6B9D4630C8EC83BD7230@XMB-RCD-303.cisco.com>
"Christian Benvenuti (benve)" <benve@cisco.com> wrote on 12/11/2010 07:53:44 PM:
[posting via we page since my mail program puts html into the message]
>
> (*)
>
>
> >> So what you are saying is that libvirt should use #ifdef to
> >> distinguish between
> >>
> >> if_link.h/pre_new_attributes
> >> and
> >> if_link.h/new_attributes?
> >
> > Yes. It looks like you'll have to determine the availability in the
> > configure script and introduce a new #define there.
>
> (*2)
>
> I suppose that based on my comment (*) above, this should not be
> necessary because any kernel supported as of today will continue to
> work exactly the same way.
>
What I meant is that the user-level code (i.e., libvirt) with your new
attributes will only compile on a system that has their names in the
if_link.h. So, users that compile libvirt with a kernel that doesn't have
these new attributes in if_link.h should still be able to compile the
macvtap.c there, but will of course only get support for the old attributes,
which at least seem to be in working condition for 802.1Qbg. User who
compile libvirt with a new kernel should then get the support for the old
attributes and the new attributes compiled in. To cover these cases you'd
have to isolate the code dealing with the new attributes with for example
#ifdef NEW_8021QBGH_ATTRIBUTES
[...]
#endif
where the #define NEW_8021QBGH_ATTRIBUTES would be set through
libvirt's configure script that determines it by test-compiling a program
using one of the new attributes and set the #define if one of the new
attributes was found to be available.. Ideally your CLUSTER_UUID support
would not come too long after the first batch of new attributes, but would
be 'covered' with the NEW_8021QBGH_ATTRIBUTES. Along those lines, I hope you
won't have to introduce a VERY_NEW_8021QBGH_ATTRIBUTES #define to cover
anything coming even later.
> >> I guess this would be something similar to what
> >> doPortProfileOp8021Qbg (in src/util/macvtap.c) does by checking for
> >> IFLA_VF_PORT_MAX in order to distinguish between
> >> 8021Qbh/pre_port_profile and 8021Qbh/post_port_profile.
> >> Is it correct?
> >
> > Yes. If you provided the code for 802.1Qbh that'd be great.
>
> Based on my comment (*2) above we should not need to add any new #ifdef.
>
> >> Is this #ifdef based approach the right way to keep track of the
> >> if_link.h/IFLA_PORT_* changes?
> >
> >If there's a better way of doing this, let me know. The problem is
> >people compiling libvirt may have all kinds of different levels of
> >systems, without even macvtap, then with macvtap but without the first
> >set of attributes for port profiles etc. - The progress in the kernel
> >is reflected in the code with these #ifdefs... not nice, but I
> > doubt there's a better way of doing this.
>
> Well, “versioning” is not a default feature in (RT)Netlink, and other
> proposals (in slightly different contexts) got rejected in the past.
> (see for example: http://www.spinics.net/lists/netdev/msg127715.html)
>
> Since we are changing the attribute scheme, this could be the right
> moment to add versioning to the IFLA_PORT_* attributes group.
> We can consider the current one as being version 1 (or 0) and from
> now on increment the version by 1 each time we apply some changes to
> the IFLA_PORT_* attributes.
> The most likely changes that may take place would be the introduction
> of new attributes (the BH/BG protocols are still evolving).
> This is not the way Netlink is used normally (see Miller's comment
> in the URL I provided above), but it would make libvirt code much
> easier to update and we would not need to populate it with #ifdefs.
The thing is that you may have users compiling an application, i.e.,
libvirt, on systems with different versions of the kernel, and with
that the if_link.h, and those users may want to be able to follow the
application source tree and not necessarily the linux tree. After
updating the application source tree they should still get working
802.1Qbg/h support. So requirements on the underlying kernel shouldn't
just 'move'.
I wouldn't like it if I updated my libvirt tree and all of a sudden the
802.1Qbg/h support wouldn't work anymore, due to requirements for new
attributes in libvirt's macvtap.c, after a re-compile of libvirt. From
a libvirt programmer perspective *all* the attributes would *ideally*
appear from one kernel version to the other. So if one kernel version
provides working support for 802.1Qbg/h I would want to be able to follow the
libvirt tree without having to upgrade the kernel. So that's why I am
proposing the #ifdef's around nearly each step of new attributes being added
in the if_link.h, assuming that at each step the technology was working
and new attributes only make it work 'better' than before.
>
> The presence of the version would not be an excuse to be allowed to
> make bad changes to the attributes knowing that you can fix them
> later with a newer version (I agree with Miller's comment), but
> simply to help consumers (ie libvirt in this case) to determine
> what level of if_link.h/IFLA_PORT_* they are dealing with, at
> run/time (the idea is that of offering a GET for that version number).
It's fine by me if we end up sending a message containing old and
new attributes. For dealing with the responses we will have to start
looking for the newest attributes first, then go backwards towards the
first ones. Knowing the version of the supported attributes we could
invoke specific code for the attributes that are expected to be supported.
So I think knowing the version would be advantageous in interpreting
the responses from the kernel.
Nevertheless I would go through the complication of #ifdef'ing
each new major step of new attributes in the libvirt code...
>
> Right now (RT)Netlink silently ignores the attributes it does not
> understand (ie, type > maxtype), therefore there are no other
> mechanisms for determining at run-time what version of the attribute
> list the kernel/recipient understands.
>
> >> We may need to change if_link.h again, for example to add new
> >> IFLA_PORT_* attributes.
> >> Does it mean that in libvirt we will have to add an #ifdef each time?
> >
> >I think so, yes. And since they are enums (rather than #define's
> >themselves) you'll have to introduce the #define's name and probe for
> >it by trying to compiling something with it in the configure script.
>
> If this is the only option, we can go for that. No problem. We will
> submit the libvirt patches.
>
> If however the versioning scheme was accepted, the libvirt code would
> be cleaner and easier to maintain.
I agree.
> Before to discard this option I would like someone on netdev to
> comment on that.
> Dave, can you confirm us that versioning the IFLA_PORT_* attributes
> (not the all if_link.h header) is not an option?
> >
> >802.1Qbh support has been in libvirt for quite a while. I assume it
> >worked without the CLUSTER_UUID attribute that you are introducing only
> >now. I have no 802.1Qbh hardware to verify this, though.
>
> Yes, it worked because so far port profiles were global. Now we would
> like to use the concept of CLUSTER_UUID (already in use by most VMM)
> to scope port profiles. This way we can limit the scope of a port
> profile to those hosts belonging to a given cluster.
>
> The main purpose of the kernel patches we submitted was to cleanup
> the attribute scheme used for BH/BG, and at the same time make it
> easier to add new attributes if/when needed.
> However, this should not come at the cost of making libvirt support
> a nightmare (#ifdef, etc).
The complication comes through *following* an evolving standard rather
than having the *ideal* case where we go from darkness to light from one
kernel version to another -- or make support for the new technology
only public once it's done.
> To me it looks like
>
> (1) sending both legacy and new attributes
> +
> (2) using a versioning scheme for the IFLA_PORT_* attributes
>
> make it easy/clean for libvirt to adapt to the underlying kernel
> version (ie, if_link.h/IFLA_PORT_* version).
>
> - Because of (1) above we are not breaking any current user of the
> IFLA_PORT_* attributes.
>
> - (2) above is optional but it would make updating libvirt easier.
>
> Again, if #ifdef is the only option, we will stick to it.
Ok.
>
> Do you have any comment on the optional attribute IFLA_PORT_DATA
> I proposed in PATCH 0/2 section 8 (at the end of the post)?
To quote from there:
"This attribute would allow the use of extra attributes that are not part of
the official protocol specs (802.1Qbg/bh for now) or simply allow device
drivers to start supporting pre-standard parameters that would not be included
in the Netlink scheme before they reach some stability."
Hm, does this sound like an 'experimental' attribute that can change over time
('some stability')? I hope not, because otherwise you may have mismatches
between what libvirt assumes it needs to pass versus what the evolving device
driver expects. If so, we would have to go as far as determining the version of
the device driver to match up libvirt code against it (?).
Regards
Stefan
>
> Thanks
> /Christian
>
^ permalink raw reply
* [PATCH] net: delete expired route in ip6_pmtu_deliver
From: Andrey Vagin @ 2010-12-12 1:20 UTC (permalink / raw)
To: David S. Miller; +Cc: avagin, netdev, linux-kernel
The first big packets sent to a "low-MTU" client correctly
triggers the creation of a temporary route containing the reduced MTU.
But after the temporary route has expired, new ICMP6 "packet too big"
will be sent, rt6_pmtu_discovery will find the previous EXPIRED route
check that its mtu isn't bigger then in icmp packet and do nothing
before the temporary route will not deleted by gc.
I make the simple experiment:
while :; do
time ( dd if=/dev/zero bs=10K count=1 | ssh hostname dd of=/dev/null ) || break;
done
The "time" reports real 0m0.197s if a temporary route isn't expired, but
it reports real 0m52.837s (!!!!) immediately after a temporare route has
expired.
Cc: stable@kernel.org
Signed-off-by: Andrey Vagin <avagin@openvz.org>
---
net/ipv6/route.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 96455ffb..7659d6f 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1565,11 +1565,16 @@ static void rt6_do_pmtu_disc(struct in6_addr *daddr, struct in6_addr *saddr,
{
struct rt6_info *rt, *nrt;
int allfrag = 0;
-
+again:
rt = rt6_lookup(net, daddr, saddr, ifindex, 0);
if (rt == NULL)
return;
+ if (rt6_check_expired(rt)) {
+ ip6_del_rt(rt);
+ goto again;
+ }
+
if (pmtu >= dst_mtu(&rt->dst))
goto out;
--
1.7.2.1
^ permalink raw reply related
* RE: [RFC][net-next-2.6 PATCH 0/2] rtnetlink: New IFLA_PORT_PROTO_* attr
From: Christian Benvenuti (benve) @ 2010-12-12 0:53 UTC (permalink / raw)
To: Stefan Berger
Cc: netdev, chrisw, arnd, David Miller, Roopa Prabhu (roprabhu),
David Wang (dwang2)
In-Reply-To: <loom.20101209T141255-700@post.gmane.org>
Hi,
>> >> The following series add the new IFLA_PORT_PROTO_* nested protocol
>> >> attributes to rtnetlink and it updates the enic driver to support
>> >> them.
>> >>
>> >> 01/2 - Add new protocol nested IFLA_PORT_PROTO_* attrs
>> >> 02/2 - Update enic driver to support new IFLA_PORT_PROTO_* attrs
>> >>
>> >> Signed-off-by: Christian Benvenuti <benve <at> cisco.com>
>> >> Signed-off-by: Roopa Prabhu <roprabhu <at> cisco.com>
>> >> Signed-off-by: David Wang <dwang2 <at> cisco.com>
>> >>
>> > [...]
>> >
>> >> When the protocol nested attributes IFLA_PORT_PROTO_* will be
>> >> populated with new sub-attributes (like the CLUSTER_UUID we would
>> >> like to add), the user space clients will have to adapt to the new
>> >> attribute scheme if they want to be able to see/receive the new
>> >> attributes (like CLUSTER_UUID).
>>
>> >I don't have a problem with these changes. Just on the libvirt level
>> >it's going to be a lot more messy. We'll need another level of
>> >#ifdef's
>>
>> >for when these new attributes became available. In case they are
>> >there we should not just create the netlink messages with the new
>> >attributes but first independently probe for 802.1Qbg and 802.1Qbh
>> >for whether lldpad or the kernel respectively saw the same level of
>> >if_link.h include and/or support the new attributes and fall back to
>> >using the old ones in case the probing failed. That way we can
>> >support multi-boot
>>
>> >installations with kernels before and after these changes or an
>> >lldpad that doesn't support the new attributes and still give the
>> >user the experience that the starting of the VM 'works' as before
>> >(the new
>> kernel was installed).
>>
>> We will definitely take care of the libvirt changes necessary to
>> support this.
>> I can see two points in your comment above. Please correct me if I
>> did not understand them correctly:
>>
>> 1) libvirt compilation on multi-boot installations
>>
>> First let me verify if I understand what you mean by multi-boot
>> installations:
>>
>> systems where there are multiple kernel versions installed and
>> therefore where the running system may potentially be using
>> different if_link.h versions, with or without the new attributes
>> ("new" = replacements for the deprecated ones)
>>
>> Is this correct?
>
>Yes. The problem case would be a user (re-)compiles libvirt with
>support for the new attributes on the new kernel and then boots into
>the old one. The user would expect it to still work as before the
>re-compilation.
(*)
With our proposal it would work because, regardless of the kernel
version in use, libvirt would always send both old and new
attributes (and the kernel, if/when asked, would do the same).
For example, supposing the user wanted to configure a port
profile, libvirt would send (among the other attributes) the
following ones:
...
[IFLA_PORT_PROFILE] <-------------- OLD ONE
[IFLA_PORT_PROTO_8021QBH]
[IFLA_PORT_8021QBH_PROFILE] <--- NEW ONE ...
Note that the “NEW” attribute above does not add any new
functionality, and it does not replace the old/legacy one.
Those recipients that support the new attributes will look
for IFLA_PORT_8021QBH_PROFILE and, if not present, will
check for IFLA_PORT_PROFILE (if expected to work with older
kernels/apps).
Those recipients that only understand the old attributes will
only check for IFLA_PORT_PROFILE and will ignore completely
the new nested attr IFLA_PORT_PROTO_8021QBH (as per default
Netlink behavior).
The two attributes (old and new) carry the same exact piece
of information.
They only change the attribute scheme in order to make it
easier to maintain the attribute list:
it classifies attributes by protocol.
Once this change is in, we will propose the addition of new
(8021Qbh) attributes (ie, CLUSTER_UUID), but the patches
currently pending in netdev do not introduce them yet.
Any new attribute added after the changes proposed with these
patches will be available only using the new scheme.
(Note that we are deprecating only two attributes in the
IFLA_PORT_* enum)
>> So what you are saying is that libvirt should use #ifdef to
>> distinguish between
>>
>> if_link.h/pre_new_attributes
>> and
>> if_link.h/new_attributes?
>
> Yes. It looks like you'll have to determine the availability in the
> configure script and introduce a new #define there.
(*2)
I suppose that based on my comment (*) above, this should not be
necessary because any kernel supported as of today will continue to
work exactly the same way.
>> I guess this would be something similar to what
>> doPortProfileOp8021Qbg (in src/util/macvtap.c) does by checking for
>> IFLA_VF_PORT_MAX in order to distinguish between
>> 8021Qbh/pre_port_profile and 8021Qbh/post_port_profile.
>> Is it correct?
>
> Yes. If you provided the code for 802.1Qbh that'd be great.
Based on my comment (*2) above we should not need to add any new #ifdef.
>> Is this #ifdef based approach the right way to keep track of the
>> if_link.h/IFLA_PORT_* changes?
>
>If there's a better way of doing this, let me know. The problem is
>people compiling libvirt may have all kinds of different levels of
>systems, without even macvtap, then with macvtap but without the first
>set of attributes for port profiles etc. - The progress in the kernel
>is reflected in the code with these #ifdefs... not nice, but I
> doubt there's a better way of doing this.
Well, “versioning” is not a default feature in (RT)Netlink, and other
proposals (in slightly different contexts) got rejected in the past.
(see for example: http://www.spinics.net/lists/netdev/msg127715.html)
Since we are changing the attribute scheme, this could be the right
moment to add versioning to the IFLA_PORT_* attributes group.
We can consider the current one as being version 1 (or 0) and from
now on increment the version by 1 each time we apply some changes to
the IFLA_PORT_* attributes.
The most likely changes that may take place would be the introduction
of new attributes (the BH/BG protocols are still evolving).
This is not the way Netlink is used normally (see Miller's comment
in the URL I provided above), but it would make libvirt code much
easier to update and we would not need to populate it with #ifdefs.
The presence of the version would not be an excuse to be allowed to
make bad changes to the attributes knowing that you can fix them
later with a newer version (I agree with Miller's comment), but
simply to help consumers (ie libvirt in this case) to determine
what level of if_link.h/IFLA_PORT_* they are dealing with, at
run/time (the idea is that of offering a GET for that version number).
Right now (RT)Netlink silently ignores the attributes it does not
understand (ie, type > maxtype), therefore there are no other
mechanisms for determining at run-time what version of the attribute
list the kernel/recipient understands.
>> We may need to change if_link.h again, for example to add new
>> IFLA_PORT_* attributes.
>> Does it mean that in libvirt we will have to add an #ifdef each time?
>
>I think so, yes. And since they are enums (rather than #define's
>themselves) you'll have to introduce the #define's name and probe for
>it by trying to compiling something with it in the configure script.
If this is the only option, we can go for that. No problem. We will
submit the libvirt patches.
If however the versioning scheme was accepted, the libvirt code would
be cleaner and easier to maintain.
Before to discard this option I would like someone on netdev to
comment on that.
Dave, can you confirm us that versioning the IFLA_PORT_* attributes
(not the all if_link.h header) is not an option?
>>> 2) old vs new attributes handling
>>>
>>> You proposed to probe the recipient of the message to see if it
>>> supports the new attributes, and downgrade to the old attr scheme if
>>> the
>> recipient does not understand the new ones.
>>
>> Current Netlink implementation does not provide such (probing)
>> facility, and the Kernel for example simply ignores any attr whose
>> id/type is bigger than the defined __XXX_MAX for the domain the
>> attr belongs to.
>
>Ok, then that's a problem. But it's equally a problem if user's don't
>see why things don't work anymore today with the new kernel whereas
>things still worked yesterday with the old one.
As I said in (*) above, with the current changes nothing will break
because the new attributes deprecate the old ones, and support for
the old ones won’t change at all.
This therefore should not be any problem.
>Is there any RTM_GETLINK one could do to determine whether the new
>attributes are being used?
No.
The versioning mentioned above would add support for that.
>> Because of that there would not be a clean way to probe for remote
>> support of a given attribute.
>> Is this correct? Please let me know if I misunderstood your "probe"
>> comment.
>
>You understood the probe comment correctly.
>
>> What we propose is this:
>>
>> - Given that we deprecated only two attributes, we would send always
>> NEW attr + OLD/DEPRECATED attr
>>
>> - A recipient that only understands the OLD/DEPRECATED attributes
>> will parse and process only the OLD/DEPRECATED attributes and ignore
>> the NEW ones.
>> Here by "NEW ones" I mean those that replaced the DEPRECATED ones
>> (ie, I do not refer to those that do not exist today and will be
>> introduced therefore using the new Netlink scheme directly)
>>
>> - A recipient that supports the NEW ones can safely use the NEW ones
>> only and ignore the OLD ones.
>
>If mixing the old and new ones in one message is ok then probing won't
>be necessary.
Exactly. That’s the idea.
>> Note that if/when we will add new attributes (for example
>> CLUSTER_UUID) that do not exist today and that therefore do not
>> represent replacements for deprecated attributes, we will add them
>> using the new scheme and therefore all recipients/consumers must
>> update to the new scheme if they want to be able to use any of them.
>> None of the applications using the old attribute-set can expect to be
>> able to use the new attributes without an upgrade.
>>
>> > I am assuming that it worked with 802.1Qbh before even though you
>> > didn't have the CLUSTER_UUID support... Now that will probably add
>> > quite a bit to the complexity of the code and the testing. I hope
>> > you'll submit a patch like that to libvirt mailing list.
>>
>> I am not sure I understand your point here. Can you please clarify?
>
>802.1Qbh support has been in libvirt for quite a while. I assume it
>worked without the CLUSTER_UUID attribute that you are introducing only
>now. I have no 802.1Qbh hardware to verify this, though.
Yes, it worked because so far port profiles were global. Now we would
like to use the concept of CLUSTER_UUID (already in use by most VMM)
to scope port profiles. This way we can limit the scope of a port
profile to those hosts belonging to a given cluster.
The main purpose of the kernel patches we submitted was to cleanup
the attribute scheme used for BH/BG, and at the same time make it
easier to add new attributes if/when needed.
However, this should not come at the cost of making libvirt support
a nightmare (#ifdef, etc).
To me it looks like
(1) sending both legacy and new attributes
+
(2) using a versioning scheme for the IFLA_PORT_* attributes
make it easy/clean for libvirt to adapt to the underlying kernel
version (ie, if_link.h/IFLA_PORT_* version).
- Because of (1) above we are not breaking any current user of the
IFLA_PORT_* attributes.
- (2) above is optional but it would make updating libvirt easier.
Again, if #ifdef is the only option, we will stick to it.
Do you have any comment on the optional attribute IFLA_PORT_DATA
I proposed in PATCH 0/2 section 8 (at the end of the post)?
Thanks
/Christian
^ permalink raw reply
* Re: [PATCH] pppoe.c: Fix kernel panic caused by __pppoe_xmit
From: Andrej Ota @ 2010-12-11 23:23 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20101211200823.GA1917@del.dom.local>
> Thanks Andrej! I've only updated emails a bit.
Thank you for your help and support in submitting this patch.
Andrej Ota.
^ permalink raw reply
* Re: [PATCH] rfc: ethtool: early-orphan control
From: Simon Horman @ 2010-12-11 22:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Ben Hutchings
In-Reply-To: <1292087480.2746.54.camel@edumazet-laptop>
On Sat, Dec 11, 2010 at 06:11:20PM +0100, Eric Dumazet wrote:
> Le samedi 11 décembre 2010 à 09:03 +0100, Eric Dumazet a écrit :
> > Le samedi 11 décembre 2010 à 13:24 +0900, Simon Horman a écrit :
> > > On Sat, Dec 11, 2010 at 01:13:35PM +0900, Simon Horman wrote:
> > > > Early orphaning is an optimisation which avoids unnecessary cache misses by
> > > > orphaning an skb just before it is handed to a device for transmit thus
> > > > avoiding the case where the orphaning occurs on a different CPU.
> > > >
> > > > In the case of bonded devices this has the unfortunate side-effect of
> > > > breaking down flow control allowing a socket to send UDP packets as fast as
> > > > the CPU will allow. This is particularly undesirable in virtualised
> > > > network environments.
> > > >
> > > > This patch introduces ethtool control of early orphaning.
> > > > It remains on by default by it now may be disabled on a per-interface basis.
> > > >
> > > > I have implemented this as a generic flag.
> > > > As it seems to be the first generic flag that requires
> > > > no driver awareness I also supplied a default flag handler.
> > > > I am unsure if any aspect of this approach is acceptable.
> > > >
> > > > I believe Eric has it in mind that some of the calls
> > > > to skb_orphan() in drivers can be removed with the addition
> > > > of this feature. I need to discuss that with him further.
> > > >
> > > > A patch for the ethtool user-space utility accompanies this patch.
> > >
> > > The following results were measured using kvm using virto without vhost net.
> > > The virtio device is bridged to a bond device which has one gigabit slave.
> > >
> >
> > As you know, vhost net does the orphaning, as well as some NIC drivers,
> > so one UDP flood would have same problem.
> >
> > I wonder if this problem could not be solved in other ways.
> >
> >
> > We might do early orphaning only for sockets with SOCK_USE_WRITE_QUEUE
> > flag asserted. (tcp sets it)
> >
> > Then, we could also say : Why tcp use sock_wfree() at all...
> >
>
> I removed skb_orphan_try() and did a quick test, with bonding or not,
> same results on a Gigabit interface.
>
> $ netperf -C -c -4 -t UDP_STREAM -H 55.225.18.57 -- -m 1000
> UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 55.225.18.57 (55.225.18.57) port 0 AF_INET
> Socket Message Elapsed Messages CPU Service
> Size Size Time Okay Errors Throughput Util Demand
> bytes bytes secs # # 10^6bits/sec % SS us/KB
>
> 10000000 1000 10.00 6611385 0 5289.0 13.18 9.278
> 1000000 10.00 1163454 930.7 4.58 6.456
>
>
> As soon as 'socket size' is big enough, UDP flow control is ineffective,
> and no error is reported to user. sendto() says all frames were properly sent.
>
Yes, I've done that test too (as you suggested previously). But my thought
was that in a virtualised environment the administrator of the host can set
the socket size to be small enough and the guest can't change it.
However, I now realise that the same effect can be produced
in the guest's network stack by increasing wmem_default there.
So I'm not sure that this change is useful after all. And I've
got a worse flow control problem than I previously realised.
^ permalink raw reply
* [net-2.6 PATCH 1/1] qlge: Fix deadlock when cancelling worker.
From: Ron Mercer @ 2010-12-11 21:06 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, jarkao2, mingo, Linux-Driver
In-Reply-To: <4CF95995.1070506@gmail.com>
Removing usage of rtnl_lock() to protect firmware interface registers.
These registers are accessed in some worker threads and can create a
deadlock if rtnl_lock is taken by upper layers while the worker is still
pending.
We remove rtnl_lock and use a driver mutex just while mailboxes are
accessed.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge.h | 1 +
drivers/net/qlge/qlge_main.c | 1 +
drivers/net/qlge/qlge_mpi.c | 12 ++++--------
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/net/qlge/qlge.h b/drivers/net/qlge/qlge.h
index 2282139..9787dff 100644
--- a/drivers/net/qlge/qlge.h
+++ b/drivers/net/qlge/qlge.h
@@ -2083,6 +2083,7 @@ struct ql_adapter {
u32 mailbox_in;
u32 mailbox_out;
struct mbox_params idc_mbc;
+ struct mutex mpi_mutex;
int tx_ring_size;
int rx_ring_size;
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index 528eaef..2555b1d 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -4629,6 +4629,7 @@ static int __devinit ql_init_device(struct pci_dev *pdev,
INIT_DELAYED_WORK(&qdev->mpi_idc_work, ql_mpi_idc_work);
INIT_DELAYED_WORK(&qdev->mpi_core_to_log, ql_mpi_core_to_log);
init_completion(&qdev->ide_completion);
+ mutex_init(&qdev->mpi_mutex);
if (!cards_found) {
dev_info(&pdev->dev, "%s\n", DRV_STRING);
diff --git a/drivers/net/qlge/qlge_mpi.c b/drivers/net/qlge/qlge_mpi.c
index 0e7c7c7..a2e919b 100644
--- a/drivers/net/qlge/qlge_mpi.c
+++ b/drivers/net/qlge/qlge_mpi.c
@@ -534,6 +534,7 @@ static int ql_mailbox_command(struct ql_adapter *qdev, struct mbox_params *mbcp)
int status;
unsigned long count;
+ mutex_lock(&qdev->mpi_mutex);
/* Begin polled mode for MPI */
ql_write32(qdev, INTR_MASK, (INTR_MASK_PI << 16));
@@ -603,6 +604,7 @@ done:
end:
/* End polled mode for MPI */
ql_write32(qdev, INTR_MASK, (INTR_MASK_PI << 16) | INTR_MASK_PI);
+ mutex_unlock(&qdev->mpi_mutex);
return status;
}
@@ -1099,9 +1101,7 @@ int ql_wait_fifo_empty(struct ql_adapter *qdev)
static int ql_set_port_cfg(struct ql_adapter *qdev)
{
int status;
- rtnl_lock();
status = ql_mb_set_port_cfg(qdev);
- rtnl_unlock();
if (status)
return status;
status = ql_idc_wait(qdev);
@@ -1122,9 +1122,7 @@ void ql_mpi_port_cfg_work(struct work_struct *work)
container_of(work, struct ql_adapter, mpi_port_cfg_work.work);
int status;
- rtnl_lock();
status = ql_mb_get_port_cfg(qdev);
- rtnl_unlock();
if (status) {
netif_err(qdev, drv, qdev->ndev,
"Bug: Failed to get port config data.\n");
@@ -1167,7 +1165,6 @@ void ql_mpi_idc_work(struct work_struct *work)
u32 aen;
int timeout;
- rtnl_lock();
aen = mbcp->mbox_out[1] >> 16;
timeout = (mbcp->mbox_out[1] >> 8) & 0xf;
@@ -1231,7 +1228,6 @@ void ql_mpi_idc_work(struct work_struct *work)
}
break;
}
- rtnl_unlock();
}
void ql_mpi_work(struct work_struct *work)
@@ -1242,7 +1238,7 @@ void ql_mpi_work(struct work_struct *work)
struct mbox_params *mbcp = &mbc;
int err = 0;
- rtnl_lock();
+ mutex_lock(&qdev->mpi_mutex);
/* Begin polled mode for MPI */
ql_write32(qdev, INTR_MASK, (INTR_MASK_PI << 16));
@@ -1259,7 +1255,7 @@ void ql_mpi_work(struct work_struct *work)
/* End polled mode for MPI */
ql_write32(qdev, INTR_MASK, (INTR_MASK_PI << 16) | INTR_MASK_PI);
- rtnl_unlock();
+ mutex_unlock(&qdev->mpi_mutex);
ql_enable_completion_interrupt(qdev, 0);
}
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] pppoe.c: Fix kernel panic caused by __pppoe_xmit
From: Jarek Poplawski @ 2010-12-11 20:08 UTC (permalink / raw)
To: Andrej Ota
Cc: Paweł Staszewski, Andrew Morton, netdev, Paul Mackerras,
bugzilla-daemon, bugme-daemon, pstaszewski, Eric Dumazet,
David Miller, Gorik Van Steenberge, Daniel Kenzelmann,
Denys Fedoryshchenko
In-Reply-To: <4D037236.4080903@ota.si>
On Sat, Dec 11, 2010 at 01:44:38PM +0100, Andrej Ota wrote:
> __pppoe_xmit function return value was invalid resulting in
> additional call to kfree_skb on already freed skb. This resulted in
> memory corruption and consequent kernel panic after PPPoE peer
> terminated the link.
>
> This fixes commit 55c95e738da85373965cb03b4f975d0fd559865b.
>
> Signed-off-by: Jarek Poplawski [jarkao2@gmail.com]
> Signed-off-by: Andrej Ota [andrej@ota.si]
> Reported-by: Pawel Staszewski [pstaszewski@artcom.pl]
Thanks Andrej! I've only updated emails a bit.
Jarek P.
Reported-by: Gorik Van Steenberge <gvs@zemos.net>
Reported-by: Daniel Kenzelmann <kernel.bugzilla@kenzelmann.dyndns.info>
Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Reported-by: Pawel Staszewski <pstaszewski@artcom.pl>
Diagnosed-by: Andrej Ota <andrej@ota.si>
Diagnosed-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Tested-by: Pawel Staszewski <pstaszewski@artcom.pl>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: Andrej Ota <andrej@ota.si>
^ permalink raw reply
* Re: [PATCH] net: au1000_eth: remove unused global variable.
From: David Miller @ 2010-12-11 20:01 UTC (permalink / raw)
To: manuel.lauss; +Cc: netdev, florian
In-Reply-To: <1292097222-11319-1-git-send-email-manuel.lauss@googlemail.com>
From: Manuel Lauss <manuel.lauss@googlemail.com>
Date: Sat, 11 Dec 2010 20:53:42 +0100
> The driver global au_macs[] is unused in the entire kernel tree,
> so remove it.
>
> Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox