* Re: [PATCH net-next 2/6] tg3: Move EEE definitions into mdio.h
From: Ben Hutchings @ 2010-12-06 19:30 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev, andy
In-Reply-To: <1291660134-3801-3-git-send-email-mcarlson@broadcom.com>
On Mon, 2010-12-06 at 10:28 -0800, Matt Carlson wrote:
> In commit 52b02d04c801fff51ca49ad033210846d1713253 entitled "tg3: Add
> EEE support", Ben Hutchings had commented that the EEE advertisement
> register will be in a standard location. This patch moves that
> definition into mdio.h and changes the code to use it.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
[...]
Thanks, Matt.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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
* [PATCH] Convert netpoll blocking api in bonding driver to be a counter
From: nhorman @ 2010-12-06 19:05 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Jay Vosburgh, Andy Gospodarek, David S. Miller
From: Neil Horman <nhorman@tuxdriver.com>
A while back I made some changes to enable netpoll in the bonding driver. Among
them was a per-cpu flag that indicated we were in a path that held locks which
could cause the netpoll path to block in during tx, and as such the tx path
should queue the frame for later use. This appears to have given rise to a
regression. If one of those paths on which we hold the per-cpu flag yields the
cpu, its possible for us to come back on a different cpu, leading to us clearing
a different flag than we set. This results in odd netpoll drops, and BUG
backtraces appearing in the log, as we check to make sure that we only clear set
bits, and only set clear bits. I had though briefly about changing the
offending paths so that they wouldn't sleep, but looking at my origional work
more closely, it doesn't appear that a per-cpu flag is warranted. We alrady
gate the checking of this flag on IFF_IN_NETPOLL, so we don't hit this in the
normal tx case anyway. And practically speaking, the normal use case for
netpoll is to only have one client anyway, so we're not going to erroneously
queue netpoll frames when its actually safe to do so. As such, lets just
convert that per-cpu flag to an atomic counter. It fixes the rescheduling bugs,
is equivalent from a performance perspective and actually eliminates some code
in the process.
Tested by the reporter and myself, successfully
Reported-by: Liang Zheng <lzheng@redhat.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
---
drivers/net/bonding/bond_main.c | 17 +++++------------
drivers/net/bonding/bonding.h | 12 ++++--------
2 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 0273ad0..0bae9a5 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -171,7 +171,7 @@ MODULE_PARM_DESC(resend_igmp, "Number of IGMP membership reports to send on link
/*----------------------------- Global variables ----------------------------*/
#ifdef CONFIG_NET_POLL_CONTROLLER
-cpumask_var_t netpoll_block_tx;
+atomic_t netpoll_block_tx = ATOMIC_INIT(0);
#endif
static const char * const version =
@@ -5293,13 +5293,6 @@ static int __init bonding_init(void)
if (res)
goto out;
-#ifdef CONFIG_NET_POLL_CONTROLLER
- if (!alloc_cpumask_var(&netpoll_block_tx, GFP_KERNEL)) {
- res = -ENOMEM;
- goto out;
- }
-#endif
-
res = register_pernet_subsys(&bond_net_ops);
if (res)
goto out;
@@ -5328,9 +5321,6 @@ err:
rtnl_link_unregister(&bond_link_ops);
err_link:
unregister_pernet_subsys(&bond_net_ops);
-#ifdef CONFIG_NET_POLL_CONTROLLER
- free_cpumask_var(netpoll_block_tx);
-#endif
goto out;
}
@@ -5347,7 +5337,10 @@ static void __exit bonding_exit(void)
unregister_pernet_subsys(&bond_net_ops);
#ifdef CONFIG_NET_POLL_CONTROLLER
- free_cpumask_var(netpoll_block_tx);
+ /*
+ * Make sure we don't have an imbalance on our netpoll blocking
+ */
+ WARN_ON(atomic_read(&netpoll_block_tx));
#endif
}
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index ad3ae46..bd1a9ab 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -119,26 +119,22 @@
#ifdef CONFIG_NET_POLL_CONTROLLER
-extern cpumask_var_t netpoll_block_tx;
+extern atomic_t netpoll_block_tx;
static inline void block_netpoll_tx(void)
{
- preempt_disable();
- BUG_ON(cpumask_test_and_set_cpu(smp_processor_id(),
- netpoll_block_tx));
+ atomic_inc(&netpoll_block_tx);
}
static inline void unblock_netpoll_tx(void)
{
- BUG_ON(!cpumask_test_and_clear_cpu(smp_processor_id(),
- netpoll_block_tx));
- preempt_enable();
+ atomic_dec(&netpoll_block_tx);
}
static inline int is_netpoll_tx_blocked(struct net_device *dev)
{
if (unlikely(dev->priv_flags & IFF_IN_NETPOLL))
- return cpumask_test_cpu(smp_processor_id(), netpoll_block_tx);
+ return atomic_read(&netpoll_block_tx);
return 0;
}
#else
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH net-next 0/6] tg3: Bugfix and EEE updates
From: David Miller @ 2010-12-06 19:04 UTC (permalink / raw)
To: mcarlson; +Cc: netdev, andy
In-Reply-To: <1291660134-3801-1-git-send-email-mcarlson@broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Mon, 6 Dec 2010 10:28:48 -0800
> This patch integrates a jumbo frame bd flag bugfix and a few EEE refinements.
All applied, thanks Matt.
^ permalink raw reply
* Re: [PATCH 2/2] bluetooth: Use printf extension %pMbt
From: Joe Perches @ 2010-12-06 18:50 UTC (permalink / raw)
To: Gustavo F. Padovan, Michał Mirosław
Cc: Marcel Holtmann, netdev, David S. Miller, linux-bluetooth,
linux-kernel
In-Reply-To: <20101206181507.GC883@vigoh>
On Mon, 2010-12-06 at 16:15 -0200, Gustavo F. Padovan wrote:
> This patch doesn't apply to the bluetooth-next-2.6 tree.
> Can you please rebase it against the bluetooth-next-2.6 tree?
No worries, it was done against next-20101202.
Do you care about using %pMR vs %pMbt as Michał suggested in
https://lkml.org/lkml/2010/12/4/21 ?
I think %pMbt more specific, Michał %pMR more generic.
Doesn't matter much to me. Do tell, I'll resubmit either way.
^ permalink raw reply
* [PATCH net-next 1/6] tg3: Raise the jumbo frame BD flag threshold
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
The current transmit routines set the jumbo frame BD flag too
aggressively. This can reduce performance for common cases. This patch
raises the jumbo flag threshold to 1518, up from 1500.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index afb79db..b8ae5e1 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5761,7 +5761,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb,
dma_unmap_addr_set(&tnapi->tx_buffers[entry], mapping, mapping);
if ((tp->tg3_flags3 & TG3_FLG3_USE_JUMBO_BDFLAG) &&
- !mss && skb->len > ETH_DATA_LEN)
+ !mss && skb->len > VLAN_ETH_FRAME_LEN)
base_flags |= TXD_FLAG_JMB_PKT;
tg3_set_txd(tnapi, entry, mapping, len, base_flags,
@@ -5995,7 +5995,7 @@ static netdev_tx_t tg3_start_xmit_dma_bug(struct sk_buff *skb,
#endif
if ((tp->tg3_flags3 & TG3_FLG3_USE_JUMBO_BDFLAG) &&
- !mss && skb->len > ETH_DATA_LEN)
+ !mss && skb->len > VLAN_ETH_FRAME_LEN)
base_flags |= TXD_FLAG_JMB_PKT;
len = skb_headlen(skb);
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 4/6] tg3: Minor EEE code tweaks
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
The first hunk of this patch makes sure that the driver checks for the
appropriate preconditions before checking if EEE negotiation succeeded.
More specifically the link needs to be full duplex for EEE to be
enabled.
The second and third hunks of this patch fix a bug where the eee
advertisement register would be programmed with extra bits set.
The fourth hunk of this patch makes sure the EEE capability flag is not
set for 5718 A0 devices and that the device is not a serdes device.
None of these modifications are strictly necessary. The driver /
hardware still does the right thing. They are submitted primarily for
correctness.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index e4efb52..81dafc2 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1770,9 +1770,9 @@ static void tg3_phy_eee_adjust(struct tg3 *tp, u32 current_link_up)
if (tp->link_config.autoneg == AUTONEG_ENABLE &&
current_link_up == 1 &&
- (tp->link_config.active_speed == SPEED_1000 ||
- (tp->link_config.active_speed == SPEED_100 &&
- tp->link_config.active_duplex == DUPLEX_FULL))) {
+ tp->link_config.active_duplex == DUPLEX_FULL &&
+ (tp->link_config.active_speed == SPEED_100 ||
+ tp->link_config.active_speed == SPEED_1000)) {
u32 eeectl;
if (tp->link_config.active_speed == SPEED_1000)
@@ -2969,7 +2969,7 @@ static void tg3_phy_copper_begin(struct tg3 *tp)
}
if (tp->phy_flags & TG3_PHYFLG_EEE_CAP) {
- u32 val = 0;
+ u32 val;
tw32(TG3_CPMU_EEE_MODE,
tr32(TG3_CPMU_EEE_MODE) & ~TG3_CPMU_EEEMD_LPI_ENABLE);
@@ -2986,6 +2986,7 @@ static void tg3_phy_copper_begin(struct tg3 *tp)
tg3_phydsp_write(tp, MII_TG3_DSP_CH34TP2,
val | MII_TG3_DSP_CH34TP2_HIBW01);
+ val = 0;
if (tp->link_config.autoneg == AUTONEG_ENABLE) {
/* Advertise 100-BaseTX EEE ability */
if (tp->link_config.advertising &
@@ -12569,9 +12570,11 @@ static int __devinit tg3_phy_probe(struct tg3 *tp)
}
}
- if (tp->pdev->device == TG3PCI_DEVICE_TIGON3_5718 ||
- (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57765 &&
- tp->pci_chip_rev_id != CHIPREV_ID_57765_A0))
+ if (!(tp->phy_flags & TG3_PHYFLG_ANY_SERDES) &&
+ ((tp->pdev->device == TG3PCI_DEVICE_TIGON3_5718 &&
+ tp->pci_chip_rev_id != CHIPREV_ID_5717_A0) ||
+ (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57765 &&
+ tp->pci_chip_rev_id != CHIPREV_ID_57765_A0)))
tp->phy_flags |= TG3_PHYFLG_EEE_CAP;
if (!(tp->phy_flags & TG3_PHYFLG_ANY_SERDES) &&
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 6/6] tg3: Update version to 3.116
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
This patch updates the tg3 version to 3.116.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index bb95c6e..5faa87d 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -70,10 +70,10 @@
#define DRV_MODULE_NAME "tg3"
#define TG3_MAJ_NUM 3
-#define TG3_MIN_NUM 115
+#define TG3_MIN_NUM 116
#define DRV_MODULE_VERSION \
__stringify(TG3_MAJ_NUM) "." __stringify(TG3_MIN_NUM)
-#define DRV_MODULE_RELDATE "October 14, 2010"
+#define DRV_MODULE_RELDATE "December 3, 2010"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 2/6] tg3: Move EEE definitions into mdio.h
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
In commit 52b02d04c801fff51ca49ad033210846d1713253 entitled "tg3: Add
EEE support", Ben Hutchings had commented that the EEE advertisement
register will be in a standard location. This patch moves that
definition into mdio.h and changes the code to use it.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 16 ++++++++--------
drivers/net/tg3.h | 3 ---
include/linux/mdio.h | 5 +++++
3 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index b8ae5e1..1e7a135 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -32,6 +32,7 @@
#include <linux/etherdevice.h>
#include <linux/skbuff.h>
#include <linux/ethtool.h>
+#include <linux/mdio.h>
#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/brcmphy.h>
@@ -1781,7 +1782,8 @@ static void tg3_phy_eee_adjust(struct tg3 *tp, u32 current_link_up)
tw32(TG3_CPMU_EEE_CTRL, eeectl);
- tg3_phy_cl45_read(tp, 0x7, TG3_CL45_D7_EEERES_STAT, &val);
+ tg3_phy_cl45_read(tp, MDIO_MMD_AN,
+ TG3_CL45_D7_EEERES_STAT, &val);
if (val == TG3_CL45_D7_EEERES_STAT_LP_1000T ||
val == TG3_CL45_D7_EEERES_STAT_LP_100TX)
@@ -2987,16 +2989,14 @@ static void tg3_phy_copper_begin(struct tg3 *tp)
if (tp->link_config.autoneg == AUTONEG_ENABLE) {
/* Advertise 100-BaseTX EEE ability */
if (tp->link_config.advertising &
- (ADVERTISED_100baseT_Half |
- ADVERTISED_100baseT_Full))
- val |= TG3_CL45_D7_EEEADV_CAP_100TX;
+ ADVERTISED_100baseT_Full)
+ val |= MDIO_AN_EEE_ADV_100TX;
/* Advertise 1000-BaseT EEE ability */
if (tp->link_config.advertising &
- (ADVERTISED_1000baseT_Half |
- ADVERTISED_1000baseT_Full))
- val |= TG3_CL45_D7_EEEADV_CAP_1000T;
+ ADVERTISED_1000baseT_Full)
+ val |= MDIO_AN_EEE_ADV_1000T;
}
- tg3_phy_cl45_write(tp, 0x7, TG3_CL45_D7_EEEADV_CAP, val);
+ tg3_phy_cl45_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
/* Turn off SM_DSP clock. */
val = MII_TG3_AUXCTL_SHDWSEL_AUXCTL |
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 59b0e09..6e72c6b 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2172,9 +2172,6 @@
#define MII_TG3_TEST1_CRC_EN 0x8000
/* Clause 45 expansion registers */
-#define TG3_CL45_D7_EEEADV_CAP 0x003c
-#define TG3_CL45_D7_EEEADV_CAP_100TX 0x0002
-#define TG3_CL45_D7_EEEADV_CAP_1000T 0x0004
#define TG3_CL45_D7_EEERES_STAT 0x803e
#define TG3_CL45_D7_EEERES_STAT_LP_100TX 0x0002
#define TG3_CL45_D7_EEERES_STAT_LP_1000T 0x0004
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index c779b49..b1494ac 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -55,6 +55,7 @@
#define MDIO_PCS_10GBRT_STAT2 33 /* 10GBASE-R/-T PCS status 2 */
#define MDIO_AN_10GBT_CTRL 32 /* 10GBASE-T auto-negotiation control */
#define MDIO_AN_10GBT_STAT 33 /* 10GBASE-T auto-negotiation status */
+#define MDIO_AN_EEE_ADV 60 /* EEE advertisement */
/* LASI (Link Alarm Status Interrupt) registers, defined by XENPAK MSA. */
#define MDIO_PMA_LASI_RXCTRL 0x9000 /* RX_ALARM control */
@@ -235,6 +236,10 @@
#define MDIO_AN_10GBT_STAT_MS 0x4000 /* Master/slave config */
#define MDIO_AN_10GBT_STAT_MSFLT 0x8000 /* Master/slave config fault */
+/* AN EEE Advertisement register. */
+#define MDIO_AN_EEE_ADV_100TX 0x0002 /* Advertise 100TX EEE cap */
+#define MDIO_AN_EEE_ADV_1000T 0x0004 /* Advertise 1000T EEE cap */
+
/* LASI RX_ALARM control/status registers. */
#define MDIO_PMA_LASI_RX_PHYXSLFLT 0x0001 /* PHY XS RX local fault */
#define MDIO_PMA_LASI_RX_PCSLFLT 0x0008 /* PCS RX local fault */
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 5/6] tg3: Relax EEE thresholds
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
The hardware defaults to fairly aggressive EEE thresholds. While there
appear to be no ill effects, this patch relaxes them, just as a
precaution.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 25 ++++++++++++++++++++-----
drivers/net/tg3.h | 20 +++++++++++++-------
2 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 81dafc2..bb95c6e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7819,11 +7819,26 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
tw32_f(TG3_CPMU_EEE_CTRL,
TG3_CPMU_EEE_CTRL_EXIT_20_1_US);
- tw32_f(TG3_CPMU_EEE_MODE,
- TG3_CPMU_EEEMD_ERLY_L1_XIT_DET |
- TG3_CPMU_EEEMD_LPI_IN_TX |
- TG3_CPMU_EEEMD_LPI_IN_RX |
- TG3_CPMU_EEEMD_EEE_ENABLE);
+ val = TG3_CPMU_EEEMD_ERLY_L1_XIT_DET |
+ TG3_CPMU_EEEMD_LPI_IN_TX |
+ TG3_CPMU_EEEMD_LPI_IN_RX |
+ TG3_CPMU_EEEMD_EEE_ENABLE;
+
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5717)
+ val |= TG3_CPMU_EEEMD_SND_IDX_DET_EN;
+
+ if (tp->tg3_flags3 & TG3_FLG3_ENABLE_APE)
+ val |= TG3_CPMU_EEEMD_APE_TX_DET_EN;
+
+ tw32_f(TG3_CPMU_EEE_MODE, val);
+
+ tw32_f(TG3_CPMU_EEE_DBTMR1,
+ TG3_CPMU_DBTMR1_PCIEXIT_2047US |
+ TG3_CPMU_DBTMR1_LNKIDLE_2047US);
+
+ tw32_f(TG3_CPMU_EEE_DBTMR2,
+ TG3_CPMU_DBTMR1_APE_TX_2047US |
+ TG3_CPMU_DBTMR2_TXIDXEQ_2047US);
}
if (reset_phy)
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 6e72c6b..d62c8d9 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -1094,13 +1094,19 @@
/* 0x3664 --> 0x36b0 unused */
#define TG3_CPMU_EEE_MODE 0x000036b0
-#define TG3_CPMU_EEEMD_ERLY_L1_XIT_DET 0x00000008
-#define TG3_CPMU_EEEMD_LPI_ENABLE 0x00000080
-#define TG3_CPMU_EEEMD_LPI_IN_TX 0x00000100
-#define TG3_CPMU_EEEMD_LPI_IN_RX 0x00000200
-#define TG3_CPMU_EEEMD_EEE_ENABLE 0x00100000
-/* 0x36b4 --> 0x36b8 unused */
-
+#define TG3_CPMU_EEEMD_APE_TX_DET_EN 0x00000004
+#define TG3_CPMU_EEEMD_ERLY_L1_XIT_DET 0x00000008
+#define TG3_CPMU_EEEMD_SND_IDX_DET_EN 0x00000040
+#define TG3_CPMU_EEEMD_LPI_ENABLE 0x00000080
+#define TG3_CPMU_EEEMD_LPI_IN_TX 0x00000100
+#define TG3_CPMU_EEEMD_LPI_IN_RX 0x00000200
+#define TG3_CPMU_EEEMD_EEE_ENABLE 0x00100000
+#define TG3_CPMU_EEE_DBTMR1 0x000036b4
+#define TG3_CPMU_DBTMR1_PCIEXIT_2047US 0x07ff0000
+#define TG3_CPMU_DBTMR1_LNKIDLE_2047US 0x000070ff
+#define TG3_CPMU_EEE_DBTMR2 0x000036b8
+#define TG3_CPMU_DBTMR1_APE_TX_2047US 0x07ff0000
+#define TG3_CPMU_DBTMR2_TXIDXEQ_2047US 0x000070ff
#define TG3_CPMU_EEE_LNKIDL_CTRL 0x000036bc
#define TG3_CPMU_EEE_LNKIDL_PCIE_NL0 0x01000000
#define TG3_CPMU_EEE_LNKIDL_UART_IDL 0x00000004
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 3/6] tg3: Fix 57765 EEE support
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
EEE support in the 57765 internal phy will not enable after a phy reset
unless it sees that EEE is supported in the MAC. This patch moves the
code that programs the CPMU EEE registers to a place before the phy
reset.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 1e7a135..e4efb52 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7809,6 +7809,22 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
if (tp->tg3_flags & TG3_FLAG_INIT_COMPLETE)
tg3_abort_hw(tp, 1);
+ /* Enable MAC control of LPI */
+ if (tp->phy_flags & TG3_PHYFLG_EEE_CAP) {
+ tw32_f(TG3_CPMU_EEE_LNKIDL_CTRL,
+ TG3_CPMU_EEE_LNKIDL_PCIE_NL0 |
+ TG3_CPMU_EEE_LNKIDL_UART_IDL);
+
+ tw32_f(TG3_CPMU_EEE_CTRL,
+ TG3_CPMU_EEE_CTRL_EXIT_20_1_US);
+
+ tw32_f(TG3_CPMU_EEE_MODE,
+ TG3_CPMU_EEEMD_ERLY_L1_XIT_DET |
+ TG3_CPMU_EEEMD_LPI_IN_TX |
+ TG3_CPMU_EEEMD_LPI_IN_RX |
+ TG3_CPMU_EEEMD_EEE_ENABLE);
+ }
+
if (reset_phy)
tg3_phy_reset(tp);
@@ -7890,22 +7906,6 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
tw32(TG3_CPMU_LSPD_10MB_CLK, val);
}
- /* Enable MAC control of LPI */
- if (tp->phy_flags & TG3_PHYFLG_EEE_CAP) {
- tw32_f(TG3_CPMU_EEE_LNKIDL_CTRL,
- TG3_CPMU_EEE_LNKIDL_PCIE_NL0 |
- TG3_CPMU_EEE_LNKIDL_UART_IDL);
-
- tw32_f(TG3_CPMU_EEE_CTRL,
- TG3_CPMU_EEE_CTRL_EXIT_20_1_US);
-
- tw32_f(TG3_CPMU_EEE_MODE,
- TG3_CPMU_EEEMD_ERLY_L1_XIT_DET |
- TG3_CPMU_EEEMD_LPI_IN_TX |
- TG3_CPMU_EEEMD_LPI_IN_RX |
- TG3_CPMU_EEEMD_EEE_ENABLE);
- }
-
/* This works around an issue with Athlon chipsets on
* B3 tigon3 silicon. This bit has no effect on any
* other revision. But do not set this on PCI Express
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 0/6] tg3: Bugfix and EEE updates
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
This patch integrates a jumbo frame bd flag bugfix and a few EEE refinements.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Add Nic partitioning mode (57712 devices)
From: Dimitris Michailidis @ 2010-12-06 18:21 UTC (permalink / raw)
To: Matt Domsch
Cc: Eilon Greenstein, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, narendra_k@dell.com,
jordan_hargrave@dell.com
In-Reply-To: <20101206173534.GC13628@auslistsprd01.us.dell.com>
Matt Domsch wrote:
> For SR-IOV, biosdevname follows the physfn and virtfn* pointers to map
> VFs to the PF.
This gives the PF a VF maps to but in general doesn't say anything about the
port the VF maps to, unless you make additional assumptions as below.
> But it assumes 1 PF -> 1 port. For the Intel 1GbE and
> 10GbE cards I have, this is true, but nothing says it has to be true.
Yes, there are devices for which this isn't true. You can have several PFs
mapping to 1 port, 1 PF mapping to several ports, a PF mapping to some
port(s) but its VFs mapping to different port(s), ...
> Maybe something like:
>
> /sys/class/net_port/<port_name>/<ifname> -> /sys/class/net/<ifname>
>
> /sys/class/net/<ifname>/port -> /sys/class/net_port/<port_name>
>
> This introduces the idea of ports, though adds the complication of
> needing to name them somehow. But it would expose the relationship of
> each net interface to a specific port, as well as allow multiple
> interfaces per port, conceptually independent of the PCI device
> mapping. That way, each driver, which must know the mapping somehow,
> could fill these links out?
/sys/class/net/<ifname>/dev_id indicates the physical port <ifname> is
associated with. At least a few drivers set up dev_id this way.
^ permalink raw reply
* Re: [PATCH 2/2] bluetooth: Use printf extension %pMbt
From: Gustavo F. Padovan @ 2010-12-06 18:15 UTC (permalink / raw)
To: Joe Perches
Cc: Marcel Holtmann, netdev, David S. Miller, linux-bluetooth,
linux-kernel
In-Reply-To: <b966e9510dec12556a3d1313b026cb2c8281e4d6.1291419007.git.joe@perches.com>
Hi Joe,
* Joe Perches <joe@perches.com> [2010-12-03 18:33:04 -0800]:
> Save some text and bss.
> Remove function batostr so there's no possibility of bad output.
>
> from the net/bluetooth directory:
>
> $ size built-in.o.*
> text data bss dec hex filename
> 293562 16265 70088 379915 5cc0b built-in.o.allyesconfig.new
> 294619 16269 70480 381368 5d1b8 built-in.o.allyesconfig.old
> 30359 772 56 31187 79d3 built-in.o.btonly.new
> 30555 776 92 31423 7abf built-in.o.btonly.old
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> net/bluetooth/bnep/core.c | 3 +--
> net/bluetooth/cmtp/core.c | 2 +-
> net/bluetooth/hci_conn.c | 6 +++---
> net/bluetooth/hci_core.c | 8 ++++----
> net/bluetooth/hci_event.c | 6 +++---
> net/bluetooth/hci_sysfs.c | 10 +++++-----
> net/bluetooth/hidp/core.c | 4 ++--
> net/bluetooth/l2cap.c | 19 +++++++++----------
> net/bluetooth/lib.c | 14 --------------
> net/bluetooth/rfcomm/core.c | 16 ++++++++--------
> net/bluetooth/rfcomm/sock.c | 8 ++++----
> net/bluetooth/rfcomm/tty.c | 6 +++---
> net/bluetooth/sco.c | 12 ++++++------
> 13 files changed, 49 insertions(+), 65 deletions(-)
This patch doesn't apply to the bluetooth-next-2.6 tree. Can you please rebase
it against the bluetooth-next-2.6 tree? The tree is at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6.git
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 1/2] vsprintf: Add %pMbt, bluetooth mac address
From: Gustavo F. Padovan @ 2010-12-06 18:11 UTC (permalink / raw)
To: Joe Perches; +Cc: Marcel Holtmann, linux-kernel, netdev
In-Reply-To: <a33a0b00eeb29713a08d91156cbb2d816176f990.1291419007.git.joe@perches.com>
Hi Joe,
* Joe Perches <joe@perches.com> [2010-12-03 18:33:03 -0800]:
> Bluetooth output the MAC address in reverse order.
> Bluetooth memory order: 00 01 02 03 04 05 is output "05:04:03:02:01:00".
>
> This can save overall text when bluetooth is compiled in.
>
> Bluetooth currently uses a very slightly unsafe local function (batostr)
> to output these formatted addresses.
>
> Adding %pMbt allows the batostr function to be removed.
>
> For x86:
>
> $ size lib/vsprintf*.o*
> text data bss dec hex filename
> 8189 0 2 8191 1fff lib/vsprintf.o.defconfig.new
> 8150 0 2 8152 1fd8 lib/vsprintf.o.defconfig.old
> 18633 56 3936 22625 5861 lib/vsprintf.o.allyesconfig.new
> 18571 56 3920 22547 5813 lib/vsprintf.o.allyesconfig.old
>
> Signed-off-by: Joe Perches <joe@perches.com>
Looks good to me.
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFC] mark devices with broken LRO implementation
From: Stephen Hemminger @ 2010-12-06 17:58 UTC (permalink / raw)
To: David Miller, Yevgeny Petrilin; +Cc: olof, leitao, eli, netdev
In-Reply-To: <20101206.092855.193714367.davem@davemloft.net>
On Mon, 06 Dec 2010 09:28:55 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Olof Johansson <olof@lixom.net>
> Date: Mon, 6 Dec 2010 11:18:16 -0600
>
> > On Mon, Dec 06, 2010 at 09:10:10AM -0800, Stephen Hemminger wrote:
> >> The kernel uses dev_disable_lro to disable Large Receive Offload
> >> for cases where it is inappropriate. But several drivers do not implement
> >> the required hook. This is a "penalty box" patch to encourage those
> >> drivers to add support for the necessary ethtool set_flags.
> >>
> >> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > pasemi_mac:
> >
> > Acked-by: Olof Johansson <olof@lixom.net>
> >
> >> I only found three drivers that are broken. Normally, I would just fix
> >> them; but since changing state in the device is hardware specific, and
> >> I don't have the hardware or specs to do anything useful to fix it.
> >
> > Thanks. All my hardware is currently in storage due to my relocation, but
> > I'll take a look at it when I have something to run on back. :-)
>
> I don't think we can do what this patch does.
>
> It serves no purpose, as it just means the user is going to have an
> extra headache to turn their driver on.
>
> And %99 of them won't see it, the distribution folks will.
>
> So this is all for nothing.
>
> Better to just work on fixing the problem in the few drivers for
> which the issue exists.
>
> And I'm always happy to receive patches that just plain rip LRO
> support out of such drivers. That's a real legitimate patch unlike
> this one because it keeps the user able to get their driver enabled
> with no fuss and it removes only the improperly functioning feature.
I am less worried about the drivers for embedded devices, the one that
surprises me the mellanox driver. But it looks like that driver doesn't
really do LRO (only GRO).
Subject: mlx4: remove reference to LRO
This device does not do LRO, the current version does GRO.
This patch removes unused inline and changes the configuration
and comments to reflect that. Compile tested only.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/Kconfig | 1 -
drivers/net/mlx4/en_rx.c | 6 +++---
drivers/net/mlx4/mlx4_en.h | 17 -----------------
3 files changed, 3 insertions(+), 21 deletions(-)
--- a/drivers/net/Kconfig 2010-12-06 09:49:11.210488154 -0800
+++ b/drivers/net/Kconfig 2010-12-06 09:49:45.461406671 -0800
@@ -2859,7 +2859,6 @@ config MLX4_EN
tristate "Mellanox Technologies 10Gbit Ethernet support"
depends on PCI && INET
select MLX4_CORE
- select INET_LRO
help
This driver supports Mellanox Technologies ConnectX Ethernet
devices.
--- a/drivers/net/mlx4/en_rx.c 2010-12-06 09:51:38.316270948 -0800
+++ b/drivers/net/mlx4/en_rx.c 2010-12-06 09:51:55.758024934 -0800
@@ -584,7 +584,7 @@ int mlx4_en_process_rx_cq(struct net_dev
if ((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
(cqe->checksum == cpu_to_be16(0xffff))) {
priv->port_stats.rx_chksum_good++;
- /* This packet is eligible for LRO if it is:
+ /* This packet is eligible for GRO if it is:
* - DIX Ethernet (type interpretation)
* - TCP/IP (v4)
* - without IP options
@@ -616,7 +616,7 @@ int mlx4_en_process_rx_cq(struct net_dev
goto next;
}
- /* LRO not possible, complete processing here */
+ /* GRO not possible, complete processing here */
ip_summed = CHECKSUM_UNNECESSARY;
} else {
ip_summed = CHECKSUM_NONE;
@@ -657,7 +657,7 @@ next:
cqe = &cq->buf[index];
if (++polled == budget) {
/* We are here because we reached the NAPI budget -
- * flush only pending LRO sessions */
+ * flush only pending GRO sessions */
goto out;
}
}
--- a/drivers/net/mlx4/mlx4_en.h 2010-12-06 09:50:40.142348439 -0800
+++ b/drivers/net/mlx4/mlx4_en.h 2010-12-06 09:51:59.470397030 -0800
@@ -83,8 +83,6 @@
#define MLX4_EN_ALLOC_ORDER 2
#define MLX4_EN_ALLOC_SIZE (PAGE_SIZE << MLX4_EN_ALLOC_ORDER)
-#define MLX4_EN_MAX_LRO_DESCRIPTORS 32
-
/* Receive fragment sizes; we use at most 4 fragments (for 9600 byte MTU
* and 4K allocations) */
enum {
@@ -268,21 +266,6 @@ struct mlx4_en_rx_ring {
unsigned long packets;
};
-
-static inline int mlx4_en_can_lro(__be16 status)
-{
- return (status & cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
- MLX4_CQE_STATUS_IPV4F |
- MLX4_CQE_STATUS_IPV6 |
- MLX4_CQE_STATUS_IPV4OPT |
- MLX4_CQE_STATUS_TCP |
- MLX4_CQE_STATUS_UDP |
- MLX4_CQE_STATUS_IPOK)) ==
- cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
- MLX4_CQE_STATUS_IPOK |
- MLX4_CQE_STATUS_TCP);
-}
-
struct mlx4_en_cq {
struct mlx4_cq mcq;
struct mlx4_hwq_resources wqres;
^ permalink raw reply
* Re: [PATCH] use total_highpages when calculating lowmem-only allocation sizes (dccp)
From: David Miller @ 2010-12-06 17:36 UTC (permalink / raw)
To: JBeulich; +Cc: netdev, akpm
In-Reply-To: <4CFD2096020000780002627B@vpn.id2.novell.com>
From: "Jan Beulich" <JBeulich@novell.com>
Date: Mon, 06 Dec 2010 16:42:46 +0000
> For those (large) table allocations that come only from lowmem, the
> total amount of memory shouldn't really matter.
>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
Instead of continually tweaking the bits in these code paths,
we should be converting them over to using a central routine
such as alloc_large_system_hash() where the logic is consolidated
_AND_ the code knows to use vmalloc() and NUMA aware allocations
when warranted.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Add Nic partitioning mode (57712 devices)
From: Matt Domsch @ 2010-12-06 17:35 UTC (permalink / raw)
To: Eilon Greenstein
Cc: Dmitry Kravkov, davem@davemloft.net, netdev@vger.kernel.org,
narendra_k@dell.com, jordan_hargrave@dell.com
In-Reply-To: <1291023192.9770.0.camel@lb-tlvb-eilong.il.broadcom.com>
On Mon, Nov 29, 2010 at 11:33:12AM +0200, Eilon Greenstein wrote:
> The main difference here is that we are talking about multiple PFs - so
> each can be brought up or down independently of the others. So there is
> no one master PF that controls the port and once it is brought down, the
> port is down too. At any given moment, one of the PFs is acting as the
> port master and controls the shared HW - but once this PF is brought
> down, another PF is seamlessly taking over.
Hmm, that complicates things a bit.
> I think the main difference is that we have real PCI functions and not
> virtual ones. On the same PCI bus, we have two physical ports, and 8
> physical functions - 4 on each port. I agree that exposing which
> functions are using the same port can really help - so I'm open to
> suggestions on the "how".
We really need, for NPAR, SR-IOV, and the Chelsio
multiple-ports-per-PCI-device model, a "network port" abstraction in
sysfs. We need the ability to map M ports to N PCI devices, and
expose that mapping in sysfs.
For SR-IOV, biosdevname follows the physfn and virtfn* pointers to map
VFs to the PF. But it assumes 1 PF -> 1 port. For the Intel 1GbE and
10GbE cards I have, this is true, but nothing says it has to be true.
Maybe something like:
/sys/class/net_port/<port_name>/<ifname> -> /sys/class/net/<ifname>
/sys/class/net/<ifname>/port -> /sys/class/net_port/<port_name>
This introduces the idea of ports, though adds the complication of
needing to name them somehow. But it would expose the relationship of
each net interface to a specific port, as well as allow multiple
interfaces per port, conceptually independent of the PCI device
mapping. That way, each driver, which must know the mapping somehow,
could fill these links out?
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH] ehea: add the correct LRO status at dev->features
From: David Miller @ 2010-12-06 17:33 UTC (permalink / raw)
To: leitao; +Cc: shemminger, netdev
In-Reply-To: <4CFD15F6.7040609@linux.vnet.ibm.com>
From: Breno Leitao <leitao@linux.vnet.ibm.com>
Date: Mon, 06 Dec 2010 14:57:26 -0200
> On 12/06/2010 02:48 PM, Stephen Hemminger wrote:
>> On Mon, 6 Dec 2010 14:39:42 -0200
>> leitao@linux.vnet.ibm.com wrote:
>>
>>> Currently ehea is not setting NETIF_F_LRO, and it is not providing
>>> a callback for get_flags on ethtool. This patch fixes it.
>>>
>>> Signed-off-by: Breno Leitao<leitao@linux.vnet.ibm.com>
>>
>> More importantly, ehea does not support set_flags to disable LRO.
> Correct, currently LRO is a module parameter. I have an item in my
> TODO list to implement set_flags, and thus, the LRO scheme.
>
> So, if you prefer I can send this patch with the future set_flags
> ones. But, for now, this patch allows the user to check when LRO is
> enabled. As it is today, it shows that LRO is disabled all the time.
>
> Anyway, you choose what is the best option.
Your options are: 1) send a set_flags patch now 2) rip LRO support
completely out of the ehea driver.
The feature is implemented improperly, and as such we have every right
to forcefully disable it or remove it until it is fixed to function
correctly.
^ permalink raw reply
* Re: PATCH] filter: fix sk_filter rcu handling
From: David Miller @ 2010-12-06 17:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: hagen, xiaosuo, wirelesser, netdev, xemul, stable, paulmck
In-Reply-To: <1291582432.2806.300.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 05 Dec 2010 21:53:52 +0100
> [PATCH] filter: fix sk_filter rcu handling
>
> Pavel Emelyanov tried to fix a race between sk_filter_(de|at)tach and
> sk_clone() in commit 47e958eac280c263397
>
> Problem is we can have several clones sharing a common sk_filter, and
> these clones might want to sk_filter_attach() their own filters at the
> same time, and can overwrite old_filter->rcu, corrupting RCU queues.
>
> We can not use filter->rcu without being sure no other thread could do
> the same thing.
>
> Switch code to a more conventional ref-counting technique : Do the
> atomic decrement immediately and queue one rcu call back when last
> reference is released.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, and queued up for -stable, thanks.
^ permalink raw reply
* Re: [RFC] mark devices with broken LRO implementation
From: David Miller @ 2010-12-06 17:28 UTC (permalink / raw)
To: olof; +Cc: shemminger, leitao, eli, netdev
In-Reply-To: <20101206171816.GA25568@lixom.net>
From: Olof Johansson <olof@lixom.net>
Date: Mon, 6 Dec 2010 11:18:16 -0600
> On Mon, Dec 06, 2010 at 09:10:10AM -0800, Stephen Hemminger wrote:
>> The kernel uses dev_disable_lro to disable Large Receive Offload
>> for cases where it is inappropriate. But several drivers do not implement
>> the required hook. This is a "penalty box" patch to encourage those
>> drivers to add support for the necessary ethtool set_flags.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> pasemi_mac:
>
> Acked-by: Olof Johansson <olof@lixom.net>
>
>> I only found three drivers that are broken. Normally, I would just fix
>> them; but since changing state in the device is hardware specific, and
>> I don't have the hardware or specs to do anything useful to fix it.
>
> Thanks. All my hardware is currently in storage due to my relocation, but
> I'll take a look at it when I have something to run on back. :-)
I don't think we can do what this patch does.
It serves no purpose, as it just means the user is going to have an
extra headache to turn their driver on.
And %99 of them won't see it, the distribution folks will.
So this is all for nothing.
Better to just work on fixing the problem in the few drivers for
which the issue exists.
And I'm always happy to receive patches that just plain rip LRO
support out of such drivers. That's a real legitimate patch unlike
this one because it keeps the user able to get their driver enabled
with no fuss and it removes only the improperly functioning feature.
^ permalink raw reply
* Re: [RFC] mark devices with broken LRO implementation
From: Olof Johansson @ 2010-12-06 17:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Breno Leitao, Eli Cohen, davem, netdev
In-Reply-To: <20101206091010.036cd78b@nehalam>
On Mon, Dec 06, 2010 at 09:10:10AM -0800, Stephen Hemminger wrote:
> The kernel uses dev_disable_lro to disable Large Receive Offload
> for cases where it is inappropriate. But several drivers do not implement
> the required hook. This is a "penalty box" patch to encourage those
> drivers to add support for the necessary ethtool set_flags.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
pasemi_mac:
Acked-by: Olof Johansson <olof@lixom.net>
> I only found three drivers that are broken. Normally, I would just fix
> them; but since changing state in the device is hardware specific, and
> I don't have the hardware or specs to do anything useful to fix it.
Thanks. All my hardware is currently in storage due to my relocation, but
I'll take a look at it when I have something to run on back. :-)
-Olof
^ permalink raw reply
* [RFC] mark devices with broken LRO implementation
From: Stephen Hemminger @ 2010-12-06 17:10 UTC (permalink / raw)
To: Breno Leitao, Olof Johansson, Eli Cohen; +Cc: davem, netdev
In-Reply-To: <4CFD15F6.7040609@linux.vnet.ibm.com>
The kernel uses dev_disable_lro to disable Large Receive Offload
for cases where it is inappropriate. But several drivers do not implement
the required hook. This is a "penalty box" patch to encourage those
drivers to add support for the necessary ethtool set_flags.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
I only found three drivers that are broken. Normally, I would just fix
them; but since changing state in the device is hardware specific, and
I don't have the hardware or specs to do anything useful to fix it.
--- a/drivers/net/Kconfig 2010-12-06 08:52:30.376926696 -0800
+++ b/drivers/net/Kconfig 2010-12-06 09:02:02.013224592 -0800
@@ -28,6 +28,13 @@ menuconfig NETDEVICES
# that for each of the symbols.
if NETDEVICES
+config BROKEN_LRO
+ bool
+ ---help---
+ Allow drivers with partial Large Receive Offload support. These drivers
+ do not implement the necessary feature of disabling LRO support via
+ the ethtool set_flags operation.
+
config IFB
tristate "Intermediate Functional Block support"
depends on NET_CLS_ACT
@@ -2675,7 +2682,7 @@ config CHELSIO_T4VF
config EHEA
tristate "eHEA Ethernet support"
- depends on IBMEBUS && INET && SPARSEMEM
+ depends on IBMEBUS && INET && SPARSEMEM && BROKEN_LRO
select INET_LRO
---help---
This driver supports the IBM pSeries eHEA ethernet adapter.
@@ -2848,7 +2855,7 @@ config NIU
config PASEMI_MAC
tristate "PA Semi 1/10Gbit MAC"
- depends on PPC_PASEMI && PCI && INET
+ depends on PPC_PASEMI && PCI && INET && BROKEN_LRO
select PHYLIB
select INET_LRO
help
@@ -2857,7 +2864,7 @@ config PASEMI_MAC
config MLX4_EN
tristate "Mellanox Technologies 10Gbit Ethernet support"
- depends on PCI && INET
+ depends on PCI && INET && BROKEN_LRO
select MLX4_CORE
select INET_LRO
help
^ permalink raw reply
* Re: [PATCH] ehea: add the correct LRO status at dev->features
From: Breno Leitao @ 2010-12-06 16:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20101206084824.637d6b29@nehalam>
On 12/06/2010 02:48 PM, Stephen Hemminger wrote:
> On Mon, 6 Dec 2010 14:39:42 -0200
> leitao@linux.vnet.ibm.com wrote:
>
>> Currently ehea is not setting NETIF_F_LRO, and it is not providing
>> a callback for get_flags on ethtool. This patch fixes it.
>>
>> Signed-off-by: Breno Leitao<leitao@linux.vnet.ibm.com>
>
> More importantly, ehea does not support set_flags to disable LRO.
Correct, currently LRO is a module parameter. I have an item in my TODO
list to implement set_flags, and thus, the LRO scheme.
So, if you prefer I can send this patch with the future set_flags ones.
But, for now, this patch allows the user to check when LRO is enabled.
As it is today, it shows that LRO is disabled all the time.
Anyway, you choose what is the best option.
Thanks,
Breno
^ permalink raw reply
* Re: [PATCH] ehea: add the correct LRO status at dev->features
From: Stephen Hemminger @ 2010-12-06 16:48 UTC (permalink / raw)
To: leitao; +Cc: davem, netdev
In-Reply-To: <1291653582-14177-1-git-send-email-leitao@linux.vnet.ibm.com>
On Mon, 6 Dec 2010 14:39:42 -0200
leitao@linux.vnet.ibm.com wrote:
> Currently ehea is not setting NETIF_F_LRO, and it is not providing
> a callback for get_flags on ethtool. This patch fixes it.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
More importantly, ehea does not support set_flags to disable LRO.
I will be more blunt. Any device that supports LRO and does
not have the necessary interface to disable it is broken and should
not be used.
--
^ permalink raw reply
* [PATCH] use total_highpages when calculating lowmem-only allocation sizes (sctp)
From: Jan Beulich @ 2010-12-06 16:43 UTC (permalink / raw)
To: netdev; +Cc: akpm
For those (large) table allocations that come only from lowmem, the
total amount of memory shouldn't really matter.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
---
net/sctp/protocol.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.37-rc4/net/sctp/protocol.c
+++ 2.6.37-rc4-use-totalhigh_pages/net/sctp/protocol.c
@@ -1190,10 +1190,10 @@ SCTP_STATIC __init int sctp_init(void)
/* Size and allocate the association hash table.
* The methodology is similar to that of the tcp hash tables.
*/
- if (totalram_pages >= (128 * 1024))
- goal = totalram_pages >> (22 - PAGE_SHIFT);
+ if (nr_pages >= (128 * 1024))
+ goal = nr_pages >> (22 - PAGE_SHIFT);
else
- goal = totalram_pages >> (24 - PAGE_SHIFT);
+ goal = nr_pages >> (24 - PAGE_SHIFT);
for (order = 0; (1UL << order) < goal; order++)
;
^ 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