* [PATCH net-next v2 1/2] r8152: saving the settings of EEE
From: Hayes Wang @ 2019-08-23 7:04 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-305-Taiwan-albertk@realtek.com>
Saving the settings of EEE to avoid they become the default settings
after reset_resume().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 80 +++++++++++++++++++++++++----------------
1 file changed, 50 insertions(+), 30 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1aa61610f0bb..a7aa48bee732 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -751,6 +751,7 @@ struct r8152 {
atomic_t rx_count;
+ bool eee_en;
int intr_interval;
u32 saved_wolopts;
u32 msg_enable;
@@ -762,6 +763,7 @@ struct r8152 {
u16 ocp_base;
u16 speed;
+ u16 eee_adv;
u8 *intr_buff;
u8 version;
u8 duplex;
@@ -3202,8 +3204,13 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
static void r8152b_enable_eee(struct r8152 *tp)
{
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
}
static void r8152b_enable_fc(struct r8152 *tp)
@@ -3495,8 +3502,10 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3599,8 +3608,10 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_ups_flags_w1w0(tp, ups_flags, 0);
- r8153b_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153b_aldps_en(tp, true);
r8153b_enable_fc(tp);
@@ -4891,7 +4902,7 @@ static void rtl8152_get_strings(struct net_device *dev, u32 stringset, u8 *data)
static int r8152_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = r8152_mmd_read(tp, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
@@ -4903,13 +4914,10 @@ static int r8152_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
val = r8152_mmd_read(tp, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4919,19 +4927,22 @@ static int r8152_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8152_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8152_eee_en(tp, eee->eee_enabled);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ if (eee->eee_enabled)
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ else
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
return 0;
}
static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = ocp_reg_read(tp, OCP_EEE_ABLE);
@@ -4943,13 +4954,10 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
val = ocp_reg_read(tp, OCP_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4959,12 +4967,15 @@ static int r8153_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8153_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8153_eee_en(tp, eee->eee_enabled);
- ocp_reg_write(tp, OCP_EEE_ADV, val);
+ if (eee->eee_enabled)
+ ocp_reg_write(tp, OCP_EEE_ADV, val);
+ else
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
return 0;
}
@@ -4973,12 +4984,15 @@ static int r8153b_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8153b_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8153b_eee_en(tp, eee->eee_enabled);
- ocp_reg_write(tp, OCP_EEE_ADV, val);
+ if (eee->eee_enabled)
+ ocp_reg_write(tp, OCP_EEE_ADV, val);
+ else
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
return 0;
}
@@ -5353,6 +5367,8 @@ static int rtl_ops_init(struct r8152 *tp)
ops->hw_phy_cfg = r8152b_hw_phy_cfg;
ops->autosuspend_en = rtl_runtime_suspend_enable;
tp->rx_buf_sz = 16 * 1024;
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_100TX;
break;
case RTL_VER_03:
@@ -5371,6 +5387,8 @@ static int rtl_ops_init(struct r8152 *tp)
ops->hw_phy_cfg = r8153_hw_phy_cfg;
ops->autosuspend_en = rtl8153_runtime_enable;
tp->rx_buf_sz = 32 * 1024;
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
break;
case RTL_VER_08:
@@ -5387,6 +5405,8 @@ static int rtl_ops_init(struct r8152 *tp)
ops->hw_phy_cfg = r8153b_hw_phy_cfg;
ops->autosuspend_en = rtl8153b_runtime_enable;
tp->rx_buf_sz = 32 * 1024;
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
break;
default:
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v2 2/2] r8152: add a helper function about setting EEE
From: Hayes Wang @ 2019-08-23 7:04 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-305-Taiwan-albertk@realtek.com>
Add a helper funtcion "rtl_eee_enable" for setting EEE. Besides, I
move r8153_eee_en() and r8153b_eee_en(). And, I remove r8152b_enable_eee(),
r8153_set_eee(), and r8153b_set_eee().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 166 +++++++++++++++++++---------------------
1 file changed, 77 insertions(+), 89 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a7aa48bee732..220079a8882f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3202,14 +3202,75 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
ocp_reg_write(tp, OCP_EEE_CONFIG3, config3);
}
-static void r8152b_enable_eee(struct r8152 *tp)
+static void r8153_eee_en(struct r8152 *tp, bool enable)
{
- if (tp->eee_en) {
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ u32 ocp_data;
+ u16 config;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config = ocp_reg_read(tp, OCP_EEE_CFG);
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config |= EEE10_EN;
} else {
- r8152_eee_en(tp, false);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config &= ~EEE10_EN;
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CFG, config);
+}
+
+static void r8153b_eee_en(struct r8152 *tp, bool enable)
+{
+ r8153_eee_en(tp, enable);
+
+ if (enable)
+ r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
+ else
+ r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
+}
+
+static void rtl_eee_enable(struct r8152 *tp, bool enable)
+{
+ switch (tp->version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ case RTL_VER_07:
+ if (enable) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
+ tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_03:
+ case RTL_VER_04:
+ case RTL_VER_05:
+ case RTL_VER_06:
+ if (enable) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_08:
+ case RTL_VER_09:
+ if (enable) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ default:
+ break;
}
}
@@ -3231,7 +3292,7 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
- r8152b_enable_eee(tp);
+ rtl_eee_enable(tp, tp->eee_en);
r8152_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3425,36 +3486,6 @@ static void r8153b_aldps_en(struct r8152 *tp, bool enable)
r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_ALDPS);
}
-static void r8153_eee_en(struct r8152 *tp, bool enable)
-{
- u32 ocp_data;
- u16 config;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- config = ocp_reg_read(tp, OCP_EEE_CFG);
-
- if (enable) {
- ocp_data |= EEE_RX_EN | EEE_TX_EN;
- config |= EEE10_EN;
- } else {
- ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
- config &= ~EEE10_EN;
- }
-
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
- ocp_reg_write(tp, OCP_EEE_CFG, config);
-}
-
-static void r8153b_eee_en(struct r8152 *tp, bool enable)
-{
- r8153_eee_en(tp, enable);
-
- if (enable)
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
- else
- r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
-}
-
static void r8153b_enable_fc(struct r8152 *tp)
{
r8152b_enable_fc(tp);
@@ -3470,7 +3501,7 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8153_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
- r8153_eee_en(tp, false);
+ rtl_eee_enable(tp, false);
ocp_reg_write(tp, OCP_EEE_ADV, 0);
if (tp->version == RTL_VER_03) {
@@ -3502,10 +3533,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- if (tp->eee_en) {
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
- }
+ if (tp->eee_en)
+ rtl_eee_enable(tp, true);
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3545,7 +3574,7 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
- r8153b_eee_en(tp, false);
+ rtl_eee_enable(tp, false);
ocp_reg_write(tp, OCP_EEE_ADV, 0);
r8153b_green_en(tp, test_bit(GREEN_ETHERNET, &tp->flags));
@@ -3608,10 +3637,8 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_ups_flags_w1w0(tp, ups_flags, 0);
- if (tp->eee_en) {
- r8153b_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
- }
+ if (tp->eee_en)
+ rtl_eee_enable(tp, true);
r8153b_aldps_en(tp, true);
r8153b_enable_fc(tp);
@@ -4930,12 +4957,7 @@ static int r8152_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
tp->eee_en = eee->eee_enabled;
tp->eee_adv = val;
- r8152_eee_en(tp, eee->eee_enabled);
-
- if (eee->eee_enabled)
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
- else
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ rtl_eee_enable(tp, tp->eee_en);
return 0;
}
@@ -4963,40 +4985,6 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
return 0;
}
-static int r8153_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
-{
- u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
-
- tp->eee_en = eee->eee_enabled;
- tp->eee_adv = val;
-
- r8153_eee_en(tp, eee->eee_enabled);
-
- if (eee->eee_enabled)
- ocp_reg_write(tp, OCP_EEE_ADV, val);
- else
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
-
- return 0;
-}
-
-static int r8153b_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
-{
- u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
-
- tp->eee_en = eee->eee_enabled;
- tp->eee_adv = val;
-
- r8153b_eee_en(tp, eee->eee_enabled);
-
- if (eee->eee_enabled)
- ocp_reg_write(tp, OCP_EEE_ADV, val);
- else
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
-
- return 0;
-}
-
static int
rtl_ethtool_get_eee(struct net_device *net, struct ethtool_eee *edata)
{
@@ -5382,7 +5370,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->down = rtl8153_down;
ops->unload = rtl8153_unload;
ops->eee_get = r8153_get_eee;
- ops->eee_set = r8153_set_eee;
+ ops->eee_set = r8152_set_eee;
ops->in_nway = rtl8153_in_nway;
ops->hw_phy_cfg = r8153_hw_phy_cfg;
ops->autosuspend_en = rtl8153_runtime_enable;
@@ -5400,7 +5388,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->down = rtl8153b_down;
ops->unload = rtl8153b_unload;
ops->eee_get = r8153_get_eee;
- ops->eee_set = r8153b_set_eee;
+ ops->eee_set = r8152_set_eee;
ops->in_nway = rtl8153_in_nway;
ops->hw_phy_cfg = r8153b_hw_phy_cfg;
ops->autosuspend_en = rtl8153b_runtime_enable;
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v2 0/2] Save EEE
From: Hayes Wang @ 2019-08-23 7:04 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-304-Taiwan-albertk@realtek.com>
v2:
Adjust patch #1. The EEE has been disabled in the beginning of
r8153_hw_phy_cfg() and r8153b_hw_phy_cfg(), so only check if
it is necessary to enable EEE.
Add the patch #2 for the helper function.
v1:
Saving the settings of EEE to avoid they become the default settings
after reset_resume().
Hayes Wang (2):
r8152: saving the settings of EEE
r8152: add a helper function about setting EEE
drivers/net/usb/r8152.c | 182 +++++++++++++++++++++-------------------
1 file changed, 95 insertions(+), 87 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH net-next v3 0/2] r8152: save EEE
From: Hayes Wang @ 2019-08-23 7:18 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-304-Taiwan-albertk@realtek.com>
v3:
For patch #2, fix the mistake caused by copying and pasting.
v2:
Adjust patch #1. The EEE has been disabled in the beginning of
r8153_hw_phy_cfg() and r8153b_hw_phy_cfg(), so only check if
it is necessary to enable EEE.
Add the patch #2 for the helper function.
v1:
Saving the settings of EEE to avoid they become the default settings
after reset_resume().
Hayes Wang (2):
r8152: saving the settings of EEE
r8152: add a helper function about setting EEE
drivers/net/usb/r8152.c | 182 +++++++++++++++++++++-------------------
1 file changed, 95 insertions(+), 87 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH net-next v3 1/2] r8152: saving the settings of EEE
From: Hayes Wang @ 2019-08-23 7:19 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-308-Taiwan-albertk@realtek.com>
Saving the settings of EEE to avoid they become the default settings
after reset_resume().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 80 +++++++++++++++++++++++++----------------
1 file changed, 50 insertions(+), 30 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1aa61610f0bb..a7aa48bee732 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -751,6 +751,7 @@ struct r8152 {
atomic_t rx_count;
+ bool eee_en;
int intr_interval;
u32 saved_wolopts;
u32 msg_enable;
@@ -762,6 +763,7 @@ struct r8152 {
u16 ocp_base;
u16 speed;
+ u16 eee_adv;
u8 *intr_buff;
u8 version;
u8 duplex;
@@ -3202,8 +3204,13 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
static void r8152b_enable_eee(struct r8152 *tp)
{
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
}
static void r8152b_enable_fc(struct r8152 *tp)
@@ -3495,8 +3502,10 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3599,8 +3608,10 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_ups_flags_w1w0(tp, ups_flags, 0);
- r8153b_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153b_aldps_en(tp, true);
r8153b_enable_fc(tp);
@@ -4891,7 +4902,7 @@ static void rtl8152_get_strings(struct net_device *dev, u32 stringset, u8 *data)
static int r8152_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = r8152_mmd_read(tp, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
@@ -4903,13 +4914,10 @@ static int r8152_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
val = r8152_mmd_read(tp, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4919,19 +4927,22 @@ static int r8152_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8152_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8152_eee_en(tp, eee->eee_enabled);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ if (eee->eee_enabled)
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ else
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
return 0;
}
static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = ocp_reg_read(tp, OCP_EEE_ABLE);
@@ -4943,13 +4954,10 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
val = ocp_reg_read(tp, OCP_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4959,12 +4967,15 @@ static int r8153_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8153_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8153_eee_en(tp, eee->eee_enabled);
- ocp_reg_write(tp, OCP_EEE_ADV, val);
+ if (eee->eee_enabled)
+ ocp_reg_write(tp, OCP_EEE_ADV, val);
+ else
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
return 0;
}
@@ -4973,12 +4984,15 @@ static int r8153b_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8153b_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8153b_eee_en(tp, eee->eee_enabled);
- ocp_reg_write(tp, OCP_EEE_ADV, val);
+ if (eee->eee_enabled)
+ ocp_reg_write(tp, OCP_EEE_ADV, val);
+ else
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
return 0;
}
@@ -5353,6 +5367,8 @@ static int rtl_ops_init(struct r8152 *tp)
ops->hw_phy_cfg = r8152b_hw_phy_cfg;
ops->autosuspend_en = rtl_runtime_suspend_enable;
tp->rx_buf_sz = 16 * 1024;
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_100TX;
break;
case RTL_VER_03:
@@ -5371,6 +5387,8 @@ static int rtl_ops_init(struct r8152 *tp)
ops->hw_phy_cfg = r8153_hw_phy_cfg;
ops->autosuspend_en = rtl8153_runtime_enable;
tp->rx_buf_sz = 32 * 1024;
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
break;
case RTL_VER_08:
@@ -5387,6 +5405,8 @@ static int rtl_ops_init(struct r8152 *tp)
ops->hw_phy_cfg = r8153b_hw_phy_cfg;
ops->autosuspend_en = rtl8153b_runtime_enable;
tp->rx_buf_sz = 32 * 1024;
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
break;
default:
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 2/2] r8152: add a helper function about setting EEE
From: Hayes Wang @ 2019-08-23 7:19 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-308-Taiwan-albertk@realtek.com>
Add a helper funtion "rtl_eee_enable" for setting EEE. Besides, I
move r8153_eee_en() and r8153b_eee_en(). And, I remove r8152b_enable_eee(),
r8153_set_eee(), and r8153b_set_eee().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 166 +++++++++++++++++++---------------------
1 file changed, 77 insertions(+), 89 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a7aa48bee732..a003591c3078 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3202,14 +3202,75 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
ocp_reg_write(tp, OCP_EEE_CONFIG3, config3);
}
-static void r8152b_enable_eee(struct r8152 *tp)
+static void r8153_eee_en(struct r8152 *tp, bool enable)
{
- if (tp->eee_en) {
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ u32 ocp_data;
+ u16 config;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config = ocp_reg_read(tp, OCP_EEE_CFG);
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config |= EEE10_EN;
} else {
- r8152_eee_en(tp, false);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config &= ~EEE10_EN;
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CFG, config);
+}
+
+static void r8153b_eee_en(struct r8152 *tp, bool enable)
+{
+ r8153_eee_en(tp, enable);
+
+ if (enable)
+ r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
+ else
+ r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
+}
+
+static void rtl_eee_enable(struct r8152 *tp, bool enable)
+{
+ switch (tp->version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ case RTL_VER_07:
+ if (enable) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
+ tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_03:
+ case RTL_VER_04:
+ case RTL_VER_05:
+ case RTL_VER_06:
+ if (enable) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_08:
+ case RTL_VER_09:
+ if (enable) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153b_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ default:
+ break;
}
}
@@ -3231,7 +3292,7 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
- r8152b_enable_eee(tp);
+ rtl_eee_enable(tp, tp->eee_en);
r8152_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3425,36 +3486,6 @@ static void r8153b_aldps_en(struct r8152 *tp, bool enable)
r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_ALDPS);
}
-static void r8153_eee_en(struct r8152 *tp, bool enable)
-{
- u32 ocp_data;
- u16 config;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- config = ocp_reg_read(tp, OCP_EEE_CFG);
-
- if (enable) {
- ocp_data |= EEE_RX_EN | EEE_TX_EN;
- config |= EEE10_EN;
- } else {
- ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
- config &= ~EEE10_EN;
- }
-
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
- ocp_reg_write(tp, OCP_EEE_CFG, config);
-}
-
-static void r8153b_eee_en(struct r8152 *tp, bool enable)
-{
- r8153_eee_en(tp, enable);
-
- if (enable)
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
- else
- r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
-}
-
static void r8153b_enable_fc(struct r8152 *tp)
{
r8152b_enable_fc(tp);
@@ -3470,7 +3501,7 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8153_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
- r8153_eee_en(tp, false);
+ rtl_eee_enable(tp, false);
ocp_reg_write(tp, OCP_EEE_ADV, 0);
if (tp->version == RTL_VER_03) {
@@ -3502,10 +3533,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- if (tp->eee_en) {
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
- }
+ if (tp->eee_en)
+ rtl_eee_enable(tp, true);
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3545,7 +3574,7 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
- r8153b_eee_en(tp, false);
+ rtl_eee_enable(tp, false);
ocp_reg_write(tp, OCP_EEE_ADV, 0);
r8153b_green_en(tp, test_bit(GREEN_ETHERNET, &tp->flags));
@@ -3608,10 +3637,8 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_ups_flags_w1w0(tp, ups_flags, 0);
- if (tp->eee_en) {
- r8153b_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
- }
+ if (tp->eee_en)
+ rtl_eee_enable(tp, true);
r8153b_aldps_en(tp, true);
r8153b_enable_fc(tp);
@@ -4930,12 +4957,7 @@ static int r8152_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
tp->eee_en = eee->eee_enabled;
tp->eee_adv = val;
- r8152_eee_en(tp, eee->eee_enabled);
-
- if (eee->eee_enabled)
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
- else
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ rtl_eee_enable(tp, tp->eee_en);
return 0;
}
@@ -4963,40 +4985,6 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
return 0;
}
-static int r8153_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
-{
- u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
-
- tp->eee_en = eee->eee_enabled;
- tp->eee_adv = val;
-
- r8153_eee_en(tp, eee->eee_enabled);
-
- if (eee->eee_enabled)
- ocp_reg_write(tp, OCP_EEE_ADV, val);
- else
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
-
- return 0;
-}
-
-static int r8153b_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
-{
- u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
-
- tp->eee_en = eee->eee_enabled;
- tp->eee_adv = val;
-
- r8153b_eee_en(tp, eee->eee_enabled);
-
- if (eee->eee_enabled)
- ocp_reg_write(tp, OCP_EEE_ADV, val);
- else
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
-
- return 0;
-}
-
static int
rtl_ethtool_get_eee(struct net_device *net, struct ethtool_eee *edata)
{
@@ -5382,7 +5370,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->down = rtl8153_down;
ops->unload = rtl8153_unload;
ops->eee_get = r8153_get_eee;
- ops->eee_set = r8153_set_eee;
+ ops->eee_set = r8152_set_eee;
ops->in_nway = rtl8153_in_nway;
ops->hw_phy_cfg = r8153_hw_phy_cfg;
ops->autosuspend_en = rtl8153_runtime_enable;
@@ -5400,7 +5388,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->down = rtl8153b_down;
ops->unload = rtl8153b_unload;
ops->eee_get = r8153_get_eee;
- ops->eee_set = r8153b_set_eee;
+ ops->eee_set = r8152_set_eee;
ops->in_nway = rtl8153_in_nway;
ops->hw_phy_cfg = r8153b_hw_phy_cfg;
ops->autosuspend_en = rtl8153b_runtime_enable;
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v4 1/2] r8152: saving the settings of EEE
From: Hayes Wang @ 2019-08-23 7:33 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-311-Taiwan-albertk@realtek.com>
Saving the settings of EEE to avoid they become the default settings
after reset_resume().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 80 +++++++++++++++++++++++++----------------
1 file changed, 50 insertions(+), 30 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1aa61610f0bb..a7aa48bee732 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -751,6 +751,7 @@ struct r8152 {
atomic_t rx_count;
+ bool eee_en;
int intr_interval;
u32 saved_wolopts;
u32 msg_enable;
@@ -762,6 +763,7 @@ struct r8152 {
u16 ocp_base;
u16 speed;
+ u16 eee_adv;
u8 *intr_buff;
u8 version;
u8 duplex;
@@ -3202,8 +3204,13 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
static void r8152b_enable_eee(struct r8152 *tp)
{
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
}
static void r8152b_enable_fc(struct r8152 *tp)
@@ -3495,8 +3502,10 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3599,8 +3608,10 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_ups_flags_w1w0(tp, ups_flags, 0);
- r8153b_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153b_aldps_en(tp, true);
r8153b_enable_fc(tp);
@@ -4891,7 +4902,7 @@ static void rtl8152_get_strings(struct net_device *dev, u32 stringset, u8 *data)
static int r8152_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = r8152_mmd_read(tp, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
@@ -4903,13 +4914,10 @@ static int r8152_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
val = r8152_mmd_read(tp, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4919,19 +4927,22 @@ static int r8152_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8152_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8152_eee_en(tp, eee->eee_enabled);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ if (eee->eee_enabled)
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ else
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
return 0;
}
static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = ocp_reg_read(tp, OCP_EEE_ABLE);
@@ -4943,13 +4954,10 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
val = ocp_reg_read(tp, OCP_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4959,12 +4967,15 @@ static int r8153_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8153_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8153_eee_en(tp, eee->eee_enabled);
- ocp_reg_write(tp, OCP_EEE_ADV, val);
+ if (eee->eee_enabled)
+ ocp_reg_write(tp, OCP_EEE_ADV, val);
+ else
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
return 0;
}
@@ -4973,12 +4984,15 @@ static int r8153b_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8153b_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8153b_eee_en(tp, eee->eee_enabled);
- ocp_reg_write(tp, OCP_EEE_ADV, val);
+ if (eee->eee_enabled)
+ ocp_reg_write(tp, OCP_EEE_ADV, val);
+ else
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
return 0;
}
@@ -5353,6 +5367,8 @@ static int rtl_ops_init(struct r8152 *tp)
ops->hw_phy_cfg = r8152b_hw_phy_cfg;
ops->autosuspend_en = rtl_runtime_suspend_enable;
tp->rx_buf_sz = 16 * 1024;
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_100TX;
break;
case RTL_VER_03:
@@ -5371,6 +5387,8 @@ static int rtl_ops_init(struct r8152 *tp)
ops->hw_phy_cfg = r8153_hw_phy_cfg;
ops->autosuspend_en = rtl8153_runtime_enable;
tp->rx_buf_sz = 32 * 1024;
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
break;
case RTL_VER_08:
@@ -5387,6 +5405,8 @@ static int rtl_ops_init(struct r8152 *tp)
ops->hw_phy_cfg = r8153b_hw_phy_cfg;
ops->autosuspend_en = rtl8153b_runtime_enable;
tp->rx_buf_sz = 32 * 1024;
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
break;
default:
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v4 2/2] r8152: add a helper function about setting EEE
From: Hayes Wang @ 2019-08-23 7:33 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-311-Taiwan-albertk@realtek.com>
Add a helper function "rtl_eee_enable" for setting EEE. Besides, I
move r8153_eee_en() and r8153b_eee_en(). And, I remove r8152b_enable_eee(),
r8153_set_eee(), and r8153b_set_eee().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 168 ++++++++++++++++++----------------------
1 file changed, 77 insertions(+), 91 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a7aa48bee732..17f0e9e98697 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3202,14 +3202,75 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
ocp_reg_write(tp, OCP_EEE_CONFIG3, config3);
}
-static void r8152b_enable_eee(struct r8152 *tp)
+static void r8153_eee_en(struct r8152 *tp, bool enable)
{
- if (tp->eee_en) {
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ u32 ocp_data;
+ u16 config;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config = ocp_reg_read(tp, OCP_EEE_CFG);
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config |= EEE10_EN;
} else {
- r8152_eee_en(tp, false);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config &= ~EEE10_EN;
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CFG, config);
+}
+
+static void r8153b_eee_en(struct r8152 *tp, bool enable)
+{
+ r8153_eee_en(tp, enable);
+
+ if (enable)
+ r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
+ else
+ r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
+}
+
+static void rtl_eee_enable(struct r8152 *tp, bool enable)
+{
+ switch (tp->version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ case RTL_VER_07:
+ if (enable) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
+ tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_03:
+ case RTL_VER_04:
+ case RTL_VER_05:
+ case RTL_VER_06:
+ if (enable) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_08:
+ case RTL_VER_09:
+ if (enable) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153b_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ default:
+ break;
}
}
@@ -3231,7 +3292,7 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
- r8152b_enable_eee(tp);
+ rtl_eee_enable(tp, tp->eee_en);
r8152_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3425,36 +3486,6 @@ static void r8153b_aldps_en(struct r8152 *tp, bool enable)
r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_ALDPS);
}
-static void r8153_eee_en(struct r8152 *tp, bool enable)
-{
- u32 ocp_data;
- u16 config;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- config = ocp_reg_read(tp, OCP_EEE_CFG);
-
- if (enable) {
- ocp_data |= EEE_RX_EN | EEE_TX_EN;
- config |= EEE10_EN;
- } else {
- ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
- config &= ~EEE10_EN;
- }
-
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
- ocp_reg_write(tp, OCP_EEE_CFG, config);
-}
-
-static void r8153b_eee_en(struct r8152 *tp, bool enable)
-{
- r8153_eee_en(tp, enable);
-
- if (enable)
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
- else
- r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
-}
-
static void r8153b_enable_fc(struct r8152 *tp)
{
r8152b_enable_fc(tp);
@@ -3470,8 +3501,7 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8153_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
- r8153_eee_en(tp, false);
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ rtl_eee_enable(tp, false);
if (tp->version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
@@ -3502,10 +3532,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- if (tp->eee_en) {
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
- }
+ if (tp->eee_en)
+ rtl_eee_enable(tp, true);
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3545,8 +3573,7 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
- r8153b_eee_en(tp, false);
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ rtl_eee_enable(tp, false);
r8153b_green_en(tp, test_bit(GREEN_ETHERNET, &tp->flags));
@@ -3608,10 +3635,8 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_ups_flags_w1w0(tp, ups_flags, 0);
- if (tp->eee_en) {
- r8153b_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
- }
+ if (tp->eee_en)
+ rtl_eee_enable(tp, true);
r8153b_aldps_en(tp, true);
r8153b_enable_fc(tp);
@@ -4930,12 +4955,7 @@ static int r8152_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
tp->eee_en = eee->eee_enabled;
tp->eee_adv = val;
- r8152_eee_en(tp, eee->eee_enabled);
-
- if (eee->eee_enabled)
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
- else
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ rtl_eee_enable(tp, tp->eee_en);
return 0;
}
@@ -4963,40 +4983,6 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
return 0;
}
-static int r8153_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
-{
- u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
-
- tp->eee_en = eee->eee_enabled;
- tp->eee_adv = val;
-
- r8153_eee_en(tp, eee->eee_enabled);
-
- if (eee->eee_enabled)
- ocp_reg_write(tp, OCP_EEE_ADV, val);
- else
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
-
- return 0;
-}
-
-static int r8153b_set_eee(struct r8152 *tp, struct ethtool_eee *eee)
-{
- u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
-
- tp->eee_en = eee->eee_enabled;
- tp->eee_adv = val;
-
- r8153b_eee_en(tp, eee->eee_enabled);
-
- if (eee->eee_enabled)
- ocp_reg_write(tp, OCP_EEE_ADV, val);
- else
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
-
- return 0;
-}
-
static int
rtl_ethtool_get_eee(struct net_device *net, struct ethtool_eee *edata)
{
@@ -5382,7 +5368,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->down = rtl8153_down;
ops->unload = rtl8153_unload;
ops->eee_get = r8153_get_eee;
- ops->eee_set = r8153_set_eee;
+ ops->eee_set = r8152_set_eee;
ops->in_nway = rtl8153_in_nway;
ops->hw_phy_cfg = r8153_hw_phy_cfg;
ops->autosuspend_en = rtl8153_runtime_enable;
@@ -5400,7 +5386,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->down = rtl8153b_down;
ops->unload = rtl8153b_unload;
ops->eee_get = r8153_get_eee;
- ops->eee_set = r8153b_set_eee;
+ ops->eee_set = r8152_set_eee;
ops->in_nway = rtl8153_in_nway;
ops->hw_phy_cfg = r8153b_hw_phy_cfg;
ops->autosuspend_en = rtl8153b_runtime_enable;
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v4 0/2] r8152: save EEE
From: Hayes Wang @ 2019-08-23 7:33 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-304-Taiwan-albertk@realtek.com>
v4:
For patch #2, remove redundant calling of "ocp_reg_write(tp, OCP_EEE_ADV, 0)".
v3:
For patch #2, fix the mistake caused by copying and pasting.
v2:
Adjust patch #1. The EEE has been disabled in the beginning of
r8153_hw_phy_cfg() and r8153b_hw_phy_cfg(), so only check if
it is necessary to enable EEE.
Add the patch #2 for the helper function.
v1:
Saving the settings of EEE to avoid they become the default settings
after reset_resume().
Hayes Wang (2):
r8152: saving the settings of EEE
r8152: add a helper function about setting EEE
drivers/net/usb/r8152.c | 182 +++++++++++++++++++++-------------------
1 file changed, 95 insertions(+), 87 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH] brcmfmac: replace strncpy() by strscpy()
From: Xulin Sun @ 2019-08-23 7:47 UTC (permalink / raw)
To: kvalo
Cc: stefan.wahren, xulin.sun, linux-kernel, netdev,
brcm80211-dev-list, brcm80211-dev-list.pdl, linux-wireless,
arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, davem, stanley.hsu
The strncpy() may truncate the copied string,
replace it by the safer strscpy().
To avoid below compile warning with gcc 8.2:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:In function 'brcmf_vndr_ie':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4227:2:
warning: 'strncpy' output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation]
strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Xulin Sun <xulin.sun@windriver.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b6d0df354b36..7ad60374fa96 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4226,9 +4226,7 @@ brcmf_parse_vndr_ies(const u8 *vndr_ie_buf, u32 vndr_ie_len,
static u32
brcmf_vndr_ie(u8 *iebuf, s32 pktflag, u8 *ie_ptr, u32 ie_len, s8 *add_del_cmd)
{
-
- strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
- iebuf[VNDR_IE_CMD_LEN - 1] = '\0';
+ strscpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN);
put_unaligned_le32(1, &iebuf[VNDR_IE_COUNT_OFFSET]);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
From: Jiri Pirko @ 2019-08-23 8:12 UTC (permalink / raw)
To: Parav Pandit
Cc: Alex Williamson, Jiri Pirko, David S . Miller, Kirti Wankhede,
Cornelia Huck, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
cjia, netdev@vger.kernel.org
In-Reply-To: <AM0PR05MB4866F9650CF73FC671972127D1A50@AM0PR05MB4866.eurprd05.prod.outlook.com>
Thu, Aug 22, 2019 at 03:33:30PM CEST, parav@mellanox.com wrote:
>
>
>> -----Original Message-----
>> From: Jiri Pirko <jiri@resnulli.us>
>> Sent: Thursday, August 22, 2019 5:50 PM
>> To: Parav Pandit <parav@mellanox.com>
>> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
>> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
>> Wankhede <kwankhede@nvidia.com>; Cornelia Huck <cohuck@redhat.com>;
>> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia <cjia@nvidia.com>;
>> netdev@vger.kernel.org
>> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>>
>> Thu, Aug 22, 2019 at 12:04:02PM CEST, parav@mellanox.com wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Jiri Pirko <jiri@resnulli.us>
>> >> Sent: Thursday, August 22, 2019 3:28 PM
>> >> To: Parav Pandit <parav@mellanox.com>
>> >> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
>> >> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
>> >> Wankhede <kwankhede@nvidia.com>; Cornelia Huck
>> <cohuck@redhat.com>;
>> >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
>> >> <cjia@nvidia.com>; netdev@vger.kernel.org
>> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> >>
>> >> Thu, Aug 22, 2019 at 11:42:13AM CEST, parav@mellanox.com wrote:
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Jiri Pirko <jiri@resnulli.us>
>> >> >> Sent: Thursday, August 22, 2019 2:59 PM
>> >> >> To: Parav Pandit <parav@mellanox.com>
>> >> >> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
>> >> >> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
>> >> >> Wankhede <kwankhede@nvidia.com>; Cornelia Huck
>> >> <cohuck@redhat.com>;
>> >> >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
>> >> >> <cjia@nvidia.com>; netdev@vger.kernel.org
>> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> >> >>
>> >> >> Wed, Aug 21, 2019 at 08:23:17AM CEST, parav@mellanox.com wrote:
>> >> >> >
>> >> >> >
>> >> >> >> -----Original Message-----
>> >> >> >> From: Alex Williamson <alex.williamson@redhat.com>
>> >> >> >> Sent: Wednesday, August 21, 2019 10:56 AM
>> >> >> >> To: Parav Pandit <parav@mellanox.com>
>> >> >> >> Cc: Jiri Pirko <jiri@mellanox.com>; David S . Miller
>> >> >> >> <davem@davemloft.net>; Kirti Wankhede <kwankhede@nvidia.com>;
>> >> >> >> Cornelia Huck <cohuck@redhat.com>; kvm@vger.kernel.org;
>> >> >> >> linux-kernel@vger.kernel.org; cjia <cjia@nvidia.com>;
>> >> >> >> netdev@vger.kernel.org
>> >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> >> >> >>
>> >> >> >> > > > > Just an example of the alias, not proposing how it's set.
>> >> >> >> > > > > In fact, proposing that the user does not set it,
>> >> >> >> > > > > mdev-core provides one
>> >> >> >> > > automatically.
>> >> >> >> > > > >
>> >> >> >> > > > > > > Since there seems to be some prefix overhead, as I
>> >> >> >> > > > > > > ask about above in how many characters we actually
>> >> >> >> > > > > > > have to work with in IFNAMESZ, maybe we start with
>> >> >> >> > > > > > > 8 characters (matching your "index" namespace) and
>> >> >> >> > > > > > > expand as necessary for
>> >> >> disambiguation.
>> >> >> >> > > > > > > If we can eliminate overhead in IFNAMESZ, let's start with
>> 12.
>> >> >> >> > > > > > > Thanks,
>> >> >> >> > > > > > >
>> >> >> >> > > > > > If user is going to choose the alias, why does it
>> >> >> >> > > > > > have to be limited to
>> >> >> >> sha1?
>> >> >> >> > > > > > Or you just told it as an example?
>> >> >> >> > > > > >
>> >> >> >> > > > > > It can be an alpha-numeric string.
>> >> >> >> > > > >
>> >> >> >> > > > > No, I'm proposing a different solution where mdev-core
>> >> >> >> > > > > creates an alias based on an abbreviated sha1. The
>> >> >> >> > > > > user does not provide the
>> >> >> >> alias.
>> >> >> >> > > > >
>> >> >> >> > > > > > Instead of mdev imposing number of characters on the
>> >> >> >> > > > > > alias, it should be best
>> >> >> >> > > > > left to the user.
>> >> >> >> > > > > > Because in future if netdev improves on the naming
>> >> >> >> > > > > > scheme, mdev will be
>> >> >> >> > > > > limiting it, which is not right.
>> >> >> >> > > > > > So not restricting alias size seems right to me.
>> >> >> >> > > > > > User configuring mdev for networking devices in a
>> >> >> >> > > > > > given kernel knows what
>> >> >> >> > > > > user is doing.
>> >> >> >> > > > > > So user can choose alias name size as it finds suitable.
>> >> >> >> > > > >
>> >> >> >> > > > > That's not what I'm proposing, please read again.
>> >> >> >> > > > > Thanks,
>> >> >> >> > > >
>> >> >> >> > > > I understood your point. But mdev doesn't know how user
>> >> >> >> > > > is going to use
>> >> >> >> > > udev/systemd to name the netdev.
>> >> >> >> > > > So even if mdev chose to pick 12 characters, it could
>> >> >> >> > > > result in
>> >> collision.
>> >> >> >> > > > Hence the proposal to provide the alias by the user, as
>> >> >> >> > > > user know the best
>> >> >> >> > > policy for its use case in the environment its using.
>> >> >> >> > > > So 12 character sha1 method will still work by user.
>> >> >> >> > >
>> >> >> >> > > Haven't you already provided examples where certain drivers
>> >> >> >> > > or subsystems have unique netdev prefixes? If mdev
>> >> >> >> > > provides a unique alias within the subsystem, couldn't we
>> >> >> >> > > simply define a netdev prefix for the mdev subsystem and
>> >> >> >> > > avoid all other collisions? I'm not in favor of the user
>> >> >> >> > > providing both a uuid and an alias/instance. Thanks,
>> >> >> >> > >
>> >> >> >> > For a given prefix, say ens2f0, can two UUID->sha1 first 9
>> >> >> >> > characters have
>> >> >> >> collision?
>> >> >> >>
>> >> >> >> I think it would be a mistake to waste so many chars on a
>> >> >> >> prefix, but
>> >> >> >> 9 characters of sha1 likely wouldn't have a collision before we
>> >> >> >> have 10s of thousands of devices. Thanks,
>> >> >> >>
>> >> >> >> Alex
>> >> >> >
>> >> >> >Jiri, Dave,
>> >> >> >Are you ok with it for devlink/netdev part?
>> >> >> >Mdev core will create an alias from a UUID.
>> >> >> >
>> >> >> >This will be supplied during devlink port attr set such as,
>> >> >> >
>> >> >> >devlink_port_attrs_mdev_set(struct devlink_port *port, const char
>> >> >> >*mdev_alias);
>> >> >> >
>> >> >> >This alias is used to generate representor netdev's phys_port_name.
>> >> >> >This alias from the mdev device's sysfs will be used by the
>> >> >> >udev/systemd to
>> >> >> generate predicable netdev's name.
>> >> >> >Example: enm<mdev_alias_first_12_chars>
>> >> >>
>> >> >> What happens in unlikely case of 2 UUIDs collide?
>> >> >>
>> >> >Since users sees two devices with same phys_port_name, user should
>> >> >destroy
>> >> recently created mdev and recreate mdev with different UUID?
>> >>
>> >> Driver should make sure phys port name wont collide,
>> >So when mdev creation is initiated, mdev core calculates the alias and if there
>> is any other mdev with same alias exist, it returns -EEXIST error before
>> progressing further.
>> >This way user will get to know upfront in event of collision before the mdev
>> device gets created.
>> >How about that?
>>
>> Sounds fine to me. Now the question is how many chars do we want to have.
>>
>12 characters from Alex's suggestion similar to git?
Ok.
>
>> >
>> >
>> >> in this case that it does
>> >> not provide 2 same attrs for 2 different ports.
>> >> Hmm, so the order of creation matters. That is not good.
>> >>
>> >> >>
>> >> >> >I took Ethernet mdev as an example.
>> >> >> >New prefix 'm' stands for mediated device.
>> >> >> >Remaining 12 characters are first 12 chars of the mdev alias.
>> >> >>
>> >> >> Does this resolve the identification of devlink port representor?
>> >> >Not sure if I understood your question correctly, attemping to answer
>> below.
>> >> >phys_port_name of devlink port is defined by the first 12 characters
>> >> >of mdev
>> >> alias.
>> >> >> I assume you want to use the same 12(or so) chars, don't you?
>> >> >Mdev's netdev will also use the same mdev alias from the sysfs to
>> >> >rename
>> >> netdev name from ethX to enm<mdev_alias>, where en=Etherenet,
>> m=mdev.
>> >> >
>> >> >So yes, same 12 characters are use for mdev's netdev and mdev
>> >> >devlink port's
>> >> phys_port_name.
>> >> >
>> >> >Is that what are you asking?
>> >>
>> >> Yes. Then you have 3 chars to handle the rest of the name (pci, pf)...
^ permalink raw reply
* RE: [PATCH v2 0/2] Simplify mtty driver and mdev core
From: Parav Pandit @ 2019-08-23 8:14 UTC (permalink / raw)
To: Jiri Pirko
Cc: Alex Williamson, Jiri Pirko, David S . Miller, Kirti Wankhede,
Cornelia Huck, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
cjia, netdev@vger.kernel.org
In-Reply-To: <20190823081221.GG2276@nanopsycho.orion>
Hi Alex,
> -----Original Message-----
> From: Jiri Pirko <jiri@resnulli.us>
> Sent: Friday, August 23, 2019 1:42 PM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
> Wankhede <kwankhede@nvidia.com>; Cornelia Huck <cohuck@redhat.com>;
> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia <cjia@nvidia.com>;
> netdev@vger.kernel.org
> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>
> Thu, Aug 22, 2019 at 03:33:30PM CEST, parav@mellanox.com wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jiri Pirko <jiri@resnulli.us>
> >> Sent: Thursday, August 22, 2019 5:50 PM
> >> To: Parav Pandit <parav@mellanox.com>
> >> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
> >> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
> >> Wankhede <kwankhede@nvidia.com>; Cornelia Huck
> <cohuck@redhat.com>;
> >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> >> <cjia@nvidia.com>; netdev@vger.kernel.org
> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> >>
> >> Thu, Aug 22, 2019 at 12:04:02PM CEST, parav@mellanox.com wrote:
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: Jiri Pirko <jiri@resnulli.us>
> >> >> Sent: Thursday, August 22, 2019 3:28 PM
> >> >> To: Parav Pandit <parav@mellanox.com>
> >> >> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
> >> >> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
> >> >> Wankhede <kwankhede@nvidia.com>; Cornelia Huck
> >> <cohuck@redhat.com>;
> >> >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> >> >> <cjia@nvidia.com>; netdev@vger.kernel.org
> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> >> >>
> >> >> Thu, Aug 22, 2019 at 11:42:13AM CEST, parav@mellanox.com wrote:
> >> >> >
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: Jiri Pirko <jiri@resnulli.us>
> >> >> >> Sent: Thursday, August 22, 2019 2:59 PM
> >> >> >> To: Parav Pandit <parav@mellanox.com>
> >> >> >> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
> >> >> >> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>;
> >> >> >> Kirti Wankhede <kwankhede@nvidia.com>; Cornelia Huck
> >> >> <cohuck@redhat.com>;
> >> >> >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> >> >> >> <cjia@nvidia.com>; netdev@vger.kernel.org
> >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> >> >> >>
> >> >> >> Wed, Aug 21, 2019 at 08:23:17AM CEST, parav@mellanox.com wrote:
> >> >> >> >
> >> >> >> >
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: Alex Williamson <alex.williamson@redhat.com>
> >> >> >> >> Sent: Wednesday, August 21, 2019 10:56 AM
> >> >> >> >> To: Parav Pandit <parav@mellanox.com>
> >> >> >> >> Cc: Jiri Pirko <jiri@mellanox.com>; David S . Miller
> >> >> >> >> <davem@davemloft.net>; Kirti Wankhede
> >> >> >> >> <kwankhede@nvidia.com>; Cornelia Huck <cohuck@redhat.com>;
> >> >> >> >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> >> >> >> >> <cjia@nvidia.com>; netdev@vger.kernel.org
> >> >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev
> >> >> >> >> core
> >> >> >> >>
> >> >> >> >> > > > > Just an example of the alias, not proposing how it's set.
> >> >> >> >> > > > > In fact, proposing that the user does not set it,
> >> >> >> >> > > > > mdev-core provides one
> >> >> >> >> > > automatically.
> >> >> >> >> > > > >
> >> >> >> >> > > > > > > Since there seems to be some prefix overhead, as
> >> >> >> >> > > > > > > I ask about above in how many characters we
> >> >> >> >> > > > > > > actually have to work with in IFNAMESZ, maybe we
> >> >> >> >> > > > > > > start with
> >> >> >> >> > > > > > > 8 characters (matching your "index" namespace)
> >> >> >> >> > > > > > > and expand as necessary for
> >> >> >> disambiguation.
> >> >> >> >> > > > > > > If we can eliminate overhead in IFNAMESZ, let's
> >> >> >> >> > > > > > > start with
> >> 12.
> >> >> >> >> > > > > > > Thanks,
> >> >> >> >> > > > > > >
> >> >> >> >> > > > > > If user is going to choose the alias, why does it
> >> >> >> >> > > > > > have to be limited to
> >> >> >> >> sha1?
> >> >> >> >> > > > > > Or you just told it as an example?
> >> >> >> >> > > > > >
> >> >> >> >> > > > > > It can be an alpha-numeric string.
> >> >> >> >> > > > >
> >> >> >> >> > > > > No, I'm proposing a different solution where
> >> >> >> >> > > > > mdev-core creates an alias based on an abbreviated
> >> >> >> >> > > > > sha1. The user does not provide the
> >> >> >> >> alias.
> >> >> >> >> > > > >
> >> >> >> >> > > > > > Instead of mdev imposing number of characters on
> >> >> >> >> > > > > > the alias, it should be best
> >> >> >> >> > > > > left to the user.
> >> >> >> >> > > > > > Because in future if netdev improves on the naming
> >> >> >> >> > > > > > scheme, mdev will be
> >> >> >> >> > > > > limiting it, which is not right.
> >> >> >> >> > > > > > So not restricting alias size seems right to me.
> >> >> >> >> > > > > > User configuring mdev for networking devices in a
> >> >> >> >> > > > > > given kernel knows what
> >> >> >> >> > > > > user is doing.
> >> >> >> >> > > > > > So user can choose alias name size as it finds suitable.
> >> >> >> >> > > > >
> >> >> >> >> > > > > That's not what I'm proposing, please read again.
> >> >> >> >> > > > > Thanks,
> >> >> >> >> > > >
> >> >> >> >> > > > I understood your point. But mdev doesn't know how
> >> >> >> >> > > > user is going to use
> >> >> >> >> > > udev/systemd to name the netdev.
> >> >> >> >> > > > So even if mdev chose to pick 12 characters, it could
> >> >> >> >> > > > result in
> >> >> collision.
> >> >> >> >> > > > Hence the proposal to provide the alias by the user,
> >> >> >> >> > > > as user know the best
> >> >> >> >> > > policy for its use case in the environment its using.
> >> >> >> >> > > > So 12 character sha1 method will still work by user.
> >> >> >> >> > >
> >> >> >> >> > > Haven't you already provided examples where certain
> >> >> >> >> > > drivers or subsystems have unique netdev prefixes? If
> >> >> >> >> > > mdev provides a unique alias within the subsystem,
> >> >> >> >> > > couldn't we simply define a netdev prefix for the mdev
> >> >> >> >> > > subsystem and avoid all other collisions? I'm not in
> >> >> >> >> > > favor of the user providing both a uuid and an
> >> >> >> >> > > alias/instance. Thanks,
> >> >> >> >> > >
> >> >> >> >> > For a given prefix, say ens2f0, can two UUID->sha1 first 9
> >> >> >> >> > characters have
> >> >> >> >> collision?
> >> >> >> >>
> >> >> >> >> I think it would be a mistake to waste so many chars on a
> >> >> >> >> prefix, but
> >> >> >> >> 9 characters of sha1 likely wouldn't have a collision before
> >> >> >> >> we have 10s of thousands of devices. Thanks,
> >> >> >> >>
> >> >> >> >> Alex
> >> >> >> >
> >> >> >> >Jiri, Dave,
> >> >> >> >Are you ok with it for devlink/netdev part?
> >> >> >> >Mdev core will create an alias from a UUID.
> >> >> >> >
> >> >> >> >This will be supplied during devlink port attr set such as,
> >> >> >> >
> >> >> >> >devlink_port_attrs_mdev_set(struct devlink_port *port, const
> >> >> >> >char *mdev_alias);
> >> >> >> >
> >> >> >> >This alias is used to generate representor netdev's phys_port_name.
> >> >> >> >This alias from the mdev device's sysfs will be used by the
> >> >> >> >udev/systemd to
> >> >> >> generate predicable netdev's name.
> >> >> >> >Example: enm<mdev_alias_first_12_chars>
> >> >> >>
> >> >> >> What happens in unlikely case of 2 UUIDs collide?
> >> >> >>
> >> >> >Since users sees two devices with same phys_port_name, user
> >> >> >should destroy
> >> >> recently created mdev and recreate mdev with different UUID?
> >> >>
> >> >> Driver should make sure phys port name wont collide,
> >> >So when mdev creation is initiated, mdev core calculates the alias
> >> >and if there
> >> is any other mdev with same alias exist, it returns -EEXIST error
> >> before progressing further.
> >> >This way user will get to know upfront in event of collision before
> >> >the mdev
> >> device gets created.
> >> >How about that?
> >>
> >> Sounds fine to me. Now the question is how many chars do we want to have.
> >>
> >12 characters from Alex's suggestion similar to git?
>
> Ok.
>
Can you please confirm this scheme looks good now? I like to get patches started.
> >
> >> >
> >> >
> >> >> in this case that it does
> >> >> not provide 2 same attrs for 2 different ports.
> >> >> Hmm, so the order of creation matters. That is not good.
> >> >>
> >> >> >>
> >> >> >> >I took Ethernet mdev as an example.
> >> >> >> >New prefix 'm' stands for mediated device.
> >> >> >> >Remaining 12 characters are first 12 chars of the mdev alias.
> >> >> >>
> >> >> >> Does this resolve the identification of devlink port representor?
> >> >> >Not sure if I understood your question correctly, attemping to
> >> >> >answer
> >> below.
> >> >> >phys_port_name of devlink port is defined by the first 12
> >> >> >characters of mdev
> >> >> alias.
> >> >> >> I assume you want to use the same 12(or so) chars, don't you?
> >> >> >Mdev's netdev will also use the same mdev alias from the sysfs to
> >> >> >rename
> >> >> netdev name from ethX to enm<mdev_alias>, where en=Etherenet,
> >> m=mdev.
> >> >> >
> >> >> >So yes, same 12 characters are use for mdev's netdev and mdev
> >> >> >devlink port's
> >> >> phys_port_name.
> >> >> >
> >> >> >Is that what are you asking?
> >> >>
> >> >> Yes. Then you have 3 chars to handle the rest of the name (pci, pf)...
^ permalink raw reply
* Re: [PATCH] brcmfmac: replace strncpy() by strscpy()
From: Arend Van Spriel @ 2019-08-23 8:18 UTC (permalink / raw)
To: Xulin Sun, kvalo
Cc: stefan.wahren, linux-kernel, netdev, brcm80211-dev-list,
brcm80211-dev-list.pdl, linux-wireless, franky.lin,
hante.meuleman, chi-hsien.lin, wright.feng, davem, stanley.hsu
In-Reply-To: <20190823074708.20081-1-xulin.sun@windriver.com>
On 8/23/2019 9:47 AM, Xulin Sun wrote:
> The strncpy() may truncate the copied string,
> replace it by the safer strscpy().
>
> To avoid below compile warning with gcc 8.2:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:In function 'brcmf_vndr_ie':
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4227:2:
> warning: 'strncpy' output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation]
> strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Xulin Sun <xulin.sun@windriver.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH net 0/9] rxrpc: Fix use of skb_cow_data()
From: David Howells @ 2019-08-23 8:52 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, netdev, linux-afs, linux-kernel
In-Reply-To: <20190822.121207.731320146177703787.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> Why don't you just do an skb_unshare() at the beginning when you know that
> you'll need to do that?
I was trying to defer any copying to process context rather than doing it in
softirq context to spend less time in softirq context - plus that way I can
use GFP_NOIO (kafs) or GFP_KERNEL (direct AF_RXRPC socket) rather than
GFP_ATOMIC if the api supports it.
I don't remember now why I used skb_cow_data() rather than skb_unshare() - but
it was probably because the former leaves the sk_buff object itself intact,
whereas the latter replaces it. I can switch to using skb_unshare() instead.
Question for you: how likely is a newly received buffer, through a UDP socket,
to be 'cloned'?
David
^ permalink raw reply
* [PATCH] wimax/i2400m: fix calculation of index, remove sizeof
From: Colin King @ 2019-08-23 8:52 UTC (permalink / raw)
To: Inaky Perez-Gonzalez, linux-wimax, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The subtraction of the two pointers is automatically scaled by the
size of the size of the object the pointers point to, so the division
by sizeof(*i2400m->barker) is incorrect. Fix this by removing the
division. Also make index an unsigned int to clean up a checkpatch
warning.
Addresses-Coverity: ("Extra sizeof expression")
Fixes: aba3792ac2d7 ("wimax/i2400m: rework bootrom initialization to be more flexible")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wimax/i2400m/fw.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wimax/i2400m/fw.c b/drivers/net/wimax/i2400m/fw.c
index 489cba9b284d..599a703af6eb 100644
--- a/drivers/net/wimax/i2400m/fw.c
+++ b/drivers/net/wimax/i2400m/fw.c
@@ -399,8 +399,7 @@ int i2400m_is_boot_barker(struct i2400m *i2400m,
* associated with the device. */
if (i2400m->barker
&& !memcmp(buf, i2400m->barker, sizeof(i2400m->barker->data))) {
- unsigned index = (i2400m->barker - i2400m_barker_db)
- / sizeof(*i2400m->barker);
+ unsigned int index = i2400m->barker - i2400m_barker_db;
d_printf(2, dev, "boot barker cache-confirmed #%u/%08x\n",
index, le32_to_cpu(i2400m->barker->data[0]));
return 0;
--
2.20.1
^ permalink raw reply related
* [PATCH net 0/2] r8152: fix side effect
From: Hayes Wang @ 2019-08-23 8:53 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, jslaby, Hayes Wang
The commit 0ee1f4734967 ("r8152: napi hangup fix after disconnect")
add a check to avoid using napi_disable after netif_napi_del. However,
the commit ffa9fec30ca0 ("r8152: set RTL8152_UNPLUG only for real
disconnection") let the check useless.
Therefore, I revert commit 0ee1f4734967 ("r8152: napi hangup fix
after disconnect") first, and add another patch to fix it.
Hayes Wang (2):
Revert "r8152: napi hangup fix after disconnect"
r8152: avoid using napi_disable after netif_napi_del.
drivers/net/usb/r8152.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH net 1/2] Revert "r8152: napi hangup fix after disconnect"
From: Hayes Wang @ 2019-08-23 8:53 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, jslaby, Hayes Wang
In-Reply-To: <1394712342-15778-314-Taiwan-albertk@realtek.com>
This reverts commit 0ee1f4734967af8321ecebaf9c74221ace34f2d5.
This conflicts with commit ffa9fec30ca0 ("r8152: set
RTL8152_UNPLUG only for real disconnection").
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0cc03a9ff545..690a24d1ef82 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4018,8 +4018,7 @@ static int rtl8152_close(struct net_device *netdev)
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(&tp->pm_notifier);
#endif
- if (!test_bit(RTL8152_UNPLUG, &tp->flags))
- napi_disable(&tp->napi);
+ napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
--
2.21.0
^ permalink raw reply related
* [PATCH net 2/2] r8152: avoid using napi_disable after netif_napi_del.
From: Hayes Wang @ 2019-08-23 8:53 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, jslaby, Hayes Wang
In-Reply-To: <1394712342-15778-314-Taiwan-albertk@realtek.com>
Exchange netif_napi_del() and unregister_netdev() in rtl8152_disconnect()
to avoid using napi_disable() after netif_napi_del().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 690a24d1ef82..29390eda5251 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -5364,8 +5364,8 @@ static void rtl8152_disconnect(struct usb_interface *intf)
if (tp) {
rtl_set_unplug(tp);
- netif_napi_del(&tp->napi);
unregister_netdev(tp->netdev);
+ netif_napi_del(&tp->napi);
cancel_delayed_work_sync(&tp->hw_phy_work);
tp->rtl_ops.unload(tp);
free_netdev(tp->netdev);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v6 4/7] nfc: pn533: Split pn533 init & nfc_register
From: Lars Poeschel @ 2019-08-23 9:07 UTC (permalink / raw)
To: Claudiu.Beznea
Cc: gregkh, allison, swinslow, tglx, kstewart, gustavo, keescook,
opensource, netdev, linux-kernel, johan
In-Reply-To: <67dbe5a1-35e7-0ac9-efbc-6425b3628b18@microchip.com>
On Thu, Aug 22, 2019 at 10:08:40AM +0000, Claudiu.Beznea@microchip.com wrote:
>
>
> On 20.08.2019 15:03, Lars Poeschel wrote:
> > There is a problem in the initialisation and setup of the pn533: It
> > registers with nfc too early. It could happen, that it finished
> > registering with nfc and someone starts using it. But setup of the pn533
> > is not yet finished. Bad or at least unintended things could happen.
> > So I split out nfc registering (and unregistering) to seperate functions
> > that have to be called late in probe then.
> >
> > Cc: Johan Hovold <johan@kernel.org>
> > Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
> > ---
> > Changes in v6:
> > - Rebased the patch series on v5.3-rc5
> >
> > Changes in v5:
> > - This patch is new in v5
> >
> > drivers/nfc/pn533/i2c.c | 17 +++++-----
> > drivers/nfc/pn533/pn533.c | 66 ++++++++++++++++++++-------------------
> > drivers/nfc/pn533/pn533.h | 11 ++++---
> > drivers/nfc/pn533/usb.c | 12 +++++--
> > 4 files changed, 59 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> > index 1abd40398a5a..e9e5a1ec8857 100644
> > --- a/drivers/nfc/pn533/i2c.c
> > +++ b/drivers/nfc/pn533/i2c.c
> > @@ -193,12 +193,10 @@ static int pn533_i2c_probe(struct i2c_client *client,
> > phy->i2c_dev = client;
> > i2c_set_clientdata(client, phy);
> >
> > - priv = pn533_register_device(PN533_DEVICE_PN532,
> > - PN533_NO_TYPE_B_PROTOCOLS,
> > + priv = pn53x_common_init(PN533_DEVICE_PN532,
> > PN533_PROTO_REQ_ACK_RESP,
> > phy, &i2c_phy_ops, NULL,
> > - &phy->i2c_dev->dev,
> > - &client->dev);
> > + &phy->i2c_dev->dev);
> >
> > if (IS_ERR(priv)) {
> > r = PTR_ERR(priv);
> > @@ -220,13 +218,17 @@ static int pn533_i2c_probe(struct i2c_client *client,
> > if (r)
> > goto fn_setup_err;
> >
> > - return 0;
> > + r = pn53x_register_nfc(priv, PN533_NO_TYPE_B_PROTOCOLS, &client->dev);
> > + if (r)
> > + goto fn_setup_err;
> > +
> > + return r;
> >
> > fn_setup_err:
> > free_irq(client->irq, phy);
> >
> > irq_rqst_err:
> > - pn533_unregister_device(phy->priv);
> > + pn53x_common_clean(phy->priv);
> >
> > return r;
> > }
> > @@ -239,7 +241,8 @@ static int pn533_i2c_remove(struct i2c_client *client)
> >
> > free_irq(client->irq, phy);
> >
> > - pn533_unregister_device(phy->priv);
> > + pn53x_unregister_nfc(phy->priv);
> > + pn53x_common_clean(phy->priv);
> >
> > return 0;
> > }
> > diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
> > index 64836c727aee..a8c756caa678 100644
> > --- a/drivers/nfc/pn533/pn533.c
> > +++ b/drivers/nfc/pn533/pn533.c
> > @@ -2590,14 +2590,12 @@ int pn533_finalize_setup(struct pn533 *dev)
> > }
> > EXPORT_SYMBOL_GPL(pn533_finalize_setup);
> >
> > -struct pn533 *pn533_register_device(u32 device_type,
> > - u32 protocols,
> > +struct pn533 *pn53x_common_init(u32 device_type,
> > enum pn533_protocol_type protocol_type,
> > void *phy,
> > struct pn533_phy_ops *phy_ops,
> > struct pn533_frame_ops *fops,
> > - struct device *dev,
> > - struct device *parent)
> > + struct device *dev)
> > {
> > struct pn533 *priv;
> > int rc = -ENOMEM;
> > @@ -2638,43 +2636,18 @@ struct pn533 *pn533_register_device(u32 device_type,
> > skb_queue_head_init(&priv->fragment_skb);
> >
> > INIT_LIST_HEAD(&priv->cmd_queue);
> > -
> > - priv->nfc_dev = nfc_allocate_device(&pn533_nfc_ops, protocols,
> > - priv->ops->tx_header_len +
> > - PN533_CMD_DATAEXCH_HEAD_LEN,
> > - priv->ops->tx_tail_len);
> > - if (!priv->nfc_dev) {
> > - rc = -ENOMEM;
> > - goto destroy_wq;
> > - }
> > -
> > - nfc_set_parent_dev(priv->nfc_dev, parent);
> > - nfc_set_drvdata(priv->nfc_dev, priv);
> > -
> > - rc = nfc_register_device(priv->nfc_dev);
> > - if (rc)
> > - goto free_nfc_dev;
> > -
> > return priv;
> >
> > -free_nfc_dev:
> > - nfc_free_device(priv->nfc_dev);
> > -
> > -destroy_wq:
> > - destroy_workqueue(priv->wq);
> > error:
> > kfree(priv);
> > return ERR_PTR(rc);
> > }
> > -EXPORT_SYMBOL_GPL(pn533_register_device);
> > +EXPORT_SYMBOL_GPL(pn53x_common_init);
> >
> > -void pn533_unregister_device(struct pn533 *priv)
> > +void pn53x_common_clean(struct pn533 *priv)
> > {
> > struct pn533_cmd *cmd, *n;
> >
> > - nfc_unregister_device(priv->nfc_dev);
> > - nfc_free_device(priv->nfc_dev);
> > -
> > flush_delayed_work(&priv->poll_work);
> > destroy_workqueue(priv->wq);
> >
> > @@ -2689,8 +2662,37 @@ void pn533_unregister_device(struct pn533 *priv)
> >
> > kfree(priv);
> > }
> > -EXPORT_SYMBOL_GPL(pn533_unregister_device);
> > +EXPORT_SYMBOL_GPL(pn53x_common_clean);
> > +
> > +int pn53x_register_nfc(struct pn533 *priv, u32 protocols,
> > + struct device *parent)
> > +{
> > + int rc = -ENOMEM;
>
> No need to initialize rc here... or just return rc below.
I will remove the initialization. Looks better to me.
> > +
> > + priv->nfc_dev = nfc_allocate_device(&pn533_nfc_ops, protocols,
> > + priv->ops->tx_header_len +
> > + PN533_CMD_DATAEXCH_HEAD_LEN,
> > + priv->ops->tx_tail_len);
> > + if (!priv->nfc_dev)
> > + return -ENOMEM;
> > +
> > + nfc_set_parent_dev(priv->nfc_dev, parent);
> > + nfc_set_drvdata(priv->nfc_dev, priv);
> > +
> > + rc = nfc_register_device(priv->nfc_dev);
> > + if (rc)
> > + nfc_free_device(priv->nfc_dev);
> > +
> > + return rc;
> > +}
> > +EXPORT_SYMBOL_GPL(pn53x_register_nfc);
> >
> > +void pn53x_unregister_nfc(struct pn533 *priv)
> > +{
> > + nfc_unregister_device(priv->nfc_dev);
> > + nfc_free_device(priv->nfc_dev);
> > +}
> > +EXPORT_SYMBOL_GPL(pn53x_unregister_nfc);
> >
> > MODULE_AUTHOR("Lauro Ramos Venancio <lauro.venancio@openbossa.org>");
> > MODULE_AUTHOR("Aloisio Almeida Jr <aloisio.almeida@openbossa.org>");
> > diff --git a/drivers/nfc/pn533/pn533.h b/drivers/nfc/pn533/pn533.h
> > index 570ee0a3e832..510ddebbd896 100644
> > --- a/drivers/nfc/pn533/pn533.h
> > +++ b/drivers/nfc/pn533/pn533.h
> > @@ -219,18 +219,19 @@ struct pn533_phy_ops {
> > };
> >
> >
> > -struct pn533 *pn533_register_device(u32 device_type,
> > - u32 protocols,
> > +struct pn533 *pn53x_common_init(u32 device_type,
> > enum pn533_protocol_type protocol_type,
> > void *phy,
> > struct pn533_phy_ops *phy_ops,
> > struct pn533_frame_ops *fops,
> > - struct device *dev,
> > - struct device *parent);
> > + struct device *dev);
> >
> > int pn533_finalize_setup(struct pn533 *dev);
> > -void pn533_unregister_device(struct pn533 *priv);
> > +void pn53x_common_clean(struct pn533 *priv);
> > void pn533_recv_frame(struct pn533 *dev, struct sk_buff *skb, int status);
> > +int pn53x_register_nfc(struct pn533 *priv, u32 protocols,
> > + struct device *parent);
> > +void pn53x_unregister_nfc(struct pn533 *priv);
> >
> > bool pn533_rx_frame_is_cmd_response(struct pn533 *dev, void *frame);
> > bool pn533_rx_frame_is_ack(void *_frame);
> > diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
> > index c5289eaf17ee..a1c6a41944c6 100644
> > --- a/drivers/nfc/pn533/usb.c
> > +++ b/drivers/nfc/pn533/usb.c
> > @@ -534,9 +534,9 @@ static int pn533_usb_probe(struct usb_interface *interface,
> > goto error;
> > }
> >
> > - priv = pn533_register_device(id->driver_info, protocols, protocol_type,
> > + priv = pn53x_common_init(id->driver_info, protocol_type,
> > phy, &usb_phy_ops, fops,
> > - &phy->udev->dev, &interface->dev);
> > + &phy->udev->dev);
> >
> > if (IS_ERR(priv)) {
> > rc = PTR_ERR(priv);
> > @@ -550,9 +550,14 @@ static int pn533_usb_probe(struct usb_interface *interface,
> > goto error;
> >
> > usb_set_intfdata(interface, phy);
>
> Above this instruction there is this code:
>
> rc = pn533_finalize_setup(priv);
> if (rc)
> goto error;
>
> Instead of "goto error;" you should have "goto err_clean;"
Thank you for catching this one. I will change it.
> > + rc = pn53x_register_nfc(priv, protocols, &interface->dev);
> > + if (rc)
> > + goto err_clean;
> >
> > return 0;
> >
> > +err_clean:
> > + pn53x_common_clean(priv);
> > error:
> > usb_free_urb(phy->in_urb);
> > usb_free_urb(phy->out_urb);
> > @@ -570,7 +575,8 @@ static void pn533_usb_disconnect(struct usb_interface *interface)
> > if (!phy)
> > return;
> >
> > - pn533_unregister_device(phy->priv);
> > + pn53x_unregister_nfc(phy->priv);
> > + pn53x_common_clean(phy->priv);
> >
> > usb_set_intfdata(interface, NULL);
> >
> >
^ permalink raw reply
* Re: Bridge zeros out skb->cb in 5.2 (not in 5.1)
From: Florian Westphal @ 2019-08-23 9:12 UTC (permalink / raw)
To: Dan Siemon; +Cc: netdev, bpf
In-Reply-To: <CAB2AaTmtwpHKvuOi6a-54SW1JXUxt1N03Lb=GXMVv_-y+zYyEA@mail.gmail.com>
Dan Siemon <dan@coverfire.com> wrote:
[ CCing bpf maling list ]
> Commit f12064d1b402c60c5db9c4b63d5ed6d7facb33f6 zeros out skb->cb in
> br_input.c:
>
> memset(skb->cb, 0, sizeof(struct br_input_skb_cb));
>
> https://github.com/torvalds/linux/commit/f12064d1b402c60c5db9c4b63d5ed6d7facb33f6
>
> Prior to 5.2, it was possible to store information in skb->cb and have it
> pass through the bridge to the output link.
I did not know this was even possible.
Any owner of the skb (bridge, ip stack, etc.) use skb->cb[] as they see fit.
> We leveraged this to have a BPF
> prog that runs on ingress and does custom packet parsing and stores the
> output qdisc:class in skb->cb. This enabled the egress BPF filter to be
> super simple and avoid having to parse the entire packet again.
>
> Note I haven't built with this patch removed so it's possible this isn't
> the problem but the memset is unconditional...
You're not exactly saying what the problem is, so I have no idea.
> Is this a regression? Is it expected that the bridge would wipe this field
> when just passing frames?
Even if you remove the memset, that commit br_input_skb_cb
has existed, and is used. Fields were just cleared on-demand rather
than unconditionally at the start.
I think the latter is better practice and also what other owners do.
So please explain what exactly the problem is and/or check that the
cb clearing "is the problem".
If it is, I have no idea how to fix it.
^ permalink raw reply
* Re: libbpf distro packaging
From: Jiri Olsa @ 2019-08-23 9:22 UTC (permalink / raw)
To: Julia Kartseva
Cc: Andrii Nakryiko, labbott@redhat.com, acme@kernel.org,
debian-kernel@lists.debian.org, netdev@vger.kernel.org,
Andrii Nakryiko, Andrey Ignatov, Alexei Starovoitov,
Yonghong Song, jolsa@kernel.org
In-Reply-To: <20190821210906.GA31031@krava>
On Wed, Aug 21, 2019 at 11:09:06PM +0200, Jiri Olsa wrote:
> On Tue, Aug 20, 2019 at 10:27:23PM +0000, Julia Kartseva wrote:
> >
> >
> > On 8/19/19, 11:08 AM, "Julia Kartseva" <hex@fb.com> wrote:
> >
> > On 8/13/19, 11:24 AM, "Andrii Nakryiko" <andrii.nakryiko@gmail.com> wrote:
> >
> > On Tue, Aug 13, 2019 at 5:26 AM Jiri Olsa <jolsa@redhat.com> wrote:
> > >
> > > On Mon, Aug 12, 2019 at 07:04:12PM +0000, Julia Kartseva wrote:
> > > > I would like to bring up libbpf publishing discussion started at [1].
> > > > The present state of things is that libbpf is built from kernel tree, e.g. [2]
> > > > For Debian and [3] for Fedora whereas the better way would be having a
> > > > package built from github mirror. The advantages of the latter:
> > > > - Consistent, ABI matching versioning across distros
> > > > - The mirror has integration tests
> > > > - No need in kernel tree to build a package
> > > > - Changes can be merged directly to github w/o waiting them to be merged
> > > > through bpf-next -> net-next -> main
> > > > There is a PR introducing a libbpf.spec which can be used as a starting point: [4]
> > > > Any comments regarding the spec itself can be posted there.
> > > > In the future it may be used as a source of truth.
> > > > Please consider switching libbpf packaging to the github mirror instead
> > > > of the kernel tree.
> > > > Thanks
> > > >
> > > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.iovisor.org_g_iovisor-2Ddev_message_1521&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=zUrDY_Sp_5PqcGtRQPNeDA&m=prYVDiu3-aH1o2PWH4ZcP7lEQRCQAcTwcWPrJrtaroQ&s=dYAc2jLhFg0wtCZ_ms2HF5bWANoHzA3UMug5TNCeBtE&e=
> > > > [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__packages.debian.org_sid_libbpf4.19&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=zUrDY_Sp_5PqcGtRQPNeDA&m=prYVDiu3-aH1o2PWH4ZcP7lEQRCQAcTwcWPrJrtaroQ&s=lq1MpF-bt6y6ZEtFc57eT-BO_wMBx8uUBACJooWbUYk&e=
> > > > [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__rpmfind.net_linux_RPM_fedora_devel_rawhide_x86-5F64_l_libbpf-2D5.3.0-2D0.rc2.git0.1.fc31.x86-5F64.html&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=zUrDY_Sp_5PqcGtRQPNeDA&m=prYVDiu3-aH1o2PWH4ZcP7lEQRCQAcTwcWPrJrtaroQ&s=NoolYHL57G2KhzE768iWdy6v5LD2GfJQyqPmtjy196E&e=
> > > > [4] https://github.com/libbpf/libbpf/pull/64
> > >
> > > hi,
> > > Fedora has libbpf as kernel-tools subpackage, so I think
> > > we'd need to create new package and deprecate the current
> > >
> > > but I like the ABI stability by using github .. how's actually
> > > the sync (in both directions) with kernel sources going on?
> >
> > Sync is always in one direction, from kernel sources into Github repo.
> > Right now it's triggered by a human (usually me), but we are using a
> > script that automates entire process (see
> > https://github.com/libbpf/libbpf/blob/master/scripts/sync-kernel.sh).
> > It cherry-pick relevant commits from kernel, transforms them to match
> > Github's file layout and re-applies those changes to Github repo.
> >
> > There is never a sync from Github back to kernel, but Github repo
> > contains some extra stuff that's not in kernel. E.g., the script I
> > mentioned, plus Github's Makefile is different, because it can't rely
> > on kernel's kbuild setup.
> >
> > Hi Jiri,
> > I'm curious if you have any comments regarding sync procedure described
> > By Andrii. Or if there is anything else you'd like us to address so Fedora
> > can be switched to libbpf built from the github mirror?
>
> hi,
> yea, I think it's ok.. just need to check the implications
> for rhel packaging and I'll let you know
btw, the libbpf GH repo tag v0.0.4 has 0.0.3 version set in Makefile:
VERSION = 0
PATCHLEVEL = 0
EXTRAVERSION = 3
current code takes version from libbpf.map so it's fine,
but would be great to start from 0.0.5 so we don't need to
bother with rpm patches.. is 0.0.5 planned soon?
thanks,
jirka
^ permalink raw reply
* [PATCH net] s390/qeth: reject oversized SNMP requests
From: Julian Wiedmann @ 2019-08-23 9:29 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Heiko Carstens, Stefan Raspl, Ursula Braun,
Julian Wiedmann
Commit d4c08afafa04 ("s390/qeth: streamline SNMP cmd code") removed
the bounds checking for req_len, under the assumption that the check in
qeth_alloc_cmd() would suffice.
But that code path isn't sufficiently robust to handle a user-provided
data_length, which could overflow (when adding the cmd header overhead)
before being checked against QETH_BUFSIZE. We end up allocating just a
tiny iob, and the subsequent copy_from_user() writes past the end of
that iob.
Special-case this path and add a coarse bounds check, to protect against
maliciuous requests. This let's the subsequent code flow do its normal
job and precise checking, without risk of overflow.
Fixes: d4c08afafa04 ("s390/qeth: streamline SNMP cmd code")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Ursula Braun <ubraun@linux.ibm.com>
---
drivers/s390/net/qeth_core_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index 9c3310c4d61d..6502b148541e 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -4374,6 +4374,10 @@ static int qeth_snmp_command(struct qeth_card *card, char __user *udata)
get_user(req_len, &ureq->hdr.req_len))
return -EFAULT;
+ /* Sanitize user input, to avoid overflows in iob size calculation: */
+ if (req_len > QETH_BUFSIZE)
+ return -EINVAL;
+
iob = qeth_get_adapter_cmd(card, IPA_SETADP_SET_SNMP_CONTROL, req_len);
if (!iob)
return -ENOMEM;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] s390/qeth: reject oversized SNMP requests
From: Julian Wiedmann @ 2019-08-23 9:31 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Heiko Carstens, Stefan Raspl, Ursula Braun,
Dan Carpenter
In-Reply-To: <20190823092923.8507-1-jwi@linux.ibm.com>
+cc Dan
On 23.08.19 11:29, Julian Wiedmann wrote:
> Commit d4c08afafa04 ("s390/qeth: streamline SNMP cmd code") removed
> the bounds checking for req_len, under the assumption that the check in
> qeth_alloc_cmd() would suffice.
>
> But that code path isn't sufficiently robust to handle a user-provided
> data_length, which could overflow (when adding the cmd header overhead)
> before being checked against QETH_BUFSIZE. We end up allocating just a
> tiny iob, and the subsequent copy_from_user() writes past the end of
> that iob.
>
> Special-case this path and add a coarse bounds check, to protect against
> maliciuous requests. This let's the subsequent code flow do its normal
> job and precise checking, without risk of overflow.
>
> Fixes: d4c08afafa04 ("s390/qeth: streamline SNMP cmd code")
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
> Reviewed-by: Ursula Braun <ubraun@linux.ibm.com>
> ---
> drivers/s390/net/qeth_core_main.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
> index 9c3310c4d61d..6502b148541e 100644
> --- a/drivers/s390/net/qeth_core_main.c
> +++ b/drivers/s390/net/qeth_core_main.c
> @@ -4374,6 +4374,10 @@ static int qeth_snmp_command(struct qeth_card *card, char __user *udata)
> get_user(req_len, &ureq->hdr.req_len))
> return -EFAULT;
>
> + /* Sanitize user input, to avoid overflows in iob size calculation: */
> + if (req_len > QETH_BUFSIZE)
> + return -EINVAL;
> +
> iob = qeth_get_adapter_cmd(card, IPA_SETADP_SET_SNMP_CONTROL, req_len);
> if (!iob)
> return -ENOMEM;
>
^ permalink raw reply
* [PATCH net-next 0/7] s390/qeth: updates 2019-08-23
From: Julian Wiedmann @ 2019-08-23 9:48 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Heiko Carstens, Stefan Raspl, Ursula Braun,
Julian Wiedmann
Hi Dave,
please apply one more round of qeth patches. These implement support for
a bunch of TX-related features - namely TX NAPI, BQL and xmit_more.
Note that this includes two qdio patches which lay the necessary
groundwork, and have been acked by Vasily.
Thanks,
Julian
Julian Wiedmann (7):
s390/qdio: enable drivers to poll for Output completions
s390/qdio: let drivers opt-out from Output Queue scanning
s390/qeth: collect accurate TX statistics
s390/qeth: add TX NAPI support for IQD devices
s390/qeth: when in TX NAPI mode, use napi_consume_skb()
s390/qeth: add BQL support for IQD devices
s390/qeth: add xmit_more support for IQD devices
arch/s390/include/asm/qdio.h | 6 +-
drivers/s390/cio/qdio.h | 3 +-
drivers/s390/cio/qdio_main.c | 75 ++++--
drivers/s390/cio/qdio_setup.c | 2 +-
drivers/s390/net/qeth_core.h | 52 ++++
drivers/s390/net/qeth_core_main.c | 410 +++++++++++++++++++++---------
drivers/s390/net/qeth_ethtool.c | 2 +
drivers/s390/net/qeth_l2_main.c | 12 +-
drivers/s390/net/qeth_l3_main.c | 9 +-
9 files changed, 414 insertions(+), 157 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next 3/7] s390/qeth: collect accurate TX statistics
From: Julian Wiedmann @ 2019-08-23 9:48 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Heiko Carstens, Stefan Raspl, Ursula Braun,
Julian Wiedmann
In-Reply-To: <20190823094853.63814-1-jwi@linux.ibm.com>
This consolidates the SW statistics code, and improves it to
(1) account for the header overhead of each segment on a TSO skb,
(2) count dangling packets as in-error (during eg. shutdown), and
(3) only count offloads when the skb was successfully transmitted.
We also count each segment of an TSO skb as one packet - except for
tx_dropped, to be consistent with dev->tx_dropped.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
---
drivers/s390/net/qeth_core.h | 1 +
drivers/s390/net/qeth_core_main.c | 66 +++++++++++++++++++------------
drivers/s390/net/qeth_l2_main.c | 12 ++----
drivers/s390/net/qeth_l3_main.c | 9 ++---
4 files changed, 49 insertions(+), 39 deletions(-)
diff --git a/drivers/s390/net/qeth_core.h b/drivers/s390/net/qeth_core.h
index 72755a025b4d..a0911ce55db3 100644
--- a/drivers/s390/net/qeth_core.h
+++ b/drivers/s390/net/qeth_core.h
@@ -30,6 +30,7 @@
#include <net/ipv6.h>
#include <net/if_inet6.h>
#include <net/addrconf.h>
+#include <net/sch_generic.h>
#include <net/tcp.h>
#include <asm/debug.h>
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index 44fbaa4f7264..d7a15a88bdba 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -71,7 +71,7 @@ static void qeth_free_qdio_queues(struct qeth_card *card);
static void qeth_notify_skbs(struct qeth_qdio_out_q *queue,
struct qeth_qdio_out_buffer *buf,
enum iucv_tx_notify notification);
-static void qeth_release_skbs(struct qeth_qdio_out_buffer *buf);
+static void qeth_tx_complete_buf(struct qeth_qdio_out_buffer *buf, bool error);
static int qeth_init_qdio_out_buf(struct qeth_qdio_out_q *, int);
static void qeth_close_dev_handler(struct work_struct *work)
@@ -411,7 +411,7 @@ static void qeth_cleanup_handled_pending(struct qeth_qdio_out_q *q, int bidx,
/* release here to avoid interleaving between
outbound tasklet and inbound tasklet
regarding notifications and lifecycle */
- qeth_release_skbs(c);
+ qeth_tx_complete_buf(c, forced_cleanup);
c = f->next_pending;
WARN_ON_ONCE(head->next_pending != f);
@@ -1077,22 +1077,51 @@ static void qeth_notify_skbs(struct qeth_qdio_out_q *q,
}
}
-static void qeth_release_skbs(struct qeth_qdio_out_buffer *buf)
+static void qeth_tx_complete_buf(struct qeth_qdio_out_buffer *buf, bool error)
{
+ struct qeth_qdio_out_q *queue = buf->q;
struct sk_buff *skb;
/* release may never happen from within CQ tasklet scope */
WARN_ON_ONCE(atomic_read(&buf->state) == QETH_QDIO_BUF_IN_CQ);
if (atomic_read(&buf->state) == QETH_QDIO_BUF_PENDING)
- qeth_notify_skbs(buf->q, buf, TX_NOTIFY_GENERALERROR);
+ qeth_notify_skbs(queue, buf, TX_NOTIFY_GENERALERROR);
+
+ /* Empty buffer? */
+ if (buf->next_element_to_fill == 0)
+ return;
+
+ QETH_TXQ_STAT_INC(queue, bufs);
+ QETH_TXQ_STAT_ADD(queue, buf_elements, buf->next_element_to_fill);
+ while ((skb = __skb_dequeue(&buf->skb_list)) != NULL) {
+ unsigned int bytes = qdisc_pkt_len(skb);
+ bool is_tso = skb_is_gso(skb);
+ unsigned int packets;
+
+ packets = is_tso ? skb_shinfo(skb)->gso_segs : 1;
+ if (error) {
+ QETH_TXQ_STAT_ADD(queue, tx_errors, packets);
+ } else {
+ QETH_TXQ_STAT_ADD(queue, tx_packets, packets);
+ QETH_TXQ_STAT_ADD(queue, tx_bytes, bytes);
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ QETH_TXQ_STAT_ADD(queue, skbs_csum, packets);
+ if (skb_is_nonlinear(skb))
+ QETH_TXQ_STAT_INC(queue, skbs_sg);
+ if (is_tso) {
+ QETH_TXQ_STAT_INC(queue, skbs_tso);
+ QETH_TXQ_STAT_ADD(queue, tso_bytes, bytes);
+ }
+ }
- while ((skb = __skb_dequeue(&buf->skb_list)) != NULL)
consume_skb(skb);
+ }
}
static void qeth_clear_output_buffer(struct qeth_qdio_out_q *queue,
- struct qeth_qdio_out_buffer *buf)
+ struct qeth_qdio_out_buffer *buf,
+ bool error)
{
int i;
@@ -1100,7 +1129,7 @@ static void qeth_clear_output_buffer(struct qeth_qdio_out_q *queue,
if (buf->buffer->element[0].sflags & SBAL_SFLAGS0_PCI_REQ)
atomic_dec(&queue->set_pci_flags_count);
- qeth_release_skbs(buf);
+ qeth_tx_complete_buf(buf, error);
for (i = 0; i < queue->max_elements; ++i) {
if (buf->buffer->element[i].addr && buf->is_header[i])
@@ -1122,7 +1151,7 @@ static void qeth_drain_output_queue(struct qeth_qdio_out_q *q, bool free)
if (!q->bufs[j])
continue;
qeth_cleanup_handled_pending(q, j, 1);
- qeth_clear_output_buffer(q, q->bufs[j]);
+ qeth_clear_output_buffer(q, q->bufs[j], true);
if (free) {
kmem_cache_free(qeth_qdio_outbuf_cache, q->bufs[j]);
q->bufs[j] = NULL;
@@ -3240,14 +3269,12 @@ static void qeth_flush_buffers(struct qeth_qdio_out_q *queue, int index,
}
}
- QETH_TXQ_STAT_ADD(queue, bufs, count);
qdio_flags = QDIO_FLAG_SYNC_OUTPUT;
if (atomic_read(&queue->set_pci_flags_count))
qdio_flags |= QDIO_FLAG_PCI_OUT;
rc = do_QDIO(CARD_DDEV(queue->card), qdio_flags,
queue->queue_no, index, count);
if (rc) {
- QETH_TXQ_STAT_ADD(queue, tx_errors, count);
/* ignore temporary SIGA errors without busy condition */
if (rc == -ENOBUFS)
return;
@@ -3456,7 +3483,7 @@ static void qeth_qdio_output_handler(struct ccw_device *ccwdev,
qeth_notify_skbs(queue, buffer, n);
}
- qeth_clear_output_buffer(queue, buffer);
+ qeth_clear_output_buffer(queue, buffer, qdio_error);
}
qeth_cleanup_handled_pending(queue, bidx, 0);
}
@@ -3942,7 +3969,6 @@ int qeth_xmit(struct qeth_card *card, struct sk_buff *skb,
unsigned int hd_len = 0;
unsigned int elements;
int push_len, rc;
- bool is_sg;
if (is_tso) {
hw_hdr_len = sizeof(struct qeth_hdr_tso);
@@ -3971,7 +3997,6 @@ int qeth_xmit(struct qeth_card *card, struct sk_buff *skb,
qeth_fill_tso_ext((struct qeth_hdr_tso *) hdr,
frame_len - proto_len, skb, proto_len);
- is_sg = skb_is_nonlinear(skb);
if (IS_IQD(card)) {
rc = qeth_do_send_packet_fast(queue, skb, hdr, data_offset,
hd_len);
@@ -3982,18 +4007,9 @@ int qeth_xmit(struct qeth_card *card, struct sk_buff *skb,
hd_len, elements);
}
- if (!rc) {
- QETH_TXQ_STAT_ADD(queue, buf_elements, elements);
- if (is_sg)
- QETH_TXQ_STAT_INC(queue, skbs_sg);
- if (is_tso) {
- QETH_TXQ_STAT_INC(queue, skbs_tso);
- QETH_TXQ_STAT_ADD(queue, tso_bytes, frame_len);
- }
- } else {
- if (!push_len)
- kmem_cache_free(qeth_core_header_cache, hdr);
- }
+ if (rc && !push_len)
+ kmem_cache_free(qeth_core_header_cache, hdr);
+
return rc;
}
EXPORT_SYMBOL_GPL(qeth_xmit);
diff --git a/drivers/s390/net/qeth_l2_main.c b/drivers/s390/net/qeth_l2_main.c
index 662bd51f922f..b8799cd3e7aa 100644
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -175,10 +175,8 @@ static void qeth_l2_fill_header(struct qeth_qdio_out_q *queue,
hdr->hdr.l2.id = QETH_HEADER_TYPE_L2_TSO;
} else {
hdr->hdr.l2.id = QETH_HEADER_TYPE_LAYER2;
- if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
qeth_tx_csum(skb, &hdr->hdr.l2.flags[1], ipv);
- QETH_TXQ_STAT_INC(queue, skbs_csum);
- }
}
/* set byte byte 3 to casting flags */
@@ -588,9 +586,10 @@ static netdev_tx_t qeth_l2_hard_start_xmit(struct sk_buff *skb,
struct qeth_card *card = dev->ml_priv;
u16 txq = skb_get_queue_mapping(skb);
struct qeth_qdio_out_q *queue;
- int tx_bytes = skb->len;
int rc;
+ if (!skb_is_gso(skb))
+ qdisc_skb_cb(skb)->pkt_len = skb->len;
if (IS_IQD(card))
txq = qeth_iqd_translate_txq(dev, txq);
queue = card->qdio.out_qs[txq];
@@ -601,11 +600,8 @@ static netdev_tx_t qeth_l2_hard_start_xmit(struct sk_buff *skb,
rc = qeth_xmit(card, skb, queue, qeth_get_ip_version(skb),
qeth_l2_fill_header);
- if (!rc) {
- QETH_TXQ_STAT_INC(queue, tx_packets);
- QETH_TXQ_STAT_ADD(queue, tx_bytes, tx_bytes);
+ if (!rc)
return NETDEV_TX_OK;
- }
QETH_TXQ_STAT_INC(queue, tx_dropped);
kfree_skb(skb);
diff --git a/drivers/s390/net/qeth_l3_main.c b/drivers/s390/net/qeth_l3_main.c
index 54799fe6a700..d7bfc7a0e4c0 100644
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -1957,7 +1957,6 @@ static void qeth_l3_fill_header(struct qeth_qdio_out_q *queue,
/* some HW requires combined L3+L4 csum offload: */
if (ipv == 4)
hdr->hdr.l3.ext_flags |= QETH_HDR_EXT_CSUM_HDR_REQ;
- QETH_TXQ_STAT_INC(queue, skbs_csum);
}
}
@@ -2044,9 +2043,10 @@ static netdev_tx_t qeth_l3_hard_start_xmit(struct sk_buff *skb,
u16 txq = skb_get_queue_mapping(skb);
int ipv = qeth_get_ip_version(skb);
struct qeth_qdio_out_q *queue;
- int tx_bytes = skb->len;
int rc;
+ if (!skb_is_gso(skb))
+ qdisc_skb_cb(skb)->pkt_len = skb->len;
if (IS_IQD(card)) {
queue = card->qdio.out_qs[qeth_iqd_translate_txq(dev, txq)];
@@ -2069,11 +2069,8 @@ static netdev_tx_t qeth_l3_hard_start_xmit(struct sk_buff *skb,
else
rc = qeth_xmit(card, skb, queue, ipv, qeth_l3_fill_header);
- if (!rc) {
- QETH_TXQ_STAT_INC(queue, tx_packets);
- QETH_TXQ_STAT_ADD(queue, tx_bytes, tx_bytes);
+ if (!rc)
return NETDEV_TX_OK;
- }
tx_drop:
QETH_TXQ_STAT_INC(queue, tx_dropped);
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox