Re: [PATCH] [linux-next] rtlwifi: Fix typo in printk
On 06/28/2016 10:37 PM, Masanari Iida wrote:
This patch fix spelling typos found in drivers/net/wireless/realtek.
Signed-off-by: Masanari Iida
Acked--by: Larry Finger
Thanks,
Larry
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c| 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
index 416a9ba6382e..422c7813f5ee 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
@@ -1239,7 +1239,7 @@ u8 rtl88e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl88e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current channel
%d\n",
+"sw_chnl_inprogress false schedule workitem current channel
%d\n",
rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index 77e61b19bf36..9301583ce768 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -757,7 +757,7 @@ u8 rtl92c_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92c_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
index 459f3d0efa2f..0a5c9fcfe73b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
@@ -496,7 +496,7 @@ static void rtl92ee_dm_find_minimum_rssi(struct
ieee80211_hw *hw)
rtl_dm_dig->min_undec_pwdb_for_dm =
rtlpriv->dm.entry_min_undec_sm_pwdb;
RT_TRACE(rtlpriv, COMP_BB_POWERSAVING, DBG_LOUD,
-"AP Ext Port or disconnet PWDB = 0x%x\n",
+"AP Ext Port or disconnect PWDB = 0x%x\n",
rtl_dm_dig->min_undec_pwdb_for_dm);
}
RT_TRACE(rtlpriv, COMP_DIG, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index c2bf8d1a7af3..97d9a8e209f1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -1819,7 +1819,7 @@ u8 rtl92ee_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92ee_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current channel
%d\n",
+"sw_chnl_inprogress false schedule workitem current channel
%d\n",
rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
index d367097f490b..e9a9bbf44966 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
@@ -893,7 +893,7 @@ u8 rtl8723e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl8723e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 08288ac9020a..97ae14d48840 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/rea
[net-next 01/16] i40e: add functions to control default VSI
From: Mitch Williams
Add functions to enable and disable default VSI on a VEB. This allows
for configuration of limited promiscuous mode specifically for bridging
purposes.
Change-ID: I0cc5bd68b31c500fdff4d47e1f15d50d2739faf4
Signed-off-by: Mitch Williams
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/i40e/i40e_common.c| 56
drivers/net/ethernet/intel/i40e/i40e_prototype.h | 2 +
2 files changed, 58 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 422b41d..e447dc4 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -1967,6 +1967,62 @@ aq_add_vsi_exit:
}
/**
+ * i40e_aq_set_default_vsi
+ * @hw: pointer to the hw struct
+ * @seid: vsi number
+ * @cmd_details: pointer to command details structure or NULL
+ **/
+i40e_status i40e_aq_set_default_vsi(struct i40e_hw *hw,
+ u16 seid,
+ struct i40e_asq_cmd_details *cmd_details)
+{
+ struct i40e_aq_desc desc;
+ struct i40e_aqc_set_vsi_promiscuous_modes *cmd =
+ (struct i40e_aqc_set_vsi_promiscuous_modes *)
+ &desc.params.raw;
+ i40e_status status;
+
+ i40e_fill_default_direct_cmd_desc(&desc,
+
i40e_aqc_opc_set_vsi_promiscuous_modes);
+
+ cmd->promiscuous_flags = cpu_to_le16(I40E_AQC_SET_VSI_DEFAULT);
+ cmd->valid_flags = cpu_to_le16(I40E_AQC_SET_VSI_DEFAULT);
+ cmd->seid = cpu_to_le16(seid);
+
+ status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
+
+ return status;
+}
+
+/**
+ * i40e_aq_clear_default_vsi
+ * @hw: pointer to the hw struct
+ * @seid: vsi number
+ * @cmd_details: pointer to command details structure or NULL
+ **/
+i40e_status i40e_aq_clear_default_vsi(struct i40e_hw *hw,
+ u16 seid,
+ struct i40e_asq_cmd_details *cmd_details)
+{
+ struct i40e_aq_desc desc;
+ struct i40e_aqc_set_vsi_promiscuous_modes *cmd =
+ (struct i40e_aqc_set_vsi_promiscuous_modes *)
+ &desc.params.raw;
+ i40e_status status;
+
+ i40e_fill_default_direct_cmd_desc(&desc,
+
i40e_aqc_opc_set_vsi_promiscuous_modes);
+
+ cmd->promiscuous_flags = cpu_to_le16(0);
+ cmd->valid_flags = cpu_to_le16(I40E_AQC_SET_VSI_DEFAULT);
+ cmd->seid = cpu_to_le16(seid);
+
+ status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
+
+ return status;
+}
+
+/**
* i40e_aq_set_vsi_unicast_promiscuous
* @hw: pointer to the hw struct
* @seid: vsi number
diff --git a/drivers/net/ethernet/intel/i40e/i40e_prototype.h
b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
index 80403c6..4660c5a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_prototype.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
@@ -98,6 +98,8 @@ i40e_status i40e_aq_set_phy_debug(struct i40e_hw *hw, u8
cmd_flags,
struct i40e_asq_cmd_details *cmd_details);
i40e_status i40e_aq_set_default_vsi(struct i40e_hw *hw, u16 vsi_id,
struct i40e_asq_cmd_details *cmd_details);
+i40e_status i40e_aq_clear_default_vsi(struct i40e_hw *hw, u16 vsi_id,
+ struct i40e_asq_cmd_details *cmd_details);
enum i40e_status_code i40e_aq_get_phy_capabilities(struct i40e_hw *hw,
bool qualified_modules, bool report_init,
struct i40e_aq_get_phy_abilities_resp *abilities,
--
2.5.5
[net-next 13/16] i40e: add VSI info to macaddr messages
From: Shannon Nelson
Since the macaddr add and delete happens asynchronously, error
messages don't easily get associated to the actual request. Here
we add a bit of information to the error messages to help
determine the source of the error.
Change-ID: Id2d6df5287141c3579677d72d8bd21122823d79f
Signed-off-by: Shannon Nelson
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 31 -
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index d6a5106..880602f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1837,6 +1837,7 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
struct i40e_hw *hw = &vsi->back->hw;
bool promisc_forced_on = false;
bool add_happened = false;
+ char vsi_name[16] = "PF";
int filter_list_len = 0;
u32 changed_flags = 0;
i40e_status aq_ret = 0;
@@ -1864,6 +1865,11 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
INIT_LIST_HEAD(&tmp_del_list);
INIT_LIST_HEAD(&tmp_add_list);
+ if (vsi->type == I40E_VSI_SRIOV)
+ snprintf(vsi_name, sizeof(vsi_name) - 1, "VF %d", vsi->vf_id);
+ else if (vsi->type != I40E_VSI_MAIN)
+ snprintf(vsi_name, sizeof(vsi_name) - 1, "vsi %d", vsi->seid);
+
if (vsi->flags & I40E_VSI_FLAG_FILTER_CHANGED) {
vsi->flags &= ~I40E_VSI_FLAG_FILTER_CHANGED;
@@ -1958,8 +1964,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
if (aq_ret && aq_err != I40E_AQ_RC_ENOENT) {
retval = -EIO;
dev_err(&pf->pdev->dev,
- "ignoring delete macvlan error,
err %s, aq_err %s while flushing a full buffer\n",
-
+"ignoring delete macvlan error
on %s, err %s, aq_err %s while flushing a full buffer\n",
+vsi_name,
i40e_stat_str(hw, aq_ret),
i40e_aq_str(hw, aq_err));
}
@@ -1979,7 +1985,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
if (aq_ret && aq_err != I40E_AQ_RC_ENOENT)
dev_info(&pf->pdev->dev,
-"ignoring delete macvlan error, err %s
aq_err %s\n",
+"ignoring delete macvlan error on %s,
err %s aq_err %s\n",
+vsi_name,
i40e_stat_str(hw, aq_ret),
i40e_aq_str(hw, aq_err));
}
@@ -2056,7 +2063,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
if (add_happened && aq_ret && aq_err != I40E_AQ_RC_EINVAL) {
retval = i40e_aq_rc_to_posix(aq_ret, aq_err);
dev_info(&pf->pdev->dev,
-"add filter failed, err %s aq_err %s\n",
+"add filter failed on %s, err %s aq_err %s\n",
+vsi_name,
i40e_stat_str(hw, aq_ret),
i40e_aq_str(hw, aq_err));
if ((hw->aq.asq_last_status == I40E_AQ_RC_ENOSPC) &&
@@ -2065,7 +2073,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
promisc_forced_on = true;
set_bit(__I40E_FILTER_OVERFLOW_PROMISC,
&vsi->state);
- dev_info(&pf->pdev->dev, "promiscuous mode
forced on\n");
+ dev_info(&pf->pdev->dev, "promiscuous mode
forced on %s\n",
+vsi_name);
}
}
}
@@ -2089,7 +2098,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
retval = i40e_aq_rc_to_posix(aq_ret,
hw->aq.asq_last_status);
dev_info(&pf->pdev->dev,
-"set multi promisc failed, err %s aq_err %s\n",
+"set multi promisc failed on %s, err %s aq_err
%s\n",
+vsi_name,
i40e_stat_str(hw, aq_ret),
i40e_aq_str(hw, hw->aq.asq_last_status));
}
@@ -2124,7 +2134,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
retval = i40e_aq_rc_to_posix(aq_ret,
h
[net-next 11/16] i40evf: always activate correct MAC address filter
From: Mitch Williams Always add MAC address at the tail of the MAC filter list. Since the device's "real" MAC address is added first, it will always be at the beginning of the list. This prevents an issue where the "real" MAC filter might not get added if too many other filters are added before bringing the interface up. Change-ID: I34a8aeebeb0cb87a44b24118adc4176c7b943c1c Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c index 16c5529..da9221b 100644 --- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c +++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c @@ -825,7 +825,7 @@ i40evf_mac_filter *i40evf_add_filter(struct i40evf_adapter *adapter, ether_addr_copy(f->macaddr, macaddr); - list_add(&f->list, &adapter->mac_filter_list); + list_add_tail(&f->list, &adapter->mac_filter_list); f->add = true; adapter->aq_required |= I40EVF_FLAG_AQ_ADD_MAC_FILTER; } -- 2.5.5
[net-next 09/16] i40e: Removing unnecessary code which caused supported link mode bug
From: Avinash Dayanand
Removing this code which wasn't allowing 100BaseT to show up in the supported
link modes for 10GBaseT PHYs.
Change-ID: Iada2eafa7ef6b4bac9a2a1380ff533ae5de51e1d
Signed-off-by: Avinash Dayanand
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 8381dab..4962e85 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -313,8 +313,7 @@ static void i40e_phy_type_to_ethtool(struct i40e_pf *pf,
u32 *supported,
*advertising |= ADVERTISED_Autoneg |
ADVERTISED_4baseCR4_Full;
}
- if ((phy_types & I40E_CAP_PHY_TYPE_100BASE_TX) &&
- !(phy_types & I40E_CAP_PHY_TYPE_1000BASE_T)) {
+ if (phy_types & I40E_CAP_PHY_TYPE_100BASE_TX) {
*supported |= SUPPORTED_Autoneg |
SUPPORTED_100baseT_Full;
*advertising |= ADVERTISED_Autoneg |
--
2.5.5
[net-next 10/16] i40e: Fix RSS to not be limited by the number of CPUs
From: Catherine Sullivan Limiting qcount to pf->num_lan_msix, effectively limits the RSS queues to only use the number of CPUs, and ignore all other queues. We don't want to do this. If the user has changed the RSS settings to use more queues then CPUS, we want to trust they know what they are doing and let them. More importantly, if we tell them that is what we did, we want to actually do it and allow traffic into all of the queues we have allocated. This does not change the default setting to initially allocate only the number of CPUS of queue pairs. Change-ID: Ie941a96e806e4bcd016addb4e17affb46770ada5 Signed-off-by: Catherine Sullivan Tested-by: Andrew Bowers --- drivers/net/ethernet/intel/i40e/i40e_main.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 52d9d28..a32be7c 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -1579,14 +1579,8 @@ static void i40e_vsi_setup_queue_map(struct i40e_vsi *vsi, vsi->tc_config.numtc = numtc; vsi->tc_config.enabled_tc = enabled_tc ? enabled_tc : 1; /* Number of queues per enabled TC */ - /* In MFP case we can have a much lower count of MSIx -* vectors available and so we need to lower the used -* q count. -*/ - if (pf->flags & I40E_FLAG_MSIX_ENABLED) - qcount = min_t(int, vsi->alloc_queue_pairs, pf->num_lan_msix); - else - qcount = vsi->alloc_queue_pairs; + qcount = vsi->alloc_queue_pairs; + num_tc_qps = qcount / numtc; num_tc_qps = min_t(int, num_tc_qps, i40e_pf_get_max_q_per_tc(pf)); -- 2.5.5
[net-next 00/16][pull request] 40GbE Intel Wired LAN Driver Updates 2016-06-27
This series contains updates to i40e and i40evf only. Mitch provides several changes, first adds functions to enable and disable VSI on a VEB, which allows for configuration of limited promiscuous mode specifically for bridging purposes. Sets the RSS Hash Enable registers by default now that VF RSS is configured by the PF driver. Fixed a issue where we could overflow the buffer, by checking the address count and bail out of the loop at the appropriate time. Removed the need for a reset when the device enters limited promiscuous mode, since this was causing heartburn for people who were using VFs and bridging. Catherine adds a call to set the client interface down when we put the VSI down. Fixed an issue where RSS queues was being limited to the number of CPUs, so if a user wants to use more queues than CPUs, we want to trust they know what they are doing and let them. Greg cleans up the driver suspend routine to ensure we are calling synchronize_irq() before freeing IRQ vectors and explicitly free the other causes interrupt resources and shut down the MSIX interrupt. Serey fixes i40e_set_settings() to not fail when a Direct Attach (DA) cable is used. Avinash fixes a supported link bug by removing code which was not allowing 100BaseT to show up in the supported link modes for 10GBaseT PHYs. Shannon adds a bit of information to the error messages to help determine the source of error by adding VSI info to macaddr messages. Tushar Dave fixes error received when turning off TSO on some systems, which was caused by enabling FD_SB without checking availability of MSIx vectors, so add the check. Neerav fixes a possible panic when LLDP/DCBX change happens and the driver tried to notify the client(s) for each of the PF VSIs, which would panic when it reached a VSI that did not have any netdev associated with it. The following are changes since commit de2fbe7ae3637533ebf711b91b04988633bf38ee: Merge branch 'sfp-infra' and are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE Avinash Dayanand (1): i40e: Removing unnecessary code which caused supported link mode bug Bimmy Pujari (1): i40e/i40evf: Bump version from 1.5.16 to 1.6.4 Catherine Sullivan (2): i40e: Add a call to set the client interface down i40e: Fix RSS to not be limited by the number of CPUs Greg Rose (2): i40e: Clean up MSIX IRQs before suspend i40e: Save PCI state before suspend Mitch Williams (6): i40e: add functions to control default VSI i40e: add hw struct local variable i40e: write HENA for VFs i40evf: don't overflow buffer i40evf: always activate correct MAC address filter i40e: set default VSI without a reset Neerav Parikh (1): i40e: Don't notify client(s) for DCB changes on all VSIs Serey Kong (1): i40e: fix missing DA cable check Shannon Nelson (1): i40e: add VSI info to macaddr messages Tushar Dave (1): i40e: Fix errors resulted while turning off TSO drivers/net/ethernet/intel/i40e/i40e.h | 1 + drivers/net/ethernet/intel/i40e/i40e_common.c | 56 +++ drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 4 +- drivers/net/ethernet/intel/i40e/i40e_main.c| 173 + drivers/net/ethernet/intel/i40e/i40e_prototype.h | 2 + drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 6 + drivers/net/ethernet/intel/i40evf/i40evf_main.c| 6 +- .../net/ethernet/intel/i40evf/i40evf_virtchnl.c| 8 + 8 files changed, 183 insertions(+), 73 deletions(-) -- 2.5.5
[net-next 14/16] i40e/i40evf: Bump version from 1.5.16 to 1.6.4
From: Bimmy Pujari Signed-off-by: Bimmy Pujari Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/i40e/i40e_main.c | 4 ++-- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 880602f..3e394bf 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -40,8 +40,8 @@ static const char i40e_driver_string[] = #define DRV_KERN "-k" #define DRV_VERSION_MAJOR 1 -#define DRV_VERSION_MINOR 5 -#define DRV_VERSION_BUILD 16 +#define DRV_VERSION_MINOR 6 +#define DRV_VERSION_BUILD 4 #define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \ __stringify(DRV_VERSION_MINOR) "." \ __stringify(DRV_VERSION_BUILD)DRV_KERN diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c index da9221b..eac057b 100644 --- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c +++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c @@ -37,8 +37,8 @@ static const char i40evf_driver_string[] = #define DRV_KERN "-k" #define DRV_VERSION_MAJOR 1 -#define DRV_VERSION_MINOR 5 -#define DRV_VERSION_BUILD 10 +#define DRV_VERSION_MINOR 6 +#define DRV_VERSION_BUILD 4 #define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \ __stringify(DRV_VERSION_MINOR) "." \ __stringify(DRV_VERSION_BUILD) \ -- 2.5.5
[net-next 12/16] i40e: set default VSI without a reset
From: Mitch Williams
Remove the need for a reset when the device enters limited promiscuous
mode. This was causing heartburn for people who were using VFs and
bridging, since this would require all of the VFs to undergo a reset
each time the PF changed its promiscuity.
Change-ID: I0a83495c5e4d68112bbc7a7a076d20fa8dd3b61c
Signed-off-by: Mitch Williams
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index a32be7c..d6a5106 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -2110,7 +2110,25 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
*/
if (pf->cur_promisc != cur_promisc) {
pf->cur_promisc = cur_promisc;
- set_bit(__I40E_PF_RESET_REQUESTED, &pf->state);
+ if (cur_promisc)
+ aq_ret =
+ i40e_aq_set_default_vsi(hw,
+ vsi->seid,
+ NULL);
+ else
+ aq_ret =
+ i40e_aq_clear_default_vsi(hw,
+ vsi->seid,
+ NULL);
+ if (aq_ret) {
+ retval = i40e_aq_rc_to_posix(aq_ret,
+ hw->aq.asq_last_status);
+ dev_info(&pf->pdev->dev,
+"Set default VSI failed, err
%s, aq_err %s\n",
+i40e_stat_str(hw, aq_ret),
+i40e_aq_str(hw,
+hw->aq.asq_last_status));
+ }
}
} else {
aq_ret = i40e_aq_set_vsi_unicast_promiscuous(
@@ -10047,14 +10065,14 @@ void i40e_veb_release(struct i40e_veb *veb)
static int i40e_add_veb(struct i40e_veb *veb, struct i40e_vsi *vsi)
{
struct i40e_pf *pf = veb->pf;
- bool is_default = veb->pf->cur_promisc;
bool enable_stats = !!(pf->flags & I40E_FLAG_VEB_STATS_ENABLED);
int ret;
- /* get a VEB from the hardware */
ret = i40e_aq_add_veb(&pf->hw, veb->uplink_seid, vsi->seid,
- veb->enabled_tc, is_default,
+ veb->enabled_tc, false,
&veb->seid, enable_stats, NULL);
+
+ /* get a VEB from the hardware */
if (ret) {
dev_info(&pf->pdev->dev,
"couldn't add VEB, err %s aq_err %s\n",
--
2.5.5
[net-next 04/16] i40e: Add a call to set the client interface down
From: Catherine Sullivan We were failing to set the client interface down when we put the VSI down. Add this call so that the client doesn't get an open called with no close. Also remove an un-needed delay. The VF should not be affected at all by i40e_down. Change-ID: I1135dffef534bf84e6fed57cf51bcf590e6cfaf7 Signed-off-by: Catherine Sullivan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 9a26ecc..a2b4012 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -5181,12 +5181,6 @@ static void i40e_vsi_reinit_locked(struct i40e_vsi *vsi) usleep_range(1000, 2000); i40e_down(vsi); - /* Give a VF some time to respond to the reset. The -* two second wait is based upon the watchdog cycle in -* the VF driver. -*/ - if (vsi->type == I40E_VSI_SRIOV) - msleep(2000); i40e_up(vsi); clear_bit(__I40E_CONFIG_BUSY, &pf->state); } @@ -5229,6 +5223,9 @@ void i40e_down(struct i40e_vsi *vsi) i40e_clean_tx_ring(vsi->tx_rings[i]); i40e_clean_rx_ring(vsi->rx_rings[i]); } + + i40e_notify_client_of_netdev_close(vsi, false); + } /** @@ -5931,7 +5928,6 @@ static void i40e_fdir_flush_and_replay(struct i40e_pf *pf) if (I40E_DEBUG_FD & pf->hw.debug_mask) dev_info(&pf->pdev->dev, "FD Filter table flushed and FD-SB replayed.\n"); } - } /** -- 2.5.5
[net-next 07/16] i40e: Save PCI state before suspend
From: Greg Rose
The i40e_suspend() function was failing to save PCI state
and this would result in a kernel stack trace from a WARN_ONCE in the
pci_legacy_suspend() function.
Add a call to pci_save_state() to fix that problem.
Change-ID: I4736e62bb660966bd208cc8af617a14cb07fc4bd
Signed-off-by: Greg Rose
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index e071c22..52d9d28 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11441,6 +11441,7 @@ static int i40e_suspend(struct pci_dev *pdev,
pm_message_t state)
{
struct i40e_pf *pf = pci_get_drvdata(pdev);
struct i40e_hw *hw = &pf->hw;
+ int retval = 0;
set_bit(__I40E_SUSPENDED, &pf->state);
set_bit(__I40E_DOWN, &pf->state);
@@ -11454,10 +11455,14 @@ static int i40e_suspend(struct pci_dev *pdev,
pm_message_t state)
i40e_stop_misc_vector(pf);
+ retval = pci_save_state(pdev);
+ if (retval)
+ return retval;
+
pci_wake_from_d3(pdev, pf->wol_en);
pci_set_power_state(pdev, PCI_D3hot);
- return 0;
+ return retval;
}
/**
--
2.5.5
Re: [PATCH 0/4] Mesh mpm fixes and enhancements
Hi Yaniv, On Tue, Jun 28, 2016 at 9:13 PM, Yaniv Machani wrote: > This patch set is addressing some issues found in the current 802.11s > implementation, > specifically when using hostap mpm. > It's aligning the beacon format and handling some corner cases. > > Maital Hahn (2): > mac80211: mesh: flush stations before beacons are stopped > mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting > > Meirav Kama (2): > mac80211: mesh: fixed HT ies in beacon template > mac80211: sta_info: max_peers reached falsely Patches that you send must be signed off by you, not ack'd by you. I.e. From: Random Developer . Signed-off-by: Random Developer Signed-off-by: Patch Sender Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/
[net-next 16/16] i40e: Don't notify client(s) for DCB changes on all VSIs
From: Neerav Parikh
When LLDP/DCBX change happens the i40e driver code flow tried to
notify the client(s) for each of the PF VSIs. This resulted into
kernel panic on the first VSI that didn't have any netdev
associated to it.
The DCB change notification to the client(s) should be done only
once for the PF/LAN VSI where the client(s) instances have been
added to. Also, move the notification call after the PF driver has
made changes related to the updated DCB configuration.
Signed-off-by: Neerav Parikh
Signed-off-by: Usha Ketineni
Tested-by: Ronald J Bynoe
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index a313194..2b11405 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -4982,7 +4982,6 @@ static void i40e_dcb_reconfigure(struct i40e_pf *pf)
if (pf->vsi[v]->netdev)
i40e_dcbnl_set_all(pf->vsi[v]);
}
- i40e_notify_client_of_l2_param_changes(pf->vsi[v]);
}
}
@@ -5730,6 +5729,8 @@ static int i40e_handle_lldp_event(struct i40e_pf *pf,
i40e_service_event_schedule(pf);
} else {
i40e_pf_unquiesce_all_vsi(pf);
+ /* Notify the client for the DCB changes */
+ i40e_notify_client_of_l2_param_changes(pf->vsi[pf->lan_vsi]);
}
exit:
--
2.5.5
[net-next 08/16] i40e: fix missing DA cable check
From: Serey Kong When a Direct Attach (DA) cable is used, if the i40e_set_settings function is called it would return an error. Add the DA type so the function won't fail. Change-ID: I2b802f27a5d91cfefa72fd1f852acb4d74647a8e Signed-off-by: Serey Kong Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c index 5e8d84f..8381dab 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c @@ -663,6 +663,7 @@ static int i40e_set_settings(struct net_device *netdev, if (hw->phy.media_type != I40E_MEDIA_TYPE_BASET && hw->phy.media_type != I40E_MEDIA_TYPE_FIBER && hw->phy.media_type != I40E_MEDIA_TYPE_BACKPLANE && + hw->phy.media_type != I40E_MEDIA_TYPE_DA && hw->phy.link_info.link_info & I40E_AQ_LINK_UP) return -EOPNOTSUPP; -- 2.5.5
[net-next 06/16] i40e: Clean up MSIX IRQs before suspend
From: Greg Rose The i40e_suspend() function calls another function that preps the device for the power save and resume by freeing all the Tx/Rx resources and interrupts but that function does not free the "other" causes interrupt vector and IRQ. It also fails to call synchronize_irq() before freeing the IRQ vectors. This sometimes may result in some AER errors on those systems with that PCIe error reporting feature enabled. Call synchronize_irq() before freeing IRQ vectors and explicitly free the other causes interrupt resources and shut down that MSIX interrupt. Change-ID: Ib88e4536756518a352446da0232189716618ad81 Signed-off-by: Greg Rose Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index a2b4012..e071c22 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -3950,6 +3950,7 @@ static void i40e_vsi_free_irq(struct i40e_vsi *vsi) /* clear the affinity_mask in the IRQ descriptor */ irq_set_affinity_hint(pf->msix_entries[vector].vector, NULL); + synchronize_irq(pf->msix_entries[vector].vector); free_irq(pf->msix_entries[vector].vector, vsi->q_vectors[i]); @@ -11451,6 +11452,8 @@ static int i40e_suspend(struct pci_dev *pdev, pm_message_t state) wr32(hw, I40E_PFPM_APM, (pf->wol_en ? I40E_PFPM_APM_APME_MASK : 0)); wr32(hw, I40E_PFPM_WUFC, (pf->wol_en ? I40E_PFPM_WUFC_MAG_MASK : 0)); + i40e_stop_misc_vector(pf); + pci_wake_from_d3(pdev, pf->wol_en); pci_set_power_state(pdev, PCI_D3hot); -- 2.5.5
[net-next 03/16] i40e: write HENA for VFs
From: Mitch Williams
Now that VF RSS is configured by the PF driver, it needs to set the RSS
Hash Enable registers by default. Without this, no packets will be
hashed and they'll all end up on queue 0.
Change-ID: I38e425f40ddb81e3b19a951cfbb939fa5b1123f1
Signed-off-by: Mitch Williams
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 1fcafcf..6fcbf76 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -665,6 +665,8 @@ static int i40e_alloc_vsi_res(struct i40e_vf *vf, enum
i40e_vsi_type type)
goto error_alloc_vsi_res;
}
if (type == I40E_VSI_SRIOV) {
+ u64 hena = i40e_pf_get_default_rss_hena(pf);
+
vf->lan_vsi_idx = vsi->idx;
vf->lan_vsi_id = vsi->id;
/* If the port VLAN has been configured and then the
@@ -687,6 +689,10 @@ static int i40e_alloc_vsi_res(struct i40e_vf *vf, enum
i40e_vsi_type type)
vf->default_lan_addr.addr, vf->vf_id);
}
spin_unlock_bh(&vsi->mac_filter_list_lock);
+ i40e_write_rx_ctl(&pf->hw, I40E_VFQF_HENA1(0, vf->vf_id),
+ (u32)hena);
+ i40e_write_rx_ctl(&pf->hw, I40E_VFQF_HENA1(1, vf->vf_id),
+ (u32)(hena >> 32));
}
/* program mac filter */
--
2.5.5
[net-next 02/16] i40e: add hw struct local variable
From: Mitch Williams
This function uses the i40e_hw struct all over the place, so why doesn't
it keep a pointer to the struct? Add this pointer as a local variable
and use it consistently throughout the function.
Change-ID: I10eb688fe40909433fcb8ac7ac891cef67445d72
Signed-off-by: Mitch Williams
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 79 +++--
1 file changed, 41 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 734cba6..9a26ecc 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1840,6 +1840,7 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
{
struct list_head tmp_del_list, tmp_add_list;
struct i40e_mac_filter *f, *ftmp, *fclone;
+ struct i40e_hw *hw = &vsi->back->hw;
bool promisc_forced_on = false;
bool add_happened = false;
int filter_list_len = 0;
@@ -1920,7 +1921,7 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
if (!list_empty(&tmp_del_list)) {
int del_list_size;
- filter_list_len = pf->hw.aq.asq_buf_size /
+ filter_list_len = hw->aq.asq_buf_size /
sizeof(struct i40e_aqc_remove_macvlan_element_data);
del_list_size = filter_list_len *
sizeof(struct i40e_aqc_remove_macvlan_element_data);
@@ -1952,12 +1953,11 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
/* flush a full buffer */
if (num_del == filter_list_len) {
- aq_ret = i40e_aq_remove_macvlan(&pf->hw,
- vsi->seid,
- del_list,
- num_del,
- NULL);
- aq_err = pf->hw.aq.asq_last_status;
+ aq_ret =
+ i40e_aq_remove_macvlan(hw, vsi->seid,
+ del_list,
+ num_del, NULL);
+ aq_err = hw->aq.asq_last_status;
num_del = 0;
memset(del_list, 0, del_list_size);
@@ -1965,8 +1965,9 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
retval = -EIO;
dev_err(&pf->pdev->dev,
"ignoring delete macvlan error,
err %s, aq_err %s while flushing a full buffer\n",
- i40e_stat_str(&pf->hw, aq_ret),
- i40e_aq_str(&pf->hw, aq_err));
+
+i40e_stat_str(hw, aq_ret),
+i40e_aq_str(hw, aq_err));
}
}
/* Release memory for MAC filter entries which were
@@ -1977,17 +1978,16 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
}
if (num_del) {
- aq_ret = i40e_aq_remove_macvlan(&pf->hw, vsi->seid,
- del_list, num_del,
- NULL);
- aq_err = pf->hw.aq.asq_last_status;
+ aq_ret = i40e_aq_remove_macvlan(hw, vsi->seid, del_list,
+ num_del, NULL);
+ aq_err = hw->aq.asq_last_status;
num_del = 0;
if (aq_ret && aq_err != I40E_AQ_RC_ENOENT)
dev_info(&pf->pdev->dev,
"ignoring delete macvlan error, err %s
aq_err %s\n",
-i40e_stat_str(&pf->hw, aq_ret),
-i40e_aq_str(&pf->hw, aq_err));
+i40e_stat_str(hw, aq_ret),
+i40e_aq_str(hw, aq_err));
}
kfree(del_list);
@@ -1998,7 +1998,7 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
int add_list_size;
/* do all the adds now */
- filter_list_len = pf->hw.aq.asq_buf_size /
+ filter_list_len = hw->aq.asq_buf_size /
sizeof(struct i40e_aqc_add_macvlan_element_data),
add_list_size = filter_list_len *
sizeof(s
[net-next 15/16] i40e: Fix errors resulted while turning off TSO
From: Tushar Dave
On systems with 128 CPUs, turning off TSO results in errors,
i40e :03:00.0: failed to get tracking for 1 vectors for VSI 400, err=-12
i40e :03:00.0: Couldn't create FDir VSI
i40e :03:00.0: i40e_ptp_init: PTP not supported on eth0
i40e :03:00.0: couldn't add VEB, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err
I40E_AQ_RC_ENOENT
i40e :03:00.0: rebuild of switch failed: -1, will try to set up simple PF
connection
i40e :03:00.0 eth0: adding 00:10:e0:8a:24:b6 vid=0
Enabling FD_SB without checking availability of MSI-X vector is the
root cause. This change adds necessary check.
Signed-off-by: Tushar Dave
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/i40e/i40e.h | 1 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h
b/drivers/net/ethernet/intel/i40e/i40e.h
index 9c44739..e83fc8a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -283,6 +283,7 @@ struct i40e_pf {
#endif /* I40E_FCOE */
u16 num_lan_qps; /* num lan queues this PF has set up */
u16 num_lan_msix; /* num queue vectors for the base PF vsi */
+ u16 num_fdsb_msix; /* num queue vectors for sideband Fdir */
u16 num_iwarp_msix;/* num of iwarp vectors for this PF */
int iwarp_base_vector;
int queues_left; /* queues left unclaimed */
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 3e394bf..a313194 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7185,7 +7185,7 @@ static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
vsi->alloc_queue_pairs = 1;
vsi->num_desc = ALIGN(I40E_FDIR_RING_COUNT,
I40E_REQ_DESCRIPTOR_MULTIPLE);
- vsi->num_q_vectors = 1;
+ vsi->num_q_vectors = pf->num_fdsb_msix;
break;
case I40E_VSI_VMDQ2:
@@ -7569,9 +7569,11 @@ static int i40e_init_msix(struct i40e_pf *pf)
/* reserve one vector for sideband flow director */
if (pf->flags & I40E_FLAG_FD_SB_ENABLED) {
if (vectors_left) {
+ pf->num_fdsb_msix = 1;
v_budget++;
vectors_left--;
} else {
+ pf->num_fdsb_msix = 0;
pf->flags &= ~I40E_FLAG_FD_SB_ENABLED;
}
}
@@ -8590,7 +8592,9 @@ bool i40e_set_ntuple(struct i40e_pf *pf,
netdev_features_t features)
/* Enable filters and mark for reset */
if (!(pf->flags & I40E_FLAG_FD_SB_ENABLED))
need_reset = true;
- pf->flags |= I40E_FLAG_FD_SB_ENABLED;
+ /* enable FD_SB only if there is MSI-X vector */
+ if (pf->num_fdsb_msix > 0)
+ pf->flags |= I40E_FLAG_FD_SB_ENABLED;
} else {
/* turn off filters, mark for reset and clear SW filter list */
if (pf->flags & I40E_FLAG_FD_SB_ENABLED) {
--
2.5.5
[net-next 05/16] i40evf: don't overflow buffer
From: Mitch Williams If the user adds an obscene amount of MAC addresses, the driver will run into the situation where it has too many address requests to fit into a single PF message. The driver checks for this case, and calculates the maximum number of messages that it can send. Then it completely ignores this count and overflows the buffer. Fix this by checking the address count and bailing out of the loop at the appropriate time. Change-ID: If8dcbb04602c75941dc0cd8309065e1de9ca791c Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c b/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c index f134456..d76c221 100644 --- a/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c +++ b/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c @@ -434,6 +434,8 @@ void i40evf_add_ether_addrs(struct i40evf_adapter *adapter) ether_addr_copy(veal->list[i].addr, f->macaddr); i++; f->add = false; + if (i == count) + break; } } if (!more) @@ -497,6 +499,8 @@ void i40evf_del_ether_addrs(struct i40evf_adapter *adapter) i++; list_del(&f->list); kfree(f); + if (i == count) + break; } } if (!more) @@ -560,6 +564,8 @@ void i40evf_add_vlans(struct i40evf_adapter *adapter) vvfl->vlan_id[i] = f->vlan; i++; f->add = false; + if (i == count) + break; } } if (!more) @@ -623,6 +629,8 @@ void i40evf_del_vlans(struct i40evf_adapter *adapter) i++; list_del(&f->list); kfree(f); + if (i == count) + break; } } if (!more) -- 2.5.5
Re: [PATCH] [linux-next] rtlwifi: Fix typo in printk
Hi All, On Wed, Jun 29, 2016 at 1:37 PM, Masanari Iida wrote: > This patch fix spelling typos found in drivers/net/wireless/realtek. > > Signed-off-by: Masanari Iida Looks right to me. Reviewed-by: Julian Calaby Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/
[net] e1000e: keep VLAN interfaces functional after rxvlan off
From: Jarod Wilson
I've got a bug report about an e1000e interface, where a VLAN interface is
set up on top of it:
$ ip link add link ens1f0 name ens1f0.99 type vlan id 99
$ ip link set ens1f0 up
$ ip link set ens1f0.99 up
$ ip addr add 192.168.99.92 dev ens1f0.99
At this point, I can ping another host on vlan 99, ip 192.168.99.91.
However, if I do the following:
$ ethtool -K ens1f0 rxvlan off
Then no traffic passes on ens1f0.99. It comes back if I toggle rxvlan on
again. I'm not sure if this is actually intended behavior, or if there's a
lack of software VLAN stripping fallback, or what, but things continue to
work if I simply don't call e1000e_vlan_strip_disable() if there are
active VLANs (plagiarizing a function from the e1000 driver here) on the
interface.
Also slipped a related-ish fix to the kerneldoc text for
e1000e_vlan_strip_disable here...
Signed-off-by: Jarod Wilson
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/e1000e/netdev.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 75e6089..73f7452 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -154,6 +154,16 @@ void __ew32(struct e1000_hw *hw, unsigned long reg, u32
val)
writel(val, hw->hw_addr + reg);
}
+static bool e1000e_vlan_used(struct e1000_adapter *adapter)
+{
+ u16 vid;
+
+ for_each_set_bit(vid, adapter->active_vlans, VLAN_N_VID)
+ return true;
+
+ return false;
+}
+
/**
* e1000_regdump - register printout routine
* @hw: pointer to the HW structure
@@ -2789,7 +2799,7 @@ static void e1000e_vlan_filter_enable(struct
e1000_adapter *adapter)
}
/**
- * e1000e_vlan_strip_enable - helper to disable HW VLAN stripping
+ * e1000e_vlan_strip_disable - helper to disable HW VLAN stripping
* @adapter: board private structure to initialize
**/
static void e1000e_vlan_strip_disable(struct e1000_adapter *adapter)
@@ -3443,7 +3453,8 @@ static void e1000e_set_rx_mode(struct net_device *netdev)
ew32(RCTL, rctl);
- if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX)
+ if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX ||
+ e1000e_vlan_used(adapter))
e1000e_vlan_strip_enable(adapter);
else
e1000e_vlan_strip_disable(adapter);
--
2.5.5
[PATCH] [linux-next] rtlwifi: Fix typo in printk
This patch fix spelling typos found in drivers/net/wireless/realtek.
Signed-off-by: Masanari Iida
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c| 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
index 416a9ba6382e..422c7813f5ee 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
@@ -1239,7 +1239,7 @@ u8 rtl88e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl88e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current
channel %d\n",
+"sw_chnl_inprogress false schedule workitem current
channel %d\n",
rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index 77e61b19bf36..9301583ce768 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -757,7 +757,7 @@ u8 rtl92c_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92c_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
index 459f3d0efa2f..0a5c9fcfe73b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
@@ -496,7 +496,7 @@ static void rtl92ee_dm_find_minimum_rssi(struct
ieee80211_hw *hw)
rtl_dm_dig->min_undec_pwdb_for_dm =
rtlpriv->dm.entry_min_undec_sm_pwdb;
RT_TRACE(rtlpriv, COMP_BB_POWERSAVING, DBG_LOUD,
-"AP Ext Port or disconnet PWDB = 0x%x\n",
+"AP Ext Port or disconnect PWDB = 0x%x\n",
rtl_dm_dig->min_undec_pwdb_for_dm);
}
RT_TRACE(rtlpriv, COMP_DIG, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index c2bf8d1a7af3..97d9a8e209f1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -1819,7 +1819,7 @@ u8 rtl92ee_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92ee_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current
channel %d\n",
+"sw_chnl_inprogress false schedule workitem current
channel %d\n",
rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
index d367097f490b..e9a9bbf44966 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
@@ -893,7 +893,7 @@ u8 rtl8723e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl8723e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 08288ac9020a..97ae14d48840 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1474,7 +1474,7 @@ static enum version_8723e
_rtl8723be_read_chip_ve
RE: [PATCH net-next v3 0/7] r8152: support new chips
> From: Hayes Wang > Sent: Tuesday, June 28, 2016 8:29 PM > To: netdev@vger.kernel.org > Cc: nic_swsd; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; Hayes > Wang > Subject: [PATCH net-next v3 0/7] r8152: support new chips Excuse me. Please ignore these patches. We want to do more tests for the chips. I would submit the patches after the settings are stable. Best Regards, Hayes
[PATCH net-next] cxgb4: Introduce API for sending work requests on ctrl queue via copy
If the ctrl queue is full, just follows current path by allocating an
skb. If that fails then caller will just have to handle that case as
before.
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 10 +--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 2 +
drivers/net/ethernet/chelsio/cxgb4/l2t.c| 11 +--
drivers/net/ethernet/chelsio/cxgb4/sge.c| 108
5 files changed, 118 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index b4fceb92479f..08e0c639cf90 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1166,6 +1166,7 @@ netdev_tx_t t4_eth_xmit(struct sk_buff *skb, struct
net_device *dev);
int t4_ethrx_handler(struct sge_rspq *q, const __be64 *rsp,
const struct pkt_gl *gl);
int t4_mgmt_tx(struct adapter *adap, struct sk_buff *skb);
+int t4_mgmt_tx_direct(struct adapter *adap, const void *src, unsigned int len);
int t4_ofld_send(struct adapter *adap, struct sk_buff *skb);
int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq,
struct net_device *dev, int intr_idx,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c45de49dc963..cac8ef209f68 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -1696,8 +1696,8 @@ static void process_tid_release_list(struct work_struct
*work)
*/
void cxgb4_remove_tid(struct tid_info *t, unsigned int chan, unsigned int tid)
{
- struct sk_buff *skb;
struct adapter *adap = container_of(t, struct adapter, tids);
+ struct cpl_tid_release sreq, *req = &sreq;
WARN_ON(tid >= t->ntids);
@@ -1709,11 +1709,9 @@ void cxgb4_remove_tid(struct tid_info *t, unsigned int
chan, unsigned int tid)
atomic_dec(&t->tids_in_use);
}
- skb = alloc_skb(sizeof(struct cpl_tid_release), GFP_ATOMIC);
- if (likely(skb)) {
- mk_tid_release(skb, chan, tid);
- t4_ofld_send(adap, skb);
- } else
+ INIT_TP_WR_CPL(req, CPL_TID_RELEASE, tid);
+ req->rsvd = 0;
+ if (cxgb4_ctrl_send(adap->port[chan], req, sizeof(*req)))
cxgb4_queue_tid_release(t, chan, tid);
}
EXPORT_SYMBOL(cxgb4_remove_tid);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
index f3c58aaa932d..128efc914317 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
@@ -299,6 +299,8 @@ struct cxgb4_uld_info {
int cxgb4_register_uld(enum cxgb4_uld type, const struct cxgb4_uld_info *p);
int cxgb4_unregister_uld(enum cxgb4_uld type);
int cxgb4_ofld_send(struct net_device *dev, struct sk_buff *skb);
+int cxgb4_ctrl_send(struct net_device *dev, const void *src,
+ unsigned int len);
unsigned int cxgb4_dbfifo_count(const struct net_device *dev, int lpfifo);
unsigned int cxgb4_port_chan(const struct net_device *dev);
unsigned int cxgb4_port_viid(const struct net_device *dev);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/l2t.c
b/drivers/net/ethernet/chelsio/cxgb4/l2t.c
index 60a26037a1c6..e5a67cfca5bb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/l2t.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/l2t.c
@@ -139,14 +139,8 @@ static int write_l2e(struct adapter *adap, struct
l2t_entry *e, int sync)
{
struct l2t_data *d = adap->l2t;
unsigned int l2t_idx = e->idx + d->l2t_start;
- struct sk_buff *skb;
- struct cpl_l2t_write_req *req;
-
- skb = alloc_skb(sizeof(*req), GFP_ATOMIC);
- if (!skb)
- return -ENOMEM;
+ struct cpl_l2t_write_req sreq, *req = &sreq;
- req = (struct cpl_l2t_write_req *)__skb_put(skb, sizeof(*req));
INIT_TP_WR(req, 0);
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_L2T_WRITE_REQ,
@@ -159,7 +153,8 @@ static int write_l2e(struct adapter *adap, struct l2t_entry
*e, int sync)
memcpy(e->dmac, e->neigh->ha, sizeof(e->dmac));
memcpy(req->dst_mac, e->dmac, sizeof(req->dst_mac));
- t4_mgmt_tx(adap, skb);
+ if (t4_mgmt_tx_direct(adap, req, sizeof(*req)))
+ return -ENOMEM;
if (sync && e->state != L2T_STATE_SWITCHING)
e->state = L2T_STATE_SYNC_WRITE;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index bad253beb8c8..8e0562f52b91 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -1056,6 +1056,30 @@ static void *inline_tx_skb_header(const struct sk_buff
*skb,
return p;
}
+static void *inline_tx_header(const void *src,
+
Re: [PATCH v2 net-next] tcp: md5: use kmalloc() backed scratch areas
On Tue, Jun 28, 2016 at 10:35:31AM -0700, Andy Lutomirski wrote: > > Do you mean this code: Yes. > I'm wondering why support for scatterlists is all-or-nothing. Why > can't we initialize a hash object and then alternate between passing > it scatterlists and pointers? Because once you have started hashing the hash state is not stored in a consistent format. Our software code may maintain one format while a hardware implementation could do something else altogether. So you have to stick with one implementation throughout a particular hashing session. > I'm guessing that ahash enables async operation and shash is > synchronous only. If I'm right, I understand why ahash requires a > scatterlist. What I don't understand is why shash can't also accept a > scatterlist. It appears that most of the ahash users in the tree > actually want synchronous crypto and are presumably using ahash for > some other reason such as ahash's ability to hash via scatterlist (in > this case, struct page *). ahash is meant to be the interface everyone uses regardless of whether they want sync-only or async. shash should only be used for small amounts of hashing on virtual addresses. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)
On Tue, Jun 28, 2016 at 10:32:12AM -0400, George Spelvin wrote: > > - struct crypto_instance > - struct crypto_spawn > - struct crypto_blkcipher > - struct blkcipher_desc > - More on the context structures returned by crypto_tfm_ctx blkcipher is obsolete and will be removed soon. So if you are going to write this then please document skcipher instead. > Also not mentioned in the documentation is that some algorithms *do* > have different implementations depending on key size. SHA-2 is the > classic example. What do you mean by that? SHA has no keying at all. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [iproute PATCH 1/2] ip-address: Support filtering by slave type, too
On 6/28/16 7:07 AM, Phil Sutter wrote: This patch allows to query all interfaces enslaved to a bridge or bond using the following syntax: works for vrf's too.
Re: [PATCH v3] fib_rules: Added NLM_F_EXCL support to fib_nl_newrule
On 6/28/16 6:03 AM, Mateusz Bajorski wrote:
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index 98298b1..fa0c3ff 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -269,6 +269,46 @@ errout:
return err;
}
+static int rule_exists(struct fib_rules_ops *ops, struct fib_rule_hdr *frh,
+ struct nlattr **tb, struct fib_rule *rule)
+{
+ struct fib_rule *r;
+
+ list_for_each_entry(r, &ops->rules_list, list) {
+ if (r->action != rule->action)
+ continue;
+
+ if (r->table != rule->table)
+ continue;
+
+ if (r->pref != rule->pref)
+ continue;
+
+ if (memcmp(r->iifname, rule->iifname, IFNAMSIZ))
+ continue;
+
+ if (memcmp(r->oifname, rule->oifname, IFNAMSIZ))
+ continue;
+
+ if (r->mark != rule->mark)
+ continue;
+
+ if (r->mark_mask != rule->mark_mask)
+ continue;
+
+ if (r->tun_id != rule->tun_id)
+ continue;
+
+ if (r->fr_net != rule->fr_net)
+ continue;
+
+ if (!ops->compare(r, frh, tb))
+ continue;
l3mdev attribute snuck in a couple of weeks ago. You need to compare
r->l3mdev != rule->l3mdev
[PATCH net-next 08/10] liquidio: Droq validation
This patch removes redudant droq num validation.
Signed-off-by: Derek Chickles
Signed-off-by: Satanand Burla
Signed-off-by: Felix Manlunas
Signed-off-by: Raghu Vatsavayi
---
drivers/net/ethernet/cavium/liquidio/octeon_droq.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
index d37a314..b8272ae 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
@@ -833,18 +833,6 @@ octeon_process_droq_poll_cmd(struct octeon_device *oct,
u32 q_no, int cmd,
u32 arg)
{
struct octeon_droq *droq;
- struct octeon_config *oct_cfg = NULL;
-
- oct_cfg = octeon_get_conf(oct);
-
- if (!oct_cfg)
- return -EINVAL;
-
- if (q_no >= CFG_GET_OQ_MAX_Q(oct_cfg)) {
- dev_err(&oct->pci_dev->dev, "%s: droq id (%d) exceeds MAX
(%d)\n",
- __func__, q_no, (oct->num_oqs - 1));
- return -EINVAL;
- }
droq = oct->droq[q_no];
--
1.8.3.1
[PATCH net-next 09/10] liquidio: Remove redundant code
This patch removes redundant file includes and conditions.
Provides some meaningful comments and code alignment.
Signed-off-by: Derek Chickles
Signed-off-by: Satanand Burla
Signed-off-by: Felix Manlunas
Signed-off-by: Raghu Vatsavayi
---
.../net/ethernet/cavium/liquidio/cn66xx_device.c | 2 +-
drivers/net/ethernet/cavium/liquidio/cn68xx_regs.h | 1 -
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 17 ++
drivers/net/ethernet/cavium/liquidio/lio_main.c| 26 +++---
.../net/ethernet/cavium/liquidio/liquidio_common.h | 1 +
.../net/ethernet/cavium/liquidio/octeon_config.h | 4 ++--
.../net/ethernet/cavium/liquidio/octeon_console.c | 12 +-
.../net/ethernet/cavium/liquidio/octeon_device.c | 4 ++--
.../net/ethernet/cavium/liquidio/octeon_device.h | 4 ++--
drivers/net/ethernet/cavium/liquidio/octeon_droq.c | 15 -
drivers/net/ethernet/cavium/liquidio/octeon_iq.h | 2 +-
.../net/ethernet/cavium/liquidio/octeon_network.h | 1 -
.../net/ethernet/cavium/liquidio/request_manager.c | 6 +++--
13 files changed, 49 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
index 96a8802..c02e337 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
@@ -229,7 +229,7 @@ void lio_cn6xxx_setup_global_output_regs(struct
octeon_device *oct)
/* / Select Packet count instead of bytes for SLI_PKTi_CNTS[CNT] */
octeon_write_csr(oct, CN6XXX_SLI_PKT_OUT_BMODE, 0);
- /* / Select ES,RO,NS setting from register for Output Queue Packet
+ /* Select ES, RO, NS setting from register for Output Queue Packet
* Address
*/
octeon_write_csr(oct, CN6XXX_SLI_PKT_DPADDR, 0x);
diff --git a/drivers/net/ethernet/cavium/liquidio/cn68xx_regs.h
b/drivers/net/ethernet/cavium/liquidio/cn68xx_regs.h
index 38cddbd..d45a0f4 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn68xx_regs.h
+++ b/drivers/net/ethernet/cavium/liquidio/cn68xx_regs.h
@@ -29,7 +29,6 @@
#ifndef __CN68XX_REGS_H__
#define __CN68XX_REGS_H__
-#include "cn66xx_regs.h"
/*## REQUEST QUEUE #*/
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index cc755aa..b45456d 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -473,18 +473,16 @@ static int lio_set_phys_id(struct net_device *netdev,
/* Configure Beacon values */
value = LIO68XX_LED_BEACON_CFGON;
- ret =
- octnet_mdio45_access(lio, 1,
-LIO68XX_LED_BEACON_ADDR,
-&value);
+ ret = octnet_mdio45_access(lio, 1,
+ LIO68XX_LED_BEACON_ADDR,
+ &value);
if (ret)
return ret;
value = LIO68XX_LED_CTRL_CFGON;
- ret =
- octnet_mdio45_access(lio, 1,
-LIO68XX_LED_CTRL_ADDR,
-&value);
+ ret = octnet_mdio45_access(lio, 1,
+ LIO68XX_LED_CTRL_ADDR,
+ &value);
if (ret)
return ret;
} else {
@@ -1697,13 +1695,12 @@ static void lio_get_regs(struct net_device *dev,
int len = 0;
struct octeon_device *oct = lio->oct_dev;
- memset(regbuf, 0, OCT_ETHTOOL_REGDUMP_LEN);
regs->version = OCT_ETHTOOL_REGSVER;
switch (oct->chip_id) {
- /* case OCTEON_CN73XX: Todo */
case OCTEON_CN68XX:
case OCTEON_CN66XX:
+ memset(regbuf, 0, OCT_ETHTOOL_REGDUMP_LEN);
len += cn6xxx_read_csr_reg(regbuf + len, oct);
len += cn6xxx_read_config_reg(regbuf + len, oct);
break;
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index ee83047..ccd571b 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -1271,7 +1271,7 @@ static void octeon_destroy_resources(struct octeon_device
*oct)
/* Nothing to be done here either */
break;
- } /* end switch(oct->status) */
+ } /* end switch (oct->status) */
tasklet_kill(&oc
[PATCH net-next 05/10] liquidio: iq/oq limits
This patch removes the dependency of number of iq/oq's on number of cpus. Signed-off-by: Derek Chickles Signed-off-by: Satanand Burla Signed-off-by: Felix Manlunas Signed-off-by: Raghu Vatsavayi --- drivers/net/ethernet/cavium/liquidio/lio_main.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c index 4528396..313ab32 100644 --- a/drivers/net/ethernet/cavium/liquidio/lio_main.c +++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c @@ -3518,7 +3518,6 @@ static int setup_nic_devices(struct octeon_device *octeon_dev) struct liquidio_if_cfg_resp *resp; struct octdev_props *props; int retval, num_iqueues, num_oqueues; - int num_cpus = num_online_cpus(); union oct_nic_if_cfg if_cfg; unsigned int base_queue; unsigned int gmx_port_id; @@ -3560,10 +3559,7 @@ static int setup_nic_devices(struct octeon_device *octeon_dev) gmx_port_id = CFG_GET_GMXID_NIC_IF(octeon_get_conf(octeon_dev), i); ifidx_or_pfnum = i; - if (num_iqueues > num_cpus) - num_iqueues = num_cpus; - if (num_oqueues > num_cpus) - num_oqueues = num_cpus; + dev_dbg(&octeon_dev->pci_dev->dev, "requesting config for interface %d, iqs %d, oqs %d\n", ifidx_or_pfnum, num_iqueues, num_oqueues); -- 1.8.3.1
[PATCH net-next 10/10] liquidio: Response header changes
This patch changes response header to be able to communicate
with new firmware interface.
Signed-off-by: Derek Chickles
Signed-off-by: Satanand Burla
Signed-off-by: Felix Manlunas
Signed-off-by: Raghu Vatsavayi
---
drivers/net/ethernet/cavium/liquidio/liquidio_common.h | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
index d1f5b38..b3434fc 100644
--- a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
+++ b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
@@ -542,6 +542,7 @@ union octeon_rh {
u64 csum_verified:3; /** checksum verified. */
u64 has_hwtstamp:1; /** Has hardware timestamp. 1 = yes. */
u64 encap_on:1;
+ u64 has_hash:1; /** Has hash (rth or rss). 1 = yes. */
} r_dh;
struct {
u64 opcode:4;
@@ -551,7 +552,8 @@ union octeon_rh {
u64 num_gmx_ports:8;
u64 max_nic_ports:10;
u64 app_cap_flags:4;
- u64 app_mode:16;
+ u64 app_mode:8;
+ u64 pkind:8;
} r_core_drv_init;
struct {
u64 opcode:4;
@@ -571,6 +573,7 @@ union octeon_rh {
u64 opcode:4;
} r;
struct {
+ u64 has_hash:1; /** Has hash (rth or rss). 1 = yes. */
u64 encap_on:1;
u64 has_hwtstamp:1; /** 1 = has hwtstamp */
u64 csum_verified:3; /** checksum verified. */
@@ -582,7 +585,8 @@ union octeon_rh {
u64 opcode:4;
} r_dh;
struct {
- u64 app_mode:16;
+ u64 pkind:8;
+ u64 app_mode:8;
u64 app_cap_flags:4;
u64 max_nic_ports:10;
u64 num_gmx_ports:8;
@@ -640,9 +644,11 @@ union oct_link_status {
u64 autoneg:1;
u64 if_mode:5;
u64 pause:1;
- u64 reserved:16;
+ u64 flashing:1;
+ u64 reserved:15;
#else
- u64 reserved:16;
+ u64 reserved:15;
+ u64 flashing:1;
u64 pause:1;
u64 if_mode:5;
u64 autoneg:1;
@@ -869,9 +875,9 @@ union oct_nic_if_cfg {
u64 num_iqueues:16;
u64 num_oqueues:16;
u64 gmx_port_id:8;
- u64 reserved:8;
+ u64 vf_id:8;
#else
- u64 reserved:8;
+ u64 vf_id:8;
u64 gmx_port_id:8;
u64 num_oqueues:16;
u64 num_iqueues:16;
--
1.8.3.1
[PATCH net-next 06/10] liquidio: free resources during shutdown
This patch fixes the issue of proper freeing of queue
memory resources during free device. It also has fix for
correct pcie error reporting.
Signed-off-by: Derek Chickles
Signed-off-by: Satanand Burla
Signed-off-by: Felix Manlunas
Signed-off-by: Raghu Vatsavayi
---
drivers/net/ethernet/cavium/liquidio/cn66xx_device.c | 4 ++--
drivers/net/ethernet/cavium/liquidio/lio_main.c | 4 +++-
drivers/net/ethernet/cavium/liquidio/octeon_console.c | 3 +++
drivers/net/ethernet/cavium/liquidio/octeon_device.c | 10 +-
4 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
index b923c7f..96a8802 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
@@ -74,9 +74,9 @@ void lio_cn6xxx_enable_error_reporting(struct octeon_device
*oct)
u32 val;
pci_read_config_dword(oct->pci_dev, CN6XXX_PCIE_DEVCTL, &val);
- if (val & 0x000f) {
+ if (val & 0x000c) {
dev_err(&oct->pci_dev->dev, "PCI-E Link error detected:
0x%08x\n",
- val & 0x000f);
+ val & 0x000c);
}
val |= 0xf; /* Enable Link error reporting */
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 313ab32..0f39ad0 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -3991,6 +3991,7 @@ static int octeon_device_init(struct octeon_device
*octeon_dev)
/* Release any previously allocated queues */
for (j = 0; j < octeon_dev->num_oqs; j++)
octeon_delete_droq(octeon_dev, j);
+ return 1;
}
atomic_set(&octeon_dev->status, OCT_DEV_DROQ_INIT_DONE);
@@ -4013,7 +4014,8 @@ static int octeon_device_init(struct octeon_device
*octeon_dev)
/* Setup the interrupt handler and record the INT SUM register address
*/
- octeon_setup_interrupt(octeon_dev);
+ if (octeon_setup_interrupt(octeon_dev))
+ return 1;
/* Enable Octeon device interrupts */
octeon_dev->fn_list.enable_interrupt(octeon_dev->chip);
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_console.c
b/drivers/net/ethernet/cavium/liquidio/octeon_console.c
index f96a9d6..05313ac 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_console.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_console.c
@@ -323,6 +323,9 @@ static u64 cvmx_bootmem_phy_named_block_find(struct
octeon_device *oct,
if (name && named_size) {
char *name_tmp =
kmalloc(name_length + 1, GFP_KERNEL);
+ if (!name_tmp)
+ break;
+
CVMX_BOOTMEM_NAMED_GET_NAME(oct, named_addr,
name_tmp,
name_length);
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
index 3372207..26cd494 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
@@ -652,16 +652,16 @@ int octeon_download_firmware(struct octeon_device *oct,
const u8 *data,
void octeon_free_device_mem(struct octeon_device *oct)
{
- u32 i;
+ int i;
for (i = 0; i < MAX_OCTEON_OUTPUT_QUEUES(oct); i++) {
- /* could check mask as well */
- vfree(oct->droq[i]);
+ if (oct->io_qmask.oq & (1ULL << i))
+ vfree(oct->droq[i]);
}
for (i = 0; i < MAX_OCTEON_INSTR_QUEUES(oct); i++) {
- /* could check mask as well */
- vfree(oct->instr_queue[i]);
+ if (oct->io_qmask.iq & (1ULL << i))
+ vfree(oct->instr_queue[i]);
}
i = oct->octeon_id;
--
1.8.3.1
[PATCH net-next 01/10] liquidio: Vxlan support
This patch adds support for Vxaln offloads in liquidio driver.
Signed-off-by: Derek Chickles
Signed-off-by: Satanand Burla
Signed-off-by: Felix Manlunas
Signed-off-by: Raghu Vatsavayi
---
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 29 +++
drivers/net/ethernet/cavium/liquidio/lio_main.c| 233 -
.../net/ethernet/cavium/liquidio/liquidio_common.h | 12 ++
drivers/net/ethernet/cavium/liquidio/octeon_droq.h | 3 +
drivers/net/ethernet/cavium/liquidio/octeon_iq.h | 1 +
.../net/ethernet/cavium/liquidio/octeon_network.h | 8 +
6 files changed, 278 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 03bfa97..a060586 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -106,6 +106,7 @@ static const char oct_stats_strings[][ETH_GSTRING_LEN] = {
"tx_tso",
"tx_tso_packets",
"tx_tso_err",
+ "tx_vxlan",
"mac_tx_total_pkts",
"mac_tx_total_bytes",
@@ -129,6 +130,9 @@ static const char oct_stats_strings[][ETH_GSTRING_LEN] = {
"rx_err_link",
"rx_err_drop",
+ "rx_vxlan",
+ "rx_vxlan_err",
+
"rx_lro_pkts",
"rx_lro_bytes",
"rx_total_lro",
@@ -167,6 +171,7 @@ static const char oct_iq_stats_strings[][ETH_GSTRING_LEN] =
{
"fw_bytes_sent",
"tso",
+ "vxlan",
"txq_restart",
};
@@ -186,6 +191,7 @@ static const char oct_droq_stats_strings[][ETH_GSTRING_LEN]
= {
"fw_bytes_received",
"fw_dropped_nodispatch",
+ "vxlan",
"buffer_alloc_failure",
};
@@ -675,6 +681,10 @@ lio_get_ethtool_stats(struct net_device *netdev,
*fw_err_tso
*/
data[i++] = CVM_CAST64(oct_dev->link_stats.fromhost.fw_err_tso);
+ /*per_core_stats[cvmx_get_core_num()].link_stats[idx].fromhost.
+*fw_tx_vxlan
+*/
+ data[i++] = CVM_CAST64(oct_dev->link_stats.fromhost.fw_tx_vxlan);
/* mac tx statistics */
/*CVMX_BGXX_CMRX_TX_STAT5 */
@@ -729,6 +739,15 @@ lio_get_ethtool_stats(struct net_device *netdev,
*/
data[i++] = CVM_CAST64(oct_dev->link_stats.fromwire.fw_err_drop);
+ /*per_core_stats[cvmx_get_core_num()].link_stats[lro_ctx->ifidx].
+*fromwire.fw_rx_vxlan
+*/
+ data[i++] = CVM_CAST64(oct_dev->link_stats.fromwire.fw_rx_vxlan);
+ /*per_core_stats[cvmx_get_core_num()].link_stats[lro_ctx->ifidx].
+*fromwire.fw_rx_vxlan_err
+*/
+ data[i++] = CVM_CAST64(oct_dev->link_stats.fromwire.fw_rx_vxlan_err);
+
/* LRO */
/*per_core_stats[cvmx_get_core_num()].link_stats[ifidx].fromwire.
*fw_lro_pkts
@@ -822,6 +841,8 @@ lio_get_ethtool_stats(struct net_device *netdev,
/*tso request*/
data[i++] = CVM_CAST64(oct_dev->instr_queue[j]->stats.tx_gso);
+ /*vxlan request*/
+ data[i++] = CVM_CAST64(oct_dev->instr_queue[j]->stats.tx_vxlan);
/*txq restart*/
data[i++] =
CVM_CAST64(oct_dev->instr_queue[j]->stats.tx_restart);
@@ -858,6 +879,9 @@ lio_get_ethtool_stats(struct net_device *netdev,
CVM_CAST64(oct_dev->droq[j]->stats.bytes_received);
data[i++] =
CVM_CAST64(oct_dev->droq[j]->stats.dropped_nodispatch);
+
+ data[i++] =
+ CVM_CAST64(oct_dev->droq[j]->stats.rx_vxlan);
data[i++] =
CVM_CAST64(oct_dev->droq[j]->stats.rx_alloc_failure);
}
@@ -1083,6 +1107,9 @@ octnet_nic_stats_callback(struct octeon_device *oct_dev,
rstats->fw_err_pko = rsp_rstats->fw_err_pko;
rstats->fw_err_link = rsp_rstats->fw_err_link;
rstats->fw_err_drop = rsp_rstats->fw_err_drop;
+ rstats->fw_rx_vxlan = rsp_rstats->fw_rx_vxlan;
+ rstats->fw_rx_vxlan_err = rsp_rstats->fw_rx_vxlan_err;
+
/* Number of packets that are LROed */
rstats->fw_lro_pkts = rsp_rstats->fw_lro_pkts;
/* Number of octets that are LROed */
@@ -1127,6 +1154,8 @@ octnet_nic_stats_callback(struct octeon_device *oct_dev,
tstats->fw_tso = rsp_tstats->fw_tso;
tstats->fw_tso_fwd = rsp_tstats->fw_tso_fwd;
tstats->fw_err_tso = rsp_tstats->fw_err_tso;
+ tstats->fw_tx_vxlan = rsp_tstats->fw_tx_vxlan;
+
resp->status = 1;
} else {
resp->status = -1;
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 1a584eb..9530df8 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -2001,12 +2001,31 @@ liq
[PATCH net-next 03/10] liquidio: IQ synchronization
This patch tries to protect against bh preemption with
sc_buf_pool. It also modifies the syncronization primitives
during input queue processing.
Signed-off-by: Derek Chickles
Signed-off-by: Satanand Burla
Signed-off-by: Felix Manlunas
Signed-off-by: Raghu Vatsavayi
---
.../net/ethernet/cavium/liquidio/request_manager.c | 27 +-
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c
b/drivers/net/ethernet/cavium/liquidio/request_manager.c
index 8c82ccf..3e40cd6 100644
--- a/drivers/net/ethernet/cavium/liquidio/request_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c
@@ -371,6 +371,7 @@ lio_process_iq_request_list(struct octeon_device *oct,
unsigned int pkts_compl = 0, bytes_compl = 0;
struct octeon_soft_command *sc;
struct octeon_instr_irh *irh;
+ unsigned long flags;
while (old != iq->octeon_read_index) {
reqtype = iq->request_list[old].reqtype;
@@ -400,15 +401,19 @@ lio_process_iq_request_list(struct octeon_device *oct,
* command response list because we expect
* a response from Octeon.
*/
- spin_lock_bh(&oct->response_list
- [OCTEON_ORDERED_SC_LIST].lock);
+ spin_lock_irqsave
+ (&oct->response_list
+[OCTEON_ORDERED_SC_LIST].lock,
+flags);
atomic_inc(&oct->response_list
[OCTEON_ORDERED_SC_LIST].
pending_req_count);
list_add_tail(&sc->node, &oct->response_list
[OCTEON_ORDERED_SC_LIST].head);
- spin_unlock_bh(&oct->response_list
- [OCTEON_ORDERED_SC_LIST].lock);
+ spin_unlock_irqrestore
+ (&oct->response_list
+[OCTEON_ORDERED_SC_LIST].lock,
+flags);
} else {
if (sc->callback) {
sc->callback(oct, OCTEON_REQUEST_DONE,
@@ -688,7 +693,7 @@ int octeon_free_sc_buffer_pool(struct octeon_device *oct)
struct list_head *tmp, *tmp2;
struct octeon_soft_command *sc;
- spin_lock(&oct->sc_buf_pool.lock);
+ spin_lock_bh(&oct->sc_buf_pool.lock);
list_for_each_safe(tmp, tmp2, &oct->sc_buf_pool.head) {
list_del(tmp);
@@ -700,7 +705,7 @@ int octeon_free_sc_buffer_pool(struct octeon_device *oct)
INIT_LIST_HEAD(&oct->sc_buf_pool.head);
- spin_unlock(&oct->sc_buf_pool.lock);
+ spin_unlock_bh(&oct->sc_buf_pool.lock);
return 0;
}
@@ -719,10 +724,10 @@ struct octeon_soft_command
*octeon_alloc_soft_command(struct octeon_device *oct,
WARN_ON((offset + datasize + rdatasize + ctxsize) >
SOFT_COMMAND_BUFFER_SIZE);
- spin_lock(&oct->sc_buf_pool.lock);
+ spin_lock_bh(&oct->sc_buf_pool.lock);
if (list_empty(&oct->sc_buf_pool.head)) {
- spin_unlock(&oct->sc_buf_pool.lock);
+ spin_unlock_bh(&oct->sc_buf_pool.lock);
return NULL;
}
@@ -733,7 +738,7 @@ struct octeon_soft_command
*octeon_alloc_soft_command(struct octeon_device *oct,
atomic_inc(&oct->sc_buf_pool.alloc_buf_count);
- spin_unlock(&oct->sc_buf_pool.lock);
+ spin_unlock_bh(&oct->sc_buf_pool.lock);
sc = (struct octeon_soft_command *)tmp;
@@ -776,11 +781,11 @@ struct octeon_soft_command
*octeon_alloc_soft_command(struct octeon_device *oct,
void octeon_free_soft_command(struct octeon_device *oct,
struct octeon_soft_command *sc)
{
- spin_lock(&oct->sc_buf_pool.lock);
+ spin_lock_bh(&oct->sc_buf_pool.lock);
list_add_tail(&sc->node, &oct->sc_buf_pool.head);
atomic_dec(&oct->sc_buf_pool.alloc_buf_count);
- spin_unlock(&oct->sc_buf_pool.lock);
+ spin_unlock_bh(&oct->sc_buf_pool.lock);
}
--
1.8.3.1
[PATCH net-next 07/10] liquidio: MTU limits
This patch limits the MTU between 68 bytes and 16000 bytes.
Signed-off-by: Derek Chickles
Signed-off-by: Satanand Burla
Signed-off-by: Felix Manlunas
Signed-off-by: Raghu Vatsavayi
---
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 2 +-
drivers/net/ethernet/cavium/liquidio/lio_main.c | 21 +++--
.../net/ethernet/cavium/liquidio/octeon_network.h | 3 +++
3 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 81c3b58..cc755aa 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -563,7 +563,7 @@ lio_ethtool_get_ringparam(struct net_device *netdev,
tx_pending = CFG_GET_NUM_TX_DESCS_NIC_IF(conf6x, lio->ifidx);
}
- if (lio->mtu > OCTNET_DEFAULT_FRM_SIZE) {
+ if (lio->mtu > OCTNET_DEFAULT_FRM_SIZE - OCTNET_FRM_HEADER_SIZE) {
ering->rx_pending = 0;
ering->rx_max_pending = 0;
ering->rx_mini_pending = 0;
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 0f39ad0..ee83047 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -2386,11 +2386,14 @@ void liquidio_link_ctrl_cmd_completion(void *nctrl_ptr)
case OCTNET_CMD_CHANGE_MTU:
/* If command is successful, change the MTU. */
netif_info(lio, probe, lio->netdev, " MTU Changed from %d to
%d\n",
- netdev->mtu, nctrl->ncmd.s.param2);
+ netdev->mtu, nctrl->ncmd.s.param1);
dev_info(&oct->pci_dev->dev, "%s MTU Changed from %d to %d\n",
netdev->name, netdev->mtu,
-nctrl->ncmd.s.param2);
- netdev->mtu = nctrl->ncmd.s.param2;
+nctrl->ncmd.s.param1);
+ rtnl_lock();
+ netdev->mtu = nctrl->ncmd.s.param1;
+ call_netdevice_notifiers(NETDEV_CHANGEMTU, netdev);
+ rtnl_unlock();
break;
case OCTNET_CMD_GPIO_ACCESS:
@@ -2682,18 +2685,16 @@ static int liquidio_change_mtu(struct net_device
*netdev, int new_mtu)
struct lio *lio = GET_LIO(netdev);
struct octeon_device *oct = lio->oct_dev;
struct octnic_ctrl_pkt nctrl;
- int max_frm_size = new_mtu + OCTNET_FRM_HEADER_SIZE;
int ret = 0;
- /* Limit the MTU to make sure the ethernet packets are between 64 bytes
-* and 65535 bytes
+ /* Limit the MTU to make sure the ethernet packets are between 68 bytes
+* and 16000 bytes
*/
- if ((max_frm_size < OCTNET_MIN_FRM_SIZE) ||
- (max_frm_size > OCTNET_MAX_FRM_SIZE)) {
+ if ((new_mtu < LIO_MIN_MTU_SIZE) ||
+ (new_mtu > LIO_MAX_MTU_SIZE)) {
dev_err(&oct->pci_dev->dev, "Invalid MTU: %d\n", new_mtu);
dev_err(&oct->pci_dev->dev, "Valid range %d and %d\n",
- (OCTNET_MIN_FRM_SIZE - OCTNET_FRM_HEADER_SIZE),
- (OCTNET_MAX_FRM_SIZE - OCTNET_FRM_HEADER_SIZE));
+ LIO_MIN_MTU_SIZE, LIO_MAX_MTU_SIZE);
return -EINVAL;
}
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_network.h
b/drivers/net/ethernet/cavium/liquidio/octeon_network.h
index 4489fc4..aa9ee79 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_network.h
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_network.h
@@ -30,6 +30,9 @@
#include
#include
+#define LIO_MAX_MTU_SIZE (OCTNET_MAX_FRM_SIZE - OCTNET_FRM_HEADER_SIZE)
+#define LIO_MIN_MTU_SIZE 68
+
struct oct_nic_stats_resp {
u64 rh;
struct oct_link_stats stats;
--
1.8.3.1
[PATCH net-next 04/10] liquidio: softcommand delay
This patch updates the delay constant for softcommands in
accrodance with new requirements.
Signed-off-by: Derek Chickles
Signed-off-by: Satanand Burla
Signed-off-by: Felix Manlunas
Signed-off-by: Raghu Vatsavayi
---
drivers/net/ethernet/cavium/liquidio/lio_main.c | 2 +-
drivers/net/ethernet/cavium/liquidio/request_manager.c | 3 ++-
drivers/net/ethernet/cavium/liquidio/response_manager.c | 5 ++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index eda593a..4528396 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -3585,7 +3585,7 @@ static int setup_nic_devices(struct octeon_device
*octeon_dev)
sc->callback = if_cfg_callback;
sc->callback_arg = sc;
- sc->wait_time = 1000;
+ sc->wait_time = 3000;
retval = octeon_send_soft_command(octeon_dev, sc);
if (retval == IQ_SEND_FAILED) {
diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c
b/drivers/net/ethernet/cavium/liquidio/request_manager.c
index 3e40cd6..096d2b9 100644
--- a/drivers/net/ethernet/cavium/liquidio/request_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c
@@ -534,9 +534,10 @@ static void check_db_timeout(struct work_struct *work)
struct octeon_device *oct = (struct octeon_device *)wk->ctxptr;
unsigned long iq_no = wk->ctxul;
struct cavium_wq *db_wq = &oct->check_db_wq[iq_no];
+ u32 delay = 10;
__check_db_timeout(oct, iq_no);
- queue_delayed_work(db_wq->wq, &db_wq->wk.work, msecs_to_jiffies(1));
+ queue_delayed_work(db_wq->wq, &db_wq->wk.work, msecs_to_jiffies(delay));
}
int
diff --git a/drivers/net/ethernet/cavium/liquidio/response_manager.c
b/drivers/net/ethernet/cavium/liquidio/response_manager.c
index c93210f..b925a30 100644
--- a/drivers/net/ethernet/cavium/liquidio/response_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/response_manager.c
@@ -66,7 +66,7 @@ int octeon_setup_response_list(struct octeon_device *oct)
INIT_DELAYED_WORK(&cwq->wk.work, oct_poll_req_completion);
cwq->wk.ctxptr = oct;
oct->cmd_resp_state = OCT_DRV_ONLINE;
- queue_delayed_work(cwq->wq, &cwq->wk.work, msecs_to_jiffies(100));
+ queue_delayed_work(cwq->wq, &cwq->wk.work, msecs_to_jiffies(50));
return ret;
}
@@ -176,6 +176,5 @@ static void oct_poll_req_completion(struct work_struct
*work)
struct cavium_wq *cwq = &oct->dma_comp_wq;
lio_process_ordered_list(oct, 0);
-
- queue_delayed_work(cwq->wq, &cwq->wk.work, msecs_to_jiffies(100));
+ queue_delayed_work(cwq->wq, &cwq->wk.work, msecs_to_jiffies(50));
}
--
1.8.3.1
[PATCH net-next 02/10] liquidio: Macro replacements
This patch has minor replacements of ACCESS_ONCE macros with
WRITE_ONCE and replacement of BUG_ON with polite version WARN_ON.
Signed-off-by: Derek Chickles
Signed-off-by: Satanand Burla
Signed-off-by: Felix Manlunas
Signed-off-by: Raghu Vatsavayi
---
.../net/ethernet/cavium/liquidio/cn66xx_device.c | 2 +-
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 13 +++---
drivers/net/ethernet/cavium/liquidio/lio_main.c| 41 ++
.../net/ethernet/cavium/liquidio/octeon_console.c | 18
.../net/ethernet/cavium/liquidio/octeon_device.h | 2 +-
drivers/net/ethernet/cavium/liquidio/octeon_droq.c | 5 +--
drivers/net/ethernet/cavium/liquidio/octeon_droq.h | 3 +-
drivers/net/ethernet/cavium/liquidio/octeon_main.h | 2 +-
.../net/ethernet/cavium/liquidio/octeon_mem_ops.c | 9 ++--
.../net/ethernet/cavium/liquidio/octeon_network.h | 2 +-
.../net/ethernet/cavium/liquidio/request_manager.c | 48 --
11 files changed, 58 insertions(+), 87 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
index d35864a..b923c7f 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
@@ -579,7 +579,7 @@ int lio_cn6xxx_process_droq_intr_regs(struct octeon_device
*oct)
continue;
droq = oct->droq[oq_no];
- pkt_count = octeon_droq_check_hw_for_pkts(oct, droq);
+ pkt_count = octeon_droq_check_hw_for_pkts(droq);
if (pkt_count) {
oct->droq_intr |= (1ULL << oq_no);
if (droq->ops.poll_mode) {
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index a060586..81c3b58 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -357,9 +357,9 @@ static void octnet_mdio_resp_callback(struct octeon_device
*oct,
if (status) {
dev_err(&oct->pci_dev->dev, "MIDO instruction failed. Status:
%llx\n",
CVM_CAST64(status));
- ACCESS_ONCE(mdio_cmd_ctx->cond) = -1;
+ WRITE_ONCE(mdio_cmd_ctx->cond, -1);
} else {
- ACCESS_ONCE(mdio_cmd_ctx->cond) = 1;
+ WRITE_ONCE(mdio_cmd_ctx->cond, 1);
}
wake_up_interruptible(&mdio_cmd_ctx->wc);
}
@@ -390,7 +390,7 @@ octnet_mdio45_access(struct lio *lio, int op, int loc, int
*value)
mdio_cmd_rsp = (struct oct_mdio_cmd_resp *)sc->virtrptr;
mdio_cmd = (struct oct_mdio_cmd *)sc->virtdptr;
- ACCESS_ONCE(mdio_cmd_ctx->cond) = 0;
+ WRITE_ONCE(mdio_cmd_ctx->cond, 0);
mdio_cmd_ctx->octeon_id = lio_get_device_id(oct_dev);
mdio_cmd->op = op;
mdio_cmd->mdio_addr = loc;
@@ -429,7 +429,7 @@ octnet_mdio45_access(struct lio *lio, int op, int loc, int
*value)
octeon_swap_8B_data((u64 *)(&mdio_cmd_rsp->resp),
sizeof(struct oct_mdio_cmd) / 8);
- if (ACCESS_ONCE(mdio_cmd_ctx->cond) == 1) {
+ if (READ_ONCE(mdio_cmd_ctx->cond) == 1) {
if (!op)
*value = mdio_cmd_rsp->resp.value1;
} else {
@@ -623,7 +623,8 @@ lio_get_pauseparam(struct net_device *netdev, struct
ethtool_pauseparam *pause)
static void
lio_get_ethtool_stats(struct net_device *netdev,
- struct ethtool_stats *stats, u64 *data)
+ struct ethtool_stats *stats __attribute__((unused)),
+ u64 *data)
{
struct lio *lio = GET_LIO(netdev);
struct octeon_device *oct_dev = lio->oct_dev;
@@ -1552,7 +1553,7 @@ static int lio_nway_reset(struct net_device *netdev)
}
/* Return register dump len. */
-static int lio_get_regs_len(struct net_device *dev)
+static int lio_get_regs_len(struct net_device *dev __attribute__((unused)))
{
return OCT_ETHTOOL_REGDUMP_LEN;
}
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 9530df8..eda593a 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -251,8 +251,7 @@ static int lio_wait_for_oq_pkts(struct octeon_device *oct)
for (i = 0; i < MAX_OCTEON_OUTPUT_QUEUES(oct); i++) {
if (!(oct->io_qmask.oq & (1ULL << i)))
continue;
- pkt_cnt += octeon_droq_check_hw_for_pkts(oct,
-oct->droq[i]);
+ pkt_cnt += octeon_droq_check_hw_for_pkts(oct->droq[i]);
}
if (pkt_cnt > 0) {
[PATCH net-next 00/10] liquidio updates and bug fixes
Dave, Following are some more updates and bug fixes for liquidio driver. Please apply the patches in following order as some of the patches depend on earlier patches in the sereis. Raghu Vatsavayi (10): liquidio: Vxlan support liquidio: Macro replacements liquidio: IQ synchronization liquidio: softcommand delay liquidio: iq/oq limits liquidio: free resources during shutdown liquidio: MTU limits liquidio: Droq validation liquidio: Remove redundant code liquidio: Response header changes .../net/ethernet/cavium/liquidio/cn66xx_device.c | 8 +- drivers/net/ethernet/cavium/liquidio/cn68xx_regs.h | 1 - drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 61 ++-- drivers/net/ethernet/cavium/liquidio/lio_main.c| 333 + .../net/ethernet/cavium/liquidio/liquidio_common.h | 31 +- .../net/ethernet/cavium/liquidio/octeon_config.h | 4 +- .../net/ethernet/cavium/liquidio/octeon_console.c | 33 +- .../net/ethernet/cavium/liquidio/octeon_device.c | 14 +- .../net/ethernet/cavium/liquidio/octeon_device.h | 6 +- drivers/net/ethernet/cavium/liquidio/octeon_droq.c | 32 +- drivers/net/ethernet/cavium/liquidio/octeon_droq.h | 6 +- drivers/net/ethernet/cavium/liquidio/octeon_iq.h | 3 +- drivers/net/ethernet/cavium/liquidio/octeon_main.h | 2 +- .../net/ethernet/cavium/liquidio/octeon_mem_ops.c | 9 +- .../net/ethernet/cavium/liquidio/octeon_network.h | 14 +- .../net/ethernet/cavium/liquidio/request_manager.c | 84 ++ .../ethernet/cavium/liquidio/response_manager.c| 5 +- 17 files changed, 447 insertions(+), 199 deletions(-) -- 1.8.3.1
Re: [PATCH v2 iproute2 3/3] ss: Add support to filter on device
On Tue, 28 Jun 2016 11:40:40 -0600
David Ahern wrote:
> On 6/27/16 3:13 PM, Stephen Hemminger wrote:
> > On Mon, 27 Jun 2016 11:34:25 -0700
> > David Ahern wrote:
> >
> >> + case SSF_DEVCOND:
> >> + {
> >> + struct aafilter *a = (void *)f->pred;
> >
> > I don't like the wandering bracket left, but all the code has that.
> > After this will change it to:
> > case SSF_DEVCOND: {
> > struct aafilter *a = f->pred;
> > ...
> >
>
> meaning you'll take the patches as is since they follow current
> formatting and you will apply a patch to fix the indentation in that
> run_ssfilter? They have not shown up in your repo so want to make sure I
> understand the intent.
They all got applied today
[PATCH] ip route: timeout for routes has to be set in seconds
From: Andrew Vagin
Currently a timeout is multiplied by HZ in user-space and
then it multiplied by HZ in kernel-space.
$ ./ip/ip r add 2002::0/64 dev veth1 expires 10
$ ./ip/ip -6 r
2002::/64 dev veth1 metric 1024 linkdown expires 996sec pref medium
Cc: Xin Long
Cc: Hangbin Liu
Cc: Stephen Hemminger
Fixes: 68eede250500 ("route: allow routes to be configured with expire values")
Signed-off-by: Andrew Vagin
---
ip/iproute.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index 8224d7f..7c0f5a4 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -839,7 +839,6 @@ static int iproute_modify(int cmd, unsigned int flags, int
argc, char **argv)
int table_ok = 0;
int raw = 0;
int type_ok = 0;
- static int hz;
memset(&req, 0, sizeof(req));
@@ -923,9 +922,7 @@ static int iproute_modify(int cmd, unsigned int flags, int
argc, char **argv)
NEXT_ARG();
if (get_u32(&expires, *argv, 0))
invarg("\"expires\" value is invalid\n", *argv);
- if (!hz)
- hz = get_user_hz();
- addattr32(&req.n, sizeof(req), RTA_EXPIRES, expires*hz);
+ addattr32(&req.n, sizeof(req), RTA_EXPIRES, expires);
} else if (matches(*argv, "metric") == 0 ||
matches(*argv, "priority") == 0 ||
strcmp(*argv, "preference") == 0) {
--
2.7.4
[PATCH V2 net-next] tcp: increase size at which tcp_bound_to_half_wnd bounds to > TCP_MSS_DEFAULT
In previous commit 01f83d69844d307be2aa6fea88b0e8fe5cbdb2f4 the following comments were added: "When peer uses tiny windows, there is no use in packetizing to sub-MSS pieces for the sake of SWS or making sure there are enough packets in the pipe for fast recovery." The test should be > TCP_MSS_DEFAULT not >= 512. This allows low end devices that send an MSS of 536 (TCP_MSS_DEFAULT) to see better network performance by sending it 536 bytes of data at a time instead of bounding to half window size (268). Other network stacks work this way, e.g. HP-UX. Signed-off-by: Shane Seymour --- Changed from V1 - patch reversed, Doh!, corrected patch. --- a/include/net/tcp.h 2016-06-15 17:19:21.964821477 -0500 +++ b/include/net/tcp.h 2016-06-23 20:59:14.521686048 -0500 @@ -589,7 +589,7 @@ static inline int tcp_bound_to_half_wnd( * On the other hand, for extremely large MSS devices, handling * smaller than MSS windows in this way does make sense. */ - if (tp->max_window >= 512) + if (tp->max_window > TCP_MSS_DEFAULT) cutoff = (tp->max_window >> 1); else cutoff = tp->max_window;
[PATCH 2/2] net: ethernet: lpc_eth: use phy_ethtool_{get|set}_link_ksettings
There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/nxp/lpc_eth.c | 26 ++
1 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c
b/drivers/net/ethernet/nxp/lpc_eth.c
index b003501..01b50ff 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1245,35 +1245,13 @@ static void lpc_eth_ethtool_setmsglevel(struct
net_device *ndev, u32 level)
pldat->msg_enable = level;
}
-static int lpc_eth_ethtool_getsettings(struct net_device *ndev,
- struct ethtool_cmd *cmd)
-{
- struct phy_device *phydev = ndev->phydev;
-
- if (!phydev)
- return -EOPNOTSUPP;
-
- return phy_ethtool_gset(phydev, cmd);
-}
-
-static int lpc_eth_ethtool_setsettings(struct net_device *ndev,
- struct ethtool_cmd *cmd)
-{
- struct phy_device *phydev = ndev->phydev;
-
- if (!phydev)
- return -EOPNOTSUPP;
-
- return phy_ethtool_sset(phydev, cmd);
-}
-
static const struct ethtool_ops lpc_eth_ethtool_ops = {
.get_drvinfo= lpc_eth_ethtool_getdrvinfo,
- .get_settings = lpc_eth_ethtool_getsettings,
- .set_settings = lpc_eth_ethtool_setsettings,
.get_msglevel = lpc_eth_ethtool_getmsglevel,
.set_msglevel = lpc_eth_ethtool_setmsglevel,
.get_link = ethtool_op_get_link,
+ .get_link_ksettings = phy_ethtool_get_link_ksettings,
+ .set_link_ksettings = phy_ethtool_set_link_ksettings,
};
static const struct net_device_ops lpc_netdev_ops = {
--
1.7.4.4
RE: [PATCH net-next] tcp: increase size at which tcp_bound_to_half_wnd bounds to > TCP_MSS_DEFAULT
> From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Your diff is reversed. Sorry my apologies, I'll send a V2.
Re: [PATCH net-next] tcp: increase size at which tcp_bound_to_half_wnd bounds to > TCP_MSS_DEFAULT
On Tue, Jun 28, 2016 at 5:54 PM, Seymour, Shane M wrote: >> From: Eric Dumazet [mailto:eric.duma...@gmail.com] ... >> Anyway, your patch is reversed. > > I'm not sure what you mean by reversed, I didn't change the direction > of the test in the code just what it's being compared against and so > it's greater than not greater than or equal to. By reversed, I believe Eric means the following: Your patch claims that the current line you want to replace says: - if (tp->max_window > TCP_MSS_DEFAULT) And that you want to replace it with this line: + if (tp->max_window >= 512) However, the currrent line is the latter: if (tp->max_window >= 512) And presumably you want to replace it with the former. It might be best to generate the patch with git. neal
Re: [PATCH net-next] tcp: increase size at which tcp_bound_to_half_wnd bounds to > TCP_MSS_DEFAULT
On Tue, 2016-06-28 at 21:54 +, Seymour, Shane M wrote: > > From: Eric Dumazet [mailto:eric.duma...@gmail.com] > > Trying to cope with ridiculous windows these days is really a waste of > > time, as we perform this check for all tcp sendmsg() calls :( > > I don't disagree with you but unfortunately there are still devices > out there like this and probably will be for a long time. > > > Anyway, your patch is reversed. > > I'm not sure what you mean by reversed, I didn't change the direction > of the test in the code just what it's being compared against and so > it's greater than not greater than or equal to. > > Unless auto-correction changed reviewed to reversed? Your diff is reversed. You sent : --- b/include/net/tcp.h 2016-06-23 20:59:14.521686048 -0500 +++ a/include/net/tcp.h 2016-06-15 17:19:21.964821477 -0500 @@ -589,7 +589,7 @@ static inline int tcp_bound_to_half_wnd( * On the other hand, for extremely large MSS devices, handling * smaller than MSS windows in this way does make sense. */ - if (tp->max_window > TCP_MSS_DEFAULT) + if (tp->max_window >= 512) cutoff = (tp->max_window >> 1); else cutoff = tp->max_window; You meant instead : diff --git a/include/net/tcp.h b/include/net/tcp.h index 0bcc70f4e1fb..8dafd2c31b1d 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -589,7 +589,7 @@ static inline int tcp_bound_to_half_wnd(struct tcp_sock *tp, int pktsize) * On the other hand, for extremely large MSS devices, handling * smaller than MSS windows in this way does make sense. */ - if (tp->max_window >= 512) + if (tp->max_window > TCP_MSS_DEFAULT) cutoff = (tp->max_window >> 1); else cutoff = tp->max_window;
[PATCH 1/2] net: ethernet: lpc_eth: use phydev from struct net_device
The private structure contain a pointer to phydev, but the structure
net_device already contain such pointer. So we can remove the pointer
phydev in the private structure, and update the driver to use the
one contained in struct net_device.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/nxp/lpc_eth.c | 22 +-
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c
b/drivers/net/ethernet/nxp/lpc_eth.c
index b1ce7aa..b003501 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -425,7 +425,6 @@ struct netdata_local {
unsigned intlast_tx_idx;
unsigned intnum_used_tx_buffs;
struct mii_bus *mii_bus;
- struct phy_device *phy_dev;
struct clk *clk;
dma_addr_t dma_buff_base_p;
void*dma_buff_base_v;
@@ -750,7 +749,7 @@ static int lpc_mdio_reset(struct mii_bus *bus)
static void lpc_handle_link_change(struct net_device *ndev)
{
struct netdata_local *pldat = netdev_priv(ndev);
- struct phy_device *phydev = pldat->phy_dev;
+ struct phy_device *phydev = ndev->phydev;
unsigned long flags;
bool status_change = false;
@@ -814,7 +813,6 @@ static int lpc_mii_probe(struct net_device *ndev)
pldat->link = 0;
pldat->speed = 0;
pldat->duplex = -1;
- pldat->phy_dev = phydev;
phy_attached_info(phydev);
@@ -1048,8 +1046,8 @@ static int lpc_eth_close(struct net_device *ndev)
napi_disable(&pldat->napi);
netif_stop_queue(ndev);
- if (pldat->phy_dev)
- phy_stop(pldat->phy_dev);
+ if (ndev->phydev)
+ phy_stop(ndev->phydev);
spin_lock_irqsave(&pldat->lock, flags);
__lpc_eth_reset(pldat);
@@ -1186,7 +1184,7 @@ static void lpc_eth_set_multicast_list(struct net_device
*ndev)
static int lpc_eth_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
{
struct netdata_local *pldat = netdev_priv(ndev);
- struct phy_device *phydev = pldat->phy_dev;
+ struct phy_device *phydev = ndev->phydev;
if (!netif_running(ndev))
return -EINVAL;
@@ -1207,14 +1205,14 @@ static int lpc_eth_open(struct net_device *ndev)
__lpc_eth_clock_enable(pldat, true);
/* Suspended PHY makes LPC ethernet core block, so resume now */
- phy_resume(pldat->phy_dev);
+ phy_resume(ndev->phydev);
/* Reset and initialize */
__lpc_eth_reset(pldat);
__lpc_eth_init(pldat);
/* schedule a link state check */
- phy_start(pldat->phy_dev);
+ phy_start(ndev->phydev);
netif_start_queue(ndev);
napi_enable(&pldat->napi);
@@ -1250,8 +1248,7 @@ static void lpc_eth_ethtool_setmsglevel(struct net_device
*ndev, u32 level)
static int lpc_eth_ethtool_getsettings(struct net_device *ndev,
struct ethtool_cmd *cmd)
{
- struct netdata_local *pldat = netdev_priv(ndev);
- struct phy_device *phydev = pldat->phy_dev;
+ struct phy_device *phydev = ndev->phydev;
if (!phydev)
return -EOPNOTSUPP;
@@ -1262,8 +1259,7 @@ static int lpc_eth_ethtool_getsettings(struct net_device
*ndev,
static int lpc_eth_ethtool_setsettings(struct net_device *ndev,
struct ethtool_cmd *cmd)
{
- struct netdata_local *pldat = netdev_priv(ndev);
- struct phy_device *phydev = pldat->phy_dev;
+ struct phy_device *phydev = ndev->phydev;
if (!phydev)
return -EOPNOTSUPP;
@@ -1460,7 +1456,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
netdev_info(ndev, "LPC mac at 0x%08x irq %d\n",
res->start, ndev->irq);
- phydev = pldat->phy_dev;
+ phydev = ndev->phydev;
device_init_wakeup(&pdev->dev, 1);
device_set_wakeup_enable(&pdev->dev, 0);
--
1.7.4.4
RE: [PATCH net-next] tcp: increase size at which tcp_bound_to_half_wnd bounds to > TCP_MSS_DEFAULT
> From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Trying to cope with ridiculous windows these days is really a waste of > time, as we perform this check for all tcp sendmsg() calls :( I don't disagree with you but unfortunately there are still devices out there like this and probably will be for a long time. > Anyway, your patch is reversed. I'm not sure what you mean by reversed, I didn't change the direction of the test in the code just what it's being compared against and so it's greater than not greater than or equal to. Unless auto-correction changed reviewed to reversed?
Re: [PATCH v4] wlcore: spi: add wl18xx support
On Sun, Jun 26, 2016 at 10:10:54AM +, Reizer, Eyal wrote: > Add support for using with both wl12xx and wl18xx. > > - all wilink family needs special init command for entering wspi mode. > extra clock cycles should be sent after the spi init command while the > cs pin is high. > - Use inverted chip select for sending a dummy 4 bytes command that > completes the init stage. > > Signed-off-by: Eyal Reizer > --- > v1->v2:update device tree bindings configuration > v2->v3:revert from manual gpio manipulation. use inverted chip select instead > for sending the extra init cycle which, achieves the same hardware purpose. > update device tree bindings docucmentation accordingly > v3->v4: Remove redundant data form binding documentation and fix chip select > number mismatch in wl1271 example > > .../bindings/net/wireless/ti,wlcore,spi.txt| 41 +-- Acked-by: Rob Herring > drivers/net/wireless/ti/wlcore/spi.c | 124 > + > 2 files changed, 137 insertions(+), 28 deletions(-)
Re: [PATCH] [v6] net: emac: emac gigabit ethernet controller driver
On Fri, Jun 24, 2016 at 06:46:48PM -0500, Timur Tabi wrote: > Add supports for ethernet controller HW on Qualcomm Technologies, Inc. SoC. > This driver supports the following features: > 1) Checksum offload. > 2) Interrupt coalescing support. > 3) SGMII phy. > 4) phylib interface for external phy > > Based on original work by > Niranjana Vishwanathapura > Gilad Avidov > > Signed-off-by: Timur Tabi > --- > > v6: > - Properly ordered local variables > - use built-in GEN_MASK instead of BITS_MASK > - remove redundant call to emac_rx_mode_set from emac_mac_up > - removed emac_rfd structure, use dma_addr_t directly instead > - removed emac_mac_speed enun, replaced with macros > - removed superfluous phy_stop from emac_mac_down(), which prevented > reloading module > - add missing netif_napi_del > - set the DMA mask > > v5: > - changed author to Timur, added MAINTAINERS entry > - use phylib, replacing internal phy code > - added support for EMAC internal SGMII v2 > - fix ~DIS_INT warning > - update DT bindings, including removing unused properties > - removed interrupt handler for internal sgmii > - removed link status check handler/state (replaced with phylib) > - removed periodic timer handler (replaced with phylib) > - removed power management code (will be rewritten later) > - external phy is now required, not optional > - removed redundant EMAC_STATUS_DOWN status flag > - removed redundant link status and speed variables > - removed redundant status bits (vlan strip, promiscuous, loopback, etc) > - removed useless watchdog status > - removed command-line parameters > - cleaned up probe messages > - removed redundant params from emac_sgmii_link_init() > - always call netdev_completed_queue() (per review comment) > - fix emac_napi_rtx() (per review comment) > - removed max_ints loop in interrupt handler > - removed redundant mutex around phy read/write calls > - added lock for reading emac status (per review comment) > - generate random MAC address if it can't be read from firmware > - replace EMAC_DMA_ADDR_HI/LO with upper/lower_32_bits > - don't test return value from platform_get_resource (per review comment) > - use net_warn_ratelimited (per review comment) > - don't set the dma masks (will be set by DT or IORT code) > - remove unused emac_tx_tpd_ts_save() > - removed redundant local MTU variable > > v4: > - add missing ipv6 header file > - correct compatible string > - fix spacing in emac_reg_write arrays > - drop unnecessary cell-index property > - remove unsupported DT properties from docs > - remove GPIO initialization and update docs > > v3: > - remove most of the memory barriers by using the non xxx_relaxed() api. > - remove RSS and WOL support. > - correct comments from physical address to dma address. > - rearrange structs to make them packed. > - replace polling loops with readl_poll_timeout(). > - remove unnecessary wrapper functions from phy layer. > - add blank line before return statements. > - set to null clocks after clk_put(). > - use module_platform_driver() and dma_set_mask_and_coherent() > - replace long hex bitmasks with BIT() macro. > > v2: > - replace hw bit fields to macros with bitwise operations. > - change all iterators to unsized types (int) > - some minor code flow improvements. > - change return type to void for functions which return value is never >used. > - replace instance of l_relaxed() io followed by mb() with a >readl()/writel(). > > > .../devicetree/bindings/net/qcom-emac.txt | 63 + Acked-by: Rob Herring > MAINTAINERS|6 + > drivers/net/ethernet/qualcomm/Kconfig | 11 + > drivers/net/ethernet/qualcomm/Makefile |2 + > drivers/net/ethernet/qualcomm/emac/Makefile|7 + > drivers/net/ethernet/qualcomm/emac/emac-mac.c | 1661 > > drivers/net/ethernet/qualcomm/emac/emac-mac.h | 271 > drivers/net/ethernet/qualcomm/emac/emac-phy.c | 211 +++ > drivers/net/ethernet/qualcomm/emac/emac-phy.h | 32 + > drivers/net/ethernet/qualcomm/emac/emac-sgmii.c| 700 + > drivers/net/ethernet/qualcomm/emac/emac-sgmii.h| 24 + > drivers/net/ethernet/qualcomm/emac/emac.c | 809 ++ > drivers/net/ethernet/qualcomm/emac/emac.h | 369 + > 13 files changed, 4166 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/qcom-emac.txt > create mode 100644 drivers/net/ethernet/qualcomm/emac/Makefile > create mode 100644 drivers/net/ethernet/qualcomm/emac/emac-mac.c > create mode 100644 drivers/net/ethernet/qualcomm/emac/emac-mac.h > create mode 100644 drivers/net/ethernet/qualcomm/emac/emac-phy.c > create mode 100644 drivers/net/ethernet/qualcomm/emac/emac-phy.h > create mode 100644 drivers/net/ethernet/qualcomm/emac/emac-sgmii.c > create mode 100644 drivers/net/ethernet/qualcomm/emac/
Re: [RFC 6/7] dt-bindings: net: bgmac: add bindings documentation for bgmac
Hello.
On 06/28/2016 10:34 PM, Jon Mason wrote:
Signed-off-by: Jon Mason
---
.../devicetree/bindings/net/brcm,bgmac-enet.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt
diff --git a/Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt
b/Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt
new file mode 100644
index 000..efd36d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt
@@ -0,0 +1,21 @@
+Broadcom GMAC Ethernet Controller Device Tree Bindings
+-
+
+Required properties:
+ - compatible: "brcm,bgmac-enet"
+ - reg:Address and length of the GMAC registers,
+ Address and length of the GMAC IDM registers
+ - interrupts: Interrupt number
+
+Optional properties:
+- mac-address: mac address to be assigned to the device
Refer to ethernet.txt in the same directory.
+
+Examples:
+
+gmac0: enet@18022000 {
The node name should be "ethernet@..." to comply eith the ePAPR standard.
WBR, Sergei
Re: [RFC 3/7] net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file
On Tue, Jun 28, 2016 at 03:34:40PM -0400, Jon Mason wrote: > Move the BCMA MDIO phy into a separate file, as it is very tightly > coupled with the BCMA bus. This will help with the upcoming BCMA > removal from the bgmac driver. Optimally, this should be moved into > phy drivers, but it is too tightly coupled with the bgmac driver to > effectively move it without more changes to the driver. It is quite common to have the MII bus driver as a sub driver of the MAC driver, if they are tightly coupled. The MII drivers in drivers/net/phy are all independent of the MAC driver and use a different space in the register sets. This does not seem the case here, so i think the split you have made is O.K, and i don't see a need to move it into phy. Andrew
Re: [RFC 1/7] net: ethernet: bgmac: change bgmac_* prints to dev_* prints
On Tue, 2016-06-28 at 15:34 -0400, Jon Mason wrote:
> The bgmac_* print wrappers call dev_* prints with the dev pointer from
> the bcma core.  In anticipation of removing the bcma requirement for
> this driver, these must be changed to not reference that struct.  So,
> simply change all of the bgmac_* prints to their dev_* counterparts.  In
> some cases netdev_* prints are more appropriate, so change those as
> well.
Thanks, but...
> diff --git a/drivers/net/ethernet/broadcom/bgmac.c
> b/drivers/net/ethernet/broadcom/bgmac.c
[]
> @@ -1515,7 +1516,7 @@ static void bgmac_get_drvinfo(struct net_device
> *net_dev,
> Â Â Â struct ethtool_drvinfo *info)
> Â {
> Â strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
> - strlcpy(info->bus_info, "BCMA", sizeof(info->bus_info));
> + strlcpy(info->bus_info, "AXI", sizeof(info->bus_info));
> Â }
Unrelated change?
[RFC 1/7] net: ethernet: bgmac: change bgmac_* prints to dev_* prints
The bgmac_* print wrappers call dev_* prints with the dev pointer from
the bcma core. In anticipation of removing the bcma requirement for
this driver, these must be changed to not reference that struct. So,
simply change all of the bgmac_* prints to their dev_* counterparts. In
some cases netdev_* prints are more appropriate, so change those as
well.
Signed-off-by: Jon Mason
---
drivers/net/ethernet/broadcom/bgmac.c | 105 +-
drivers/net/ethernet/broadcom/bgmac.h | 14 +
2 files changed, 56 insertions(+), 63 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c
b/drivers/net/ethernet/broadcom/bgmac.c
index e6e74ca..2ab0887 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -50,7 +50,7 @@ static bool bgmac_wait_value(struct bcma_device *core, u16
reg, u32 mask,
return true;
udelay(10);
}
- pr_err("Timeout waiting for reg 0x%X\n", reg);
+ dev_err(&core->dev, "Timeout waiting for reg 0x%X\n", reg);
return false;
}
@@ -84,8 +84,8 @@ static void bgmac_dma_tx_reset(struct bgmac *bgmac, struct
bgmac_dma_ring *ring)
udelay(10);
}
if (i)
- bgmac_err(bgmac, "Timeout suspending DMA TX ring 0x%X
(BGMAC_DMA_TX_STAT: 0x%08X)\n",
- ring->mmio_base, val);
+ dev_err(bgmac->dev, "Timeout suspending DMA TX ring 0x%X
(BGMAC_DMA_TX_STAT: 0x%08X)\n",
+ ring->mmio_base, val);
/* Remove SUSPEND bit */
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_TX_CTL, 0);
@@ -93,13 +93,13 @@ static void bgmac_dma_tx_reset(struct bgmac *bgmac, struct
bgmac_dma_ring *ring)
ring->mmio_base + BGMAC_DMA_TX_STATUS,
BGMAC_DMA_TX_STAT, BGMAC_DMA_TX_STAT_DISABLED,
1)) {
- bgmac_warn(bgmac, "DMA TX ring 0x%X wasn't disabled on time,
waiting additional 300us\n",
- ring->mmio_base);
+ dev_warn(bgmac->dev, "DMA TX ring 0x%X wasn't disabled on time,
waiting additional 300us\n",
+ring->mmio_base);
udelay(300);
val = bgmac_read(bgmac, ring->mmio_base + BGMAC_DMA_TX_STATUS);
if ((val & BGMAC_DMA_TX_STAT) != BGMAC_DMA_TX_STAT_DISABLED)
- bgmac_err(bgmac, "Reset of DMA TX ring 0x%X failed\n",
- ring->mmio_base);
+ dev_err(bgmac->dev, "Reset of DMA TX ring 0x%X
failed\n",
+ ring->mmio_base);
}
}
@@ -161,7 +161,7 @@ static netdev_tx_t bgmac_dma_tx_add(struct bgmac *bgmac,
int i;
if (skb->len > BGMAC_DESC_CTL1_LEN) {
- bgmac_err(bgmac, "Too long skb (%d)\n", skb->len);
+ netdev_err(bgmac->net_dev, "Too long skb (%d)\n", skb->len);
goto err_drop;
}
@@ -174,7 +174,7 @@ static netdev_tx_t bgmac_dma_tx_add(struct bgmac *bgmac,
* even when ring->end overflows
*/
if (ring->end - ring->start + nr_frags + 1 >= BGMAC_TX_RING_SLOTS) {
- bgmac_err(bgmac, "TX ring is full, queue should be stopped!\n");
+ netdev_err(bgmac->net_dev, "TX ring is full, queue should be
stopped!\n");
netif_stop_queue(net_dev);
return NETDEV_TX_BUSY;
}
@@ -241,8 +241,8 @@ err_dma:
}
err_dma_head:
- bgmac_err(bgmac, "Mapping error of skb on ring 0x%X\n",
- ring->mmio_base);
+ netdev_err(bgmac->net_dev, "Mapping error of skb on ring 0x%X\n",
+ ring->mmio_base);
err_drop:
dev_kfree_skb(skb);
@@ -320,8 +320,8 @@ static void bgmac_dma_rx_reset(struct bgmac *bgmac, struct
bgmac_dma_ring *ring)
ring->mmio_base + BGMAC_DMA_RX_STATUS,
BGMAC_DMA_RX_STAT, BGMAC_DMA_RX_STAT_DISABLED,
1))
- bgmac_err(bgmac, "Reset of ring 0x%X RX failed\n",
- ring->mmio_base);
+ dev_err(bgmac->dev, "Reset of ring 0x%X RX failed\n",
+ ring->mmio_base);
}
static void bgmac_dma_rx_enable(struct bgmac *bgmac,
@@ -370,7 +370,7 @@ static int bgmac_dma_rx_skb_for_slot(struct bgmac *bgmac,
dma_addr = dma_map_single(dma_dev, buf + BGMAC_RX_BUF_OFFSET,
BGMAC_RX_BUF_SIZE, DMA_FROM_DEVICE);
if (dma_mapping_error(dma_dev, dma_addr)) {
- bgmac_err(bgmac, "DMA mapping error\n");
+ netdev_err(bgmac->net_dev, "DMA mapping error\n");
put_page(virt_to_head_page(buf));
return -ENOMEM;
}
@@ -465,16 +465,16 @@ static int bgmac_dma_rx_read(struct bgmac *bgmac, struct
bgmac_dma_ring *ring,
[RFC 3/7] net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file
Move the BCMA MDIO phy into a separate file, as it is very tightly
coupled with the BCMA bus. This will help with the upcoming BCMA
removal from the bgmac driver. Optimally, this should be moved into
phy drivers, but it is too tightly coupled with the bgmac driver to
effectively move it without more changes to the driver.
Note: the phy_reset was intentionally removed, as the mdio phy subsystem
automatically resets the phy if a reset function pointer is present. In
addition to the moving of the driver, this reset function is added.
Signed-off-by: Jon Mason
---
drivers/net/ethernet/broadcom/Makefile | 2 +-
drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c | 264
drivers/net/ethernet/broadcom/bgmac.c | 246 +++---
drivers/net/ethernet/broadcom/bgmac.h | 3 +
4 files changed, 298 insertions(+), 217 deletions(-)
create mode 100644 drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
diff --git a/drivers/net/ethernet/broadcom/Makefile
b/drivers/net/ethernet/broadcom/Makefile
index 00584d7..f559794 100644
--- a/drivers/net/ethernet/broadcom/Makefile
+++ b/drivers/net/ethernet/broadcom/Makefile
@@ -10,6 +10,6 @@ obj-$(CONFIG_CNIC) += cnic.o
obj-$(CONFIG_BNX2X) += bnx2x/
obj-$(CONFIG_SB1250_MAC) += sb1250-mac.o
obj-$(CONFIG_TIGON3) += tg3.o
-obj-$(CONFIG_BGMAC) += bgmac.o
+obj-$(CONFIG_BGMAC) += bgmac.o bgmac-bcma-mdio.o
obj-$(CONFIG_SYSTEMPORT) += bcmsysport.o
obj-$(CONFIG_BNXT) += bnxt/
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
new file mode 100644
index 000..1e65349
--- /dev/null
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
@@ -0,0 +1,264 @@
+/*
+ * Driver for (BCM4706)? GBit MAC core on BCMA bus.
+ *
+ * Copyright (C) 2012 Rafał Miłecki
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include "bgmac.h"
+
+struct bcma_mdio {
+ struct bcma_device *core;
+ u8 phyaddr;
+};
+
+static bool bcma_mdio_wait_value(struct bcma_device *core, u16 reg, u32 mask,
+u32 value, int timeout)
+{
+ u32 val;
+ int i;
+
+ for (i = 0; i < timeout / 10; i++) {
+ val = bcma_read32(core, reg);
+ if ((val & mask) == value)
+ return true;
+ udelay(10);
+ }
+ dev_err(&core->dev, "Timeout waiting for reg 0x%X\n", reg);
+ return false;
+}
+
+/**
+ * PHY ops
+ **/
+
+static u16 bcma_mdio_phy_read(struct bcma_mdio *bcma_mdio, u8 phyaddr, u8 reg)
+{
+ struct bcma_device *core;
+ u16 phy_access_addr;
+ u16 phy_ctl_addr;
+ u32 tmp;
+
+ BUILD_BUG_ON(BGMAC_PA_DATA_MASK != BCMA_GMAC_CMN_PA_DATA_MASK);
+ BUILD_BUG_ON(BGMAC_PA_ADDR_MASK != BCMA_GMAC_CMN_PA_ADDR_MASK);
+ BUILD_BUG_ON(BGMAC_PA_ADDR_SHIFT != BCMA_GMAC_CMN_PA_ADDR_SHIFT);
+ BUILD_BUG_ON(BGMAC_PA_REG_MASK != BCMA_GMAC_CMN_PA_REG_MASK);
+ BUILD_BUG_ON(BGMAC_PA_REG_SHIFT != BCMA_GMAC_CMN_PA_REG_SHIFT);
+ BUILD_BUG_ON(BGMAC_PA_WRITE != BCMA_GMAC_CMN_PA_WRITE);
+ BUILD_BUG_ON(BGMAC_PA_START != BCMA_GMAC_CMN_PA_START);
+ BUILD_BUG_ON(BGMAC_PC_EPA_MASK != BCMA_GMAC_CMN_PC_EPA_MASK);
+ BUILD_BUG_ON(BGMAC_PC_MCT_MASK != BCMA_GMAC_CMN_PC_MCT_MASK);
+ BUILD_BUG_ON(BGMAC_PC_MCT_SHIFT != BCMA_GMAC_CMN_PC_MCT_SHIFT);
+ BUILD_BUG_ON(BGMAC_PC_MTE != BCMA_GMAC_CMN_PC_MTE);
+
+ if (bcma_mdio->core->id.id == BCMA_CORE_4706_MAC_GBIT) {
+ core = bcma_mdio->core->bus->drv_gmac_cmn.core;
+ phy_access_addr = BCMA_GMAC_CMN_PHY_ACCESS;
+ phy_ctl_addr = BCMA_GMAC_CMN_PHY_CTL;
+ } else {
+ core = bcma_mdio->core;
+ phy_access_addr = BGMAC_PHY_ACCESS;
+ phy_ctl_addr = BGMAC_PHY_CNTL;
+ }
+
+ tmp = bcma_read32(core, phy_ctl_addr);
+ tmp &= ~BGMAC_PC_EPA_MASK;
+ tmp |= phyaddr;
+ bcma_write32(core, phy_ctl_addr, tmp);
+
+ tmp = BGMAC_PA_START;
+ tmp |= phyaddr << BGMAC_PA_ADDR_SHIFT;
+ tmp |= reg << BGMAC_PA_REG_SHIFT;
+ bcma_write32(core, phy_access_addr, tmp);
+
+ if (!bcma_mdio_wait_value(core, phy_access_addr, BGMAC_PA_START, 0,
+ 1000)) {
+ dev_err(&core->dev, "Reading PHY %d register 0x%X failed\n",
+ phyaddr, reg);
+ return 0x;
+ }
+
+ return bcma_read32(core, phy_access_addr) & BGMAC_PA_DATA_MASK;
+}
+
+/* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipphywr */
+static int bcma_mdio_phy_write(struct bcma_mdio *bcma_mdio, u8 phyaddr, u8 reg,
+ u16 value)
+{
+ struct bcma_device *core;
+ u16 phy_access_addr;
+ u16 phy_ctl_addr;
+
[RFC 5/7] net: ethernet: bgmac: Add platform device support
The bcma portion of the driver has been split off into a bcma specific
driver. This has been mirrored for the platform driver. The last
references to the bcma core struct have been changed into a generic
function call. These function calls are wrappers to either the original
bcma code or new platform functions that access the same areas via MMIO.
This necessitated adding function pointers for both platform and bcma to
hide which backend is being used from the generic bgmac code.
Signed-off-by: Jon Mason
---
drivers/net/ethernet/broadcom/Kconfig | 23 +-
drivers/net/ethernet/broadcom/Makefile | 4 +-
drivers/net/ethernet/broadcom/bgmac-bcma.c | 315
drivers/net/ethernet/broadcom/bgmac-platform.c | 208
drivers/net/ethernet/broadcom/bgmac.c | 327 -
drivers/net/ethernet/broadcom/bgmac.h | 73 +-
6 files changed, 666 insertions(+), 284 deletions(-)
create mode 100644 drivers/net/ethernet/broadcom/bgmac-bcma.c
create mode 100644 drivers/net/ethernet/broadcom/bgmac-platform.c
diff --git a/drivers/net/ethernet/broadcom/Kconfig
b/drivers/net/ethernet/broadcom/Kconfig
index d74a92e..bd8c80c 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -140,10 +140,18 @@ config BNX2X_SRIOV
allows for virtual function acceleration in virtual environments.
config BGMAC
- tristate "BCMA bus GBit core support"
+ tristate
+ help
+ This enables the integrated ethernet controller support for many
+ Broadcom (mostly iProc) SoCs. An appropriate bus interface driver
+ needs to be enabled to select this.
+
+config BGMAC_BCMA
+ tristate "Broadcom iProc GBit BCMA support"
depends on BCMA && BCMA_HOST_SOC
depends on HAS_DMA
depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST
+ select BGMAC
select PHYLIB
select FIXED_PHY
---help---
@@ -152,6 +160,19 @@ config BGMAC
In case of using this driver on BCM4706 it's also requires to enable
BCMA_DRIVER_GMAC_CMN to make it work.
+config BGMAC_PLATFORM
+ tristate "Broadcom iProc GBit platform support"
+ depends on HAS_DMA
+ depends on ARCH_BCM_IPROC || COMPILE_TEST
+ depends on OF
+ select BGMAC
+ select PHYLIB
+ select FIXED_PHY
+ default ARCH_BCM_IPROC
+ ---help---
+ Say Y here if you want to use the Broadcom iProc Gigabit Ethernet
+ controller through the generic platform interface
+
config SYSTEMPORT
tristate "Broadcom SYSTEMPORT internal MAC support"
depends on OF
diff --git a/drivers/net/ethernet/broadcom/Makefile
b/drivers/net/ethernet/broadcom/Makefile
index f559794..79f2372 100644
--- a/drivers/net/ethernet/broadcom/Makefile
+++ b/drivers/net/ethernet/broadcom/Makefile
@@ -10,6 +10,8 @@ obj-$(CONFIG_CNIC) += cnic.o
obj-$(CONFIG_BNX2X) += bnx2x/
obj-$(CONFIG_SB1250_MAC) += sb1250-mac.o
obj-$(CONFIG_TIGON3) += tg3.o
-obj-$(CONFIG_BGMAC) += bgmac.o bgmac-bcma-mdio.o
+obj-$(CONFIG_BGMAC) += bgmac.o
+obj-$(CONFIG_BGMAC_BCMA) += bgmac-bcma.o bgmac-bcma-mdio.o
+obj-$(CONFIG_BGMAC_PLATFORM) += bgmac-platform.o
obj-$(CONFIG_SYSTEMPORT) += bcmsysport.o
obj-$(CONFIG_BNXT) += bnxt/
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c
b/drivers/net/ethernet/broadcom/bgmac-bcma.c
new file mode 100644
index 000..9a9745c4
--- /dev/null
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -0,0 +1,315 @@
+/*
+ * Driver for (BCM4706)? GBit MAC core on BCMA bus.
+ *
+ * Copyright (C) 2012 Rafał Miłecki
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include "bgmac.h"
+
+static inline bool bgmac_is_bcm4707_family(struct bcma_device *core)
+{
+ switch (core->bus->chipinfo.id) {
+ case BCMA_CHIP_ID_BCM4707:
+ case BCMA_CHIP_ID_BCM47094:
+ case BCMA_CHIP_ID_BCM53018:
+ return true;
+ default:
+ return false;
+ }
+}
+
+/**
+ * BCMA bus ops
+ **/
+
+static u32 bcma_bgmac_read(struct bgmac *bgmac, u16 offset)
+{
+ return bcma_read32(bgmac->bcma.core, offset);
+}
+
+static void bcma_bgmac_write(struct bgmac *bgmac, u16 offset, u32 value)
+{
+ bcma_write32(bgmac->bcma.core, offset, value);
+}
+
+static u32 bcma_bgmac_idm_read(struct bgmac *bgmac, u16 offset)
+{
+ return bcma_aread32(bgmac->bcma.core, offset);
+}
+
+static void bcma_bgmac_idm_write(struct bgmac *bgmac, u16 offset, u32 value)
+{
+ return bcma_awrite32(bgmac->bcma.core, offset, value);
+}
+
+static bool bcma_bgmac_clk_enabled(struct bgmac *bgmac)
+{
+ return bcma_core_is_enabled(bgmac->bcma.core);
+}
+
+static void bcma_bgmac_clk_enable(struct bgmac *bgmac,
[RFC 4/7] net: ethernet: bgmac: convert to feature flags
The bgmac driver is using the bcma provides device ID and revision, as
well as the SoC ID and package, to determine which features are
necessary to enable, reset, etc in the driver. In anticipation of
removing the bcma requirement for this driver, these must be changed to
not reference that struct. In place of that, each "feature" has been
given a flag, and the flags are enabled for their respective device and
SoC.
Signed-off-by: Jon Mason
---
drivers/net/ethernet/broadcom/bgmac.c | 167 --
drivers/net/ethernet/broadcom/bgmac.h | 21 -
2 files changed, 140 insertions(+), 48 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c
b/drivers/net/ethernet/broadcom/bgmac.c
index 88b9513..4346994 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -109,7 +109,7 @@ static void bgmac_dma_tx_enable(struct bgmac *bgmac,
u32 ctl;
ctl = bgmac_read(bgmac, ring->mmio_base + BGMAC_DMA_TX_CTL);
- if (bgmac->core->id.rev >= 4) {
+ if (bgmac->feature_flags & BGMAC_FEAT_TX_MASK_SETUP) {
ctl &= ~BGMAC_DMA_TX_BL_MASK;
ctl |= BGMAC_DMA_TX_BL_128 << BGMAC_DMA_TX_BL_SHIFT;
@@ -330,7 +330,7 @@ static void bgmac_dma_rx_enable(struct bgmac *bgmac,
u32 ctl;
ctl = bgmac_read(bgmac, ring->mmio_base + BGMAC_DMA_RX_CTL);
- if (bgmac->core->id.rev >= 4) {
+ if (bgmac->feature_flags & BGMAC_FEAT_RX_MASK_SETUP) {
ctl &= ~BGMAC_DMA_RX_BL_MASK;
ctl |= BGMAC_DMA_RX_BL_128 << BGMAC_DMA_RX_BL_SHIFT;
@@ -768,14 +768,20 @@ static void bgmac_cmdcfg_maskset(struct bgmac *bgmac, u32
mask, u32 set,
{
u32 cmdcfg = bgmac_read(bgmac, BGMAC_CMDCFG);
u32 new_val = (cmdcfg & mask) | set;
+ u32 cmdcfg_sr;
- bgmac_set(bgmac, BGMAC_CMDCFG, BGMAC_CMDCFG_SR(bgmac->core->id.rev));
+ if (bgmac->feature_flags & BGMAC_FEAT_CMDCFG_SR_REV4)
+ cmdcfg_sr = BGMAC_CMDCFG_SR_REV4;
+ else
+ cmdcfg_sr = BGMAC_CMDCFG_SR_REV0;
+
+ bgmac_set(bgmac, BGMAC_CMDCFG, cmdcfg_sr);
udelay(2);
if (new_val != cmdcfg || force)
bgmac_write(bgmac, BGMAC_CMDCFG, new_val);
- bgmac_mask(bgmac, BGMAC_CMDCFG, ~BGMAC_CMDCFG_SR(bgmac->core->id.rev));
+ bgmac_mask(bgmac, BGMAC_CMDCFG, ~cmdcfg_sr);
udelay(2);
}
@@ -804,7 +810,7 @@ static void bgmac_chip_stats_update(struct bgmac *bgmac)
{
int i;
- if (bgmac->core->id.id != BCMA_CORE_4706_MAC_GBIT) {
+ if (!(bgmac->feature_flags & BGMAC_FEAT_NO_CLR_MIB)) {
for (i = 0; i < BGMAC_NUM_MIB_TX_REGS; i++)
bgmac->mib_tx_regs[i] =
bgmac_read(bgmac,
@@ -823,7 +829,7 @@ static void bgmac_clear_mib(struct bgmac *bgmac)
{
int i;
- if (bgmac->core->id.id == BCMA_CORE_4706_MAC_GBIT)
+ if (bgmac->feature_flags & BGMAC_FEAT_NO_CLR_MIB)
return;
bgmac_set(bgmac, BGMAC_DEV_CTL, BGMAC_DC_MROR);
@@ -866,9 +872,8 @@ static void bgmac_mac_speed(struct bgmac *bgmac)
static void bgmac_miiconfig(struct bgmac *bgmac)
{
struct bcma_device *core = bgmac->core;
- u8 imode;
- if (bgmac_is_bcm4707_family(bgmac)) {
+ if (bgmac->feature_flags & BGMAC_FEAT_FORCE_SPEED_2500) {
bcma_awrite32(core, BCMA_IOCTL,
bcma_aread32(core, BCMA_IOCTL) | 0x40 |
BGMAC_BCMA_IOCTL_SW_CLKEN);
@@ -876,6 +881,8 @@ static void bgmac_miiconfig(struct bgmac *bgmac)
bgmac->mac_duplex = DUPLEX_FULL;
bgmac_mac_speed(bgmac);
} else {
+ u8 imode;
+
imode = (bgmac_read(bgmac, BGMAC_DEV_STATUS) &
BGMAC_DS_MM_MASK) >> BGMAC_DS_MM_SHIFT;
if (imode == 0 || imode == 1) {
@@ -890,9 +897,7 @@ static void bgmac_miiconfig(struct bgmac *bgmac)
static void bgmac_chip_reset(struct bgmac *bgmac)
{
struct bcma_device *core = bgmac->core;
- struct bcma_bus *bus = core->bus;
- struct bcma_chipinfo *ci = &bus->chipinfo;
- u32 flags;
+ u32 cmdcfg_sr;
u32 iost;
int i;
@@ -915,15 +920,12 @@ static void bgmac_chip_reset(struct bgmac *bgmac)
}
iost = bcma_aread32(core, BCMA_IOST);
- if ((ci->id == BCMA_CHIP_ID_BCM5357 && ci->pkg == BCMA_PKG_ID_BCM47186)
||
- (ci->id == BCMA_CHIP_ID_BCM4749 && ci->pkg == 10) ||
- (ci->id == BCMA_CHIP_ID_BCM53572 && ci->pkg ==
BCMA_PKG_ID_BCM47188))
+ if (bgmac->feature_flags & BGMAC_FEAT_IOST_ATTACHED)
iost &= ~BGMAC_BCMA_IOST_ATTACHED;
/* 3GMAC: for BCM4707 & BCM47094, only do core reset at bgmac_probe() */
- if (ci->id != BCMA_CHIP_ID_BCM4707 &&
- ci->id != BCMA_CHIP_ID_BCM47094) {
- flags = 0;
+ if (!(bgmac->feature_flags & BGM
[RFC 0/7] net: ethernet: bgmac: Add platform device support
I'm sending out this RFC to see if this is the direction the maintainers would like to go to add support for other, non-bcma iProc SoC's to the bgmac driver. Specifically, we are interested in adding support for the NSP, Cygnus, and NS2 families (with more possible down the road). To support non-bcma enabled SoCs, we need to add the standard device tree "platform device" support. Unfortunately, this driver is very tighly coupled with the bcma bus and much unwinding is needed. I tried to break this up into a number of patches to make it more obvious what was being done to add platform device support. I was able to verify that the bcma code still works using a 53012K board (NS SoC), and that the platform code works using a 58625K board (NSP SoC). It is worth noting that the phy logic present in the driver needs to be moved to drivers/phy. However, I was not able to fully decouple that code from the bgmac driver. I was able to move it into a separate C file, with only 2 function calls needed to create and destroy the mii bus. Someone with more knowledge of this and HW to test it needs to do it properly. This would natually dovetail into creating an interface which the NSP bgmac can use for the external MDIO Phy to properly connect (instead of using the fixed phy). Thanks, Jon Jon Mason (7): net: ethernet: bgmac: change bgmac_* prints to dev_* prints net: ethernet: bgmac: add dma_dev pointer net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file net: ethernet: bgmac: convert to feature flags net: ethernet: bgmac: Add platform device support dt-bindings: net: bgmac: add bindings documentation for bgmac ARM: dts: NSP: Add bgmac entries .../devicetree/bindings/net/brcm,bgmac-enet.txt| 21 + arch/arm/boot/dts/bcm-nsp.dtsi | 16 + arch/arm/boot/dts/bcm958625k.dts | 8 + drivers/net/ethernet/broadcom/Kconfig | 23 +- drivers/net/ethernet/broadcom/Makefile | 2 + drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c| 264 + drivers/net/ethernet/broadcom/bgmac-bcma.c | 315 ++ drivers/net/ethernet/broadcom/bgmac-platform.c | 208 +++ drivers/net/ethernet/broadcom/bgmac.c | 658 + drivers/net/ethernet/broadcom/bgmac.h | 112 +++- 10 files changed, insertions(+), 516 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt create mode 100644 drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c create mode 100644 drivers/net/ethernet/broadcom/bgmac-bcma.c create mode 100644 drivers/net/ethernet/broadcom/bgmac-platform.c -- 1.9.1
[RFC 7/7] ARM: dts: NSP: Add bgmac entries
Add device tree entries for the ethernet devices present on the
Broadcom Northstar Plus SoCs
Signed-off-by: Jon Mason
---
arch/arm/boot/dts/bcm-nsp.dtsi | 16
arch/arm/boot/dts/bcm958625k.dts | 8
2 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index def9e78..9b4e45e 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -192,6 +192,22 @@
status = "disabled";
};
+ gmac0: enet@22000 {
+ compatible = "brcm,bgmac-enet";
+ reg = <0x022000 0x1000>,
+ <0x11 0x1000>;
+ interrupts = ;
+ status = "disabled";
+ };
+
+ gmac1: enet@23000 {
+ compatible = "brcm,bgmac-enet";
+ reg = <0x023000 0x1000>,
+ <0x111000 0x1000>;
+ interrupts = ;
+ status = "disabled";
+ };
+
nand: nand@26000 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x026000 0x600>,
diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts
index e298450..d16ab53 100644
--- a/arch/arm/boot/dts/bcm958625k.dts
+++ b/arch/arm/boot/dts/bcm958625k.dts
@@ -56,6 +56,14 @@
status = "okay";
};
+&gmac0 {
+ status = "okay";
+};
+
+&gmac1 {
+ status = "okay";
+};
+
&pcie0 {
status = "okay";
};
--
1.9.1
[RFC 6/7] dt-bindings: net: bgmac: add bindings documentation for bgmac
Signed-off-by: Jon Mason
---
.../devicetree/bindings/net/brcm,bgmac-enet.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt
diff --git a/Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt
b/Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt
new file mode 100644
index 000..efd36d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,bgmac-enet.txt
@@ -0,0 +1,21 @@
+Broadcom GMAC Ethernet Controller Device Tree Bindings
+-
+
+Required properties:
+ - compatible: "brcm,bgmac-enet"
+ - reg:Address and length of the GMAC registers,
+ Address and length of the GMAC IDM registers
+ - interrupts: Interrupt number
+
+Optional properties:
+- mac-address: mac address to be assigned to the device
+
+Examples:
+
+gmac0: enet@18022000 {
+ compatible = "brcm,bgmac-enet";
+ reg = <0x18022000 0x1000>,
+ <0x1811 0x1000>;
+ interrupts = ;
+ status = "disabled";
+};
--
1.9.1
[RFC 2/7] net: ethernet: bgmac: add dma_dev pointer
The dma buffer allocation, etc references a dma_dev device pointer from
the bcma core. In anticipation of removing the bcma requirement for
this driver, these must be changed to not reference that struct. Add a
dma_dev device pointer to the bgmac stuct and reference that instead.
Signed-off-by: Jon Mason
---
drivers/net/ethernet/broadcom/bgmac.c | 17 +
drivers/net/ethernet/broadcom/bgmac.h | 1 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c
b/drivers/net/ethernet/broadcom/bgmac.c
index 2ab0887..b5c35bc 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -152,7 +152,7 @@ static netdev_tx_t bgmac_dma_tx_add(struct bgmac *bgmac,
struct bgmac_dma_ring *ring,
struct sk_buff *skb)
{
- struct device *dma_dev = bgmac->core->dma_dev;
+ struct device *dma_dev = bgmac->dma_dev;
struct net_device *net_dev = bgmac->net_dev;
int index = ring->end % BGMAC_TX_RING_SLOTS;
struct bgmac_slot_info *slot = &ring->slots[index];
@@ -254,7 +254,7 @@ err_drop:
/* Free transmitted packets */
static void bgmac_dma_tx_free(struct bgmac *bgmac, struct bgmac_dma_ring *ring)
{
- struct device *dma_dev = bgmac->core->dma_dev;
+ struct device *dma_dev = bgmac->dma_dev;
int empty_slot;
bool freed = false;
unsigned bytes_compl = 0, pkts_compl = 0;
@@ -351,7 +351,7 @@ static void bgmac_dma_rx_enable(struct bgmac *bgmac,
static int bgmac_dma_rx_skb_for_slot(struct bgmac *bgmac,
struct bgmac_slot_info *slot)
{
- struct device *dma_dev = bgmac->core->dma_dev;
+ struct device *dma_dev = bgmac->dma_dev;
dma_addr_t dma_addr;
struct bgmac_rx_header *rx;
void *buf;
@@ -440,7 +440,7 @@ static int bgmac_dma_rx_read(struct bgmac *bgmac, struct
bgmac_dma_ring *ring,
end_slot /= sizeof(struct bgmac_dma_desc);
while (ring->start != end_slot) {
- struct device *dma_dev = bgmac->core->dma_dev;
+ struct device *dma_dev = bgmac->dma_dev;
struct bgmac_slot_info *slot = &ring->slots[ring->start];
struct bgmac_rx_header *rx = slot->buf + BGMAC_RX_BUF_OFFSET;
struct sk_buff *skb;
@@ -543,7 +543,7 @@ static bool bgmac_dma_unaligned(struct bgmac *bgmac,
static void bgmac_dma_tx_ring_free(struct bgmac *bgmac,
struct bgmac_dma_ring *ring)
{
- struct device *dma_dev = bgmac->core->dma_dev;
+ struct device *dma_dev = bgmac->dma_dev;
struct bgmac_dma_desc *dma_desc = ring->cpu_base;
struct bgmac_slot_info *slot;
int i;
@@ -569,7 +569,7 @@ static void bgmac_dma_tx_ring_free(struct bgmac *bgmac,
static void bgmac_dma_rx_ring_free(struct bgmac *bgmac,
struct bgmac_dma_ring *ring)
{
- struct device *dma_dev = bgmac->core->dma_dev;
+ struct device *dma_dev = bgmac->dma_dev;
struct bgmac_slot_info *slot;
int i;
@@ -590,7 +590,7 @@ static void bgmac_dma_ring_desc_free(struct bgmac *bgmac,
struct bgmac_dma_ring *ring,
int num_slots)
{
- struct device *dma_dev = bgmac->core->dma_dev;
+ struct device *dma_dev = bgmac->dma_dev;
int size;
if (!ring->cpu_base)
@@ -628,7 +628,7 @@ static void bgmac_dma_free(struct bgmac *bgmac)
static int bgmac_dma_alloc(struct bgmac *bgmac)
{
- struct device *dma_dev = bgmac->core->dma_dev;
+ struct device *dma_dev = bgmac->dma_dev;
struct bgmac_dma_ring *ring;
static const u16 ring_base[] = { BGMAC_DMA_BASE0, BGMAC_DMA_BASE1,
BGMAC_DMA_BASE2, BGMAC_DMA_BASE3, };
@@ -1701,6 +1701,7 @@ static int bgmac_probe(struct bcma_device *core)
net_dev->ethtool_ops = &bgmac_ethtool_ops;
bgmac = netdev_priv(net_dev);
bgmac->dev = &core->dev;
+ bgmac->dma_dev = core->dma_dev;
bgmac->net_dev = net_dev;
bgmac->core = core;
bcma_set_drvdata(core, bgmac);
diff --git a/drivers/net/ethernet/broadcom/bgmac.h
b/drivers/net/ethernet/broadcom/bgmac.h
index abb9dd8..fd20018 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -429,6 +429,7 @@ struct bgmac {
struct bcma_device *cmn; /* Reference to CMN core for BCM4706 */
struct device *dev;
+ struct device *dma_dev;
struct net_device *net_dev;
struct napi_struct napi;
struct mii_bus *mii_bus;
--
1.9.1
Re: [PATCH net-next 08/16] net/devlink: Add E-Switch mode control
On 16-06-28 12:12 PM, Jiri Pirko wrote: > Tue, Jun 28, 2016 at 09:04:00PM CEST, sridhar.samudr...@intel.com wrote: >> >> >> On 6/28/2016 11:46 AM, Jiri Pirko wrote: >>> Tue, Jun 28, 2016 at 07:19:06PM CEST, john.fastab...@gmail.com wrote: On 16-06-28 09:19 AM, John Fastabend wrote: > On 16-06-28 03:25 AM, Or Gerlitz wrote: >> On 6/28/2016 8:57 AM, John Fastabend wrote: >>> On 16-06-27 09:07 AM, Saeed Mahameed wrote: Add the commands to set and show the mode of SRIOV E-Switch, two modes are supported: * legacy : operating in the "old" L2 based mode (DMAC --> VF vport) * offloads : offloading SW rules/policy (e.g Bridge/FDB or TC/Flows based) set by the host OS Nice work overall also I really appreciated that the core networking interfaces appear to able to support this without any change. >> thanks.. >> On this patch though do we really need modes like this? My concern with modes is two fold. One its another knob that some controller will have to get right which I would prefer to avoid. And two I suspect switching between the two modes flushes the tables or leaves them in some unexpected state? At least I can't figure out what the expected should be off-hand. >> Re the 1st concern (another knob), I think we do want that, see below >> >> Re the 2nd concern, I will re-read the cover letter and change logs and >> if needed clarify/improve: the transition is clean! When you are moving > >from legacy to offloads or the other way around, nothing is left in >> unexpected state, all HW forwarding tables as filled by the current >> mode are flushed and next they are set as needed for the new mode. >> > OK if I had read the entire patch series maybe I would have caught this > :) > Could we instead continue to use the "legacy" mode by default by just populating the fdb table correctly and then if users want to enable the "offloads" mode they can modify the fdb tables by deleting entries or adding them or just extending the dmac/vf mapping via 'tc'. This would seem natural to me. The flooding rules in fdb might need to be exposed a bit more cleanly to get the right default flooding behavior etc. But to me at least this would be much cleaner. Everything will be nicely defined and we wont have issues with drivers doing slightly and subtle different defaults between legacy/offload and the transitions between the states or on resets or etc. If users need to discover the current configuration then they just query fdb, query tc, and the state is known no need for any magic toggle switch as best I can see. >> >> Few comments here: >> >> Each mode has it's own way of the driver doing setup for the HW tables >> and how population of the HW tables is done. > hmm so in the hardware I have there is actually a l2 table and various > other tables so I don't have any issue with doing table setup. I would > like to see a table_create/table_delete/table_show devlink commands at > some point though but I'm not there yet. This would allow users to > optimize the table slices if they cared to. But that is future work > IMO. Certainly not needed in this series at least. If you want I can > show you a patch I had for this against rocker but it was before devlink > so it would need some porting. > >> The offloads mode needs to create a black hole miss rule and >> send-to-vport rules and create the tables so they can contain later >> rules set by the kernel in a way which is HW/driver dependent. > Agreed a black hole miss rule needs to be applied but rather than apply > it automatically with some toggle I would prefer to just add a 'tc' rule > for this. Or alternatively it can be added by configuring flooding > ports so that only a single port is in the flooding mode. This could > all be done via 'bridge fdb ...' and 'bridge link ...' today I believe. > Then the user defines the state and not the driver writer. It really is > cleaner in my opinion. > > One oddball case I have is if I have two PF functions behind a single > network facing port. Yes its a bit strange but in this case its nice to > pick which host facing PF to flood on vs the driver picking one. > > And send-to-vport rules I'm not entirely clear on what these actually > are used for. Is this a rule to match packets sent from a VF representer > netdev to the actual VF pcie device? If this is the case its seems to > me that any packet sent on a VF representer should be sent to the VF > directly and these rules can be created when the VF is created. Or did > you mean some other rule by this? > >> The legacy mode creat
Re: [PATCH net-next 08/16] net/devlink: Add E-Switch mode control
Tue, Jun 28, 2016 at 09:04:00PM CEST, sridhar.samudr...@intel.com wrote: > > >On 6/28/2016 11:46 AM, Jiri Pirko wrote: >>Tue, Jun 28, 2016 at 07:19:06PM CEST, john.fastab...@gmail.com wrote: >>>On 16-06-28 09:19 AM, John Fastabend wrote: On 16-06-28 03:25 AM, Or Gerlitz wrote: >On 6/28/2016 8:57 AM, John Fastabend wrote: >>On 16-06-27 09:07 AM, Saeed Mahameed wrote: >>>Add the commands to set and show the mode of SRIOV E-Switch, two >>>modes are supported: >>> >>>* legacy : operating in the "old" L2 based mode (DMAC --> VF vport) >>>* offloads : offloading SW rules/policy (e.g Bridge/FDB or TC/Flows >>>based) set by the host OS >>> >>>Nice work overall also I really appreciated that the core networking >>>interfaces appear to able to support this without any change. >thanks.. > >>>On this patch though do we really need modes like this? My concern with >>>modes is two fold. One its another knob that some controller will have >>>to get right which I would prefer to avoid. And two I suspect switching >>>between the two modes flushes the tables or leaves them in some >>>unexpected state? At least I can't figure out what the expected should >>>be off-hand. >Re the 1st concern (another knob), I think we do want that, see below > >Re the 2nd concern, I will re-read the cover letter and change logs and >if needed clarify/improve: the transition is clean! When you are moving >from legacy to offloads or the other way around, nothing is left in >unexpected state, all HW forwarding tables as filled by the current >mode are flushed and next they are set as needed for the new mode. > OK if I had read the entire patch series maybe I would have caught this :) >>>Could we instead continue to use the "legacy" mode by default by just >>>populating the fdb table correctly and then if users want to enable >>>the "offloads" mode they can modify the fdb tables by deleting entries >>>or adding them or just extending the dmac/vf mapping via 'tc'. This >>>would seem natural to me. The flooding rules in fdb might need to be >>>exposed a bit more cleanly to get the right default flooding behavior >>>etc. But to me at least this would be much cleaner. Everything will be >>>nicely defined and we wont have issues with drivers doing slightly >>>and subtle different defaults between legacy/offload and the transitions >>>between the states or on resets or etc. If users need to discover the >>>current configuration then they just query fdb, query tc, and the state >>>is known no need for any magic toggle switch as best I can see. > >Few comments here: > >Each mode has it's own way of the driver doing setup for the HW tables >and how population of the HW tables is done. hmm so in the hardware I have there is actually a l2 table and various other tables so I don't have any issue with doing table setup. I would like to see a table_create/table_delete/table_show devlink commands at some point though but I'm not there yet. This would allow users to optimize the table slices if they cared to. But that is future work IMO. Certainly not needed in this series at least. If you want I can show you a patch I had for this against rocker but it was before devlink so it would need some porting. >The offloads mode needs to create a black hole miss rule and >send-to-vport rules and create the tables so they can contain later >rules set by the kernel in a way which is HW/driver dependent. Agreed a black hole miss rule needs to be applied but rather than apply it automatically with some toggle I would prefer to just add a 'tc' rule for this. Or alternatively it can be added by configuring flooding ports so that only a single port is in the flooding mode. This could all be done via 'bridge fdb ...' and 'bridge link ...' today I believe. Then the user defines the state and not the driver writer. It really is cleaner in my opinion. One oddball case I have is if I have two PF functions behind a single network facing port. Yes its a bit strange but in this case its nice to pick which host facing PF to flood on vs the driver picking one. And send-to-vport rules I'm not entirely clear on what these actually are used for. Is this a rule to match packets sent from a VF representer netdev to the actual VF pcie device? If this is the case its seems to me that any packet sent on a VF representer should be sent to the VF directly and these rules can be created when the VF is created. Or did you mean some other rule by this? >The legacy mode creates the tables differently and populates them later >with rule set by >the driver and not the kernel. > >Even if we put the different table setup issue a side, I don't think it >would be co
Re: [PATCH net-next 08/16] net/devlink: Add E-Switch mode control
On 6/28/2016 11:46 AM, Jiri Pirko wrote: Tue, Jun 28, 2016 at 07:19:06PM CEST, john.fastab...@gmail.com wrote: On 16-06-28 09:19 AM, John Fastabend wrote: On 16-06-28 03:25 AM, Or Gerlitz wrote: On 6/28/2016 8:57 AM, John Fastabend wrote: On 16-06-27 09:07 AM, Saeed Mahameed wrote: Add the commands to set and show the mode of SRIOV E-Switch, two modes are supported: * legacy : operating in the "old" L2 based mode (DMAC --> VF vport) * offloads : offloading SW rules/policy (e.g Bridge/FDB or TC/Flows based) set by the host OS Nice work overall also I really appreciated that the core networking interfaces appear to able to support this without any change. thanks.. On this patch though do we really need modes like this? My concern with modes is two fold. One its another knob that some controller will have to get right which I would prefer to avoid. And two I suspect switching between the two modes flushes the tables or leaves them in some unexpected state? At least I can't figure out what the expected should be off-hand. Re the 1st concern (another knob), I think we do want that, see below Re the 2nd concern, I will re-read the cover letter and change logs and if needed clarify/improve: the transition is clean! When you are moving from legacy to offloads or the other way around, nothing is left in unexpected state, all HW forwarding tables as filled by the current mode are flushed and next they are set as needed for the new mode. OK if I had read the entire patch series maybe I would have caught this :) Could we instead continue to use the "legacy" mode by default by just populating the fdb table correctly and then if users want to enable the "offloads" mode they can modify the fdb tables by deleting entries or adding them or just extending the dmac/vf mapping via 'tc'. This would seem natural to me. The flooding rules in fdb might need to be exposed a bit more cleanly to get the right default flooding behavior etc. But to me at least this would be much cleaner. Everything will be nicely defined and we wont have issues with drivers doing slightly and subtle different defaults between legacy/offload and the transitions between the states or on resets or etc. If users need to discover the current configuration then they just query fdb, query tc, and the state is known no need for any magic toggle switch as best I can see. Few comments here: Each mode has it's own way of the driver doing setup for the HW tables and how population of the HW tables is done. hmm so in the hardware I have there is actually a l2 table and various other tables so I don't have any issue with doing table setup. I would like to see a table_create/table_delete/table_show devlink commands at some point though but I'm not there yet. This would allow users to optimize the table slices if they cared to. But that is future work IMO. Certainly not needed in this series at least. If you want I can show you a patch I had for this against rocker but it was before devlink so it would need some porting. The offloads mode needs to create a black hole miss rule and send-to-vport rules and create the tables so they can contain later rules set by the kernel in a way which is HW/driver dependent. Agreed a black hole miss rule needs to be applied but rather than apply it automatically with some toggle I would prefer to just add a 'tc' rule for this. Or alternatively it can be added by configuring flooding ports so that only a single port is in the flooding mode. This could all be done via 'bridge fdb ...' and 'bridge link ...' today I believe. Then the user defines the state and not the driver writer. It really is cleaner in my opinion. One oddball case I have is if I have two PF functions behind a single network facing port. Yes its a bit strange but in this case its nice to pick which host facing PF to flood on vs the driver picking one. And send-to-vport rules I'm not entirely clear on what these actually are used for. Is this a rule to match packets sent from a VF representer netdev to the actual VF pcie device? If this is the case its seems to me that any packet sent on a VF representer should be sent to the VF directly and these rules can be created when the VF is created. Or did you mean some other rule by this? The legacy mode creates the tables differently and populates them later with rule set by the driver and not the kernel. Even if we put the different table setup issue a side, I don't think it would be correct for bridge/tc to remove rules they didn't add, which is needed under your proposal when moving from legacy type rules to offloads mode. Querying is problematic too, since legacy could (and does) involve some default rules set by the FW, e.g that deals with outer world (== not belonging to VM on this host) MACs which are invisible to the driver. But even legacy mode should report the correct fdb table and setup. I don't think querying should be a problem if the driver reports the configuration correct
Re: [PATCH net-next 08/16] net/devlink: Add E-Switch mode control
Tue, Jun 28, 2016 at 07:19:06PM CEST, john.fastab...@gmail.com wrote: >On 16-06-28 09:19 AM, John Fastabend wrote: >> On 16-06-28 03:25 AM, Or Gerlitz wrote: >>> On 6/28/2016 8:57 AM, John Fastabend wrote: On 16-06-27 09:07 AM, Saeed Mahameed wrote: > Add the commands to set and show the mode of SRIOV E-Switch, two > modes are supported: > > * legacy : operating in the "old" L2 based mode (DMAC --> VF vport) > * offloads : offloading SW rules/policy (e.g Bridge/FDB or TC/Flows > based) set by the host OS > > Nice work overall also I really appreciated that the core networking > interfaces appear to able to support this without any change. >>> >>> thanks.. >>> > On this patch though do we really need modes like this? My concern with > modes is two fold. One its another knob that some controller will have > to get right which I would prefer to avoid. And two I suspect switching > between the two modes flushes the tables or leaves them in some > unexpected state? At least I can't figure out what the expected should > be off-hand. >>> >>> Re the 1st concern (another knob), I think we do want that, see below >>> >>> Re the 2nd concern, I will re-read the cover letter and change logs and >>> if needed clarify/improve: the transition is clean! When you are moving >>> from legacy to offloads or the other way around, nothing is left in >>> unexpected state, all HW forwarding tables as filled by the current >>> mode are flushed and next they are set as needed for the new mode. >>> >> >> OK if I had read the entire patch series maybe I would have caught this >> :) >> > Could we instead continue to use the "legacy" mode by default by just > populating the fdb table correctly and then if users want to enable > the "offloads" mode they can modify the fdb tables by deleting entries > or adding them or just extending the dmac/vf mapping via 'tc'. This > would seem natural to me. The flooding rules in fdb might need to be > exposed a bit more cleanly to get the right default flooding behavior > etc. But to me at least this would be much cleaner. Everything will be > nicely defined and we wont have issues with drivers doing slightly > and subtle different defaults between legacy/offload and the transitions > between the states or on resets or etc. If users need to discover the > current configuration then they just query fdb, query tc, and the state > is known no need for any magic toggle switch as best I can see. >>> >>> >>> Few comments here: >>> >>> Each mode has it's own way of the driver doing setup for the HW tables >>> and how population of the HW tables is done. >> >> hmm so in the hardware I have there is actually a l2 table and various >> other tables so I don't have any issue with doing table setup. I would >> like to see a table_create/table_delete/table_show devlink commands at >> some point though but I'm not there yet. This would allow users to >> optimize the table slices if they cared to. But that is future work >> IMO. Certainly not needed in this series at least. If you want I can >> show you a patch I had for this against rocker but it was before devlink >> so it would need some porting. >> >>> >>> The offloads mode needs to create a black hole miss rule and >>> send-to-vport rules and create the tables so they can contain later >>> rules set by the kernel in a way which is HW/driver dependent. >> >> Agreed a black hole miss rule needs to be applied but rather than apply >> it automatically with some toggle I would prefer to just add a 'tc' rule >> for this. Or alternatively it can be added by configuring flooding >> ports so that only a single port is in the flooding mode. This could >> all be done via 'bridge fdb ...' and 'bridge link ...' today I believe. >> Then the user defines the state and not the driver writer. It really is >> cleaner in my opinion. >> >> One oddball case I have is if I have two PF functions behind a single >> network facing port. Yes its a bit strange but in this case its nice to >> pick which host facing PF to flood on vs the driver picking one. >> >> And send-to-vport rules I'm not entirely clear on what these actually >> are used for. Is this a rule to match packets sent from a VF representer >> netdev to the actual VF pcie device? If this is the case its seems to >> me that any packet sent on a VF representer should be sent to the VF >> directly and these rules can be created when the VF is created. Or did >> you mean some other rule by this? >> >>> >>> The legacy mode creates the tables differently and populates them later >>> with rule set by >>> the driver and not the kernel. >>> >>> Even if we put the different table setup issue a side, I don't think it >>> would be correct for bridge/tc to remove rules they didn't add, which is >>> needed under your proposal when moving from legacy type rules to >>> offloads mode. Querying is problematic too, since
Re: [iproute PATCH v3 0/6] Big C99 style initializer rework
On Tue, Jun 28, 2016 at 11:59:04AM -0600, David Ahern wrote:
> On 6/28/16 11:58 AM, Phil Sutter wrote:
> >> since .ifr_qlen is already referenced in that function seems like your
> >> suggestion above (struct ifreq ifr = { .ifr_qlen = 0 };) should be
> >> acceptable.
> >
> > You mean regarding compatibility of using that define? Or are you
> > concerned with gcc creating suboptimal code?
>
> no, I was thinking in terms of open coding knowledge of a struct.
Still not sure if I understand you correctly. These are not typedefs, so
users are supposed to know the internals and removing a field means
potentially breaking every single user.
> > I'd rather use a more generic approach than the above. Retrospectively,
> > I'd rather have that brace orgy instead of the above since it's
> > intention is more clear and it can be dropped once either gcc guys
> > manage to backport their fix or the last distribution has updated it's
> > compiler.
>
> ha, that's funny.
At least someone can laugh about it. :)
Cheers, Phil
Re: [iproute PATCH v3 0/6] Big C99 style initializer rework
On 6/28/16 11:58 AM, Phil Sutter wrote:
since .ifr_qlen is already referenced in that function seems like your
suggestion above (struct ifreq ifr = { .ifr_qlen = 0 };) should be
acceptable.
You mean regarding compatibility of using that define? Or are you
concerned with gcc creating suboptimal code?
no, I was thinking in terms of open coding knowledge of a struct.
I'd rather use a more generic approach than the above. Retrospectively,
I'd rather have that brace orgy instead of the above since it's
intention is more clear and it can be dropped once either gcc guys
manage to backport their fix or the last distribution has updated it's
compiler.
ha, that's funny.
Re: [iproute PATCH v3 0/6] Big C99 style initializer rework
On Tue, Jun 28, 2016 at 11:37:43AM -0600, David Ahern wrote:
> On 6/28/16 11:37 AM, Phil Sutter wrote:
> >>> I saw these too with gcc-3.4.6 but not with 5.3.0. It appears to be a
> >>> gcc bug[1]. One possible workaround is to match the brace level of the
> >>> first field, but it's quite ugly: [2]. Another way might be to
> >>> initialize one of the fields to zero, like so:
> >>>
> >>> | struct ifreq ifr = { .ifr_qlen = 0 };
> >>>
> >>> What do you think?
> >>>
> >>> Thanks, Phil
> >>>
> >>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
> >>> [2]
> >>> http://nwl.cc/cgi-bin/git/gitweb.cgi?p=iproute2.git;a=commitdiff;h=a1cbf2b63c995b2f633c5b4699248ab308b201d2;hp=3809cfec65b03716d1d0360338126df4b4f3fbf6
> >>
> >> I am using gcc on Debian stable which is 5.3.1.
> >
> > Hmm. In a fresh install of Debian 8.5 I see the warnings as well, but it
> > has gcc-4.9.2-10 as most recent version.
> >
> > Another thing I noticed: Using empty braces ('{}') instead of the
> > universal zero initializer seems to work without causing warnings (at
> > least unless '-pedantic' is used).
>
> since .ifr_qlen is already referenced in that function seems like your
> suggestion above (struct ifreq ifr = { .ifr_qlen = 0 };) should be
> acceptable.
You mean regarding compatibility of using that define? Or are you
concerned with gcc creating suboptimal code?
I'd rather use a more generic approach than the above. Retrospectively,
I'd rather have that brace orgy instead of the above since it's
intention is more clear and it can be dropped once either gcc guys
manage to backport their fix or the last distribution has updated it's
compiler.
Cheers, Phil
Re: [PATCH v2 iproute2 3/3] ss: Add support to filter on device
On 6/27/16 3:13 PM, Stephen Hemminger wrote:
On Mon, 27 Jun 2016 11:34:25 -0700
David Ahern wrote:
+ case SSF_DEVCOND:
+ {
+ struct aafilter *a = (void *)f->pred;
I don't like the wandering bracket left, but all the code has that.
After this will change it to:
case SSF_DEVCOND: {
struct aafilter *a = f->pred;
...
meaning you'll take the patches as is since they follow current
formatting and you will apply a patch to fix the indentation in that
run_ssfilter? They have not shown up in your repo so want to make sure I
understand the intent.
Re: [iproute PATCH v3 0/6] Big C99 style initializer rework
On 6/28/16 11:37 AM, Phil Sutter wrote:
I saw these too with gcc-3.4.6 but not with 5.3.0. It appears to be a
gcc bug[1]. One possible workaround is to match the brace level of the
first field, but it's quite ugly: [2]. Another way might be to
initialize one of the fields to zero, like so:
| struct ifreq ifr = { .ifr_qlen = 0 };
What do you think?
Thanks, Phil
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
[2]
http://nwl.cc/cgi-bin/git/gitweb.cgi?p=iproute2.git;a=commitdiff;h=a1cbf2b63c995b2f633c5b4699248ab308b201d2;hp=3809cfec65b03716d1d0360338126df4b4f3fbf6
I am using gcc on Debian stable which is 5.3.1.
Hmm. In a fresh install of Debian 8.5 I see the warnings as well, but it
has gcc-4.9.2-10 as most recent version.
Another thing I noticed: Using empty braces ('{}') instead of the
universal zero initializer seems to work without causing warnings (at
least unless '-pedantic' is used).
since .ifr_qlen is already referenced in that function seems like your
suggestion above (struct ifreq ifr = { .ifr_qlen = 0 };) should be
acceptable.
Re: [PATCH v2 net-next] tcp: md5: use kmalloc() backed scratch areas
On Mon, Jun 27, 2016 at 8:41 PM, Herbert Xu wrote:
> On Mon, Jun 27, 2016 at 10:58:42AM -0700, Andy Lutomirski wrote:
>>
>> I wonder if it's worth switching from ahash to shash, though. It
>> would probably be simpler and faster.
>
> No shash is not appropriate here because it needs to hash skb
> frags which are SG lists.
>
Do you mean this code:
for (i = 0; i < shi->nr_frags; ++i) {
const struct skb_frag_struct *f = &shi->frags[i];
unsigned int offset = f->page_offset;
struct page *page = skb_frag_page(f) + (offset >> PAGE_SHIFT);
sg_set_page(&sg, page, skb_frag_size(f),
offset_in_page(offset));
ahash_request_set_crypt(req, &sg, NULL, skb_frag_size(f));
if (crypto_ahash_update(req))
return 1;
}
I'm wondering why support for scatterlists is all-or-nothing. Why
can't we initialize a hash object and then alternate between passing
it scatterlists and pointers?
I'm guessing that ahash enables async operation and shash is
synchronous only. If I'm right, I understand why ahash requires a
scatterlist. What I don't understand is why shash can't also accept a
scatterlist. It appears that most of the ahash users in the tree
actually want synchronous crypto and are presumably using ahash for
some other reason such as ahash's ability to hash via scatterlist (in
this case, struct page *).
--Andy
Re: [PATCH v2] notifier: Fix soft lockup for notifier_call_chain().
On Mon, Jun 27, 2016 at 11:22 PM, Eric Dumazet wrote: > Lot of this code was written decade ago where nobody expected a root > user was going to try hard to crash its host ;) +1 Adding cond_resched() to appropriate network notifiers sounds better.
Re: [iproute PATCH v3 0/6] Big C99 style initializer rework
On Mon, Jun 27, 2016 at 02:10:49PM -0700, Stephen Hemminger wrote:
> On Mon, 27 Jun 2016 20:23:02 +0200
> Phil Sutter wrote:
>
> > Hi,
> >
> > On Mon, Jun 27, 2016 at 10:59:12AM -0700, Stephen Hemminger wrote:
> > > On Thu, 23 Jun 2016 17:34:08 +
> > > Phil Sutter wrote:
> > >
> > > > This is v3 of my C99-style initializer related patch series. The changes
> > > > since v2 are:
> > [...]
> > >
> > > I like the idea and it makes code cleaner. But doing this introduces lots
> > > of warnings
> > > and that is not acceptable.
> > > ip
> > > CC ip.o
> > > CC ipaddress.o
> > > ipaddress.c: In function ‘print_queuelen’:
> > > ipaddress.c:175:10: warning: missing braces around initializer
> > > [-Wmissing-braces]
> > >struct ifreq ifr = { 0 };
> > > ^
> >
> > I saw these too with gcc-3.4.6 but not with 5.3.0. It appears to be a
> > gcc bug[1]. One possible workaround is to match the brace level of the
> > first field, but it's quite ugly: [2]. Another way might be to
> > initialize one of the fields to zero, like so:
> >
> > | struct ifreq ifr = { .ifr_qlen = 0 };
> >
> > What do you think?
> >
> > Thanks, Phil
> >
> > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
> > [2]
> > http://nwl.cc/cgi-bin/git/gitweb.cgi?p=iproute2.git;a=commitdiff;h=a1cbf2b63c995b2f633c5b4699248ab308b201d2;hp=3809cfec65b03716d1d0360338126df4b4f3fbf6
>
> I am using gcc on Debian stable which is 5.3.1.
Hmm. In a fresh install of Debian 8.5 I see the warnings as well, but it
has gcc-4.9.2-10 as most recent version.
Another thing I noticed: Using empty braces ('{}') instead of the
universal zero initializer seems to work without causing warnings (at
least unless '-pedantic' is used).
Cheers, Phil
Re: Deleting child qdisc doesn't reset parent to default qdisc?
On Tue, 28 Jun 2016, Cong Wang wrote: > > BTW, I've started to actually work on fixing this, and I've noticed that > > TBF behavior actually violates what's stated in pfifo_fast manpage: > > > > == > > Whenever an interface is created, the pfifo_fast qdisc is > > automatically used as a queue. If another qdisc is > > attached, it preempts the default pfifo_fast, which automatically > > returns to function when an existing qdisc is detached. > > > > In this sense this qdisc is magic, and unlike other qdiscs. > > == > > It is out of date, now default qdisc can be set to any other qdisc > via /proc. Also, probably due to historical reasons, we don't have > a unified default default qdisc, some uses bfifo, some uses pfifo, > we may break some existing script if we change that. While I do understand that reasoning, I'd argue that unpredictable and unexpected behavior of TBF causing systems with non-working networking is much more likely than any userspace having hard dependency on the fact that default (*) qdisc for TBF is noop. (*) where 'default upon creation' != 'default when reset' Thanks, -- Jiri Kosina SUSE Labs
Re: Deleting child qdisc doesn't reset parent to default qdisc?
On Tue, Jun 28, 2016 at 8:19 AM, Jiri Kosina wrote: > BTW, I've started to actually work on fixing this, and I've noticed that > TBF behavior actually violates what's stated in pfifo_fast manpage: > > == > Whenever an interface is created, the pfifo_fast qdisc is > automatically used as a queue. If another qdisc is > attached, it preempts the default pfifo_fast, which automatically > returns to function when an existing qdisc is detached. > > In this sense this qdisc is magic, and unlike other qdiscs. > == It is out of date, now default qdisc can be set to any other qdisc via /proc. Also, probably due to historical reasons, we don't have a unified default default qdisc, some uses bfifo, some uses pfifo, we may break some existing script if we change that.
Re: [PATCH net-next 08/16] net/devlink: Add E-Switch mode control
On 16-06-28 09:19 AM, John Fastabend wrote: > On 16-06-28 03:25 AM, Or Gerlitz wrote: >> On 6/28/2016 8:57 AM, John Fastabend wrote: >>> On 16-06-27 09:07 AM, Saeed Mahameed wrote: Add the commands to set and show the mode of SRIOV E-Switch, two modes are supported: * legacy : operating in the "old" L2 based mode (DMAC --> VF vport) * offloads : offloading SW rules/policy (e.g Bridge/FDB or TC/Flows based) set by the host OS Nice work overall also I really appreciated that the core networking interfaces appear to able to support this without any change. >> >> thanks.. >> On this patch though do we really need modes like this? My concern with modes is two fold. One its another knob that some controller will have to get right which I would prefer to avoid. And two I suspect switching between the two modes flushes the tables or leaves them in some unexpected state? At least I can't figure out what the expected should be off-hand. >> >> Re the 1st concern (another knob), I think we do want that, see below >> >> Re the 2nd concern, I will re-read the cover letter and change logs and >> if needed clarify/improve: the transition is clean! When you are moving >> from legacy to offloads or the other way around, nothing is left in >> unexpected state, all HW forwarding tables as filled by the current >> mode are flushed and next they are set as needed for the new mode. >> > > OK if I had read the entire patch series maybe I would have caught this > :) > Could we instead continue to use the "legacy" mode by default by just populating the fdb table correctly and then if users want to enable the "offloads" mode they can modify the fdb tables by deleting entries or adding them or just extending the dmac/vf mapping via 'tc'. This would seem natural to me. The flooding rules in fdb might need to be exposed a bit more cleanly to get the right default flooding behavior etc. But to me at least this would be much cleaner. Everything will be nicely defined and we wont have issues with drivers doing slightly and subtle different defaults between legacy/offload and the transitions between the states or on resets or etc. If users need to discover the current configuration then they just query fdb, query tc, and the state is known no need for any magic toggle switch as best I can see. >> >> >> Few comments here: >> >> Each mode has it's own way of the driver doing setup for the HW tables >> and how population of the HW tables is done. > > hmm so in the hardware I have there is actually a l2 table and various > other tables so I don't have any issue with doing table setup. I would > like to see a table_create/table_delete/table_show devlink commands at > some point though but I'm not there yet. This would allow users to > optimize the table slices if they cared to. But that is future work > IMO. Certainly not needed in this series at least. If you want I can > show you a patch I had for this against rocker but it was before devlink > so it would need some porting. > >> >> The offloads mode needs to create a black hole miss rule and >> send-to-vport rules and create the tables so they can contain later >> rules set by the kernel in a way which is HW/driver dependent. > > Agreed a black hole miss rule needs to be applied but rather than apply > it automatically with some toggle I would prefer to just add a 'tc' rule > for this. Or alternatively it can be added by configuring flooding > ports so that only a single port is in the flooding mode. This could > all be done via 'bridge fdb ...' and 'bridge link ...' today I believe. > Then the user defines the state and not the driver writer. It really is > cleaner in my opinion. > > One oddball case I have is if I have two PF functions behind a single > network facing port. Yes its a bit strange but in this case its nice to > pick which host facing PF to flood on vs the driver picking one. > > And send-to-vport rules I'm not entirely clear on what these actually > are used for. Is this a rule to match packets sent from a VF representer > netdev to the actual VF pcie device? If this is the case its seems to > me that any packet sent on a VF representer should be sent to the VF > directly and these rules can be created when the VF is created. Or did > you mean some other rule by this? > >> >> The legacy mode creates the tables differently and populates them later >> with rule set by >> the driver and not the kernel. >> >> Even if we put the different table setup issue a side, I don't think it >> would be correct for bridge/tc to remove rules they didn't add, which is >> needed under your proposal when moving from legacy type rules to >> offloads mode. Querying is problematic too, since legacy could (and >> does) involve some default rules set by the FW, e.g that deals with >> outer world (== not belonging to VM on this host) MACs which are >> invis
[iproute PATCH v4] Use ARRAY_SIZE macro everywhere
This patch was generated by the following semantic patch (a trimmed down
version of what is shipped with Linux sources):
@@
type T;
T[] E;
@@
(
- (sizeof(E)/sizeof(*E))
+ ARRAY_SIZE(E)
|
- (sizeof(E)/sizeof(E[...]))
+ ARRAY_SIZE(E)
|
- (sizeof(E)/sizeof(T))
+ ARRAY_SIZE(E)
)
The only manual adjustment was to include utils.h in misc/nstat.c to make
the macro known there.
Signed-off-by: Phil Sutter
---
Changes since v3:
- Rebased again.
- added missing include in misc/nstat.c.
Changes since v2:
- Patch recreated from scratch.
Changes since v1:
- Rebased onto current master to avoid merge conflicts.
Signed-off-by: Phil Sutter
---
bridge/link.c | 2 +-
misc/nstat.c | 3 ++-
misc/ss.c | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/bridge/link.c b/bridge/link.c
index 353e1c3da45db..b347040ccf91d 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -319,7 +319,7 @@ static int brlink_modify(int argc, char **argv)
} else if (strcmp(*argv, "state") == 0) {
NEXT_ARG();
char *endptr;
- size_t nstates = sizeof(port_states) /
sizeof(*port_states);
+ size_t nstates = ARRAY_SIZE(port_states);
state = strtol(*argv, &endptr, 10);
if (!(**argv != '\0' && *endptr == '\0')) {
diff --git a/misc/nstat.c b/misc/nstat.c
index a9e0f20789e3c..e579ce1d31586 100644
--- a/misc/nstat.c
+++ b/misc/nstat.c
@@ -30,6 +30,7 @@
#include
#include
+#include "utils.h"
int dump_zeros;
int reset_history;
@@ -95,7 +96,7 @@ static int useless_number(const char *id)
{
int i;
- for (i = 0; i < sizeof(useless_numbers)/sizeof(*useless_numbers); i++)
+ for (i = 0; i < ARRAY_SIZE(useless_numbers); i++)
if (strcmp(id, useless_numbers[i]) == 0)
return 1;
return 0;
diff --git a/misc/ss.c b/misc/ss.c
index 02be7e7407dfb..2ed9d67660b4d 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -666,7 +666,7 @@ static int get_slabstat(struct slabstat *s)
while (fgets(buf, sizeof(buf), fp) != NULL) {
int i;
- for (i = 0; i < sizeof(slabstat_ids)/sizeof(slabstat_ids[0]);
i++) {
+ for (i = 0; i < ARRAY_SIZE(slabstat_ids); i++) {
if (memcmp(buf, slabstat_ids[i],
strlen(slabstat_ids[i])) == 0) {
sscanf(buf, "%*s%d", ((int *)s) + i);
cnt--;
--
2.8.2
Re: [PATCH] libertas_tf: Remove create_workqueue
Bhaktipriya Shridhar writes: > Ping! I'm lagging behind, the patch is still on my queue: https://patchwork.kernel.org/patch/9162447/ Please don't top most, it's annoying. -- Kalle Valo
Re: [PATCH] libertas_tf: Remove create_workqueue
Ping! Thanks, Bhaktipriya On Sun, Jun 12, 2016 at 4:17 AM, Tejun Heo wrote: > On Wed, Jun 08, 2016 at 01:38:53AM +0530, Bhaktipriya Shridhar wrote: >> alloc_workqueue replaces deprecated create_workqueue(). >> >> A dedicated workqueue has been used since the workitem (viz >> &priv->cmd_work per priv, which maps to lbtf_cmd_work) is involved in >> actual command processing and may be used on a memory reclaim path. >> The workitems require forward progress under memory pressure and hence, >> WQ_MEM_RECLAIM has been set. Since there are only a fixed number of work >> items, explicit concurrency limit is unnecessary here. >> >> Signed-off-by: Bhaktipriya Shridhar > > Acked-by: Tejun Heo > > Thanks. > > -- > tejun
Re: [Patch net] mlx4: set csum_complete_sw bit when fixing complete csum
On Tue, Jun 28, 2016 at 7:30 AM, Or Gerlitz wrote: > Wow, can you please report us the exact card type (lspci -nn | grep -i > mellanox) and firmware version (ethtool -i $DEV) See below. Does commit f8c6455bb04b944edb69e rely on any firmware change to get an expected checksum? $ lspci -nn | grep -i mellanox 82:00.0 Ethernet controller [0200]: Mellanox Technologies MT27500 Family [ConnectX-3] [15b3:1003] $ ethtool -i eth0 driver: mlx4_en version: 2.2-1 (Feb 2014) firmware-version: 2.33.5220 bus-info: :82:00.0
[RFC PATCH] sch_tbf: avoid silent fallback to noop_qdisc (was Re: Deleting child qdisc doesn't reset parent to default qdisc?)
On Fri, 15 Apr 2016, Eric Dumazet wrote:
> Then you need to save the initial qdisc (bfifo for TBF) in a special
> place, to make sure the delete operation is guaranteed to succeed.
>
> Or fail the delete if the bfifo can not be allocated.
>
> I can tell that determinism if far more interesting than usability for
> some users occasionally playing with tc.
>
> Surely the silent fallback to noop_qdisc is wrong.
So before we go further and fix the fact that we actually do have hidden
qdiscs (by refactoring qdisc_match_from_root() and friends), I'd still
like to bring the patch below up for consideration.
Thanks.
From: Jiri Kosina
Subject: [PATCH] sch_tbf: avoid silent fallback to noop_qdisc
TBF started its life as a classless qdisc with a single builtin FIFO queue
which was being shaped.
When it got later turned into classful qdisc, it was written in a way that
the fallback qdisc was noop_qdisc, which produces bad user experience (delete
of last manually added class doesn't reset it to initial default, but renders
networking unusable instead).
Switch the default fallback to bfifo; this also mimics how the other guys
(HTB, HFSC, CBQ, ...) are behaving.
Signed-off-by: Jiri Kosina
---
net/sched/sch_tbf.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
index 3161e49..b06dffe 100644
--- a/net/sched/sch_tbf.c
+++ b/net/sched/sch_tbf.c
@@ -508,8 +508,12 @@ static int tbf_graft(struct Qdisc *sch, unsigned long arg,
struct Qdisc *new,
{
struct tbf_sched_data *q = qdisc_priv(sch);
- if (new == NULL)
- new = &noop_qdisc;
+ if (new == NULL) {
+ /* reset to default qdisc */
+ new = qdisc_create_dflt(sch->dev_queue, &bfifo_qdisc_ops,
sch->parent);
+ if (!new)
+ return -ENOBUFS;
+ }
*old = qdisc_replace(sch, new, &q->qdisc);
return 0;
--
Jiri Kosina
SUSE Labs
Re: [PATCH net-next 08/16] net/devlink: Add E-Switch mode control
On 16-06-28 03:25 AM, Or Gerlitz wrote: > On 6/28/2016 8:57 AM, John Fastabend wrote: >> On 16-06-27 09:07 AM, Saeed Mahameed wrote: >>> Add the commands to set and show the mode of SRIOV E-Switch, two >>> modes are supported: >>> >>> * legacy : operating in the "old" L2 based mode (DMAC --> VF vport) >>> * offloads : offloading SW rules/policy (e.g Bridge/FDB or TC/Flows >>> based) set by the host OS >>> >>> Nice work overall also I really appreciated that the core networking >>> interfaces appear to able to support this without any change. > > thanks.. > >>> On this patch though do we really need modes like this? My concern with >>> modes is two fold. One its another knob that some controller will have >>> to get right which I would prefer to avoid. And two I suspect switching >>> between the two modes flushes the tables or leaves them in some >>> unexpected state? At least I can't figure out what the expected should >>> be off-hand. > > Re the 1st concern (another knob), I think we do want that, see below > > Re the 2nd concern, I will re-read the cover letter and change logs and > if needed clarify/improve: the transition is clean! When you are moving > from legacy to offloads or the other way around, nothing is left in > unexpected state, all HW forwarding tables as filled by the current > mode are flushed and next they are set as needed for the new mode. > OK if I had read the entire patch series maybe I would have caught this :) >>> Could we instead continue to use the "legacy" mode by default by just >>> populating the fdb table correctly and then if users want to enable >>> the "offloads" mode they can modify the fdb tables by deleting entries >>> or adding them or just extending the dmac/vf mapping via 'tc'. This >>> would seem natural to me. The flooding rules in fdb might need to be >>> exposed a bit more cleanly to get the right default flooding behavior >>> etc. But to me at least this would be much cleaner. Everything will be >>> nicely defined and we wont have issues with drivers doing slightly >>> and subtle different defaults between legacy/offload and the transitions >>> between the states or on resets or etc. If users need to discover the >>> current configuration then they just query fdb, query tc, and the state >>> is known no need for any magic toggle switch as best I can see. > > > Few comments here: > > Each mode has it's own way of the driver doing setup for the HW tables > and how population of the HW tables is done. hmm so in the hardware I have there is actually a l2 table and various other tables so I don't have any issue with doing table setup. I would like to see a table_create/table_delete/table_show devlink commands at some point though but I'm not there yet. This would allow users to optimize the table slices if they cared to. But that is future work IMO. Certainly not needed in this series at least. If you want I can show you a patch I had for this against rocker but it was before devlink so it would need some porting. > > The offloads mode needs to create a black hole miss rule and > send-to-vport rules and create the tables so they can contain later > rules set by the kernel in a way which is HW/driver dependent. Agreed a black hole miss rule needs to be applied but rather than apply it automatically with some toggle I would prefer to just add a 'tc' rule for this. Or alternatively it can be added by configuring flooding ports so that only a single port is in the flooding mode. This could all be done via 'bridge fdb ...' and 'bridge link ...' today I believe. Then the user defines the state and not the driver writer. It really is cleaner in my opinion. One oddball case I have is if I have two PF functions behind a single network facing port. Yes its a bit strange but in this case its nice to pick which host facing PF to flood on vs the driver picking one. And send-to-vport rules I'm not entirely clear on what these actually are used for. Is this a rule to match packets sent from a VF representer netdev to the actual VF pcie device? If this is the case its seems to me that any packet sent on a VF representer should be sent to the VF directly and these rules can be created when the VF is created. Or did you mean some other rule by this? > > The legacy mode creates the tables differently and populates them later > with rule set by > the driver and not the kernel. > > Even if we put the different table setup issue a side, I don't think it > would be correct for bridge/tc to remove rules they didn't add, which is > needed under your proposal when moving from legacy type rules to > offloads mode. Querying is problematic too, since legacy could (and > does) involve some default rules set by the FW, e.g that deals with > outer world (== not belonging to VM on this host) MACs which are > invisible to the driver. But even legacy mode should report the correct fdb table and setup. I don't think querying should be a problem if the driver reports the configur
Re: [PATCH 2/3] can: fix oops caused by wrong rtnl dellink usage
On 06/28/2016 09:36 AM, Holger Schurig wrote:
static void can_dellink(struct net_device *dev, struct list_head *head);
and
static void can_dellink(struct net_device *dev, struct list_head *head)
{
return;
}
Wouldn't the canonical form be this:
static void can_dellink(struct net_device *dev, struct list_head *head)
{
}
- the curly braces make sure this isn't a forward definition
- but no useless return either
But then again, this "return" is only cosmetical.
Yes it is just coding style.
> No compiler will
generate any code from it.
ACK.
If you check
~/linux$ git grep \{\ return\;
there are many occurrences of empty void functions having a 'return'
inside the curly braces.
I think
static void can_dellink( ... ){}
would have made it too.
Now can_dellink() just locks similar to can_newlink() some lines above.
Regards,
Oliver
Re: [PATCH v12 net-next 1/1] hv_sock: introduce Hyper-V Sockets
On 06/28/2016 02:59 AM, Dexuan Cui wrote: The idea here is: IMO the syscalls sys_read()/write() shoudn't return -ENOMEM, so I have to make sure the buffer allocation succeeds? I tried to use kmalloc with __GFP_NOFAIL, but I hit a warning in in mm/page_alloc.c: WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); What error code do you think I should return? EAGAIN, ERESTARTSYS, or something else? May I have your suggestion? Thanks! What happens as far as errno is concerned when an application makes a read() call against a (say TCP) socket associated with a connection which has been reset? Is it limited to those errno values listed in the read() manpage, or does it end-up getting an errno value from those listed in the recv() manpage? Or, perhaps even one not (presently) listed in either? rick jones
RE: [PATCH v12 net-next 1/1] hv_sock: introduce Hyper-V Sockets
> From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, June 28, 2016 21:45 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; netdev@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com; vkuzn...@redhat.com; > cav...@redhat.com; KY Srinivasan ; Haiyang Zhang > ; j...@perches.com > Subject: Re: [PATCH v12 net-next 1/1] hv_sock: introduce Hyper-V Sockets > > From: Dexuan Cui > Date: Tue, 28 Jun 2016 09:59:21 + > > > The idea here is: IMO the syscalls sys_read()/write() shoudn't return > > -ENOMEM, so I have to make sure the buffer allocation succeeds? > > You have to fail if resources cannot be allocated. OK, I'll try to fix this, probably by returning -EAGAIN or -ERESTARTSYS. I'll report back ASAP. Thanks, -- Dexuan
[PATCH net v2] openvswitch: fix conntrack netlink event delivery
Only the first and last netlink message for a particular conntrack are
actually sent. The first message is sent through nf_conntrack_confirm when
the conntrack is committed. The last one is sent when the conntrack is
destroyed on timeout. The other conntrack state change messages are not
advertised.
When the conntrack subsystem is used from netfilter, nf_conntrack_confirm
is called for each packet, from the postrouting hook, which in turn calls
nf_ct_deliver_cached_events to send the state change netlink messages.
This commit fixes the problem by calling nf_ct_deliver_cached_events in the
non-commit case as well.
Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
CC: Joe Stringer
CC: Justin Pettit
CC: Andy Zhou
CC: Thomas Graf
Signed-off-by: Samuel Gauthier
---
v1 -> v2: don't break OVS_CT_ATTR_COMMIT attribute
This patch was tested against the net tree, checking the notifications with
conntrack -E.
net/openvswitch/conntrack.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 3d5feede962d..d84312584ee4 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -818,8 +818,18 @@ static int ovs_ct_lookup(struct net *net, struct
sw_flow_key *key,
*/
state = OVS_CS_F_TRACKED | OVS_CS_F_NEW | OVS_CS_F_RELATED;
__ovs_ct_update_key(key, state, &info->zone, exp->master);
- } else
- return __ovs_ct_lookup(net, key, info, skb);
+ } else {
+ struct nf_conn *ct;
+ int err;
+
+ err = __ovs_ct_lookup(net, key, info, skb);
+ if (err)
+ return err;
+
+ ct = (struct nf_conn *)skb->nfct;
+ if (ct)
+ nf_ct_deliver_cached_events(ct);
+ }
return 0;
}
--
2.2.1.62.g3f15098
Re: Deleting child qdisc doesn't reset parent to default qdisc?
On Fri, 15 Apr 2016, Eric Dumazet wrote: > > TBF is probably a bad example because it started life as a classless > > qdisc. There was only one built-in fifo queue that was shaped. Then > > someone made it classful and changed this behavior. To me it sounds > > reasonable to have the default behavior restored. At minimal > > consistency. > > > Then you need to save the initial qdisc (bfifo for TBF) in a special > place, to make sure the delete operation is guaranteed to succeed. > > Or fail the delete if the bfifo can not be allocated. > > I can tell that determinism if far more interesting than usability for > some users occasionally playing with tc. BTW, I've started to actually work on fixing this, and I've noticed that TBF behavior actually violates what's stated in pfifo_fast manpage: == Whenever an interface is created, the pfifo_fast qdisc is automatically used as a queue. If another qdisc is attached, it preempts the default pfifo_fast, which automatically returns to function when an existing qdisc is detached. In this sense this qdisc is magic, and unlike other qdiscs. == -- Jiri Kosina SUSE Labs
[PATCH net-next v2 1/2] net: rtnetlink: add support for the IFLA_STATS_LINK_XSTATS_SLAVE attribute
This patch adds support for the IFLA_STATS_LINK_XSTATS_SLAVE attribute
which allows to export per-slave statistics if the master device supports
the linkxstats callback. The attribute is passed down to the linkxstats
callback and it is up to the callback user to use it (an example has been
added to the only current user - the bridge). This allows us to query only
specific slaves of master devices like bridge ports and export only what
we're interested in instead of having to dump all ports and searching only
for a single one. This will be used to export per-port IGMP/MLD stats and
also per-port vlan stats in the future, possibly other statistics as well.
Signed-off-by: Nikolay Aleksandrov
---
v2: new patch
include/net/rtnetlink.h | 5 ++--
include/uapi/linux/if_link.h | 1 +
net/bridge/br_netlink.c | 59 +---
net/core/rtnetlink.c | 50 +++--
4 files changed, 108 insertions(+), 7 deletions(-)
diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
index 006a7b81d758..4113916cc1bb 100644
--- a/include/net/rtnetlink.h
+++ b/include/net/rtnetlink.h
@@ -98,10 +98,11 @@ struct rtnl_link_ops {
const struct net_device *dev,
const struct net_device
*slave_dev);
struct net *(*get_link_net)(const struct net_device *dev);
- size_t (*get_linkxstats_size)(const struct net_device
*dev);
+ size_t (*get_linkxstats_size)(const struct net_device
*dev,
+ int attr);
int (*fill_linkxstats)(struct sk_buff *skb,
const struct net_device *dev,
- int *prividx);
+ int *prividx, int attr);
};
int __rtnl_link_register(struct rtnl_link_ops *ops);
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index bb36bd5675a7..db2458ade81c 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -822,6 +822,7 @@ enum {
IFLA_STATS_UNSPEC, /* also used as 64bit pad attribute */
IFLA_STATS_LINK_64,
IFLA_STATS_LINK_XSTATS,
+ IFLA_STATS_LINK_XSTATS_SLAVE,
__IFLA_STATS_MAX,
};
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index a5343c7232bf..765e7e72edb3 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1234,7 +1234,7 @@ static int br_fill_info(struct sk_buff *skb, const struct
net_device *brdev)
return 0;
}
-static size_t br_get_linkxstats_size(const struct net_device *dev)
+static size_t bridge_get_linkxstats_size(const struct net_device *dev)
{
struct net_bridge *br = netdev_priv(dev);
struct net_bridge_vlan_group *vg;
@@ -1254,8 +1254,30 @@ static size_t br_get_linkxstats_size(const struct
net_device *dev)
nla_total_size(0);
}
-static int br_fill_linkxstats(struct sk_buff *skb, const struct net_device
*dev,
- int *prividx)
+static size_t brport_get_linkxstats_size(const struct net_device *dev)
+{
+ return nla_total_size(0);
+}
+
+static size_t br_get_linkxstats_size(const struct net_device *dev, int attr)
+{
+ size_t retsize = 0;
+
+ switch (attr) {
+ case IFLA_STATS_LINK_XSTATS:
+ retsize = bridge_get_linkxstats_size(dev);
+ break;
+ case IFLA_STATS_LINK_XSTATS_SLAVE:
+ retsize = brport_get_linkxstats_size(dev);
+ break;
+ }
+
+ return retsize;
+}
+
+static int bridge_fill_linkxstats(struct sk_buff *skb,
+ const struct net_device *dev,
+ int *prividx)
{
struct net_bridge *br = netdev_priv(dev);
struct net_bridge_vlan_group *vg;
@@ -1298,6 +1320,37 @@ nla_put_failure:
return -EMSGSIZE;
}
+static int brport_fill_linkxstats(struct sk_buff *skb,
+ const struct net_device *dev,
+ int *prividx)
+{
+ struct nlattr *nest;
+
+ nest = nla_nest_start(skb, LINK_XSTATS_TYPE_BRIDGE);
+ if (!nest)
+ return -EMSGSIZE;
+ nla_nest_end(skb, nest);
+
+ return 0;
+}
+
+static int br_fill_linkxstats(struct sk_buff *skb, const struct net_device
*dev,
+ int *prividx, int attr)
+{
+ int ret = -EINVAL;
+
+ switch (attr) {
+ case IFLA_STATS_LINK_XSTATS:
+ ret = bridge_fill_linkxstats(skb, dev, prividx);
+ break;
+ case IFLA_STATS_LINK_XSTATS_SLAVE:
+ ret = brport_fill_linkxstats(skb, dev, prividx);
+ break;
+ }
+
+ return ret;
+}
+
static struct rtnl_af_ops br_af_op
[PATCH net-next v2 2/2] net: bridge: add support for IGMP/MLD stats and export them via netlink
This patch adds stats support for the currently used IGMP/MLD types by the
bridge. The stats are per-port (plus one stat per-bridge) and per-direction
(RX/TX). The stats are exported via netlink via the new linkxstats API
(RTM_GETSTATS). In order to minimize the performance impact, a new option
is used to enable/disable the stats - multicast_stats_enabled, similar to
the recent vlan stats. Also in order to avoid multiple IGMP/MLD type
lookups and checks, we make use of the current "igmp" member of the bridge
private skb->cb region to record the type on Rx (both host-generated and
external packets pass by multicast_rcv()). We can do that since the igmp
member was used as a boolean and all the valid IGMP/MLD types are positive
values. The normal bridge fast-path is not affected at all, the only
affected paths are the flooding ones and since we make use of the IGMP/MLD
type, we can quickly determine if the packet should be counted using
cache-hot data (cb's igmp member). We add counters for:
* IGMP Queries
* IGMP Leaves
* IGMP v1/v2/v3 reports
* MLD Queries
* MLD Leaves
* MLD v1/v2 reports
These are invaluable when monitoring or debugging complex multicast setups
with bridges.
Signed-off-by: Nikolay Aleksandrov
---
v2: use the new API, also in addition counters for IGMP/MLD parse errors
have been added and members are added for per-port multicast traffic stats.
The multicast counting has been slightly optimized (moved the
br_multicast_count inside the IPv4/6 IGMP functions after the checks for
IGMP traffic) to avoid one conditional that was on all of the multicast
traffic path (both IGMP and other).
include/uapi/linux/if_bridge.h | 26 +
include/uapi/linux/if_link.h | 1 +
net/bridge/br_device.c | 10 +-
net/bridge/br_forward.c| 13 ++-
net/bridge/br_if.c | 9 +-
net/bridge/br_input.c | 3 +
net/bridge/br_multicast.c | 217 ++---
net/bridge/br_netlink.c| 91 -
net/bridge/br_private.h| 41 +++-
net/bridge/br_sysfs_br.c | 25 +
10 files changed, 390 insertions(+), 46 deletions(-)
diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
index 397d503fdedb..8304fe6f0561 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -247,8 +247,34 @@ enum {
enum {
BRIDGE_XSTATS_UNSPEC,
BRIDGE_XSTATS_VLAN,
+ BRIDGE_XSTATS_MCAST,
+ BRIDGE_XSTATS_PAD,
__BRIDGE_XSTATS_MAX
};
#define BRIDGE_XSTATS_MAX (__BRIDGE_XSTATS_MAX - 1)
+enum {
+ BR_MCAST_DIR_RX,
+ BR_MCAST_DIR_TX,
+ BR_MCAST_DIR_SIZE
+};
+
+/* IGMP/MLD statistics */
+struct br_mcast_stats {
+ __u64 igmp_queries[BR_MCAST_DIR_SIZE];
+ __u64 igmp_leaves[BR_MCAST_DIR_SIZE];
+ __u64 igmp_v1reports[BR_MCAST_DIR_SIZE];
+ __u64 igmp_v2reports[BR_MCAST_DIR_SIZE];
+ __u64 igmp_v3reports[BR_MCAST_DIR_SIZE];
+ __u64 igmp_parse_errors;
+
+ __u64 mld_queries[BR_MCAST_DIR_SIZE];
+ __u64 mld_leaves[BR_MCAST_DIR_SIZE];
+ __u64 mld_v1reports[BR_MCAST_DIR_SIZE];
+ __u64 mld_v2reports[BR_MCAST_DIR_SIZE];
+ __u64 mld_parse_errors;
+
+ __u64 mcast_bytes[BR_MCAST_DIR_SIZE];
+ __u64 mcast_packets[BR_MCAST_DIR_SIZE];
+};
#endif /* _UAPI_LINUX_IF_BRIDGE_H */
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index db2458ade81c..4285ac31e865 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -273,6 +273,7 @@ enum {
IFLA_BR_VLAN_DEFAULT_PVID,
IFLA_BR_PAD,
IFLA_BR_VLAN_STATS_ENABLED,
+ IFLA_BR_MCAST_STATS_ENABLED,
__IFLA_BR_MAX,
};
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 2c8095a5d824..0c39e0f6da09 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -104,8 +104,16 @@ static int br_dev_init(struct net_device *dev)
return -ENOMEM;
err = br_vlan_init(br);
- if (err)
+ if (err) {
free_percpu(br->stats);
+ return err;
+ }
+
+ err = br_multicast_init_stats(br);
+ if (err) {
+ free_percpu(br->stats);
+ br_vlan_flush(br);
+ }
br_set_lockdep_class(dev);
return err;
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index f47759f05b6d..6c196037d818 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -198,8 +198,10 @@ static void br_flood(struct net_bridge *br, struct sk_buff
*skb,
struct sk_buff *skb),
bool unicast)
{
- struct net_bridge_port *p;
+ u8 igmp_type = br_multicast_igmp_type(skb);
+ __be16 proto = skb->protocol;
struct net_bridge_port *prev;
+ struct net_bridge_port *p;
prev = NULL;
@@ -218,6 +220,9 @@ static void br_flood(struct net_bridge *br, struct sk_buff
*
[PATCH net-next v2 0/2] net: bridge: add support for IGMP/MLD stats
Hi all, This patchset adds support for the new IFLA_STATS_LINK_XSTATS_SLAVE attribute which can be used with RTM_GETSTATS in order to export per-slave statistics. It works by passing the attribute to the linkxstats callback and if the callback user supports it - it should dump that slave's stats. This is much more scalable and permits us to request only a single port's statistics instead of dumping everything every time. The second patch adds support for per-port IGMP/MLD statistics and uses the new API to export them for the bridge and its ports. The stats are made in a very lightweight manner, the normal fast-path is not affected at all and the flood paths (br_flood/br_multicast_flood) are only affected if the packet is IGMP and the IGMP stats have been enabled using cache-hot data for the check. v2: Patch 01 is new, patch 02 has been reworked to use the new API, also in addition counters for IGMP/MLD parse errors have been added and members are added for per-port multicast traffic stats. The multicast counting has been slightly optimized (moved the br_multicast_count inside the IPv4/6 IGMP functions after the checks for IGMP traffic) to avoid one conditional that was on all of the multicast traffic path (both IGMP and other). Thank you, Nik Nikolay Aleksandrov (2): net: rtnetlink: add support for the IFLA_STATS_LINK_XSTATS_SLAVE attribute net: bridge: add support for IGMP/MLD stats and export them via netlink include/net/rtnetlink.h| 5 +- include/uapi/linux/if_bridge.h | 26 + include/uapi/linux/if_link.h | 2 + net/bridge/br_device.c | 10 +- net/bridge/br_forward.c| 13 ++- net/bridge/br_if.c | 9 +- net/bridge/br_input.c | 3 + net/bridge/br_multicast.c | 217 ++--- net/bridge/br_netlink.c| 148 ++-- net/bridge/br_private.h| 41 +++- net/bridge/br_sysfs_br.c | 25 + net/core/rtnetlink.c | 50 +- 12 files changed, 497 insertions(+), 52 deletions(-) -- 2.1.4
Re: [PATCH net-next 10/16] net/mlx5e: Add devlink based SRIOV mode changes (legacy --> offloads)
On Tue, Jun 28, 2016 at 05:25:11PM +0300, Or Gerlitz wrote:
> On 6/28/2016 4:42 PM, Andy Gospodarek wrote:
> >On Mon, Jun 27, 2016 at 07:07:23PM +0300, Saeed Mahameed wrote:
> >>From: Or Gerlitz
> >>
> >>Implement handlers for the devlink commands to get and set the SRIOV
> >>E-Switch mode.
> >>
> >>When turning to the offloads mode, we disable the e-switch and enable
> >>it again in the new mode, create the NIC offloads table and create VF reps.
> >>
> >>When turning to legacy mode, we remove the VF reps and the offloads
> >>table, and re-initiate the e-switch in it's legacy mode.
> >>
> >>The actual creation/removal of the VF reps is done in downstream patches.
> >>
> >>Signed-off-by: Or Gerlitz
> >>Signed-off-by: Saeed Mahameed
> >>---
> >> drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 12 ++-
> >> .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 102
> >> -
> >> 2 files changed, 105 insertions(+), 9 deletions(-)
> >>
> >[...]
> >>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>index 3b3afbd..a39af6b 100644
> >>--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >[...]
> >> int mlx5_devlink_eswitch_mode_set(struct devlink *devlink, u16 mode)
> >> {
> >>- return -EOPNOTSUPP;
> >>+ struct mlx5_core_dev *dev;
> >>+ u16 cur_mode;
> >>+
> >>+ dev = devlink_priv(devlink);
> >>+
> >>+ if (!MLX5_CAP_GEN(dev, vport_group_manager))
> >>+ return -EOPNOTSUPP;
> >>+
> >>+ cur_mode = dev->priv.eswitch->mode;
> >>+
> >>+ if (cur_mode == SRIOV_NONE || mode == SRIOV_NONE)
> >>+ return -EOPNOTSUPP;
> >>+
> >>+ if (cur_mode == mode)
> >>+ return 0;
> >>+
> >>+ if (mode == SRIOV_OFFLOADS) /* current mode is legacy */
> >>+ return esw_offloads_start(dev->priv.eswitch);
> >>+ else if (mode == SRIOV_LEGACY) /* curreny mode is offloads */
> >>+ return esw_offloads_stop(dev->priv.eswitch);
> >>+ else
> >>+ return -EINVAL;
> >> }
> >>
> >>This is an _extremely_ minor nit, but I only bring it up since you are
> >>leading the way here and your model may be one that other people
> >>follow...
> >>
> >>Internally you have a enum to track the SRIOV modes:
> >>
> >>enum {
> >>SRIOV_NONE,
> >>SRIOV_LEGACY,
> >>SRIOV_OFFLOADS
> >>};
> >>
> >>But patch 8 adds a new enum for devlink to track this as well.
> >>
> >>enum devlink_eswitch_mode {
> >>DEVLINK_ESWITCH_MODE_NONE,
> >>DEVLINK_ESWITCH_MODE_LEGACY,
> >>DEVLINK_ESWITCH_MODE_OFFLOADS,
> >>};
> >>
>
>
> Andy,
>
> In mlx5 we're having an eswitch driver instance also when not in sriov mode
> where on that case the mlx5 eswitch mode is called sriov_none, which is
> maybe not a very successful name, I'll look on that.
>
> On the devlink/system level, the eswitch modes are relevant only for SRIOV,
> you can see in the mlx5 set function that we return error when in the none
> mode or asked to go there.
>
> So... with your comment, I realize now that I forgot to remove
> DEVLINK_ESWITCH_MODE_NONE value from the submission.
>
> >Would it make sense at some point to use the devlink modes in the driver
> >so it's less to track?
>
> This makes it a bit problematic for mlx5 to use the DEVLINK_ESWITCH_MODE_YYY
> values internally.
If you planned to remove DEVLINK_ESWITCH_MODE_NONE then I could see how
using these in mlx5 would be problematic. Thinking about it for just a
minute, I can see the value dropping DEVLINK_ESWITCH_MODE_NONE. If the
driver supports the ability to set the eswitch mode, then it should
report an actual mode other than none.
If you remove DEVLINK_ESWITCH_MODE_NONE, then obviously
mlx5_devlink_eswitch_mode_set/get will need to change a bit as well as
there will need to be a mapping between the two values since the enums
would no longer be the same. Easy fix, though. :-)
> >Again, this is an extremely _minor_ concern. The rest of the set looks
> >great and I like the architectural decisions made here. Awesome work
> >all around!
RE: [PATCH 2/4] mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting
On Tue, Jun 28, 2016 at 15:27:47, Bob Copeland wrote: > linux- wirel...@vger.kernel.org; netdev@vger.kernel.org; Hahn, Maital > Subject: Re: [PATCH 2/4] mac80211/cfg: mesh: fix healing time when a > mesh peer is disconnecting > > On Tue, Jun 28, 2016 at 02:13:05PM +0300, Yaniv Machani wrote: > > From: Maital Hahn > > > > Once receiving a CLOSE action frame from the disconnecting peer, > > flush all entries in the path table which has this peer as the next hop. > > Please address the user-visible behavior in your commit messages. > Does it crash? Does it send frames to an invalid peer? Do frames get > dropped? > Hi Bob, It was a crash, apparently already fixed by your patches some time ago. I'll remove that part and resend the 2nd part (with some more 'why', and less typos..) > > In addition, upon receiving a packet, if next hop is not found, > > trigger PERQ immidiatly, instead of just putting it in the queue. > > "PREQ" > > Please split this into a separate patch that we can review separately > (and also give the "why" in the commit log). > > > @@ -1011,6 +1011,7 @@ static void sta_apply_mesh_params(struct > ieee80211_local *local, > > if (sta->mesh->plink_state == NL80211_PLINK_ESTAB) > > changed = > mesh_plink_dec_estab_count(sdata); > > sta->mesh->plink_state = params->plink_state; > > + mesh_path_flush_by_nexthop(sta); > > This isn't necessary, caller should already be doing > mesh_path_flush_by_nexthop() in every case I could see. Besides it > cannot be done under plink lock. > I believe this was fixed in your patch "mac80211: mesh: flush paths outside of plink lock" There is probably no need in that on the latest as well. Thanks, Yaniv
[RFC] WireGuard: next generation secure network tunnel
Hi Dave & Folks, Today I'm releasing WireGuard, an encrypted and authenticated tunneling virtual interface for the kernel. It uses next-generation cryptography and is designed to be both easy to use and simple to implement (only ~4000 LoC, which compared to xfrm or openvpn is spectacular), avoiding the enormous complexities of all other secure tunneling tools. It's been a long road, but after considerable research, experiments, cryptographic review, and implementing, I think I'm at a point where I feel comfortable releasing this and asking for your feedback. This isn't yet a patch series, however. There's still some work to be done, I anticipate, before this is mergeable. But what we have now is a good basis for discussion and talking about what needs to be done for this to be a proper patch series. You may visit the main info site about WireGuard at https://www.wireguard.io and you can read the whitepaper and full technical description and argumentation at https://www.wireguard.io/papers/wireguard.pdf . The source code lives at https://git.zx2c4.com/WireGuard/tree/src/ and you can read instructions on building it in the install and quickstart sections of the website. I'm not going to recapitulate all of the paper here, but I will discuss the things that are most relevant to kernel development. WireGuard acts as a virtual interface, doing layer 3 IP tunneling, addable with "ip link add dev wg0 type wireguard". You can set the interface's local IP and routes using the usual ip-address and ip-route tools. The WireGuard-specific elements are in a new tool called `wg`, which will at some point be merged into the usual ip tools. With `wg` you can set the device's private key, and give it a list of associations between peers' public keys, their allowed IP addresses, and their remote UDP endpoints. When a locally generated packet hits the device, it looks at the dst IP, looks up this dst IP in the aforementioned association table, and then encrypts it using the proper public key's session. Conversely, when an encrypted packet arrives on the interface, after it's been decrypted, the inner src IP is looked up in this association table to see if it matches the public key from which it originated. This is the "cryptokey routing table", and many more details and explanations are found on the site and paper above. But that's the basic gist; you add a device with ip-link, give it keys with `wg`, and then you can start sending and receiving packets on the interface that are secure. In order to make this so seamless, WireGuard does away with a lot of the _theoretically pure_ layering abstractions typically seen. First of all, WireGuard is an interface, where crypto is done, which is a considerable departure from the (hugely complex) xfrm-approach. It is not unprecedented, however; the mac80211 infrastructure also does crypto at this same layer. The massive gain is not only greater simplicity in the codebase, but huge simplicity earnings and ease-of-security for administrators. If a packet comes from a WireGuard interface, it can be trusted as authentic and confidential. If you want outgoing packets to be tunneled, point your routing table at the WireGuard interface. It's basically that simple, removing years and years of headaches (and catastrophically insecure misconfigurations) people often have with the xfrm layer. Second, WireGuard uses something based on the Noise Protocol Framework (in Noise_IK) for key agreement and handshake, rather than, say, relegating to a userspace daemon. The reason, again, is massive simplicity and security savings. The Noise_IK handshake is extremely simple, and tight integration between the handshake and the transport layer allows WireGuard itself to handle all session-state and connection-state and so-forth, making the whole process appear "stateless" to the administrator (you set it up with `wg`, and then it _just works_). There is no x509, no ASN.1, no huge complexity; the user configures the public keys, and then the rest is taken care of. Other configuration frameworks (based on x509 or SSL or LDAP or whatever you want) can then build on top of this in userspace, if that sort of thing is desired. But the basic handshake fundamentals are left to WireGuard. This is more or less similar to SSH, which cares about the authorized_keys file. These two design choices are fundamental to WireGuard, and I believe they confer significant benefits, which are discussed extensively in the paper. There are two incidental implementation choices, however, that I think will be more controversial from a kernel perspective, and depending on the result of this discussion, maybe things will change, or maybe they wont. First, WireGuard doesn't use the kernel's crypto API. The overhead of memory allocation and abstraction/indirection behind each encryption/hashing/ec-multiplication operation not only adds unfortunate performance overhead, but also bloats the code, impacting ease of auditing and verific
Re: [Patch net] mlx4: set csum_complete_sw bit when fixing complete csum
On Tue, Jun 28, 2016 at 12:44 AM, Cong Wang wrote: > On Mon, Jun 27, 2016 at 2:08 PM, Or Gerlitz wrote: >> On Mon, Jun 27, 2016 at 9:22 PM, Cong Wang wrote: >> can you point/paste the exact warning and how to reproduce that? is >> that as simple as running ping and/or ping6? > Yes, ping is enough to reproduce it every time. > The warning is below: > [ 8693.680997] eth0: hw csum failure Wow, can you please report us the exact card type (lspci -nn | grep -i mellanox) and firmware version (ethtool -i $DEV)
Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)
> We have actually gained quite a bit of documentation recently. > Have you looked at Documentation/DocBook/crypto-API.tmpl? > > More is always welcome of course. It's improved since I last looked at it, but there are still many structures that aren't described: - struct crypto_instance - struct crypto_spawn - struct crypto_blkcipher - struct blkcipher_desc - More on the context structures returned by crypto_tfm_ctx Also not mentioned in the documentation is that some algorithms *do* have different implementations depending on key size. SHA-2 is the classic example.
Re: [PATCH net-next 10/16] net/mlx5e: Add devlink based SRIOV mode changes (legacy --> offloads)
On 6/28/2016 4:42 PM, Andy Gospodarek wrote:
On Mon, Jun 27, 2016 at 07:07:23PM +0300, Saeed Mahameed wrote:
From: Or Gerlitz
Implement handlers for the devlink commands to get and set the SRIOV
E-Switch mode.
When turning to the offloads mode, we disable the e-switch and enable
it again in the new mode, create the NIC offloads table and create VF reps.
When turning to legacy mode, we remove the VF reps and the offloads
table, and re-initiate the e-switch in it's legacy mode.
The actual creation/removal of the VF reps is done in downstream patches.
Signed-off-by: Or Gerlitz
Signed-off-by: Saeed Mahameed
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 12 ++-
.../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 102 -
2 files changed, 105 insertions(+), 9 deletions(-)
[...]
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 3b3afbd..a39af6b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
[...]
int mlx5_devlink_eswitch_mode_set(struct devlink *devlink, u16 mode)
{
- return -EOPNOTSUPP;
+ struct mlx5_core_dev *dev;
+ u16 cur_mode;
+
+ dev = devlink_priv(devlink);
+
+ if (!MLX5_CAP_GEN(dev, vport_group_manager))
+ return -EOPNOTSUPP;
+
+ cur_mode = dev->priv.eswitch->mode;
+
+ if (cur_mode == SRIOV_NONE || mode == SRIOV_NONE)
+ return -EOPNOTSUPP;
+
+ if (cur_mode == mode)
+ return 0;
+
+ if (mode == SRIOV_OFFLOADS) /* current mode is legacy */
+ return esw_offloads_start(dev->priv.eswitch);
+ else if (mode == SRIOV_LEGACY) /* curreny mode is offloads */
+ return esw_offloads_stop(dev->priv.eswitch);
+ else
+ return -EINVAL;
}
This is an _extremely_ minor nit, but I only bring it up since you are
leading the way here and your model may be one that other people
follow...
Internally you have a enum to track the SRIOV modes:
enum {
SRIOV_NONE,
SRIOV_LEGACY,
SRIOV_OFFLOADS
};
But patch 8 adds a new enum for devlink to track this as well.
enum devlink_eswitch_mode {
DEVLINK_ESWITCH_MODE_NONE,
DEVLINK_ESWITCH_MODE_LEGACY,
DEVLINK_ESWITCH_MODE_OFFLOADS,
};
Andy,
In mlx5 we're having an eswitch driver instance also when not in sriov
mode where on that case the mlx5 eswitch mode is called sriov_none,
which is maybe not a very successful name, I'll look on that.
On the devlink/system level, the eswitch modes are relevant only for
SRIOV, you can see in the mlx5 set function that we return error when in
the none mode or asked to go there.
So... with your comment, I realize now that I forgot to remove
DEVLINK_ESWITCH_MODE_NONE value from the submission.
Would it make sense at some point to use the devlink modes in the driver
so it's less to track?
This makes it a bit problematic for mlx5 to use the
DEVLINK_ESWITCH_MODE_YYY values internally.
Again, this is an extremely _minor_ concern. The rest of the set looks
great and I like the architectural decisions made here. Awesome work
all around!
Re: [PATCH] rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code size
On 06/27/2016 10:55 PM, Joe Perches wrote: On Mon, 2016-06-27 at 19:53 -0500, Larry Finger wrote: On 06/25/2016 05:46 PM, Joe Perches wrote: This debugging macro can expand to a lot of code. Make it a function to reduce code size. (x86-64 defconfig w/ all rtlwifi drivers and allyesconfig) $ size drivers/net/wireless/realtek/rtlwifi/built-in.o* text data bss dec hex filename 9000832004991907 1102489 10d299 drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.new 1113597 2004991907 1316003 1414a3 drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.old 1746879 4535038512 2208894 21b47e drivers/net/wireless/realtek/rtlwifi/built-in.o.new 2051965 5033118512 2563788 271ecc drivers/net/wireless/realtek/rtlwifi/built-in.o.old Signed-off-by: Joe Perches I acked this before; however there is a bug that breaks the build if CONFIG_RTLWIFI_DEBUG is not defined. The rest of the code calls _rtl_dbg_trace(), but that symbol is never defined. The problem can be fixed in debug.c or debug.h. Confused a bit. What breaks again? Nothing breaks and your patch is OK. I had ported it to a GitHub repo of these drivers, which had a different debug.h. That led to the missing global when CONFIG_RTLWIFI_DEBUG was not defined. That has now been fixed. Sorry for the confusion. Larry
Re: [PATCH net-next 0/6] net: dsa: Platform data for dsa2.c
On Mon, Jun 27, 2016 at 06:19:28PM -0700, Florian Fainelli wrote: > 2016-06-27 18:05 GMT-07:00 Andrew Lunn : > > On Mon, Jun 27, 2016 at 05:52:37PM -0700, Florian Fainelli wrote: > >> Hi all, > >> > >> This patch series adds support for platform data using the new code from > >> net/dsa/dsa2.c. The motivation behind this is that we have a bit of in tree > >> platforms (ar7, bcm47xx, x86, others) that could be benefiting from the new > >> dsa_register_switch() API model but do not support Device Tree, nor is > >> there a > >> plan to bring Device Tree to these platforms (time vs. benefits). > > > > Hi Florian > > > > Please could you convert an in tree device to actually use this. > > Sure, I don't think there are going to be in tree users who need the > dsa2_port_link information most of what we have is typically single > chip, and so in that case, we can even re-use the existing > dsa_platform_data. O.K. Less is better. When going through the old code for the earlier re-structuring proposals, the code is not simple at times. I would prefer not adding more complexity to dsa2 than really is needed. Andrew
Re: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon template
On Tue, Jun 28, 2016 at 02:13:06PM +0300, Yaniv Machani wrote: > From: Meirav Kama > > There are several values in HT info elements of mesh beacon (built by the > mac80211) that are incorrect. Would be good to enumerate the problems here. > To fix them: > 1. mac80211 will check configuration from cfg and will build accordingly. > 2. changes made in mesh default values. What is wrong with the defaults? > sband = local->hw.wiphy->bands[band]; > if (!sband->ht_cap.ht_supported || > @@ -431,11 +433,40 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data > *sdata, > sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10) > return 0; > > +/* determine capability flags */ > + cap = sband->ht_cap.cap; There is some weird whitespace here (space instead of tabs for the comment). -- Bob Copeland %% http://bobcopeland.com/
[PATCH] net: can: Introduce MEN 16Z192-00 CAN controller driver
This CAN Controller is found on MEN Chameleon FPGAs. The driver/device supports the CAN2.0 specification. There are 255 RX and 255 Tx buffer within the IP. The pointer for the buffer are handled by HW to make the access from within the driver as simple as possible. The driver also supports parameters to configure the buffer level interrupt for RX/TX as well as a RX timeout interrupt. With this configuration options, the driver/device provides flexibility for different types of usecases. Signed-off-by: Andreas Werner --- drivers/net/can/Kconfig| 10 + drivers/net/can/Makefile | 1 + drivers/net/can/men_z192_can.c | 990 + 3 files changed, 1001 insertions(+) create mode 100644 drivers/net/can/men_z192_can.c diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 0d40aef..0fa0387 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -104,6 +104,16 @@ config CAN_JANZ_ICAN3 This driver can also be built as a module. If so, the module will be called janz-ican3.ko. +config CAN_MEN_Z192 + tristate "MEN 16Z192-00 CAN Controller" + depends on MCB + ---help--- + Driver for MEN 16Z192-00 CAN Controller IP-Core, which + is connected to the MEN Chameleon Bus. + + This driver can also be built as a module. If so, the module will be + called men_z192_can.ko. + config CAN_RCAR tristate "Renesas R-Car CAN controller" depends on ARCH_RENESAS || ARM diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile index e3db0c8..eb206b3 100644 --- a/drivers/net/can/Makefile +++ b/drivers/net/can/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o obj-$(CONFIG_CAN_GRCAN)+= grcan.o obj-$(CONFIG_CAN_IFI_CANFD)+= ifi_canfd/ obj-$(CONFIG_CAN_JANZ_ICAN3) += janz-ican3.o +obj-$(CONFIG_CAN_MEN_Z192) += men_z192_can.o obj-$(CONFIG_CAN_MSCAN)+= mscan/ obj-$(CONFIG_CAN_M_CAN)+= m_can/ obj-$(CONFIG_CAN_RCAR) += rcar_can.o diff --git a/drivers/net/can/men_z192_can.c b/drivers/net/can/men_z192_can.c new file mode 100644 index 000..d3acc2e --- /dev/null +++ b/drivers/net/can/men_z192_can.c @@ -0,0 +1,990 @@ +/* + * MEN 16Z192 CAN Controller driver + * + * Copyright (C) 2016 MEN Mikroelektronik GmbH (www.men.de) + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; version 2 of the License. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRV_NAME "z192_can" + +#define MEN_Z192_NAPI_WEIGHT 64 +#define MEN_Z192_MODE_TOUT_US 40 + +/* CTL/BTR Register Bits */ +#define MEN_Z192_CTL0_INITRQ BIT(0) +#define MEN_Z192_CTL0_SLPRQBIT(1) +#define MEN_Z192_CTL1_INITAK BIT(8) +#define MEN_Z192_CTL1_SLPAKBIT(9) +#define MEN_Z192_CTL1_LISTEN BIT(12) +#define MEN_Z192_CTL1_LOOPBBIT(13) +#define MEN_Z192_CTL1_CANE BIT(15) +#define MEN_Z192_BTR0_BRP(x) (((x) & 0x3f) << 16) +#define MEN_Z192_BTR0_SJW(x) (((x) & 0x03) << 22) +#define MEN_Z192_BTR1_TSEG1(x) (((x) & 0x0f) << 24) +#define MEN_Z192_BTR1_TSEG2(x) (((x) & 0x07) << 28) +#define MEN_Z192_BTR1_SAMP BIT(31) + +/* IER Interrupt Enable Register bits */ +#define MEN_Z192_RXIE BIT(0) +#define MEN_Z192_OVRIE BIT(1) +#define MEN_Z192_CSCIE BIT(6) +#define MEN_Z192_TOUTE BIT(7) +#define MEN_Z192_TXIE BIT(16) +#define MEN_Z192_ERRIE BIT(17) + +#define MEN_Z192_IRQ_ALL \ + (MEN_Z192_RXIE | MEN_Z192_OVRIE | \ +MEN_Z192_CSCIE | MEN_Z192_TOUTE | \ +MEN_Z192_TXIE) + +#define MEN_Z192_IRQ_NAPI (MEN_Z192_RXIE | MEN_Z192_TOUTE) + +/* RX_TX_STAT RX/TX Status status register bits */ +#define MEN_Z192_RX_BUF_CNT(x) ((x) & 0xff) +#define MEN_Z192_TX_BUF_CNT(x) (((x) & 0xff00) >> 8) +#defineMEN_Z192_RFLG_RXIF BIT(16) +#defineMEN_Z192_RFLG_OVRF BIT(17) +#defineMEN_Z192_RFLG_TSTATEGENMASK(19, 18) +#defineMEN_Z192_RFLG_RSTATEGENMASK(21, 20) +#defineMEN_Z192_RFLG_CSCIF BIT(22) +#defineMEN_Z192_RFLG_TOUTF BIT(23) +#define MEN_Z192_TFLG_TXIF BIT(24) + +#define MEN_Z192_GET_TSTATE(x) (((x) & MEN_Z192_RFLG_TSTATE) >> 18) +#define MEN_Z192_GET_RSTATE(x) (((x) & MEN_Z192_RFLG_RSTATE) >> 20) + +#define MEN_Z192_IRQ_FLAGS_ALL \ + (MEN_Z192_RFLG_RXIF | MEN_Z192_RFLG_OVRF | \ +MEN_Z192_RFLG_TSTATE | MEN_Z192_RFLG_RSTATE | \ +MEN_Z192_RFLG_CSCIF | MEN_Z192_RFLG_TOUTF |\ +MEN_Z192_TFLG_TXIF) + +/* RX/TX Error counter bits */ +#define MEN_Z192_GET_RX_ERR_CNT(x) ((x) & 0xff) +#define MEN_Z192_GET_TX_ERR_CNT
