* [net-next 04/10] ixgbe: remove return code for functions that always return 0
From: Jeff Kirsher @ 2011-10-05 10:20 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
In-Reply-To: <1317810024-20846-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Since ixgbe_raise_i2c_clk() can never return anything else than 0
this patch removes it's return value and all checks for it.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 30 +++++++------------------
1 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
index cf3c227..9a56fd7 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
@@ -39,7 +39,7 @@ static s32 ixgbe_clock_out_i2c_byte(struct ixgbe_hw *hw, u8 data);
static s32 ixgbe_get_i2c_ack(struct ixgbe_hw *hw);
static s32 ixgbe_clock_in_i2c_bit(struct ixgbe_hw *hw, bool *data);
static s32 ixgbe_clock_out_i2c_bit(struct ixgbe_hw *hw, bool data);
-static s32 ixgbe_raise_i2c_clk(struct ixgbe_hw *hw, u32 *i2cctl);
+static void ixgbe_raise_i2c_clk(struct ixgbe_hw *hw, u32 *i2cctl);
static void ixgbe_lower_i2c_clk(struct ixgbe_hw *hw, u32 *i2cctl);
static s32 ixgbe_set_i2c_data(struct ixgbe_hw *hw, u32 *i2cctl, bool data);
static bool ixgbe_get_i2c_data(u32 *i2cctl);
@@ -1420,19 +1420,15 @@ static void ixgbe_i2c_stop(struct ixgbe_hw *hw)
**/
static s32 ixgbe_clock_in_i2c_byte(struct ixgbe_hw *hw, u8 *data)
{
- s32 status = 0;
s32 i;
bool bit = 0;
for (i = 7; i >= 0; i--) {
- status = ixgbe_clock_in_i2c_bit(hw, &bit);
+ ixgbe_clock_in_i2c_bit(hw, &bit);
*data |= bit << i;
-
- if (status != 0)
- break;
}
- return status;
+ return 0;
}
/**
@@ -1473,16 +1469,14 @@ static s32 ixgbe_clock_out_i2c_byte(struct ixgbe_hw *hw, u8 data)
**/
static s32 ixgbe_get_i2c_ack(struct ixgbe_hw *hw)
{
- s32 status;
+ s32 status = 0;
u32 i = 0;
u32 i2cctl = IXGBE_READ_REG(hw, IXGBE_I2CCTL);
u32 timeout = 10;
bool ack = 1;
- status = ixgbe_raise_i2c_clk(hw, &i2cctl);
+ ixgbe_raise_i2c_clk(hw, &i2cctl);
- if (status != 0)
- goto out;
/* Minimum high period of clock is 4us */
udelay(IXGBE_I2C_T_HIGH);
@@ -1508,7 +1502,6 @@ static s32 ixgbe_get_i2c_ack(struct ixgbe_hw *hw)
/* Minimum low period of clock is 4.7 us */
udelay(IXGBE_I2C_T_LOW);
-out:
return status;
}
@@ -1521,10 +1514,9 @@ out:
**/
static s32 ixgbe_clock_in_i2c_bit(struct ixgbe_hw *hw, bool *data)
{
- s32 status;
u32 i2cctl = IXGBE_READ_REG(hw, IXGBE_I2CCTL);
- status = ixgbe_raise_i2c_clk(hw, &i2cctl);
+ ixgbe_raise_i2c_clk(hw, &i2cctl);
/* Minimum high period of clock is 4us */
udelay(IXGBE_I2C_T_HIGH);
@@ -1537,7 +1529,7 @@ static s32 ixgbe_clock_in_i2c_bit(struct ixgbe_hw *hw, bool *data)
/* Minimum low period of clock is 4.7 us */
udelay(IXGBE_I2C_T_LOW);
- return status;
+ return 0;
}
/**
@@ -1554,7 +1546,7 @@ static s32 ixgbe_clock_out_i2c_bit(struct ixgbe_hw *hw, bool data)
status = ixgbe_set_i2c_data(hw, &i2cctl, data);
if (status == 0) {
- status = ixgbe_raise_i2c_clk(hw, &i2cctl);
+ ixgbe_raise_i2c_clk(hw, &i2cctl);
/* Minimum high period of clock is 4us */
udelay(IXGBE_I2C_T_HIGH);
@@ -1579,10 +1571,8 @@ static s32 ixgbe_clock_out_i2c_bit(struct ixgbe_hw *hw, bool data)
*
* Raises the I2C clock line '0'->'1'
**/
-static s32 ixgbe_raise_i2c_clk(struct ixgbe_hw *hw, u32 *i2cctl)
+static void ixgbe_raise_i2c_clk(struct ixgbe_hw *hw, u32 *i2cctl)
{
- s32 status = 0;
-
*i2cctl |= IXGBE_I2C_CLK_OUT;
IXGBE_WRITE_REG(hw, IXGBE_I2CCTL, *i2cctl);
@@ -1590,8 +1580,6 @@ static s32 ixgbe_raise_i2c_clk(struct ixgbe_hw *hw, u32 *i2cctl)
/* SCL rise time (1000ns) */
udelay(IXGBE_I2C_T_RISE);
-
- return status;
}
/**
--
1.7.6.4
^ permalink raw reply related
* [net-next 03/10] ixgbe: clear the data field in ixgbe_read_i2c_byte_generic
From: Jeff Kirsher @ 2011-10-05 10:20 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
In-Reply-To: <1317810024-20846-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Clear the data field in ixgbe_read_i2c_byte_generic so it does not
accumulate 1 bit using the same variable multiple times.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
index f7ca351..cf3c227 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
@@ -1205,7 +1205,7 @@ s32 ixgbe_write_i2c_eeprom_generic(struct ixgbe_hw *hw, u8 byte_offset,
* @data: value read
*
* Performs byte read operation to SFP module's EEPROM over I2C interface at
- * a specified deivce address.
+ * a specified device address.
**/
s32 ixgbe_read_i2c_byte_generic(struct ixgbe_hw *hw, u8 byte_offset,
u8 dev_addr, u8 *data)
@@ -1215,6 +1215,7 @@ s32 ixgbe_read_i2c_byte_generic(struct ixgbe_hw *hw, u8 byte_offset,
u32 retry = 0;
u16 swfw_mask = 0;
bool nack = 1;
+ *data = 0;
if (IXGBE_READ_REG(hw, IXGBE_STATUS) & IXGBE_STATUS_LAN_ID_1)
swfw_mask = IXGBE_GSSR_PHY1_SM;
--
1.7.6.4
^ permalink raw reply related
* [net-next 02/10] ixgbe: prevent link checks while resetting
From: Jeff Kirsher @ 2011-10-05 10:20 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
In-Reply-To: <1317810024-20846-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
It some situations the driver sets __IXGBE_RESETTING and then
__IXGBE_DOWN flags. It is possible a link check may sneak in
between.
This patch adds check for both flags.
The idea is to reduce register reads while the PHY is resetting.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 9cd44ad..ed92272 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -5978,7 +5978,8 @@ static void ixgbe_spoof_check(struct ixgbe_adapter *adapter)
static void ixgbe_watchdog_subtask(struct ixgbe_adapter *adapter)
{
/* if interface is down do nothing */
- if (test_bit(__IXGBE_DOWN, &adapter->state))
+ if (test_bit(__IXGBE_DOWN, &adapter->state) ||
+ test_bit(__IXGBE_RESETTING, &adapter->state))
return;
ixgbe_watchdog_update_link(adapter);
--
1.7.6.4
^ permalink raw reply related
* [net-next 01/10] e1000e: make function tables const
From: Jeff Kirsher @ 2011-10-05 10:20 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo
In-Reply-To: <1317810024-20846-1-git-send-email-jeffrey.t.kirsher@intel.com>
The initial function and setup tables can be marked as constant.
Reported-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/e1000e/80003es2lan.c | 8 +++---
drivers/net/ethernet/intel/e1000e/82571.c | 20 ++++++++--------
drivers/net/ethernet/intel/e1000e/e1000.h | 28 +++++++++++-----------
drivers/net/ethernet/intel/e1000e/ich8lan.c | 16 ++++++------
4 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/80003es2lan.c b/drivers/net/ethernet/intel/e1000e/80003es2lan.c
index b754433..e1159e5 100644
--- a/drivers/net/ethernet/intel/e1000e/80003es2lan.c
+++ b/drivers/net/ethernet/intel/e1000e/80003es2lan.c
@@ -1441,7 +1441,7 @@ static void e1000_clear_hw_cntrs_80003es2lan(struct e1000_hw *hw)
er32(ICRXDMTC);
}
-static struct e1000_mac_operations es2_mac_ops = {
+static const struct e1000_mac_operations es2_mac_ops = {
.read_mac_addr = e1000_read_mac_addr_80003es2lan,
.id_led_init = e1000e_id_led_init,
.blink_led = e1000e_blink_led_generic,
@@ -1464,7 +1464,7 @@ static struct e1000_mac_operations es2_mac_ops = {
.setup_led = e1000e_setup_led_generic,
};
-static struct e1000_phy_operations es2_phy_ops = {
+static const struct e1000_phy_operations es2_phy_ops = {
.acquire = e1000_acquire_phy_80003es2lan,
.check_polarity = e1000_check_polarity_m88,
.check_reset_block = e1000e_check_reset_block_generic,
@@ -1482,7 +1482,7 @@ static struct e1000_phy_operations es2_phy_ops = {
.cfg_on_link_up = e1000_cfg_on_link_up_80003es2lan,
};
-static struct e1000_nvm_operations es2_nvm_ops = {
+static const struct e1000_nvm_operations es2_nvm_ops = {
.acquire = e1000_acquire_nvm_80003es2lan,
.read = e1000e_read_nvm_eerd,
.release = e1000_release_nvm_80003es2lan,
@@ -1492,7 +1492,7 @@ static struct e1000_nvm_operations es2_nvm_ops = {
.write = e1000_write_nvm_80003es2lan,
};
-struct e1000_info e1000_es2_info = {
+const struct e1000_info e1000_es2_info = {
.mac = e1000_80003es2lan,
.flags = FLAG_HAS_HW_VLAN_FILTER
| FLAG_HAS_JUMBO_FRAMES
diff --git a/drivers/net/ethernet/intel/e1000e/82571.c b/drivers/net/ethernet/intel/e1000e/82571.c
index 2d4dc53..a3e65fd 100644
--- a/drivers/net/ethernet/intel/e1000e/82571.c
+++ b/drivers/net/ethernet/intel/e1000e/82571.c
@@ -1927,7 +1927,7 @@ static void e1000_clear_hw_cntrs_82571(struct e1000_hw *hw)
er32(ICRXDMTC);
}
-static struct e1000_mac_operations e82571_mac_ops = {
+static const struct e1000_mac_operations e82571_mac_ops = {
/* .check_mng_mode: mac type dependent */
/* .check_for_link: media type dependent */
.id_led_init = e1000e_id_led_init,
@@ -1949,7 +1949,7 @@ static struct e1000_mac_operations e82571_mac_ops = {
.read_mac_addr = e1000_read_mac_addr_82571,
};
-static struct e1000_phy_operations e82_phy_ops_igp = {
+static const struct e1000_phy_operations e82_phy_ops_igp = {
.acquire = e1000_get_hw_semaphore_82571,
.check_polarity = e1000_check_polarity_igp,
.check_reset_block = e1000e_check_reset_block_generic,
@@ -1967,7 +1967,7 @@ static struct e1000_phy_operations e82_phy_ops_igp = {
.cfg_on_link_up = NULL,
};
-static struct e1000_phy_operations e82_phy_ops_m88 = {
+static const struct e1000_phy_operations e82_phy_ops_m88 = {
.acquire = e1000_get_hw_semaphore_82571,
.check_polarity = e1000_check_polarity_m88,
.check_reset_block = e1000e_check_reset_block_generic,
@@ -1985,7 +1985,7 @@ static struct e1000_phy_operations e82_phy_ops_m88 = {
.cfg_on_link_up = NULL,
};
-static struct e1000_phy_operations e82_phy_ops_bm = {
+static const struct e1000_phy_operations e82_phy_ops_bm = {
.acquire = e1000_get_hw_semaphore_82571,
.check_polarity = e1000_check_polarity_m88,
.check_reset_block = e1000e_check_reset_block_generic,
@@ -2003,7 +2003,7 @@ static struct e1000_phy_operations e82_phy_ops_bm = {
.cfg_on_link_up = NULL,
};
-static struct e1000_nvm_operations e82571_nvm_ops = {
+static const struct e1000_nvm_operations e82571_nvm_ops = {
.acquire = e1000_acquire_nvm_82571,
.read = e1000e_read_nvm_eerd,
.release = e1000_release_nvm_82571,
@@ -2013,7 +2013,7 @@ static struct e1000_nvm_operations e82571_nvm_ops = {
.write = e1000_write_nvm_82571,
};
-struct e1000_info e1000_82571_info = {
+const struct e1000_info e1000_82571_info = {
.mac = e1000_82571,
.flags = FLAG_HAS_HW_VLAN_FILTER
| FLAG_HAS_JUMBO_FRAMES
@@ -2034,7 +2034,7 @@ struct e1000_info e1000_82571_info = {
.nvm_ops = &e82571_nvm_ops,
};
-struct e1000_info e1000_82572_info = {
+const struct e1000_info e1000_82572_info = {
.mac = e1000_82572,
.flags = FLAG_HAS_HW_VLAN_FILTER
| FLAG_HAS_JUMBO_FRAMES
@@ -2052,7 +2052,7 @@ struct e1000_info e1000_82572_info = {
.nvm_ops = &e82571_nvm_ops,
};
-struct e1000_info e1000_82573_info = {
+const struct e1000_info e1000_82573_info = {
.mac = e1000_82573,
.flags = FLAG_HAS_HW_VLAN_FILTER
| FLAG_HAS_WOL
@@ -2070,7 +2070,7 @@ struct e1000_info e1000_82573_info = {
.nvm_ops = &e82571_nvm_ops,
};
-struct e1000_info e1000_82574_info = {
+const struct e1000_info e1000_82574_info = {
.mac = e1000_82574,
.flags = FLAG_HAS_HW_VLAN_FILTER
| FLAG_HAS_MSIX
@@ -2091,7 +2091,7 @@ struct e1000_info e1000_82574_info = {
.nvm_ops = &e82571_nvm_ops,
};
-struct e1000_info e1000_82583_info = {
+const struct e1000_info e1000_82583_info = {
.mac = e1000_82583,
.flags = FLAG_HAS_HW_VLAN_FILTER
| FLAG_HAS_WOL
diff --git a/drivers/net/ethernet/intel/e1000e/e1000.h b/drivers/net/ethernet/intel/e1000e/e1000.h
index 1b15d1f..7877b9c 100644
--- a/drivers/net/ethernet/intel/e1000e/e1000.h
+++ b/drivers/net/ethernet/intel/e1000e/e1000.h
@@ -406,9 +406,9 @@ struct e1000_info {
u32 pba;
u32 max_hw_frame_size;
s32 (*get_variants)(struct e1000_adapter *);
- struct e1000_mac_operations *mac_ops;
- struct e1000_phy_operations *phy_ops;
- struct e1000_nvm_operations *nvm_ops;
+ const struct e1000_mac_operations *mac_ops;
+ const struct e1000_phy_operations *phy_ops;
+ const struct e1000_nvm_operations *nvm_ops;
};
/* hardware capability, feature, and workaround flags */
@@ -506,17 +506,17 @@ extern unsigned int copybreak;
extern char *e1000e_get_hw_dev_name(struct e1000_hw *hw);
-extern struct e1000_info e1000_82571_info;
-extern struct e1000_info e1000_82572_info;
-extern struct e1000_info e1000_82573_info;
-extern struct e1000_info e1000_82574_info;
-extern struct e1000_info e1000_82583_info;
-extern struct e1000_info e1000_ich8_info;
-extern struct e1000_info e1000_ich9_info;
-extern struct e1000_info e1000_ich10_info;
-extern struct e1000_info e1000_pch_info;
-extern struct e1000_info e1000_pch2_info;
-extern struct e1000_info e1000_es2_info;
+extern const struct e1000_info e1000_82571_info;
+extern const struct e1000_info e1000_82572_info;
+extern const struct e1000_info e1000_82573_info;
+extern const struct e1000_info e1000_82574_info;
+extern const struct e1000_info e1000_82583_info;
+extern const struct e1000_info e1000_ich8_info;
+extern const struct e1000_info e1000_ich9_info;
+extern const struct e1000_info e1000_ich10_info;
+extern const struct e1000_info e1000_pch_info;
+extern const struct e1000_info e1000_pch2_info;
+extern const struct e1000_info e1000_es2_info;
extern s32 e1000_read_pba_string_generic(struct e1000_hw *hw, u8 *pba_num,
u32 pba_num_size);
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 3fc3acc..3b063e1 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -4011,7 +4011,7 @@ release:
}
}
-static struct e1000_mac_operations ich8_mac_ops = {
+static const struct e1000_mac_operations ich8_mac_ops = {
.id_led_init = e1000e_id_led_init,
/* check_mng_mode dependent on mac type */
.check_for_link = e1000_check_for_copper_link_ich8lan,
@@ -4030,7 +4030,7 @@ static struct e1000_mac_operations ich8_mac_ops = {
/* id_led_init dependent on mac type */
};
-static struct e1000_phy_operations ich8_phy_ops = {
+static const struct e1000_phy_operations ich8_phy_ops = {
.acquire = e1000_acquire_swflag_ich8lan,
.check_reset_block = e1000_check_reset_block_ich8lan,
.commit = NULL,
@@ -4044,7 +4044,7 @@ static struct e1000_phy_operations ich8_phy_ops = {
.write_reg = e1000e_write_phy_reg_igp,
};
-static struct e1000_nvm_operations ich8_nvm_ops = {
+static const struct e1000_nvm_operations ich8_nvm_ops = {
.acquire = e1000_acquire_nvm_ich8lan,
.read = e1000_read_nvm_ich8lan,
.release = e1000_release_nvm_ich8lan,
@@ -4054,7 +4054,7 @@ static struct e1000_nvm_operations ich8_nvm_ops = {
.write = e1000_write_nvm_ich8lan,
};
-struct e1000_info e1000_ich8_info = {
+const struct e1000_info e1000_ich8_info = {
.mac = e1000_ich8lan,
.flags = FLAG_HAS_WOL
| FLAG_IS_ICH
@@ -4070,7 +4070,7 @@ struct e1000_info e1000_ich8_info = {
.nvm_ops = &ich8_nvm_ops,
};
-struct e1000_info e1000_ich9_info = {
+const struct e1000_info e1000_ich9_info = {
.mac = e1000_ich9lan,
.flags = FLAG_HAS_JUMBO_FRAMES
| FLAG_IS_ICH
@@ -4088,7 +4088,7 @@ struct e1000_info e1000_ich9_info = {
.nvm_ops = &ich8_nvm_ops,
};
-struct e1000_info e1000_ich10_info = {
+const struct e1000_info e1000_ich10_info = {
.mac = e1000_ich10lan,
.flags = FLAG_HAS_JUMBO_FRAMES
| FLAG_IS_ICH
@@ -4106,7 +4106,7 @@ struct e1000_info e1000_ich10_info = {
.nvm_ops = &ich8_nvm_ops,
};
-struct e1000_info e1000_pch_info = {
+const struct e1000_info e1000_pch_info = {
.mac = e1000_pchlan,
.flags = FLAG_IS_ICH
| FLAG_HAS_WOL
@@ -4125,7 +4125,7 @@ struct e1000_info e1000_pch_info = {
.nvm_ops = &ich8_nvm_ops,
};
-struct e1000_info e1000_pch2_info = {
+const struct e1000_info e1000_pch2_info = {
.mac = e1000_pch2lan,
.flags = FLAG_IS_ICH
| FLAG_HAS_WOL
--
1.7.6.4
^ permalink raw reply related
* [net-next 00/10 v3][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-05 10:20 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo
The following series contains updates to e1000e and ixgbe. The one
patch for e1000e makes function tables const, thanks to Stephen
Hemminger for reporting this. The remaining patches are for ixgbe,
and the contain the following:
- minor cleanups
- add support for 82599 device and ethtool -E support
- removal of a PHY which is not used in production silicon
v2- Updated patch 11 with the suggested changes from Ben Hutchings
v3- Drop patch 11 so that Emil can re-work the patch based on feedback
The following are changes since commit 70f14381299984f05764c3188f1706288285c953:
bna: Multiple Definition and Interface Setup Fix
and are available in the git repository at
git://github.com/Jkirsher/net-next.git
Emil Tantilov (7):
ixgbe: prevent link checks while resetting
ixgbe: clear the data field in ixgbe_read_i2c_byte_generic
ixgbe: remove return code for functions that always return 0
ixgbe: add support for new 82599 device
ixgbe: send MFLCN to ethtool
ixgbe: do not disable flow control in ixgbe_check_mac_link
ixgbe: remove instances of ixgbe_phy_aq for 82598 and 82599
Jacob Keller (1):
ixgbe: fix driver version initialization in firmware
Jeff Kirsher (1):
e1000e: make function tables const
Mika Lansirinne (1):
ixgbe: get pauseparam autoneg
drivers/net/ethernet/intel/e1000e/80003es2lan.c | 8 ++--
drivers/net/ethernet/intel/e1000e/82571.c | 20 ++++++------
drivers/net/ethernet/intel/e1000e/e1000.h | 28 +++++++++---------
drivers/net/ethernet/intel/e1000e/ich8lan.c | 16 +++++-----
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 7 ----
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 7 +----
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 6 ----
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 13 +++-----
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 12 +++++--
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 33 +++++++--------------
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 1 +
12 files changed, 63 insertions(+), 89 deletions(-)
--
1.7.6.4
^ permalink raw reply
* Re: [PATCH] net-proc: expose the tos values in /proc/net/[tcp|udp]
From: Eric Dumazet @ 2011-10-05 9:34 UTC (permalink / raw)
To: MuraliRaja Muniraju
Cc: David Miller, kuznet, jmorris, yoshfuji, kaber, netdev,
linux-kernel
In-Reply-To: <CAP3iWTTYk7tErsCVdeytdpiu0fo-7B8cNZZk0EpR_rj-VOGi-g@mail.gmail.com>
Le mardi 04 octobre 2011 à 10:38 -0700, MuraliRaja Muniraju a écrit :
> I shall make the changes by exposing the tos values via the
> netlink as suggested. I had a doubt is I have to modify the
> inet_diag_sockid or export it via a new option. I am considering
> that adding into inet_diag_sockid is better because the latter is a
> bit of a over kill for a single value to be exposed and it also seems
> to be logical fit.
> Can you let me know your thoughts on this.
I believe you could add one "u32 tos" to struct tcp_info
[ It wont solve the UDP case, since "ss -u" still dumps /proc/net/udp
and /proc/net/udp6 ]
Following patch should handle tcp/dccp ipv4/ipv6
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 7f59ee9..eec6f3b 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -167,6 +167,7 @@ struct tcp_info {
__u32 tcpi_rcv_space;
__u32 tcpi_total_retrans;
+ __u32 tos;
};
/* for TCP_MD5SIG socket option */
diff --git a/net/dccp/diag.c b/net/dccp/diag.c
index b21f261..70d9498 100644
--- a/net/dccp/diag.c
+++ b/net/dccp/diag.c
@@ -37,6 +37,7 @@ static void dccp_get_info(struct sock *sk, struct tcp_info *info)
if (dp->dccps_hc_tx_ccid != NULL)
ccid_hc_tx_get_info(dp->dccps_hc_tx_ccid, sk, info);
+ info->tos = inet_sk(sk)->tos;
}
static void dccp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 4c0da24..b24c3d8 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2493,6 +2493,7 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
info->tcpi_rcv_space = tp->rcvq_space.space;
info->tcpi_total_retrans = tp->total_retrans;
+ info->tos = inet_sk(sk)->tos;
}
EXPORT_SYMBOL_GPL(tcp_get_info);
^ permalink raw reply related
* xfrm warning by mip6d
From: András Takács @ 2011-10-05 9:22 UTC (permalink / raw)
To: netdev
Dear All,
We're running mip6d mobile IPv6 daemon on 2.6.35.13 kernel. While it is sending periodic Binding Update messages via raw IPv6 socket the following warning message appears:
[ 946.883714] ------------[ cut here ]------------
[ 946.883714] WARNING: at trunk/kernel/linux-2.6.35.13/include/linux/skbuff.h:447 skb_dst.clone.22+0x42/0x44()
[ 946.883714] Hardware name: Bochs
[ 946.890048] Modules linked in: xfrm_user
[ 946.890179] Pid: 523, comm: mip6d Tainted: G W 2.6.35.13-itssv6 #1
[ 946.890270] Call Trace:
[ 946.890354] [<c0130e75>] warn_slowpath_common+0x65/0x7a
[ 946.890453] [<c03e2b11>] ? skb_dst.clone.22+0x42/0x44
[ 946.890553] [<c0130e99>] warn_slowpath_null+0xf/0x13
[ 946.890651] [<c03e2b11>] skb_dst.clone.22+0x42/0x44
[ 946.890748] [<c03e2e04>] ip6_finish_output2+0x15/0x23c
[ 946.890847] [<c0130e99>] ? warn_slowpath_null+0xf/0x13
[ 946.890947] [<c03e438f>] ip6_finish_output+0x8b3/0x8bf
[ 946.891048] [<c0130c9c>] ? print_oops_end_marker+0x1e/0x23
[ 946.891151] [<c0130e82>] ? warn_slowpath_common+0x72/0x7a
[ 946.891248] [<c03e2b11>] ? skb_dst.clone.22+0x42/0x44
[ 946.891346] [<c0130e99>] ? warn_slowpath_null+0xf/0x13
[ 946.891445] [<c03e4443>] ip6_output+0xa8/0xb0
[ 946.891539] [<c03dd551>] xfrm_output_resume+0x99/0x349
[ 946.891639] [<c03dd80e>] xfrm_output2+0xd/0xf
[ 946.891732] [<c03dd8a6>] xfrm_output+0x96/0xa0
[ 946.891828] [<c0404fbf>] xfrm6_output_finish+0x13/0x15
[ 946.891928] [<c04050fc>] xfrm6_output+0x4a/0x52
[ 946.892020] [<c03e2b28>] dst_output+0x15/0x18
[ 946.892111] [<c03e33b0>] ip6_local_out+0x17/0x1a
[ 946.892206] [<c03e502c>] ip6_push_pending_frames+0x27c/0x31f
[ 946.892314] [<c03f62f7>] rawv6_sendmsg+0xa79/0xb0b
[ 946.892411] [<c014e7ad>] ? __lock_acquire+0x54f/0xbdc
[ 946.892525] [<c03c932d>] inet_sendmsg+0x3d/0x46
[ 946.892623] [<c0383b2f>] __sock_sendmsg+0x45/0x4e
[ 946.892722] [<c0383f8f>] sock_sendmsg+0x92/0xa6
[ 946.892822] [<c014eec2>] ? lock_release_non_nested+0x88/0x1f7
[ 946.892927] [<c0177f81>] ? might_fault+0x46/0x80
[ 946.893023] [<c0177f81>] ? might_fault+0x46/0x80
[ 946.893121] [<c024a690>] ? _copy_from_user+0x39/0x4d
[ 946.893221] [<c0385656>] sys_sendmsg+0x17d/0x1e1
[ 946.893331] [<c014eec2>] ? lock_release_non_nested+0x88/0x1f7
[ 946.893436] [<c0177f81>] ? might_fault+0x46/0x80
[ 946.893531] [<c0177f81>] ? might_fault+0x46/0x80
[ 946.893628] [<c0385a28>] sys_socketcall+0x14b/0x189
[ 946.893725] [<c024a130>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 946.893827] [<c0119b17>] sysenter_do_call+0x12/0x36
[ 946.893915] ---[ end trace a2273a766b3b014c ]---
I tried to find the issue, and printed out the three condition values of WARN_ON macro:
[ 61.686487] debug skb->_skb_refdst: 00000000CED5EA01 SKB_DST_NOREF 0000000000000001 ==> 0000000000000001
[ 61.686649] rcu_read_lock_held() 0
[ 61.686730] rcu_read_lock_bh_held() 0
I think, that the issue is somewhere in the xfrm module, which includes the Home Address Destination Option header, before ip6_output.
Did anyone have the same issue before? Where do you thing the missing rcu lock is?
Thank you very much!
Regards,
András Takács
http://www.wakoond.hu
^ permalink raw reply
* Re: [PATCH v5 6/8] tcp buffer limitation: per-cgroup limit
From: Eric Dumazet @ 2011-10-05 8:58 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <4E8C1064.3030902@parallels.com>
Le mercredi 05 octobre 2011 à 12:08 +0400, Glauber Costa a écrit :
> On 10/04/2011 04:48 PM, Eric Dumazet wrote:
> > 2) Could you add const qualifiers when possible to your pointers ?
>
> Well, I'll go over the patches again and see where I can add them.
> Any specific place site you're concerned about?
Everywhere its possible :
It helps reader to instantly knows if a function is about to change some
part of the object or only read it, without reading function body.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Eric Dumazet @ 2011-10-05 8:53 UTC (permalink / raw)
To: starlight
Cc: Joe Perches, Christoph Lameter, Serge Belyshev, Con Kolivas,
linux-kernel, netdev, Willy Tarreau, Peter Zijlstra,
Stephen Hemminger
In-Reply-To: <6.2.5.6.2.20111005025227.03a9d9f0@binnacle.cx>
Le mercredi 05 octobre 2011 à 02:58 -0400, starlight@binnacle.cx a
écrit :
> Final note:
>
> I had captured latency measurements for
> two of the three kernels. Just ran
> 2.6.18(rhel5) and the results are
> stunning. The older kernel is much,
> much better then the newer kernel.
>
> Average latency is three times better
> and the standard deviation is six
> time better. As in 300% and 600%.
>
> Latency here is the time it takes
> a packet to travel from the kernel
> (where it is timestamped) till it
> reaches the final consumption point
> in the application.
>
> Makes me think that the old kernel
> is better at keeping caches hot and
> scheduling woken threads on the same
> cores as the threads that triggered
> them.
>
Note :
Your results are from a combination of a user application and kernel
default strategies.
On other combinations, results can be completely different.
A wakeup strategy is somewhat tricky :
- Should we affine or not.
- Should we queue the wakeup on a remote CPU, to keep scheduler data hot
in a single cpu cache.
- Should we use RPS/RFS to queue the packet to another CPU before even
handling it in our stack, to keep network data hot in a single cpu
cache. (check Documentation/networking/scaling.txt)
At least, with recent kernels, we have many available choices to tune a
workload.
^ permalink raw reply
* Re: linux-next: build failure after merge of the tip tree
From: Peter Zijlstra @ 2011-10-05 8:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
linux-kernel, Huang Ying, David Miller, netdev
In-Reply-To: <20111005172528.0d0a8afc65acef7ace22a24e@canb.auug.org.au>
On Wed, 2011-10-05 at 17:25 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr':
> net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration]
> net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default]
> net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool':
> net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
>
> Caused by commit 1230db8e1543 ("llist: Make some llist functions inline")
> interacting with commit 1bc144b62524 ("net, rds, Replace xlist in
> net/rds/xlist.h with llist") from the net tree. The former commit
> removes the declarations of llist_del_first() and llist_add_batch() with
> no explanation (and probably by accident since the definitions still
> exist).
Ugh yes, my bad. Ingo objected to inlining all those functions and I
then screwed up. There are no users of those two functions in my tree.
^ permalink raw reply
* Re: [net-next 1/1] bna: Multiple Definition and Interface Setup Fix
From: Stephen Rothwell @ 2011-10-05 8:26 UTC (permalink / raw)
To: David Miller
Cc: rmody, netdev, linux-next, linux-kernel, linux-scsi, rdunlap,
huangj, adapter_linux_open_src_team
In-Reply-To: <20111004.232713.1345786533613742751.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On Tue, 04 Oct 2011 23:27:13 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> From: Rasesh Mody <rmody@brocade.com>
> Date: Tue, 4 Oct 2011 19:31:20 -0700
>
> > drivers/net/built-in.o: In function `bfa_ioc_ct2_poweron':
> > (.text+0xcdc90): multiple definition of `bfa_ioc_ct2_poweron'
> > drivers/scsi/built-in.o:(.text+0x17f9a0): first defined here
> >
> > This patch renames bfa_ioc_ct2_poweron() to bfa_nw_ioc_ct2_poweron() to avoid
> > multiple definition with Brocade scsi driver. It also modifies asic specific
> > interface setup to allocate MSIX resources at power on in case of 1860 HW with
> > no asic block and warns if the asic gen is neither BFI_ASIC_GEN_CT nor
> > BFI_ASIC_GEN_CT2.
> >
> > Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> > Signed-off-by: Rasesh Mody <rmody@brocade.com>
>
> Applied, thanks.
I also manually applied this to linux-next today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [patch net-next-2.6] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-10-05 8:22 UTC (permalink / raw)
To: Flavio Leitner
Cc: netdev, davem, eric.dumazet, bhutchings, shemminger, fubar, andy,
tgraf, ebiederm, mirqus, kaber, greearb, jesse
In-Reply-To: <20111004142713.7d8aa201@asterix.rh>
Tue, Oct 04, 2011 at 07:27:13PM CEST, fbl@redhat.com wrote:
>On Tue, 4 Oct 2011 18:12:41 +0200
>Jiri Pirko <jpirko@redhat.com> wrote:
>
>> Tue, Oct 04, 2011 at 04:53:44PM CEST, fbl@redhat.com wrote:
>>
>> <snip>
>>
>> >> +
>> >> +struct team_mode_ops {
>> >> + int (*init)(struct team *team);
>> >> + void (*exit)(struct team *team);
>> >> + rx_handler_result_t (*receive)(struct team *team,
>> >> + struct team_port *port,
>> >> + struct sk_buff *skb);
>> >
>> >nitpick:
>> >As it doesn't have any other type of results, I would suggest
>> >to rename rx_handler_result_t be to shorter, i.e. rx_result_t.
>>
>> Well that type is defined already in include/linux/netdevice.h
>> I like the original name better because it has "handler" word in it
>> (which imo reduces possible confusion)
>
>Alright, I missed that somehow. Sorry.
>
>> >
>> >> + bool (*transmit)(struct team *team, struct sk_buff *skb);
>> >> + int (*port_enter)(struct team *team, struct team_port
>> >> *port);
>> >
>> >Perhaps instead of 'port_enter', use 'port_join'.
>>
>> Might be more appropriate, not sure (my eng skills recognize these two
>> as very similar in this case)
>
>Yeah, I am just trying to find the term that is most used for this. We
>used attach/detach terms in bonding driver and they seem appropriated
>to me.
Well it's more about "entering" and "leaving" team mode.
>
>
>> >> + int (*getter)(struct team *team, void *arg);
>> >> + int (*setter)(struct team *team, void *arg);
>> >
>> >What means getter and setter?
>>
>> Option getter and setter. Function used to set and get the option.
>
>sorry, I meant the last part of it - "ter".
>getoption and setoption would make more sense to me.
I think current naming is appropriate. Similar to obj languages
terminology.
>
>
><snipped>
>> >> + union {
>> >> + char priv_first_byte;
>> >> + struct ab_priv ab_priv;
>> >> + struct rr_priv rr_priv;
>> >> + };
>> >
>> >I think the union should be a pointer or work in the same
>> >way as netdev_priv() does.
>>
>> The reason I did this this way is saving one pointer dereference in
>> hot paths. In netdev priv the memory for priv data is allcated along
>> with netdev struct. In this case this is not possible because mode
>> can be changed during team device lifetime (and team priv is netdev
>> priv).
>>
>
>but then any external/new team mode will require patching the
>team driver.
Yes.
>
>> <snip>
>>
>> >> +
>> >> +static bool rr_transmit(struct team *team, struct sk_buff *skb)
>> >> +{
>> >> + struct team_port *port;
>> >> + int port_index;
>> >> +
>> >> + port_index = team->rr_priv.sent_packets++ %
>> >> team->port_count;
>> >> + port = team_get_port_by_index_rcu(team, port_index);
>> >> + port = __get_first_port_up(team, port);
>> >
>> >Well, __get_first_port_up() will frequently just do:
>> >
>> > if (port->linkup)
>> > return port;
>> >
>> >so, as it is in the hot TX path, can this be modified to be something
>> >like below to avoid one function call?
>> >
>> > port = team_get_port_by_index_rcu(team, port_index);
>> > if (unlikely(port->linkup))
>> > port = __get_first_port_up(team, port);
>>
>> Hmm, I don't think this is correct place to use "likely". Imagine you
>> have 2 ports and one of them is down all the team lifetime. You would
>> be hitting wrong branch always which will cause performance penalty.
>
>Right, my point was to avoid the extra function call.
>I agree with you that using "likely" there might not be a good idea.
>
>
>> >> +
>> >> +static const struct team_mode ab_mode = {
>> >> + .kind = "activebackup",
>> >> + .ops = &ab_mode_ops,
>> >> +};
>> >> +
>> >
>> >I would suggest to move each of the ab and rr specifics
>> >to their own module. The idea is to have the team module
>> >as a generic module as possible and every mode on its module.
>> >Not sure what your plans are for this.
>>
>> Well I was thinking about this for sure. One reason to have this in
>> one place is the mode_priv union you were referring to.
>> Other reason is that mode parts should be very easy and short. Also
>> their number should be limited (~4).
>>
>
>Are you sure? :)
Well I'm not. I must admit I did have module loading implemented already
in similar way it's done in md raid code. But on second though, I
realized I do not want team to be second bonding with bazillion ugly
modes as atb and such. Therefore I decided to make that in more "static"
way to make mode code as much slim as it can be. The goal is to provide
adventerous people tools to do their ugly tricks in userspace :)
>
>
>> <snip>
>> >> +
>> >> +static struct rtnl_link_stats64 *team_get_stats(struct net_device
>> >> *dev,
>> >> + struct
>> >> rtnl_link_stats64 *stats) +{
>> >> + struct team *team = netdev_priv(dev);
>> >> + struct rtnl_link_stats64 temp;
>> >> + struct team_port *port;
>> >> +
>> >> + memset(stats, 0, sizeof(*stats));
>> >> +
>> >> + rcu_read_lock();
>> >> + list_for_each_entry_rcu(port, &team->port_list, list) {
>> >> + const struct rtnl_link_stats64 *pstats;
>> >> +
>> >> + pstats = dev_get_stats(port->dev, &temp);
>> >> +
>> >> + stats->rx_packets += pstats->rx_packets;
>> >> + stats->rx_bytes += pstats->rx_bytes;
>> >> + stats->rx_errors += pstats->rx_errors;
>> >> + stats->rx_dropped += pstats->rx_dropped;
>> >> +
>> >> + stats->tx_packets += pstats->tx_packets;
>> >> + stats->tx_bytes += pstats->tx_bytes;
>> >> + stats->tx_errors += pstats->tx_errors;
>> >> + stats->tx_dropped += pstats->tx_dropped;
>> >> +
>> >> + stats->multicast += pstats->multicast;
>> >> + stats->collisions += pstats->collisions;
>> >> +
>> >> + stats->rx_length_errors +=
>> >> pstats->rx_length_errors;
>> >> + stats->rx_over_errors += pstats->rx_over_errors;
>> >> + stats->rx_crc_errors += pstats->rx_crc_errors;
>> >> + stats->rx_frame_errors += pstats->rx_frame_errors;
>> >> + stats->rx_fifo_errors += pstats->rx_fifo_errors;
>> >> + stats->rx_missed_errors +=
>> >> pstats->rx_missed_errors; +
>> >> + stats->tx_aborted_errors +=
>> >> pstats->tx_aborted_errors;
>> >> + stats->tx_carrier_errors +=
>> >> pstats->tx_carrier_errors;
>> >> + stats->tx_fifo_errors += pstats->tx_fifo_errors;
>> >> + stats->tx_heartbeat_errors +=
>> >> pstats->tx_heartbeat_errors;
>> >> + stats->tx_window_errors +=
>> >> pstats->tx_window_errors;
>> >> + }
>> >> + rcu_read_unlock();
>> >> +
>> >> + return stats;
>> >> +}
>> >
>> >I don't think computing stats like that is useful. We can do
>> >that in userlevel with ethtool -S on each slave and sum all them.
>> >I think it would be better to have the errors computed based on
>> >events that happens inside of Team driver, so we can really see if
>> >something is happening inside of the Team driver or on its slaves.
>>
>> I was thinking about this as well. I did this in same ways it's done
>> in bonding driver. One of reasons were that I can't count dropped
>> packets in team_handle_frame because I do not call netif_rx there and
>> only return RX_HANDLER_ANOTHER to "reinject" (saving one function
>> call).
>>
>
>My concern is that while debugging some issue, I cannot tell if Team
>driver dropped packets or not. Actually, there are some places in the
>patch dropping skbs without any sort of notification. So, I suggested
>to compute the stats leaving the slave stats out of it but now I have
>realized that the admin and monitoring tools will expect to find the
>interface stats to be a sum of all its slaves.
>
>I think the solution would be having a master stats set apart to keep
>track of internal driver work and then sum the slaves stats like the
>patch does right now. By doing so, I can grab ethtool -S of all slaves,
>sum them, and check if Team dropped or not.
I see your point. I will try to implement this (I have an idea how to maybe
resolve RX_HANDLER_ANOTHER missed result problem)
>
>
>
>>
>> <snip>
>>
>> >> +
>> >> +static int team_add_slave(struct net_device *dev, struct
>> >> net_device *port_dev) +{
>> >> + struct team *team = netdev_priv(dev);
>> >> + int err;
>> >> +
>> >> + spin_lock(&team->lock);
>> >> + err = team_port_add(team, port_dev);
>> >> + spin_unlock(&team->lock);
>> >> + return err;
>> >> +}
>> >
>> >I am not seeing any difference between slave and port, so why not
>> >stick with just one?
>>
>> I like "port" better. It's more accurate.
>
>Definitely.
>
>> team_add/del_slave has its
>> name only because ndo is named the same.
>
>Hm, makes sense then.
>
>Although I am still digesting the patch, nice work Jiri!
>thanks,
>fbl
>
>
>
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Eli Cohen @ 2011-10-05 8:15 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Benjamin Herrenschmidt, Yevgeny Petrilin, netdev@vger.kernel.org,
Eli Cohen, linuxppc-dev
In-Reply-To: <20111004202620.GA3455@oc1711230544.ibm.com>
On Tue, Oct 04, 2011 at 05:26:20PM -0300, Thadeu Lima de Souza Cascardo wrote:
I believe we have an endianess problem here. The source buffer is in
big endian - in x86 archs, it will rich the pci device unswapped since
both x86 and pci are little endian. In ppc, it wil be swapped by the
chipset so it will reach the device in little endian which is wrong.
So, in mlx4_bf_copy, you could loop over the buffer and swap32 the all
the dwords before the call to __iowrite64_copy. Of course which should
fix this in an arch independent manner. Let me know this works for
you.
> On Tue, Oct 04, 2011 at 08:02:12AM +0200, Benjamin Herrenschmidt wrote:
> > On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
> >
> > .../...
> >
> > > > Can you also send me the output of ethtool -i?
> > > > It seems that there is a problem with write combining on Power processors, we will check this issue.
> > > >
> > > > Yevgeny
> > >
> > > Hello, Yevgeny.
> > >
> > > You will find the output of ethtool -i below.
> > >
> > > I am copying Ben and powerpc list, in case this is an issue with Power
> > > processors. They can provide us some more insight into this.
> >
> > May I get some background please ? :-)
> >
> > I'm not aware of a specific issue with write combining but I'd need to
> > know more about what you are doing and the code to do it to comment on
> > whether it should work or not.
> >
> > Cheers,
> > Ben.
> >
> >
>
> Hello, Ben.
>
> Sorry for that. I am testing mlx4_en driver on a POWER. Yevgeny has
> added blue frame support, that does not require writing to the device
> memory to indicate a new packet (the doorbell register as it is called).
>
> Well, the ring is getting full with no interrupt or packets transmitted.
> I simply added a write to the doorbell register and it works for me.
> Yevgeny says this is not the right fix, claiming there is a problem with
> write combining on POWER. The code uses memory barriers, so I don't know
> why there is any problem.
>
> I am posting the code here to show better what the situation is.
> Yevgeny can tell more about the device and the driver.
>
> The code below is the driver as of now, including a diff with what I
> changed and had resulted OK for me. Before the blue frame support, the
> only code executed was the else part. I can't tell much what the device
> should be seeing and doing after the blue frame part of the code is
> executed. But it does send the packet if I write to the doorbell
> register.
>
> Yevgeny, can you tell us what the device should be doing and why you
> think this is a problem on POWER? Is it possible that this is simply a
> problem with the firmware version?
>
> Thanks,
> Cascardo.
>
> ---
> if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
> !vlan_tag) {
> *(u32 *) (&tx_desc->ctrl.vlan_tag) |=
> ring->doorbell_qpn;
> op_own |= htonl((bf_index & 0xffff) << 8);
> /* Ensure new descirptor hits memory
> * before setting ownership of this descriptor to HW */
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
>
> wmb();
>
> mlx4_bf_copy(ring->bf.reg + ring->bf.offset, (unsigned
> long *) &tx_desc->ctrl,
> desc_size);
>
> wmb();
>
> ring->bf.offset ^= ring->bf.buf_size;
> } else {
> /* Ensure new descirptor hits memory
> * before setting ownership of this descriptor to HW */
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
> - wmb();
> - writel(ring->doorbell_qpn, ring->bf.uar->map +
> MLX4_SEND_DOORBELL);
> }
>
> + wmb();
> + writel(ring->doorbell_qpn, ring->bf.uar->map +
> MLX4_SEND_DOORBELL);
> +
> ---
^ permalink raw reply
* Re: [PATCH v5 6/8] tcp buffer limitation: per-cgroup limit
From: Glauber Costa @ 2011-10-05 8:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <1317732535.2440.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 10/04/2011 04:48 PM, Eric Dumazet wrote:
> Le mardi 04 octobre 2011 à 16:17 +0400, Glauber Costa a écrit :
>> This patch uses the "tcp_max_mem" field of the kmem_cgroup to
>> effectively control the amount of kernel memory pinned by a cgroup.
>>
>> We have to make sure that none of the memory pressure thresholds
>> specified in the namespace are bigger than the current cgroup.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
>> ---
>
>
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -256,6 +256,7 @@ extern int sysctl_tcp_thin_dupack;
>> struct mem_cgroup;
>> struct tcp_memcontrol {
>> /* per-cgroup tcp memory pressure knobs */
>> + int tcp_max_memory;
>> atomic_long_t tcp_memory_allocated;
>> struct percpu_counter tcp_sockets_allocated;
>> /* those two are read-mostly, leave them at the end */
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>
> So tcp_max_memory is an "int".
>
>
>> +static u64 tcp_read_limit(struct cgroup *cgrp, struct cftype *cft)
>> +{
>> + struct mem_cgroup *memcg = mem_cgroup_from_cont(cgrp);
>> + return memcg->tcp.tcp_max_memory<< PAGE_SHIFT;
>> +}
>
> 1) Typical integer overflow here.
>
> You need :
>
> return ((u64)memcg->tcp.tcp_max_memory)<< PAGE_SHIFT;
Thanks for spotting this, Eric.
>
> 2) Could you add const qualifiers when possible to your pointers ?
Well, I'll go over the patches again and see where I can add them.
Any specific place site you're concerned about?
^ permalink raw reply
* Re: [PATCH v5 0/8] per-cgroup tcp buffer pressure settings
From: Glauber Costa @ 2011-10-05 7:25 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, paul, lizf, ebiederm, davem, gthelen, netdev,
linux-mm, kirill, avagin, devel
In-Reply-To: <20111005092954.718a0c29.kamezawa.hiroyu@jp.fujitsu.com>
On 10/05/2011 04:29 AM, KAMEZAWA Hiroyuki wrote:
> On Tue, 4 Oct 2011 16:17:52 +0400
> Glauber Costa<glommer@parallels.com> wrote:
>
>> [[ v3: merge Kirill's suggestions, + a destroy-related bugfix ]]
>> [[ v4: Fix a bug with non-mounted cgroups + disallow task movement ]]
>> [[ v5: Compile bug with modular ipv6 + tcp files in bytes ]]
>>
>> Kame, Kirill,
>>
>> I am submitting this again merging most of your comments. I've decided to
>> leave some of them out:
>> * I am not using res_counters for allocated_memory. Besides being more
>> expensive than what we need, to make it work in a nice way, we'd have
>> to change the !cgroup code, including other protocols than tcp. Also,
>>
>> * I am not using failcnt and max_usage_in_bytes for it. I believe the value
>> of those lies more in the allocation than in the pressure control. Besides,
>> fail conditions lie mostly outside of the memory cgroup's control. (Actually,
>> a soft_limit makes a lot of sense, and I do plan to introduce it in a follow
>> up series)
>>
>> If you agree with the above, and there are any other pressing issues, let me
>> know and I will address them ASAP. Otherwise, let's discuss it. I'm always open.
>>
>
> I'm not familar with reuqirements of users. So, I appreciate your choices.
> What I adivse you here is taking a deep breath. Making new version every day
> is not good for reviewing process ;)
> (It's now -rc8 and merge will not be so quick, anyway.)
Kame,
Absolutely. I only did it this time because the difference between them
were really, really small.
> At this stage, my concern is view of interfaces and documenation, and future plans.
Okay. I will try to address them as well as I can.
> Let me give a try explanation by myself. (Correct me ;)
> I added some questions but I'm sorry you've already answered.
>
> New interfaces are 5 files. All files exists only for non-root memory cgroup.
>
> 1. memory.independent_kmem_limit
> 2. memory.kmem.usage_in_bytes
> 3. memory.kmem.limit_in_bytes
> 4. memory.kmem.tcp.limit_in_bytes
> 5. memory.kmem.tcp.usage_in_bytes
Correct so far. Note that the tcp memory pressure parameters right now
consists of 3 numbers, one of them being a soft limit. I plan to add the
soft limit file in a follow up patch, to avoid adding more and more
stuff for us to review here. (Unless of course you want to see it now)
> * memory.independent_kmem_limit
> If 1, kmem_limit_in_bytes/kmem_usage_in_bytes works.
> If 0, kmem_limit_in_bytes/kmem_usage_in_bytes doesn't work and all kmem
> usages are controlled under memory.limit_in_bytes.
Correct. For the questions below, I won't even look at the code not to
get misguided. Let's settle on the desired behavior, and everything that
deviates from it, is a bug.
> Question:
> - What happens when parent/chidlren cgroup has different indepedent_kmem_limit ?
I think it should be forbidden. It was raised by Kirill before, and
IIRC, he specifically requested it to be. (Okay: Saying it now, makes me
realizes that the child can have set it to 1 while parent was 1. But
then parent sets it to 0... I don't think I am handling this case).
> - What happens at creating a new cgroup with use_hierarchy==1.
>
> * memory.kmem_limit_in_bytes/memory.kmem.tcp.limit_in_bytes
>
> Both files works independently for _Now_. And memory.kmem_usage_in_bytes and
> memory.kmem_tcp.usage_in_bytes has no relationships.
Correct.
> In future plan, kmem.usage_in_bytes should includes tcp.kmem_usage_in_bytes.
> And kmem.limit_in_bytes should be the limiation of sum of all kmem.xxxx.limit_in_bytes.
I am not sure there will be others xxx.limit_in_bytes. (see below)
>
> Question:
> - Why this integration is difficult ?
It is not that it is difficult.
What happens is that there are two things taking place here:
One of them is allocation.
The other, is tcp-specific pressure thresholds. Bear with me with the
following example code: (from sk_stream_alloc_skb, net/ipv4/tcp.c)
1: skb = alloc_skb_fclone(size + sk->sk_prot->max_header, gfp);
if (skb) {
3: if (sk_wmem_schedule(sk, skb->truesize)) {
/*
* Make sure that we have exactly size bytes
* available to the caller, no more, no less.
*/
skb_reserve(skb, skb_tailroom(skb) - size);
return skb;
}
__kfree_skb(skb);
} else {
sk->sk_prot->enter_memory_pressure(sk);
sk_stream_moderate_sndbuf(sk);
}
In line 1, an allocation takes place. This allocs memory from the skbuff
slab cache.
But then, pressure thresholds are applied in 3. If it fails, we drop the
memory buffer even if the allocation succeeded.
So this patchset, as I've stated already, cares about pressure
conditions only. It is enough to guarantee that no more memory will be
pinned that we specified, because we'll free the allocation in case
pressure is reached.
There is work in progress from guys at google (and I have my very own
PoCs as well), to include all slab allocations in kmem.usage_in_bytes.
So what I really mean here with "will integrate later", is that I think
that we'd be better off tracking the allocations themselves at the slab
level.
> Can't tcp-limit-code borrows some amount of charges in batch from kmem_limit
> and use it ?
Sorry, I don't know what exactly do you mean. Can you clarify?
> - Don't you need a stat file to indicate "tcp memory pressure works!" ?
> It can be obtained already ?
Not 100 % clear as well. We can query the amount of buffer used, and the
amount of buffer allowed. What else do we need?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: starlight @ 2011-10-05 6:58 UTC (permalink / raw)
To: Joe Perches, Christoph Lameter, Serge Belyshev, Con Kolivas
Cc: Eric Dumazet, linux-kernel, netdev, Willy Tarreau, Peter Zijlstra,
Stephen Hemminger
Final note:
I had captured latency measurements for
two of the three kernels. Just ran
2.6.18(rhel5) and the results are
stunning. The older kernel is much,
much better then the newer kernel.
Average latency is three times better
and the standard deviation is six
time better. As in 300% and 600%.
Latency here is the time it takes
a packet to travel from the kernel
(where it is timestamped) till it
reaches the final consumption point
in the application.
Makes me think that the old kernel
is better at keeping caches hot and
scheduling woken threads on the same
cores as the threads that triggered
them.
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Eric Dumazet @ 2011-10-05 6:53 UTC (permalink / raw)
To: starlight
Cc: linux-kernel, netdev, Willy Tarreau, Peter Zijlstra,
Stephen Hemminger
In-Reply-To: <6.2.5.6.2.20111003140010.05a70ed0@binnacle.cx>
Le lundi 03 octobre 2011 à 14:02 -0400, starlight@binnacle.cx a écrit :
> At 06:16 PM 10/3/2011 +0200, Eric Dumazet wrote:
> >
> >It seems you use 4096 2MB hugepages, and your
> >machine has 1GB pages availabe, you could
> >try to use them.
> >
> >(boot cmd : hugepagesz=1GB hugepages=8 )
>
> Tried it and got errno 12 on the segment
> allocations. None were allocated, though
> the count is six and the largest is exactly
> 1GB. Don't have time to dig into it.
>
Thats pretty normal ;)
With 2MB pages, your segment size must be a 2MB multiple.
With 1GB pages, your segment size must be a .... 1GB multiple.
So only applicable is say you handle one big 8GB segment for example, or
2 4GB segments... Well you see the picture.
^ permalink raw reply
* Re: [PATCH 1/2] fix lockdep warning
From: Hans Schillstrom @ 2011-10-05 6:31 UTC (permalink / raw)
To: Julian Anastasov
Cc: Hans Schillstrom, horms, wensong, lvs-devel, netdev,
netfilter-devel
In-Reply-To: <alpine.LFD.2.00.1110050133290.2388@ja.ssi.bg>
On Wednesday, October 05, 2011 00:51:31 Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 3 Oct 2011, Hans Schillstrom wrote:
>
[snip]
>
> ip_vs_rs_key remains unused without debugging. I don't
> remember the reason why IPVS is the only place that calls
> __rwlock_init instead of rwlock_init. Can we use rwlock_init?
I'm Sorry, this was not meant to go to the list :-(
It should be rwlock_init() as you say
I'll send a new one row patch...
Thanks
Hans
^ permalink raw reply
* linux-next: build failure after merge of the tip tree
From: Stephen Rothwell @ 2011-10-05 6:25 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Huang Ying, David Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
net/rds/ib_rdma.c: In function 'rds_ib_reuse_fmr':
net/rds/ib_rdma.c:272:2: error: implicit declaration of function 'llist_del_first' [-Werror=implicit-function-declaration]
net/rds/ib_rdma.c:272:6: warning: assignment makes pointer from integer without a cast [enabled by default]
net/rds/ib_rdma.c: In function 'rds_ib_flush_mr_pool':
net/rds/ib_rdma.c:671:4: error: implicit declaration of function 'llist_add_batch' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
Caused by commit 1230db8e1543 ("llist: Make some llist functions inline")
interacting with commit 1bc144b62524 ("net, rds, Replace xlist in
net/rds/xlist.h with llist") from the net tree. The former commit
removes the declarations of llist_del_first() and llist_add_batch() with
no explanation (and probably by accident since the definitions still
exist).
I have added the following patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 5 Oct 2011 17:16:29 +1100
Subject: [PATCH] llist: add back llist_add_batch and llist_del_first
Commit 1230db8e1543 ("llist: Make some llist functions inline") appears
to have deleted the definitions by accident.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/llist.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/llist.h b/include/linux/llist.h
index 837fb4a..7287734 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -178,4 +178,10 @@ static inline struct llist_node *llist_del_all(struct llist_head *head)
{
return xchg(&head->first, NULL);
}
+
+extern bool llist_add_batch(struct llist_node *new_first,
+ struct llist_node *new_last,
+ struct llist_head *head);
+extern struct llist_node *llist_del_first(struct llist_head *head);
+
#endif /* LLIST_H */
--
1.7.6.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: starlight @ 2011-10-05 6:11 UTC (permalink / raw)
To: Joe Perches, Christoph Lameter, Serge Belyshev, Con Kolivas
Cc: Eric Dumazet, linux-kernel, netdev, Willy Tarreau, Peter Zijlstra,
Stephen Hemminger
Gremlins!
In my haste I overlooked that changing the
thread pool from 140 to 13 is radical,
especially with a core count matching
the thread count. Apples and oranges.
Ran the small-pool test on the other two
kernels and here are the results. The
user and system columns are in jiffies.
kernel total user system
2.6.18(rhel5) 02:07:16 615516 148152 (19.4%)
2.6.39.4 02:27:44 658074 228420 (25.7%)
2.6.39.4(bfs) 02:34:49 899936 29000 (3%)
So BFS performs somewhat worse than the default
scheduler on total-CPU. The old RHEL 5 kernel
is still the winner, but not by nearly as
much in the small thread-pool scenario--.39
is only 16% slower than .18 with the
system overhead being 55% worse rather
than 100% worse.
So all that is shown after all is that
the differential between the older and
newer kernels is strongly influenced by
the number of active threads, and the O(N)
aspect of BFS makes it an inappropriate
choice for heavy multithreaded workloads.
Also small thread pools are more efficient
than large ones (especially when the workflow
is routed for optimal cache locality as
is the case here). However the small
pool does not scale as well to maximum CPU
load as the large pool (a different test)
which is why it is no longer used in
production and was only dusted off
in order to enable the BFS comparison.
^ permalink raw reply
* [patch] bnx2x: remove some dead code
From: Dan Carpenter @ 2011-10-05 5:49 UTC (permalink / raw)
To: Eilon Greenstein; +Cc: netdev, kernel-janitors
This code is after the break statement so it never gets used. The
"vlan_mac_obj" variable does get initialized properly, so we can just
delete this.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 04f17a1..6486ab8 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -4353,8 +4353,6 @@ static inline void bnx2x_handle_classification_eqe(struct bnx2x *bp,
vlan_mac_obj = &bp->fp[cid].mac_obj;
break;
- vlan_mac_obj = &bp->fp[cid].mac_obj;
-
case BNX2X_FILTER_MCAST_PENDING:
/* This is only relevant for 57710 where multicast MACs are
* configured as unicast MACs using the same ramrod.
^ permalink raw reply related
* [RFC] [PATCH] virtio: Dont add "config" to list for !per_vq_vector
From: Krishna Kumar @ 2011-10-05 5:38 UTC (permalink / raw)
To: rusty, mst; +Cc: netdev, linux-kernel, Krishna Kumar, virtualization
For the MSI but non-per_vq_vector case, the config/change vq
also gets added to the list of vqs that need to process the
MSI interrupt. This is not needed as config has it's own
handler (vp_config_changed). In any case, vring_interrupt()
finds nothing needs to be done on this vq.
I tested this patch by testing the "Fallback:" and "Finally
fall back" cases in vp_find_vqs(). Please review.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
---
drivers/virtio/virtio_pci.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff -ruNp org/drivers/virtio/virtio_pci.c new/drivers/virtio/virtio_pci.c
--- org/drivers/virtio/virtio_pci.c 2011-10-03 09:10:11.000000000 +0530
+++ new/drivers/virtio/virtio_pci.c 2011-10-04 19:16:34.000000000 +0530
@@ -415,9 +415,13 @@ static struct virtqueue *setup_vq(struct
}
}
- spin_lock_irqsave(&vp_dev->lock, flags);
- list_add(&info->node, &vp_dev->virtqueues);
- spin_unlock_irqrestore(&vp_dev->lock, flags);
+ if (callback) {
+ spin_lock_irqsave(&vp_dev->lock, flags);
+ list_add(&info->node, &vp_dev->virtqueues);
+ spin_unlock_irqrestore(&vp_dev->lock, flags);
+ } else {
+ INIT_LIST_HEAD(&info->node);
+ }
return vq;
^ permalink raw reply
* [PATCH 4/4] atm: solos-pci: M25P/M25PE SPI flash support
From: Nathan Williams @ 2011-10-05 4:46 UTC (permalink / raw)
To: netdev; +Cc: linux-atm-general, David Woodhouse, linux-kernel
Newer Geos ADSL2+ routers have different SPI flash.
The FPGA on these boards require driver version = 1 to enable
flash upgrades so old drivers can't corrupt new boards.
Signed-off-by: Nathan Williams <nathan@traverse.com.au>
---
drivers/atm/solos-pci.c | 51 ++++++++++++++++++++++++++++++++++++----------
1 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 33c0c2b..2a75bf7 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -42,7 +42,8 @@
#include <linux/swab.h>
#include <linux/slab.h>
-#define VERSION "0.07"
+#define VERSION "1.0"
+#define DRIVER_VERSION 0x01
#define PTAG "solos-pci"
#define CONFIG_RAM_SIZE 128
@@ -57,16 +58,20 @@
#define FPGA_MODE 0x5C
#define FLASH_MODE 0x58
#define GPIO_STATUS 0x54
+#define DRIVER_VER 0x50
#define TX_DMA_ADDR(port) (0x40 + (4 * (port)))
#define RX_DMA_ADDR(port) (0x30 + (4 * (port)))
#define DATA_RAM_SIZE 32768
#define BUF_SIZE 2048
#define OLD_BUF_SIZE 4096 /* For FPGA versions <= 2*/
-#define FPGA_PAGE 528 /* FPGA flash page size*/
-#define SOLOS_PAGE 512 /* Solos flash page size*/
-#define FPGA_BLOCK (FPGA_PAGE * 8) /* FPGA flash block size*/
-#define SOLOS_BLOCK (SOLOS_PAGE * 8) /* Solos flash block size*/
+/* Old boards use ATMEL AD45DB161D flash */
+#define ATMEL_FPGA_PAGE 528 /* FPGA flash page size*/
+#define ATMEL_SOLOS_PAGE 512 /* Solos flash page size*/
+#define ATMEL_FPGA_BLOCK (ATMEL_FPGA_PAGE * 8) /* FPGA block size*/
+#define ATMEL_SOLOS_BLOCK (ATMEL_SOLOS_PAGE * 8) /* Solos block size*/
+/* Current boards use M25P/M25PE SPI flash */
+#define SPI_FLASH_BLOCK (256 * 64)
#define RX_BUF(card, nr) ((card->buffers) + (nr)*(card->buffer_size)*2)
#define TX_BUF(card, nr) ((card->buffers) + (nr)*(card->buffer_size)*2 + (card->buffer_size))
@@ -128,6 +133,7 @@ struct solos_card {
int using_dma;
int fpga_version;
int buffer_size;
+ int atmel_flash;
};
@@ -631,16 +637,25 @@ static int flash_upgrade(struct solos_card *card, int chip)
switch (chip) {
case 0:
fw_name = "solos-FPGA.bin";
- blocksize = FPGA_BLOCK;
+ if (card->atmel_flash)
+ blocksize = ATMEL_FPGA_BLOCK;
+ else
+ blocksize = SPI_FLASH_BLOCK;
break;
case 1:
fw_name = "solos-Firmware.bin";
- blocksize = SOLOS_BLOCK;
+ if (card->atmel_flash)
+ blocksize = ATMEL_SOLOS_BLOCK;
+ else
+ blocksize = SPI_FLASH_BLOCK;
break;
case 2:
if (card->fpga_version > LEGACY_BUFFERS){
fw_name = "solos-db-FPGA.bin";
- blocksize = FPGA_BLOCK;
+ if (card->atmel_flash)
+ blocksize = ATMEL_FPGA_BLOCK;
+ else
+ blocksize = SPI_FLASH_BLOCK;
} else {
dev_info(&card->dev->dev, "FPGA version doesn't support"
" daughter board upgrades\n");
@@ -650,7 +665,10 @@ static int flash_upgrade(struct solos_card *card, int chip)
case 3:
if (card->fpga_version > LEGACY_BUFFERS){
fw_name = "solos-Firmware.bin";
- blocksize = SOLOS_BLOCK;
+ if (card->atmel_flash)
+ blocksize = ATMEL_SOLOS_BLOCK;
+ else
+ blocksize = SPI_FLASH_BLOCK;
} else {
dev_info(&card->dev->dev, "FPGA version doesn't support"
" daughter board upgrades\n");
@@ -695,9 +713,13 @@ static int flash_upgrade(struct solos_card *card, int chip)
/* dev_info(&card->dev->dev, "Set FPGA Flash mode to Block Write\n"); */
iowrite32(((chip * 2) + 1), card->config_regs + FLASH_MODE);
- /* Copy block to buffer, swapping each 16 bits */
+ /* Copy block to buffer, swapping each 16 bits for Atmel flash */
for(i = 0; i < blocksize; i += 4) {
- uint32_t word = swahb32p((uint32_t *)(fw->data + offset + i));
+ uint32_t word;
+ if (card->atmel_flash)
+ word = swahb32p((uint32_t *)(fw->data + offset + i));
+ else
+ word = *(uint32_t *)(fw->data + offset + i);
if(card->fpga_version > LEGACY_BUFFERS)
iowrite32(word, FLASH_BUF + i);
else
@@ -1249,6 +1271,11 @@ static int fpga_probe(struct pci_dev *dev, const struct pci_device_id *id)
db_fpga_upgrade = db_firmware_upgrade = 0;
}
+ /* Stopped using Atmel flash after 0.03-38 */
+ if (fpga_ver < 39)
+ card->atmel_flash = 1;
+ else
+ card->atmel_flash = 0;
if (card->fpga_version >= DMA_SUPPORTED){
card->using_dma = 1;
} else {
@@ -1256,6 +1283,8 @@ static int fpga_probe(struct pci_dev *dev, const struct pci_device_id *id)
/* Set RX empty flag for all ports */
iowrite32(0xF0, card->config_regs + FLAGS_ADDR);
}
+ /* New FPGAs require driver version before permitting flash upgrades */
+ iowrite32(DRIVER_VERSION, card->config_regs + DRIVER_VER);
data32 = ioread32(card->config_regs + PORTS);
card->nr_ports = (data32 & 0x000000FF);
--
1.7.2.5
^ permalink raw reply related
* [PATCH 3/4] atm: solos-pci: Add support for Geos GPIO pins
From: Nathan Williams @ 2011-10-05 4:45 UTC (permalink / raw)
To: netdev; +Cc: linux-atm-general, David Woodhouse, linux-kernel
Geos ADSL2+ routers have on-board Solos chipsets with some
extra I/O pins and a push button connected to the FPGA.
PCB version and variant numbers are also made available
through the HardwareVersion and HardwareVariant attributes.
Signed-off-by: Nathan Williams <nathan@traverse.com.au>
---
drivers/atm/solos-pci.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 98 insertions(+), 0 deletions(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index bd01aa3..33c0c2b 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -56,6 +56,7 @@
#define FLASH_BUSY 0x60
#define FPGA_MODE 0x5C
#define FLASH_MODE 0x58
+#define GPIO_STATUS 0x54
#define TX_DMA_ADDR(port) (0x40 + (4 * (port)))
#define RX_DMA_ADDR(port) (0x30 + (4 * (port)))
@@ -498,6 +499,87 @@ static ssize_t console_store(struct device *dev, struct device_attribute *attr,
return err?:count;
}
+struct geos_gpio {
+ char *name;
+ int offset;
+};
+
+static struct geos_gpio geos_gpio_pins[] = {
+ {"GPIO1", 9},
+ {"GPIO2", 10},
+ {"GPIO3", 11},
+ {"GPIO4", 12},
+ {"GPIO5", 13},
+ {"PushButton", 14},
+ {NULL, 0}
+};
+
+static ssize_t geos_gpio_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct atm_dev *atmdev = container_of(dev, struct atm_dev, class_dev);
+ struct solos_card *card = atmdev->dev_data;
+ uint32_t data32;
+
+ struct geos_gpio *p = geos_gpio_pins;
+ while(p->name){
+ if(!strcmp(attr->attr.name, p->name)){
+ break;
+ }
+ p++;
+ }
+
+ data32 = ioread32(card->config_regs + GPIO_STATUS);
+ if(buf[0] == '1'){
+ data32 |= 1 << p->offset;
+ iowrite32(data32, card->config_regs + GPIO_STATUS);
+ } else if(buf[0] == '0') {
+ data32 &= ~(1 << p->offset);
+ iowrite32(data32, card->config_regs + GPIO_STATUS);
+ }
+ return count;
+}
+
+static ssize_t geos_gpio_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct atm_dev *atmdev = container_of(dev, struct atm_dev, class_dev);
+ struct solos_card *card = atmdev->dev_data;
+ uint32_t data32;
+
+ struct geos_gpio *p = geos_gpio_pins;
+ while(p->name){
+ if(!strcmp(attr->attr.name, p->name)){
+ break;
+ }
+ p++;
+ }
+
+ data32 = ioread32(card->config_regs + GPIO_STATUS);
+ data32 = (data32 >> p->offset) & 1;
+
+ return sprintf(buf, "%d\n", data32);
+}
+
+static ssize_t hardware_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct atm_dev *atmdev = container_of(dev, struct atm_dev, class_dev);
+ struct solos_card *card = atmdev->dev_data;
+ uint32_t data32;
+
+ data32 = ioread32(card->config_regs + GPIO_STATUS);
+ if(!strcmp(attr->attr.name, "HardwareVersion")){
+ data32 = data32 & 0x1F;
+ return sprintf(buf, "%d\n", data32);
+ } else if(!strcmp(attr->attr.name, "HardwareVariant")){
+ data32 = (data32 >> 5) & 0x0F;
+ return sprintf(buf, "%d\n", data32);
+ }
+
+ return sprintf(buf, "Error\n");
+}
+
static DEVICE_ATTR(console, 0644, console_show, console_store);
@@ -506,6 +588,14 @@ static DEVICE_ATTR(console, 0644, console_show, console_store);
#include "solos-attrlist.c"
+static DEVICE_ATTR(GPIO1, 0644, geos_gpio_show, geos_gpio_store);
+static DEVICE_ATTR(GPIO2, 0644, geos_gpio_show, geos_gpio_store);
+static DEVICE_ATTR(GPIO3, 0644, geos_gpio_show, geos_gpio_store);
+static DEVICE_ATTR(GPIO4, 0644, geos_gpio_show, geos_gpio_store);
+static DEVICE_ATTR(GPIO5, 0644, geos_gpio_show, geos_gpio_store);
+static DEVICE_ATTR(PushButton, 0444, geos_gpio_show, NULL);
+static DEVICE_ATTR(HardwareVersion, 0444, hardware_show, NULL);
+static DEVICE_ATTR(HardwareVariant, 0444, hardware_show, NULL);
#undef SOLOS_ATTR_RO
#undef SOLOS_ATTR_RW
@@ -514,6 +604,14 @@ static DEVICE_ATTR(console, 0644, console_show, console_store);
static struct attribute *solos_attrs[] = {
#include "solos-attrlist.c"
+ &dev_attr_GPIO1.attr,
+ &dev_attr_GPIO2.attr,
+ &dev_attr_GPIO3.attr,
+ &dev_attr_GPIO4.attr,
+ &dev_attr_GPIO5.attr,
+ &dev_attr_PushButton.attr,
+ &dev_attr_HardwareVersion.attr,
+ &dev_attr_HardwareVariant.attr,
NULL
};
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/4] atm: solos-pci: Remove annoying line of debugging
From: Nathan Williams @ 2011-10-05 4:44 UTC (permalink / raw)
To: netdev; +Cc: linux-atm-general, David Woodhouse, linux-kernel
"len: %d" isn't particularly useful for anyone and confuses users.
Signed-off-by: Nathan Williams <nathan@traverse.com.au>
---
drivers/atm/solos-pci.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 5d1d076..bd01aa3 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -452,7 +452,6 @@ static ssize_t console_show(struct device *dev, struct device_attribute *attr,
len = skb->len;
memcpy(buf, skb->data, len);
- dev_dbg(&card->dev->dev, "len: %d\n", len);
kfree_skb(skb);
return len;
--
1.7.2.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox