[net-next 9/9] ixgbe: Fix bugs in ixgbe_clear_vf_vlans()
From: Alexander Duyck
When I had rewritten the code for ixgbe_clear_vf_vlans() it looks like I
had transitioned back and forth between using word as an offset and using
word as a register offset. As a result I honestly don't see how the code
was working before other than the fact that resetting the VLANs on the VF
like didn't do much to clear them.
Another issue found is that the mask was using a divide instead of a
modulus. As a result the mask bit was incorrectly being set to either bit
0 or 1 based on the value of the VF being tested. As a result the wrong
VFs were having their VLANs cleared if they were enabled.
I have updated the code so that word represents the offset in the array.
This way we can use the modulus and xor operations and they will make sense
instead of being performed on a 4 byte aligned value.
I replaced the statement "(word % 2) ^ 1" with "~word % 2" in order to
reduce the line length as the line exceeded 80 characters with the register
name inserted. The two should be equivalent so the change should be safe.
Reported-by: Emil Tantilov
Signed-off-by: Alexander Duyck
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index fd918da..c817103 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -593,11 +593,11 @@ static void ixgbe_clear_vf_vlans(struct ixgbe_adapter
*adapter, u32 vf)
/* post increment loop, covers VLVF_ENTRIES - 1 to 0 */
for (i = IXGBE_VLVF_ENTRIES; i--;) {
- u32 word = IXGBE_VLVFB(i * 2 + vf / 32);
u32 bits[2], vlvfb, vid, vfta, vlvf;
- u32 mask = 1 << (vf / 32);
+ u32 word = i * 2 + vf / 32;
+ u32 mask = 1 << (vf % 32);
- vlvfb = IXGBE_READ_REG(hw, word);
+ vlvfb = IXGBE_READ_REG(hw, IXGBE_VLVFB(word));
/* if our bit isn't set we can skip it */
if (!(vlvfb & mask))
@@ -608,7 +608,7 @@ static void ixgbe_clear_vf_vlans(struct ixgbe_adapter
*adapter, u32 vf)
/* create 64b mask to chedk to see if we should clear VLVF */
bits[word % 2] = vlvfb;
- bits[(word % 2) ^ 1] = IXGBE_READ_REG(hw, word ^ 1);
+ bits[~word % 2] = IXGBE_READ_REG(hw, IXGBE_VLVFB(word ^ 1));
/* if promisc is enabled, PF will be present, leave VFTA */
if (adapter->flags2 & IXGBE_FLAG2_VLAN_PROMISC) {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next 5/9] ixgbe: Clean up redundancy in hw_enc_features
From: Mark Rustad
Clean up minor redundancy in the setting of hw_enc_features that
makes it appears that X550 uniquely has more encapsulation features
than other devices. The driver only supports one more feature, so
make it look that way. No longer set NETIF_F_SG since that is set
by the register_netdev call. Thanks to Alex Duyck for noticing this
slight confusion.
Reported-by: Alexander Duyck
Signed-off-by: Mark Rustad
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index c5c0fb4..ea9537d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9015,8 +9015,7 @@ skip_sriov:
netdev->vlan_features |= NETIF_F_IPV6_CSUM;
netdev->vlan_features |= NETIF_F_SG;
- netdev->hw_enc_features |= NETIF_F_SG | NETIF_F_IP_CSUM |
- NETIF_F_IPV6_CSUM;
+ netdev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
netdev->priv_flags |= IFF_UNICAST_FLT;
netdev->priv_flags |= IFF_SUPP_NOFCS;
@@ -9025,9 +9024,7 @@ skip_sriov:
switch (adapter->hw.mac.type) {
case ixgbe_mac_X550:
case ixgbe_mac_X550EM_x:
- netdev->hw_enc_features |= NETIF_F_RXCSUM |
- NETIF_F_IP_CSUM |
- NETIF_F_IPV6_CSUM;
+ netdev->hw_enc_features |= NETIF_F_RXCSUM;
break;
default:
break;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next 4/9] ixgbe: report correct media type for KR, KX and KX4 interfaces
From: Veola Nazareth
Ethtool reports backplane type interfaces as 1000/1baseT link modes.
This has been corrected to report the media as KR, KX or KX4 based on the
backplane interface present.
Signed-off-by: Veola Nazareth
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 55 ++--
1 file changed, 42 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index e10d197..2448eba 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -151,6 +151,34 @@ static const char ixgbe_gstrings_test[][ETH_GSTRING_LEN] =
{
};
#define IXGBE_TEST_LEN sizeof(ixgbe_gstrings_test) / ETH_GSTRING_LEN
+/* currently supported speeds for 10G */
+#define ADVRTSD_MSK_10G (SUPPORTED_1baseT_Full | \
+SUPPORTED_1baseKX4_Full | \
+SUPPORTED_1baseKR_Full)
+
+#define ixgbe_isbackplane(type) ((type) == ixgbe_media_type_backplane)
+
+static u32 ixgbe_get_supported_10gtypes(struct ixgbe_hw *hw)
+{
+ if (!ixgbe_isbackplane(hw->phy.media_type))
+ return SUPPORTED_1baseT_Full;
+
+ switch (hw->device_id) {
+ case IXGBE_DEV_ID_82598:
+ case IXGBE_DEV_ID_82599_KX4:
+ case IXGBE_DEV_ID_82599_KX4_MEZZ:
+ case IXGBE_DEV_ID_X550EM_X_KX4:
+ return SUPPORTED_1baseKX4_Full;
+ case IXGBE_DEV_ID_82598_BX:
+ case IXGBE_DEV_ID_82599_KR:
+ case IXGBE_DEV_ID_X550EM_X_KR:
+ return SUPPORTED_1baseKR_Full;
+ default:
+ return SUPPORTED_1baseKX4_Full |
+ SUPPORTED_1baseKR_Full;
+ }
+}
+
static int ixgbe_get_settings(struct net_device *netdev,
struct ethtool_cmd *ecmd)
{
@@ -165,29 +193,30 @@ static int ixgbe_get_settings(struct net_device *netdev,
/* set the supported link speeds */
if (supported_link & IXGBE_LINK_SPEED_10GB_FULL)
- ecmd->supported |= SUPPORTED_1baseT_Full;
+ ecmd->supported |= ixgbe_get_supported_10gtypes(hw);
if (supported_link & IXGBE_LINK_SPEED_1GB_FULL)
ecmd->supported |= SUPPORTED_1000baseT_Full;
if (supported_link & IXGBE_LINK_SPEED_100_FULL)
- ecmd->supported |= SUPPORTED_100baseT_Full;
+ ecmd->supported |= ixgbe_isbackplane(hw->phy.media_type) ?
+ SUPPORTED_1000baseKX_Full :
+ SUPPORTED_1000baseT_Full;
+ /* default advertised speed if phy.autoneg_advertised isn't set */
+ ecmd->advertising = ecmd->supported;
/* set the advertised speeds */
if (hw->phy.autoneg_advertised) {
+ ecmd->advertising = 0;
if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_100_FULL)
ecmd->advertising |= ADVERTISED_100baseT_Full;
if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_10GB_FULL)
- ecmd->advertising |= ADVERTISED_1baseT_Full;
- if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_1GB_FULL)
- ecmd->advertising |= ADVERTISED_1000baseT_Full;
+ ecmd->advertising |= ecmd->supported & ADVRTSD_MSK_10G;
+ if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_1GB_FULL) {
+ if (ecmd->supported & SUPPORTED_1000baseKX_Full)
+ ecmd->advertising |= ADVERTISED_1000baseKX_Full;
+ else
+ ecmd->advertising |= ADVERTISED_1000baseT_Full;
+ }
} else {
- /* default modes in case phy.autoneg_advertised isn't set */
- if (supported_link & IXGBE_LINK_SPEED_10GB_FULL)
- ecmd->advertising |= ADVERTISED_1baseT_Full;
- if (supported_link & IXGBE_LINK_SPEED_1GB_FULL)
- ecmd->advertising |= ADVERTISED_1000baseT_Full;
- if (supported_link & IXGBE_LINK_SPEED_100_FULL)
- ecmd->advertising |= ADVERTISED_100baseT_Full;
-
if (hw->phy.multispeed_fiber && !autoneg) {
if (supported_link & IXGBE_LINK_SPEED_10GB_FULL)
ecmd->advertising = ADVERTISED_1baseT_Full;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next 0/9][pull request] 10GbE Intel Wired LAN Driver Updates 2015-12-24
This series contains updates to ixgbe and ixgbevf.
William Dauchy provides a fix for ixgbevf that was implemented for ixgbe,
commit 5d6002b7b822c7 ("ixgbe: Fix handling of NAPI budget when multiple
queues are enabled per vector"). The issue was that the polling routine
would increase the budget for receive to at least 1 per queue if multiple
queues were present, which resulted in receive packets being processed
when the budget was 0.
Emil provides minor cleanups for ixgbevf, one being that we need to
check rx_itr_setting with == and not &, since it is not a mask. Added
QSFP PHY support in ixgbe to allow for more accurate reporting of port
settings. Fixed the max RSS limit for X550 which is 63, not 64. Lastly,
fix an issue which was causing PCI AER errors, by fixing the write to
the VLVFR register in ixgbe_clear_vf_vlans() where the word argument
is the actual offset of the register and not the index for the
IXGBE_VLVFB() macro.
Veola fixes ixgbe ethtool reporting of backplane type interfaces as
1000/1baseT link modes, instead, report the media as KR, KX or KX4
based on the backplane interface present.
Mark cleans up redundancy in the setting of hw_enc_features that makes
it appear that X550 has more encapsulation features than other devices.
Also do not set NETIF_F_SG any longer since that is set by the
register_netdev() call. Also fixed the X550EM_x revision check, which
needs to check a value, not just a bit.
Alex Duyck fixes additional bugs in ixgbe_clear_vf_vlans(), one being
that the mask was using a divide instead of a modulus, which resulted
in the mask bit being incorrectly set to 0 or 1 based on the value of
the VF being tested. Alex also found that he was not consistent in
using the "word" argument as an offset or as a register offset, so
made the code consistently use word as the offset in the array.
The following are changes since commit d7d3e25f40e950bdcec6d94faf9346b7a7d6e4bb:
cxgb4: Remove deprecated module parameters
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 10GbE
Alexander Duyck (1):
ixgbe: Fix bugs in ixgbe_clear_vf_vlans()
Emil Tantilov (4):
ixgbevf: minor cleanups for ixgbevf_set_itr()
ixgbe: add support for QSFP PHY types in ixgbe_get_settings()
ixgbe: fix RSS limit for X550
ixgbe: fix write to VLVFB in ixgbe_clear_vf_vlans()
Mark Rustad (2):
ixgbe: Clean up redundancy in hw_enc_features
ixgbe: Correct X550EM_x revision check
Veola Nazareth (1):
ixgbe: report correct media type for KR, KX and KX4 interfaces
William Dauchy (1):
ixgbevf: Fix handling of NAPI budget when multiple queues are enabled
per vector
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 59 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c| 10 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 9 ++--
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 7 ++-
7 files changed, 63 insertions(+), 33 deletions(-)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next 1/9] ixgbevf: Fix handling of NAPI budget when multiple queues are enabled per vector
From: William Dauchy
This is the same patch as for ixgbe but applied differently according to
busy polling. See commit 5d6002b7b822c74 ("ixgbe: Fix handling of NAPI
budget when multiple queues are enabled per vector")
Signed-off-by: William Dauchy
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index f098952..478c0f1 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1016,6 +1016,8 @@ static int ixgbevf_poll(struct napi_struct *napi, int
budget)
ixgbevf_for_each_ring(ring, q_vector->tx)
clean_complete &= ixgbevf_clean_tx_irq(q_vector, ring);
+ if (budget <= 0)
+ return budget;
#ifdef CONFIG_NET_RX_BUSY_POLL
if (!ixgbevf_qv_lock_napi(q_vector))
return budget;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next 8/9] ixgbe: fix write to VLVFB in ixgbe_clear_vf_vlans()
From: Emil Tantilov
Fix the write to the VLVFB register in ixgbe_clear_vf_vlans() where
word is the actual offset of the register and not the index for the
IXGBE_VLVFB macro.
This was causing PCI AER errors on my system.
Fixes: 4c7f35f679f592804736f9303051257de2c9f021
("ixgbe: Clean stale VLANs when changing port VLAN or resetting")
Signed-off-by: Emil Tantilov
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index eeff3d0..fd918da 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -640,7 +640,7 @@ update_vlvf:
IXGBE_WRITE_REG(hw, IXGBE_VLVF(i), 0);
update_vlvfb:
/* clear pool bits */
- IXGBE_WRITE_REG(hw, IXGBE_VLVFB(word), vlvfb);
+ IXGBE_WRITE_REG(hw, word, vlvfb);
}
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next 7/9] ixgbe: Correct X550EM_x revision check
From: Mark Rustad
The X550EM_x revision check needs to check a value, not just a bit.
Use a mask and check the value. Also remove the redundant check
inside the ixgbe_enter_lplu_t_x550em, because it can only be called
when both the mac type and revision check pass.
Signed-off-by: Mark Rustad
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 9 +++--
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 06add27..5f53cc6 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -3520,7 +3520,7 @@ struct ixgbe_info {
#define IXGBE_FUSES0_GROUP(_i) (0x11158 + ((_i) * 4))
#define IXGBE_FUSES0_300MHZBIT(5)
-#define IXGBE_FUSES0_REV1 BIT(6)
+#define IXGBE_FUSES0_REV_MASK (3 << 6)
#define IXGBE_KRM_PORT_CAR_GEN_CTRL(P) ((P) ? 0x8010 : 0x4010)
#define IXGBE_KRM_LINK_CTRL_1(P) ((P) ? 0x820C : 0x420C)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index f4ef0d1..87aca3f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -1857,10 +1857,6 @@ static s32 ixgbe_enter_lplu_t_x550em(struct ixgbe_hw *hw)
u32 save_autoneg;
bool link_up;
- /* SW LPLU not required on later HW revisions. */
- if (IXGBE_FUSES0_REV1 & IXGBE_READ_REG(hw, IXGBE_FUSES0_GROUP(0)))
- return 0;
-
/* If blocked by MNG FW, then don't restart AN */
if (ixgbe_check_reset_blocked(hw))
return 0;
@@ -2000,8 +1996,9 @@ static s32 ixgbe_init_phy_ops_X550em(struct ixgbe_hw *hw)
ixgbe_setup_internal_phy_t_x550em;
/* setup SW LPLU only for first revision */
- if (!(IXGBE_FUSES0_REV1 & IXGBE_READ_REG(hw,
- IXGBE_FUSES0_GROUP(0
+ if (hw->mac.type == ixgbe_mac_X550EM_x &&
+ !(IXGBE_READ_REG(hw, IXGBE_FUSES0_GROUP(0)) &
+ IXGBE_FUSES0_REV_MASK))
phy->ops.enter_lplu = ixgbe_enter_lplu_t_x550em;
phy->ops.handle_lasi = ixgbe_handle_lasi_ext_t_x550em;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next 3/9] ixgbe: add support for QSFP PHY types in ixgbe_get_settings()
From: Emil Tantilov
Add missing QSFP PHY types to allow for more accurate reporting of
port settings.
Signed-off-by: Emil Tantilov
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 1ed4c9a..e10d197 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -225,6 +225,10 @@ static int ixgbe_get_settings(struct net_device *netdev,
case ixgbe_phy_sfp_avago:
case ixgbe_phy_sfp_intel:
case ixgbe_phy_sfp_unknown:
+ case ixgbe_phy_qsfp_passive_unknown:
+ case ixgbe_phy_qsfp_active_unknown:
+ case ixgbe_phy_qsfp_intel:
+ case ixgbe_phy_qsfp_unknown:
/* SFP+ devices, further checking needed */
switch (adapter->hw.phy.sfp_type) {
case ixgbe_sfp_type_da_cu:
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next 2/9] ixgbevf: minor cleanups for ixgbevf_set_itr()
From: Emil Tantilov
adapter->rx_itr_setting is not a mask so check it with == instead of &
do not default to 12K interrupts in ixgbevf_set_itr()
There should be no functional effect from these changes.
Signed-off-by: Emil Tantilov
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 478c0f1..3558f01 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1047,7 +1047,7 @@ static int ixgbevf_poll(struct napi_struct *napi, int
budget)
return budget;
/* all work done, exit the polling mode */
napi_complete_done(napi, work_done);
- if (adapter->rx_itr_setting & 1)
+ if (adapter->rx_itr_setting == 1)
ixgbevf_set_itr(q_vector);
if (!test_bit(__IXGBEVF_DOWN, &adapter->state) &&
!test_bit(__IXGBEVF_REMOVING, &adapter->state))
@@ -1250,9 +1250,10 @@ static void ixgbevf_set_itr(struct ixgbevf_q_vector
*q_vector)
new_itr = IXGBE_20K_ITR;
break;
case bulk_latency:
- default:
new_itr = IXGBE_12K_ITR;
break;
+ default:
+ break;
}
if (new_itr != q_vector->itr) {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next 6/9] ixgbe: fix RSS limit for X550
From: Emil Tantilov
X550 allows for up to 64 RSS queues, but the driver can have max
of 63 (-1 MSIX vector for link).
On systems with >= 64 CPUs the driver will set the redirection table
for all 64 queues which will result in packets being dropped.
Signed-off-by: Emil Tantilov
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index f4c9a42..4b9156c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -317,7 +317,7 @@ enum ixgbe_ring_f_enum {
};
#define IXGBE_MAX_RSS_INDICES 16
-#define IXGBE_MAX_RSS_INDICES_X550 64
+#define IXGBE_MAX_RSS_INDICES_X550 63
#define IXGBE_MAX_VMDQ_INDICES 64
#define IXGBE_MAX_FDIR_INDICES 63 /* based on q_vector limit */
#define IXGBE_MAX_FCOE_INDICES 8
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH iproute2 net-next 1/2] iproute2: ip-route.8.in: Add missing '[' before 'pref'
Signed-off-by: Hangbin Liu --- man/man8/ip-route.8.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in index 72d8d77..5b45bc2 100644 --- a/man/man8/ip-route.8.in +++ b/man/man8/ip-route.8.in @@ -128,7 +128,7 @@ replace " } " .B quickack .IR BOOL " ] [ " .B congctl -.IR NAME " ]" +.IR NAME " ] [ " .B pref .IR PREF " ]" -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH iproute2 net-next 2/2] iproute2: ip-route.8.in: Add expires option for ip route
Signed-off-by: Hangbin Liu --- man/man8/ip-route.8.in | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in index 5b45bc2..c5494f8 100644 --- a/man/man8/ip-route.8.in +++ b/man/man8/ip-route.8.in @@ -130,7 +130,9 @@ replace " } " .B congctl .IR NAME " ] [ " .B pref -.IR PREF " ]" +.IR PREF " ] [ " +.B expires +.IR TIME " ]" .ti -8 .IR TYPE " := [ " @@ -593,6 +595,12 @@ Discovery messages. Namely: .RE .TP +.BI expires " TIME " "(4.4+ only)" +the route will be deleted after the expires time. +.B Only +support IPv6 at present. + +.TP ip route delete delete route .RS -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 00/28] DSA: Restructure probing
Le 24/12/2015 04:58, Andrew Lunn a écrit :
>> I do not think you need the platform device because ultimately what the
>> DSA platform device does is bind some data to the master network device
>> the DSA switch tree is hanging off. Sure you need some piece of code
>> that is resident in kernel or module space to be able to parse and
>> allocate that data structure and bind multiple switch drivers together,
>> but that could be a consequence of probing switch driver using their bus
>> probe function.
>>
>> The way I would imagine this in a cluster configuration is that you
>> probe switches in the order in which they should appear in the final
>> switch tree (if this order cannot be guaranteed, then defer until it
>> is), and as you parse Device Tree for these switches you allocate their
>> resources and update the dsa_switch_tree structure "live".
>
> How do you get this ordering? You cannot control the probe order in
> Linux.
Fair enough, then the ordering is not that important after all, the
cases could be something like these:
- all switch drivers built into the kernel, whichever gets probed first
creates the dsa_switch_tree and attaches its to the master network device
- subsequent switch drivers probed locate that master network device,
use the dsa_switch_tree and insert themselves at the correct index
If you need a working switch tree to boot your system from the network,
then all of this probing will eventually converge thanks to deferred
probing. If you build everything as a module, then the expectation as an
end-user could be that the switch tree becomes only fully functional
when *all* modules, and consequently switch devices are loaded/created.
Whether the switch tree is functional in between is something that
mostly depends on the default switch configuration left by
bootloader/reset defaults, so your mileage may vary.
>
>> If we are using Device Tree this is relatively easy since we can lookup
>> the entire Device Tree to know the switch tree topology whenever we
>> probe a switch device driver. If we are using platform data, then, we
>> should have a way to associate a given MDIO bus address with
>> supplementary information, very much like what this patch does:
>
> One of my aims is to abstract away the MDIO bus from DSA. How you talk
> to the switch is a switch device property. SF2 has a different way to
> talk to the switch, memory mapped IO, etc.
I appreciate you trying to see my point of view and mentioning the
driver that I care about, but I am not just after SF2 here, just any
kind of switch in general: PCIe, SPI, I2C, GPIO, MDIO, MMIO is precisely
what I would like to solve instead of narrow MDIO and distributed case
that DSA currently deals with, and MMIO with some help from the of_*
routines which do not need any kind of bus probing and struct device
creation (most often).
>
> Anyway, who do you think the device tree binding will look? Maybe take
> the .dts file in patches 2 and 20 to build an example?
The binding would look pretty much the same as what the current DSA and
your proposed binding look like, except that instead of encoding the
MDIO address *and* the switch index in tree in the same "reg" properties
(which was wrong along, but I did not really knew it back in 2009 or
so), the two would be different properties.
When you parse the Device Tree you can determine what is the position of
the switch in the switch tree by looking at its ports sub-nodes and see
if they have a "link" property which links them to another device,
eventually, in case where there is not a one to one, but one to many
connection, an additional property can help you figure out how to
flatten things out.
So in practical terms, this could wind up looking like this:
mdio_bus@deadbeef {
compatible = "acme,mdiobus";
..
switch0@0 {
compatible = "marvell,mv88e6131";
reg = <0>;
dsa,addr = <1>;
switch0port5: port@5 {
reg = <5>;
label = "dsa";
link = <&switch1port9>;
};
};
};
};
soc-bus@cafebabe {
compatible = "simple-bus";
switch1@cafedead {
compatible = "marvell,armada-xp-switch";
reg = <0xcafedead 0x1000>;
dsa,addr = <0>;
switch1port9: port9 {
reg = <9>;
label = "dsa";
link = <&switch0port5>;
};
};
};
That way you could even intertwine foreign bus switches, and that would
not make a slight difference in how they are managed by DSA.
Your changes in patch 20 make your switches appear out of any busing
hierarchy whereas they are actually child devices of their respective
mdio-mux bus nodes and should appear as such imho.
--
Florian
--
To unsubscribe from this list: send the l
Re: [PATCH RFC 25/28] Documentation: DSA: Describe how probe of DSA and switches work.
Le 23/12/2015 14:53, Andrew Lunn a écrit : > On Wed, Dec 23, 2015 at 12:48:28PM -0800, Florian Fainelli wrote: >> Le 23/12/2015 04:56, Andrew Lunn a écrit : >>> With the introduction of switches as linux devices and the use of the >>> component framework, probing has become more complex. Add some >>> documentation. >>> >>> Signed-off-by: Andrew Lunn >>> --- >>> Documentation/networking/dsa/dsa.txt | 48 >>> >>> 1 file changed, 48 insertions(+) >>> >>> diff --git a/Documentation/networking/dsa/dsa.txt >>> b/Documentation/networking/dsa/dsa.txt >>> index aa9c1f9313cd..376afa135a81 100644 >>> --- a/Documentation/networking/dsa/dsa.txt >>> +++ b/Documentation/networking/dsa/dsa.txt >>> @@ -398,6 +398,54 @@ Switch configuration >>>on the management interface and "hardcode"/"force" this MAC address for >>> the >>>CPU/management interface as an optimization >>> >>> +Call flow >>> +- >>> + >>> +With the ability for switch devices to be true linux devices, the call >>> +flow is somewhat complex. The component framework is used to link the >>> +dsa framework as the master, with switch devices, as slaves. >>> + >>> +A switch device should add itself as a component in its probe >>> +function. >>> + >>> +The DSA framework can either be configured using a platform_data >>> +structure or from the device tree. If device tree is being used, the >>> +dsa framework probe function will allocate a platform_data structure, >>> +and populate it using the device tree, via the dsa_of_probe() >>> +function. Within the DSA device tree, switch devices are represented >>> +by a phandle to the switch device. These phandles are saved into the >>> +platform data so that when switch slaves register themselves, they can >>> +be correctly positioned in the DSA cluster. >> >> Humm, I guess I am still not clear on that, in a DT-only system, do I >> still need to get the DSA platform device to be probed via DT, along >> with references to the switches I want? If that is the case, that seems >> a little awkward, could not we probe the individual switches, and see if >> they need DSA instead? Or is that how the component framework works, >> just being a bit confused here. > > The component framework needs one master device and a number of slave > devices. The master device effectively gives the framework a list of > slave devices it needs. When the slave devices probe they register > with the component framework. The master then asks the framework if > its slaves are present, and if not returns -EPRODE_DEFERS and tries > again later. > > So the dsa platform device is the master, and the switch devices are > the slaves. Ok, but then that means I still need to have a "marvell,dsa" node in Device Tree, that does not make sense to me with your changes, because the individual compatible and nodes for the switches are enough information to get their driver to probe, and as a consequence, register with DSA their switch devices, but let's keep following this point in the cover letter thread. > > It sounds like you want to 'optimise' for a DSA cluster consisting of > a single switch, throwing away the D in DSA. Now the SF2 is a bit > 'odd'. Since it is embedded in the SoC, you cannot have multiple of > them in a cluster. So such an optimization could make sense for the > SF2. But can we do this without adding too more complexity? The distributed case is the complex one, the one with a single switch hanging off an Ethernet MAC is the most common one and is much simpler to deal with. -- Florian -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: kernel panic in ipv6_defrag
On 12/23/2015 04:59 PM, Florian Westphal wrote:
> Junxiao Bi wrote:
>> The following panic happened when I run ocfs2-test on linux-next. Kernel
>> config is attached.
>>
>> [64910.905501] BUG: unable to handle kernel NULL pointer dereference at
>> (null)
>> [64910.906466] IP: [] nf_ct_frag6_gather+0x7ad/0x9c0
> [..]
>> ocfs2_stack_o2cb(O) ocfs2_dlm(O) ocfs2_nodemanager(O) ocfs2_stackglue(O)
>> iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi xen_kbdfront
>> xen_netfront xen_fbfront xen_blkfront [last unloaded: ocfs2_stackglue]
>> [64910.906466] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
>> 4.4.0-rc5-next-20151217 #1
>
> Seems like this snapshot still lacks
>
> e97ac12859dbf4d3ee0eddb9798867541d1d1e1e
> ("netfilter: ipv6: nf_defrag: fix NULL deref panic"),
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/net/ipv6/netfilter/nf_conntrack_reasm.c?id=e97ac12859dbf4d3ee0eddb9798867541d1d1e1e
>
> Its included starting with next-20151221.
>
> Please report back if it occurs with above commit present.
Looks issue resolved with this fix. Thank you.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2] ip_tunnel: Move stats update to iptunnel_xmit()
On Thu, Dec 24, 2015 at 1:14 AM, Nicolas Dichtel
wrote:
> Le 24/12/2015 00:52, Pravin B Shelar a écrit :
> [snip]
>>
>> @@ -83,22 +84,12 @@ int ip6_tnl_get_iflink(const struct net_device *dev);
>> static inline void ip6tunnel_xmit(struct sock *sk, struct sk_buff *skb,
>> struct net_device *dev)
>> {
>> - struct net_device_stats *stats = &dev->stats;
>> int pkt_len, err;
>>
>> pkt_len = skb->len - skb_inner_network_offset(skb);
>> err = ip6_local_out(dev_net(skb_dst(skb)->dev), sk, skb);
>> -
>> - if (net_xmit_eval(err) == 0) {
>> - struct pcpu_sw_netstats *tstats =
>> get_cpu_ptr(dev->tstats);
>> - u64_stats_update_begin(&tstats->syncp);
>> - tstats->tx_bytes += pkt_len;
>> - tstats->tx_packets++;
>> - u64_stats_update_end(&tstats->syncp);
>> - put_cpu_ptr(tstats);
>> - } else {
>> - stats->tx_errors++;
>> - stats->tx_aborted_errors++;
>> - }
>> + if (likely(!net_xmit_eval(err)))
>> + err = pkt_len;
>> + iptunnel_xmit_stats(dev, err);
>
> I don't think this is an equivalent change.
> For example, if err == NET_XMIT_DROP, then '!net_xmit_eval(err)' is false
> and
> iptunnel_xmit_stats() is called with err set to a positive value
> (NET_XMIT_DROP
> value is 0x01), ie not an error.
I have sent out updated patch handle it correctly.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v3] ip_tunnel: Move stats update to iptunnel_xmit()
By moving stats update into iptunnel_xmit(), we can simplify
iptunnel_xmit() usage. With this change there is no need to
call another function (iptunnel_xmit_stats()) to update stats
in tunnel xmit code path.
Signed-off-by: Pravin B Shelar
---
v2-v3:
- Fixed ip6tunnel_xmit()
v1-v2:
- keep iptunnel_xmit_stats() stats update same.
---
drivers/net/geneve.c | 17 -
drivers/net/vxlan.c | 9 -
include/net/ip6_tunnel.h | 17 -
include/net/ip_tunnels.h | 28 +++-
include/net/udp_tunnel.h | 8
net/ipv4/ip_gre.c | 7 +++
net/ipv4/ip_tunnel.c | 7 ++-
net/ipv4/ip_tunnel_core.c | 9 +
net/ipv4/ip_vti.c | 2 +-
net/ipv4/udp_tunnel.c | 11 +--
net/ipv6/sit.c| 7 ++-
net/tipc/udp_media.c | 12 +++-
12 files changed, 56 insertions(+), 78 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index e6e0092..20dd664 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -918,12 +918,11 @@ static netdev_tx_t geneve_xmit_skb(struct sk_buff *skb,
struct net_device *dev,
ttl = ttl ? : ip4_dst_hoplimit(&rt->dst);
df = 0;
}
- err = udp_tunnel_xmit_skb(rt, gs4->sock->sk, skb, fl4.saddr, fl4.daddr,
- tos, ttl, df, sport, geneve->dst_port,
- !net_eq(geneve->net, dev_net(geneve->dev)),
- !(flags & GENEVE_F_UDP_CSUM));
+ udp_tunnel_xmit_skb(rt, gs4->sock->sk, skb, fl4.saddr, fl4.daddr,
+ tos, ttl, df, sport, geneve->dst_port,
+ !net_eq(geneve->net, dev_net(geneve->dev)),
+ !(flags & GENEVE_F_UDP_CSUM));
- iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
return NETDEV_TX_OK;
tx_error:
@@ -1005,10 +1004,10 @@ static netdev_tx_t geneve6_xmit_skb(struct sk_buff
*skb, struct net_device *dev,
ttl = 1;
ttl = ttl ? : ip6_dst_hoplimit(dst);
}
- err = udp_tunnel6_xmit_skb(dst, gs6->sock->sk, skb, dev,
- &fl6.saddr, &fl6.daddr, prio, ttl,
- sport, geneve->dst_port,
- !!(flags & GENEVE_F_UDP_ZERO_CSUM6_TX));
+ udp_tunnel6_xmit_skb(dst, gs6->sock->sk, skb, dev,
+&fl6.saddr, &fl6.daddr, prio, ttl,
+sport, geneve->dst_port,
+!!(flags & GENEVE_F_UDP_ZERO_CSUM6_TX));
return NETDEV_TX_OK;
tx_error:
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ba363ce..fecf7b6 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1841,9 +1841,10 @@ static int vxlan_xmit_skb(struct rtable *rt, struct sock
*sk, struct sk_buff *sk
skb_set_inner_protocol(skb, htons(ETH_P_TEB));
- return udp_tunnel_xmit_skb(rt, sk, skb, src, dst, tos,
- ttl, df, src_port, dst_port, xnet,
- !(vxflags & VXLAN_F_UDP_CSUM));
+ udp_tunnel_xmit_skb(rt, sk, skb, src, dst, tos, ttl, df,
+ src_port, dst_port, xnet,
+ !(vxflags & VXLAN_F_UDP_CSUM));
+ return 0;
}
#if IS_ENABLED(CONFIG_IPV6)
@@ -2056,8 +2057,6 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
skb = NULL;
goto rt_tx_error;
}
-
- iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
#if IS_ENABLED(CONFIG_IPV6)
} else {
struct dst_entry *ndst;
diff --git a/include/net/ip6_tunnel.h b/include/net/ip6_tunnel.h
index ff788b6..ae07e947 100644
--- a/include/net/ip6_tunnel.h
+++ b/include/net/ip6_tunnel.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#define IP6TUNNEL_ERR_TIMEO (30*HZ)
@@ -83,22 +84,12 @@ int ip6_tnl_get_iflink(const struct net_device *dev);
static inline void ip6tunnel_xmit(struct sock *sk, struct sk_buff *skb,
struct net_device *dev)
{
- struct net_device_stats *stats = &dev->stats;
int pkt_len, err;
pkt_len = skb->len - skb_inner_network_offset(skb);
err = ip6_local_out(dev_net(skb_dst(skb)->dev), sk, skb);
-
- if (net_xmit_eval(err) == 0) {
- struct pcpu_sw_netstats *tstats = get_cpu_ptr(dev->tstats);
- u64_stats_update_begin(&tstats->syncp);
- tstats->tx_bytes += pkt_len;
- tstats->tx_packets++;
- u64_stats_update_end(&tstats->syncp);
- put_cpu_ptr(tstats);
- } else {
- stats->tx_errors++;
- stats->tx_aborted_errors++;
- }
+ if (unlikely(net_xmit_eval(err)))
+ pkt_len = -1;
+ iptunnel_xmit_stats(
Re: [PATCH V1 08/16] i40iw: add files for iwarp interface
On Thu, Dec 24, 2015 at 10:25:08AM +0200, Or Gerlitz wrote:
> On 12/24/2015 9:31 AM, Faisal Latif wrote:
> >On Wed, Dec 23, 2015 at 08:42:01AM -0800, Or Gerlitz wrote:
> >>On 12/22/2015 1:13 AM, Faisal Latif wrote:
> >>>+
> >>>+enum i40iw_memreg_type {
> >>>+ IW_MEMREG_TYPE_MEM = 0x,
> >>>+ IW_MEMREG_TYPE_QP = 0x0001,
> >>>+ IW_MEMREG_TYPE_CQ = 0x0002,
> >>>+ IW_MEMREG_TYPE_MW = 0x0003,
> >>>+ IW_MEMREG_TYPE_FMR = 0x0004,
> >>>+ IW_MEMREG_TYPE_FMEM = 0x0005,
> >>>+};
> >>Can't you re-use IB core values or derive that from the actual uverbs
> >>command?
> >I did not see anything which will have types that I needed.
>
> what do you need? what is the role of this enum?
We register register memory from user library for qp and cq rings as well
as user memory registration and do need to distinguish in the driver.
>
> >It will be confusing otherwise.
>
>
> >I will be reducing number of types from here though.
>
> so why some of it can go? is that deal values which aren't used by the code
Yes, had added all different types for user requests. But For the time being,
we will
just keep MEM, CQ, QP and add other as needed like Memory Windows.
>
> Or.
>
> >Thanks
> >Faisal
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] can: sja1000: of: add per-compatible init hook
This commit adds the capability to allocate and init private data
embedded in the sja1000_priv structure on a per-compatible basis. The
device node is passed as a parameter of the init callback to allow
parsing of custom device tree properties.
Signed-off-by: Damien Riegel
---
drivers/net/can/sja1000/sja1000_platform.c | 39 --
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/sja1000/sja1000_platform.c
b/drivers/net/can/sja1000/sja1000_platform.c
index 0552ed4..e0572d0 100644
--- a/drivers/net/can/sja1000/sja1000_platform.c
+++ b/drivers/net/can/sja1000/sja1000_platform.c
@@ -40,6 +40,11 @@ MODULE_DESCRIPTION("Socket-CAN driver for SJA1000 on the
platform bus");
MODULE_ALIAS("platform:" DRV_NAME);
MODULE_LICENSE("GPL v2");
+struct sja1000_of_data {
+ size_t priv_sz;
+ int (*init)(struct sja1000_priv *priv, struct device_node *of);
+};
+
static u8 sp_read_reg8(const struct sja1000_priv *priv, int reg)
{
return ioread8(priv->reg_base + reg);
@@ -154,7 +159,8 @@ static void sp_populate_of(struct sja1000_priv *priv,
struct device_node *of)
priv->cdr |= CDR_CBP; /* default */
}
-static int sp_probe(struct platform_device *pdev)
+static int __sp_probe(struct platform_device *pdev,
+ const struct sja1000_of_data *of_data)
{
int err, irq = 0;
void __iomem *addr;
@@ -163,6 +169,7 @@ static int sp_probe(struct platform_device *pdev)
struct resource *res_mem, *res_irq = NULL;
struct sja1000_platform_data *pdata;
struct device_node *of = pdev->dev.of_node;
+ size_t priv_sz = of_data ? of_data->priv_sz : 0;
pdata = dev_get_platdata(&pdev->dev);
if (!pdata && !of) {
@@ -191,7 +198,7 @@ static int sp_probe(struct platform_device *pdev)
if (!irq && !res_irq)
return -ENODEV;
- dev = alloc_sja1000dev(0);
+ dev = alloc_sja1000dev(priv_sz);
if (!dev)
return -ENOMEM;
priv = netdev_priv(dev);
@@ -213,6 +220,12 @@ static int sp_probe(struct platform_device *pdev)
else
sp_populate(priv, pdata, res_mem->flags);
+ if (of_data && of_data->init) {
+ err = of_data->init(priv, of);
+ if (err)
+ goto exit_free;
+ }
+
platform_set_drvdata(pdev, dev);
SET_NETDEV_DEV(dev, &pdev->dev);
@@ -248,6 +261,28 @@ static const struct of_device_id sp_of_table[] = {
};
MODULE_DEVICE_TABLE(of, sp_of_table);
+static const struct sja1000_of_data *sp_get_of_data(struct device_node *of)
+{
+ const struct of_device_id *id;
+
+ if (!of)
+ return NULL;
+
+ id = of_match_node(sp_of_table, of);
+ if (!id)
+ return NULL;
+
+ return id->data;
+}
+
+static int sp_probe(struct platform_device *pdev)
+{
+ struct device_node *of = pdev->dev.of_node;
+ const struct sja1000_of_data *of_data = sp_get_of_data(of);
+
+ return __sp_probe(pdev, of_data);
+}
+
static struct platform_driver sp_driver = {
.probe = sp_probe,
.remove = sp_remove,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] can: sja1000: of: add compatibility with Technologic Systems version
Technologic Systems provides an IP compatible with the SJA1000,
instantiated in an FPGA. Because of some bus widths issue, access to
registers is made through a "window" that works like this:
base + 0x0: address to read/write
base + 0x2: 8-bit register value
This commit adds a new compatible device, "technologic,sja1000", with
read and write functions using the window mechanism.
Signed-off-by: Damien Riegel
---
drivers/net/can/sja1000/sja1000_platform.c | 47 ++
1 file changed, 47 insertions(+)
diff --git a/drivers/net/can/sja1000/sja1000_platform.c
b/drivers/net/can/sja1000/sja1000_platform.c
index e0572d0..bfb124d 100644
--- a/drivers/net/can/sja1000/sja1000_platform.c
+++ b/drivers/net/can/sja1000/sja1000_platform.c
@@ -45,6 +45,10 @@ struct sja1000_of_data {
int (*init)(struct sja1000_priv *priv, struct device_node *of);
};
+struct technologic_priv {
+ spinlock_t io_lock;
+};
+
static u8 sp_read_reg8(const struct sja1000_priv *priv, int reg)
{
return ioread8(priv->reg_base + reg);
@@ -75,6 +79,43 @@ static void sp_write_reg32(const struct sja1000_priv *priv,
int reg, u8 val)
iowrite8(val, priv->reg_base + reg * 4);
}
+static u8 technologic_read_reg16(const struct sja1000_priv *priv, int reg)
+{
+ struct technologic_priv *tp = priv->priv;
+ unsigned long flags;
+ u8 val;
+
+ spin_lock_irqsave(&tp->io_lock, flags);
+ iowrite16(reg, priv->reg_base + 0);
+ val = ioread16(priv->reg_base + 2);
+ spin_unlock_irqrestore(&tp->io_lock, flags);
+
+ return val;
+}
+
+static void technologic_write_reg16(const struct sja1000_priv *priv,
+ int reg, u8 val)
+{
+ struct technologic_priv *tp = priv->priv;
+ unsigned long flags;
+
+ spin_lock_irqsave(&tp->io_lock, flags);
+ iowrite16(reg, priv->reg_base + 0);
+ iowrite16(val, priv->reg_base + 2);
+ spin_unlock_irqrestore(&tp->io_lock, flags);
+}
+
+static int technologic_init(struct sja1000_priv *priv, struct device_node *of)
+{
+ struct technologic_priv *tp = priv->priv;
+
+ priv->read_reg = technologic_read_reg16;
+ priv->write_reg = technologic_write_reg16;
+ spin_lock_init(&tp->io_lock);
+
+ return 0;
+}
+
static void sp_populate(struct sja1000_priv *priv,
struct sja1000_platform_data *pdata,
unsigned long resource_mem_flags)
@@ -255,8 +296,14 @@ static int sp_remove(struct platform_device *pdev)
return 0;
}
+struct sja1000_of_data technologic_data = {
+ .priv_sz = sizeof(struct technologic_priv),
+ .init = technologic_init,
+};
+
static const struct of_device_id sp_of_table[] = {
{.compatible = "nxp,sja1000"},
+ {.compatible = "technologic,sja1000", .data = &technologic_data},
{},
};
MODULE_DEVICE_TABLE(of, sp_of_table);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] can: sja1000: support for technologic version
This patchset introduces support for the technologic version of the
SJA1000. Access to IP's registers are proxied through a window,
requiring two bus accesses to read or write a register. These accesses
must be protected by a spinlock to prevent race conditions. Currently,
there is no easy way to allocate and initialize this spinlock.
SJA1000 already provides a way to allocate private data, but
sja1000_platform.c makes no use of it.
Patch 1 adds the capability to allocate and initialize private data on a
per-compatible basis in sja1000_platform.c.
Patch 2 updates device tree documentation to add the technologic
version.
Patch 3 updates the driver to implement the technologic version
Changes in v2:
- added a patch to allocate and initialize private data
- changed device tree documentation
- added a spinlock to protect bus accesses
- changed sp_{read,write}_reg16 to io{read,write}16
Damien Riegel (3):
can: sja1000: of: add per-compatible init hook
can: sja1000: add documentation for Technologic Systems version
can: sja1000: of: add compatibility with Technologic Systems version
.../devicetree/bindings/net/can/sja1000.txt| 3 +-
drivers/net/can/sja1000/sja1000_platform.c | 86 +-
2 files changed, 86 insertions(+), 3 deletions(-)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] can: sja1000: add documentation for Technologic Systems version
This commit adds documentation for the Technologic Systems version of SJA1000. The difference with the NXP version is in the way the registers are accessed. Signed-off-by: Damien Riegel --- Documentation/devicetree/bindings/net/can/sja1000.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/can/sja1000.txt b/Documentation/devicetree/bindings/net/can/sja1000.txt index b4a6d53..ac3160e 100644 --- a/Documentation/devicetree/bindings/net/can/sja1000.txt +++ b/Documentation/devicetree/bindings/net/can/sja1000.txt @@ -2,7 +2,7 @@ Memory mapped SJA1000 CAN controller from NXP (formerly Philips) Required properties: -- compatible : should be "nxp,sja1000". +- compatible : should be one of "nxp,sja1000", "technologic,sja1000". - reg : should specify the chip select, address offset and size required to map the registers of the SJA1000. The size is usually 0x80. @@ -14,6 +14,7 @@ Optional properties: - reg-io-width : Specify the size (in bytes) of the IO accesses that should be performed on the device. Valid value is 1, 2 or 4. + This property is ignored for technologic version. Default to 1 (8 bits). - nxp,external-clock-frequency : Frequency of the external oscillator -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 3/4] soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF
On Tue, Dec 22, 2015 at 03:05:09PM -0500, Craig Gallek wrote:
> From: Craig Gallek
>
> Expose socket options for setting a classic or extended BPF program
> for use when selecting sockets in an SO_REUSEPORT group. These options
> can be used on the first socket to belong to a group before bind or
> on any socket in the group after bind.
>
> This change includes refactoring of the existing sk_filter code to
> allow reuse of the existing BPF filter validation checks.
>
> Signed-off-by: Craig Gallek
interesting stuff.
> +static struct sock *run_bpf(struct sock_reuseport *reuse, u16 socks,
> + struct bpf_prog *prog, struct sk_buff *skb,
> + int hdr_len)
> +{
> + struct sk_buff *nskb = NULL;
> + u32 index;
> +
> + if (skb_shared(skb)) {
> + nskb = skb_clone(skb, GFP_ATOMIC);
> + if (!nskb)
> + return NULL;
> + skb = nskb;
> + }
what is the typical case here skb_shared or not?
> + /* temporarily advance data past protocol header */
> + if (skb_headlen(skb) < hdr_len || !skb_pull_inline(skb, hdr_len)) {
though bpf core will read just fine past linear part of the packet,
here we're limiting this feature only to packets where udp header is
part of headlen. Will it make it somewhat unreliable?
May be we can avoid doing this pull/push and use negative load
instructions with SKF_NET_OFF ? Something like:
load_word(skb, SKF_NET_OFF + sizeof(struct udphdr)));
> /**
> * reuseport_select_sock - Select a socket from an SO_REUSEPORT group.
> * @sk: First socket in the group.
> - * @hash: Use this hash to select.
> + * @hash: When no BPF filter is available, use this hash to select.
> + * @skb: skb to run through BPF filter.
> + * @hdr_len: BPF filter expects skb data pointer at payload data. If
> + *the skb does not yet point at the payload, this parameter represents
> + *how far the pointer needs to advance to reach the payload.
what is the use case of this?
Do you expect programs to be stateful?
> + sk2 = reuseport_select_sock(sk, hash, NULL, 0);
...
> + sk2 = reuseport_select_sock(sk, hash, skb,
> + sizeof(struct udphdr));
these are the cases that comment is trying to explain?
Meaning the bpf program needs to understand well enough when udp stack
is calling it ?
Will do more careful review of bpf bits once I'm back from PTO.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled
On Thu, 24 Dec 2015, Oliver Neukum wrote: > On Thu, 2015-12-24 at 10:14 -0500, Alan Stern wrote: > > On Thu, 24 Dec 2015, Oliver Neukum wrote: > > > > > On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote: > > > > But you cannot keep that setting if the system goes down > > > or any broadcast packet would resume the whole system. > > > Yet you cannot just disable remote wake up, as WoL packages > > > still must trigger a remote wake up. > > > > This means that sometimes you want to avoid losing packets and other > > times you do want to lose packets. That is a policy decision, and > > therefore it should be made by the user, not the kernel. > > Indeed it is and there is a tool for this with a defined > interface called "ethtool" No; ethtool affects the wakeup setting for system suspend, but not for runtime suspend. I was referring to something that would specify the setting for both cases. But perhaps that doesn't make sense, because you never want to drop relevant packets during runtime suspend. If you did, you would run "ifconfig down" instead. > > the PM core aren't adequate for what the driver needs. The PM core > > distinguishes between wakeup enabled or disabled; it doesn't > > distinguish among different levels of wakekup. > > True and sanely it cannot. We could only distinguish between drivers > which need their devices to be resumed before the system suspends and > the rest. > Or we tell driver coders to use the notifier chains. "Resume before system suspend" sounds like a reasonable thing to implement, for devices that have multiple levels of wakeup settings. Would you like to post a proposal on linux-pm for this? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] cxgb4: Get TID calculation right for IPv6 mode
From: Hariprasad Shenai Date: Thu, 24 Dec 2015 16:15:17 +0530 > CLIP is always enabled and hardware uses 2 TID entries instead of 4 for > IPv6 in CLIP mode. > > Signed-off-by: Hariprasad Shenai Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] cxgb4: Remove deprecated module parameters
From: Hariprasad Shenai Date: Thu, 24 Dec 2015 16:24:53 +0530 > Remove deprecated module parameters, and mark one parameter as > deprecated. > > Signed-off-by: Hariprasad Shenai Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] qlcnic: fix a loop exit condition better
From: Dan Carpenter
Date: Thu, 24 Dec 2015 12:21:22 +0300
> In the original code, if we succeeded on the last iteration through the
> loop then we still returned failure.
>
> Fixes: 389e4e04ad2d ('qlcnic: fix a timeout loop')
> Signed-off-by: Dan Carpenter
Applied, thanks Dan.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled
On Thu, 2015-12-24 at 10:14 -0500, Alan Stern wrote: > On Thu, 24 Dec 2015, Oliver Neukum wrote: > > > On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote: > > But you cannot keep that setting if the system goes down > > or any broadcast packet would resume the whole system. > > Yet you cannot just disable remote wake up, as WoL packages > > still must trigger a remote wake up. > > This means that sometimes you want to avoid losing packets and other > times you do want to lose packets. That is a policy decision, and > therefore it should be made by the user, not the kernel. Indeed it is and there is a tool for this with a defined interface called "ethtool" The problem here is not the policy decision, but implementing it in kernel space. > > So there are drivers which must change settings on devices > > as the system goes to sleep, even if their devices have > > already been autosuspended. We could use the notifier chains > > for that. But can this solution be called elegant? > > Instead of the driver trying to do this automatically, you could rely > on userspace telling the driver which packets should cause a wakeup. It does. > The setting could be updated immediately before and after each system > suspend. The API is so that user space sets the policy, which persists until user space changes the setting and the kernel implements it. The problem is that to do so the kernel needs to do IO to the device as the system is about to suspend. Thus the driver may need to resume the device and it needs to learn that the system is about to go to sleep, even if the device it manages is already autosuspended. > I admit this is more awkward than having the driver make a choice based > on the type of suspend. This is a case where the resources provided by It also is a race condition, unless you want user space to disable autosuspend as the system is about to go to sleep. And it makes relatively little sense, as enabling remote wakeup is the last thing we do before the device suspends. Setting the filters long before that doesn't make much sense. > the PM core aren't adequate for what the driver needs. The PM core > distinguishes between wakeup enabled or disabled; it doesn't > distinguish among different levels of wakekup. True and sanely it cannot. We could only distinguish between drivers which need their devices to be resumed before the system suspends and the rest. Or we tell driver coders to use the notifier chains. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled
On Thu, 24 Dec 2015, Oliver Neukum wrote: > On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote: > > > I don't understand why the wakeup conditions are different. It seems > > to me that the choice of which packets will generate a wakeup ought to > > depend on the user's selection, not on the kind of suspend. For > > instance, if the user says that only a magic packet should cause a > > wakeup then that should be true for both runtime suspend and system > > suspend. > > > > To put it another way, as far as the device is concerned a suspend is > > just a suspend -- there's no different between a runtime suspend and a > > system suspend. > > This literally true, but the host and the driver care. > If we autosuspend a running network device, any packet > (maybe filtered for MAC) should cause a remote wake up, > else we'd lose packets. That's also true during system suspend. > But you cannot keep that setting if the system goes down > or any broadcast packet would resume the whole system. > Yet you cannot just disable remote wake up, as WoL packages > still must trigger a remote wake up. This means that sometimes you want to avoid losing packets and other times you do want to lose packets. That is a policy decision, and therefore it should be made by the user, not the kernel. > So there are drivers which must change settings on devices > as the system goes to sleep, even if their devices have > already been autosuspended. We could use the notifier chains > for that. But can this solution be called elegant? Instead of the driver trying to do this automatically, you could rely on userspace telling the driver which packets should cause a wakeup. The setting could be updated immediately before and after each system suspend. I admit this is more awkward than having the driver make a choice based on the type of suspend. This is a case where the resources provided by the PM core aren't adequate for what the driver needs. The PM core distinguishes between wakeup enabled or disabled; it doesn't distinguish among different levels of wakekup. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex
>-Original Message-
>From: zhuyj [mailto:zyjzyj2...@gmail.com]
>Sent: Wednesday, December 23, 2015 10:24 PM
>To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak,
>John; Williams, Mitch A; intel-wired-...@lists.osuosl.org;
>netdev@vger.kernel.org; e1000-de...@lists.sourceforge.net
>Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); Bourg,
>Vincent (Wind River)
>Subject: Re: [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize
>reporting "link on" and getting speed and duplex
>
>On 12/24/2015 01:58 PM, Tantilov, Emil S wrote:
>>> -Original Message-
>>> From: zhuyj [mailto:zyjzyj2...@gmail.com]
>>> Sent: Wednesday, December 23, 2015 6:28 PM
>>> To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>>> Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak,
>>> John; Williams, Mitch A; intel-wired-...@lists.osuosl.org;
>>> netdev@vger.kernel.org; e1000-de...@lists.sourceforge.net
>>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River);
>Bourg,
>>> Vincent (Wind River)
>>> Subject: Re: [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize
>>> reporting "link on" and getting speed and duplex
>>>
>>> On 12/23/2015 11:59 PM, Tantilov, Emil S wrote:
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-
>boun...@lists.osuosl.org]
>>> On
> Behalf Of zyjzyj2...@gmail.com
> Sent: Tuesday, December 22, 2015 10:47 PM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
> Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak, John; Williams,
>>> Mitch
> A; intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; e1000-
> de...@lists.sourceforge.net
> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River);
>>> Bourg,
> Vincent (Wind River)
> Subject: [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize
> reporting "link on" and getting speed and duplex
>
> From: Zhu Yanjun
>
> In X540 NIC, there is a time span between reporting "link on" and
> getting the speed and duplex. To a bonding driver in 802.3ad mode,
> this time span will make it not work well if the time span is big
> enough. The big time span will make bonding driver change the state of
> the slave device to up while the speed and duplex of the slave device
> can not be gotten. Later the bonding driver will not have change to
> get the speed and duplex of the slave device. The speed and duplex of
> the slave device are important to a bonding driver in 802.3ad mode.
>
> To 82599_SFP NIC and other kinds of NICs, this problem does
> not exist. As such, it is necessary for X540 to report"link on" when
> the link speed is not IXGBE_LINK_SPEED_UNKNOWN.
>
> Signed-off-by: Zhu Yanjun
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index aed8d02..cb9d310 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -6479,7 +6479,21 @@ static void ixgbe_watchdog_link_is_up(struct
> ixgbe_adapter *adapter)
> (flow_rx ? "RX" :
> (flow_tx ? "TX" : "None";
>
> - netif_carrier_on(netdev);
> + /*
> + * In X540 NIC, there is a time span between reporting "link
>on"
> + * and getting the speed and duplex. To a bonding driver in
>802.3ad
> + * mode, this time span will make it not work well if the time
>span
> + * is big enough. To 82599_SFP NIC and other kinds of NICs,
>this
> + * problem does not exist. As such, it is better for X540 to
>report
> + * "link on" when the link speed is not
>IXGBE_LINK_SPEED_UNKNOWN.
> + */
> + if ((hw->mac.type == ixgbe_mac_X540) &&
> + (link_speed != IXGBE_LINK_SPEED_UNKNOWN)) {
> + netif_carrier_on(netdev);
> + } else {
> + netif_carrier_on(netdev);
> + }
> +
> ixgbe_check_vf_rate_limit(adapter);
>
> /* enable transmits */
> --
> 1.7.9.5
NAK
I have already submitted a patch that will address the issue with
>bonding
>>> reporting
unknown speed (in /proc/bonding/bondX) after the link is established
>due
>>> to link flaps:
http://patchwork.ozlabs.org/patch/552485/
The bonding driver gets the speed from ethtool and this is where the
>>> reporting needs
to be fixed. The issue is that the bonding driver polls for
>>> netif_carrier_ok() at a
certain rate and as such will not be able to detect rapid link changes.
>>> Thanks for your reply. The root cause is different from my problem. My
>>> problem is that
>>> "link up" is prior
Re: [PATCH net-next v2] ip_tunnel: Move stats update to iptunnel_xmit()
Le 24/12/2015 13:46, Thadeu Lima de Souza Cascardo a écrit :
On Thu, Dec 24, 2015 at 10:21:27AM +0100, Nicolas Dichtel wrote:
Le 24/12/2015 00:52, Pravin B Shelar a écrit :
[snip]
diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index 6af78c6..d63a911 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -182,15 +182,9 @@ static int tipc_udp_send_msg(struct net *net, struct
sk_buff *skb,
goto tx_error;
}
ttl = ip4_dst_hoplimit(&rt->dst);
- err = udp_tunnel_xmit_skb(rt, ub->ubsock->sk, skb,
- src->ipv4.s_addr,
- dst->ipv4.s_addr, 0, ttl, 0,
- src->udp_port, dst->udp_port,
- false, true);
- if (err < 0) {
- ip_rt_put(rt);
- goto tx_error;
- }
+ udp_tunnel_xmit_skb(rt, ub->ubsock->sk, skb, src->ipv4.s_addr,
+ dst->ipv4.s_addr, 0, ttl, 0, src->udp_port,
+ dst->udp_port, false, true);
I don't know how tipc works, but this change is clearly suspect. What make the
error path not needed anymore after your patch?
I looked into it as well. As far as I see, err could only be positive or 0, so
if there is a tipc bug here, Pravin's patch introduces no regression. Or did I
fail to see how udp_tunnel_xmit_skb could return a negative value?
You're probably right. But I think it needs a separate patch in that case.
Regards,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] wlcore/wl12xx: spi: fix NULL pointer dereference (Oops)
Fix the below Oops when trying to modprobe wlcore_spi.
The oops occurs because the wl1271_power_{off,on}()
function doesn't check the power() function pointer.
[ 23.401447] Unable to handle kernel NULL pointer dereference at
virtual address
[ 23.409954] pgd = c0004000
[ 23.412922] [] *pgd=
[ 23.416693] Internal error: Oops: 8007 [#1] SMP ARM
[ 23.422168] Modules linked in: wl12xx wlcore mac80211 cfg80211
musb_dsps musb_hdrc usbcore usb_common snd_soc_simple_card evdev joydev
omap_rng wlcore_spi snd_soc_tlv320aic23_i2c rng_core snd_soc_tlv320aic23
c_can_platform c_can can_dev snd_soc_davinci_mcasp snd_soc_edma
snd_soc_omap omap_wdt musb_am335x cpufreq_dt thermal_sys hwmon
[ 23.453253] CPU: 0 PID: 36 Comm: kworker/0:2 Not tainted
4.2.0-2-g951efee-dirty #233
[ 23.461720] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 23.468123] Workqueue: events request_firmware_work_func
[ 23.473690] task: de32efc0 ti: de4ee000 task.ti: de4ee000
[ 23.479341] PC is at 0x0
[ 23.482112] LR is at wl12xx_set_power_on+0x28/0x124 [wlcore]
[ 23.488074] pc : [<>]lr : []psr: 6013
[ 23.488074] sp : de4efe50 ip : 0002 fp :
[ 23.500162] r10: de7cdd00 r9 : dc848800 r8 : bf27af00
[ 23.505663] r7 : bf27a1a8 r6 : dcbd8a80 r5 : dce0e2e0 r4 :
dce0d2e0
[ 23.512536] r3 : r2 : r1 : 0001 r0 :
dc848810
[ 23.519412] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 23.527109] Control: 10c5387d Table: 9cb78019 DAC: 0015
[ 23.533160] Process kworker/0:2 (pid: 36, stack limit = 0xde4ee218)
[ 23.539760] Stack: (0xde4efe50 to 0xde4f)
[...]
[ 23.665030] [] (wl12xx_set_power_on [wlcore]) from
[] (wlcore_nvs_cb+0x118/0xa4c [wlcore])
[ 23.675604] [] (wlcore_nvs_cb [wlcore]) from []
(request_firmware_work_func+0x30/0x58)
[ 23.685784] [] (request_firmware_work_func) from
[] (process_one_work+0x1b4/0x4b4)
[ 23.695591] [] (process_one_work) from []
(worker_thread+0x3c/0x4a4)
[ 23.704124] [] (worker_thread) from []
(kthread+0xd4/0xf0)
[ 23.711747] [] (kthread) from []
(ret_from_fork+0x14/0x3c)
[ 23.719357] Code: bad PC value
[ 23.722760] ---[ end trace 981be8510db9b3a9 ]---
Prevent oops by validationg power() pointer value before
calling the function.
Signed-off-by: Uri Mashiach
Cc: sta...@vger.kernel.org
Acked-by: Igor Grinberg
---
drivers/net/wireless/ti/wlcore/io.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/io.h
b/drivers/net/wireless/ti/wlcore/io.h
index 0305729..10cf374 100644
--- a/drivers/net/wireless/ti/wlcore/io.h
+++ b/drivers/net/wireless/ti/wlcore/io.h
@@ -207,19 +207,23 @@ static inline int __must_check wlcore_write_reg(struct
wl1271 *wl, int reg,
static inline void wl1271_power_off(struct wl1271 *wl)
{
- int ret;
+ int ret = 0;
if (!test_bit(WL1271_FLAG_GPIO_POWER, &wl->flags))
return;
- ret = wl->if_ops->power(wl->dev, false);
+ if (wl->if_ops->power)
+ ret = wl->if_ops->power(wl->dev, false);
if (!ret)
clear_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);
}
static inline int wl1271_power_on(struct wl1271 *wl)
{
- int ret = wl->if_ops->power(wl->dev, true);
+ int ret = 0;
+
+ if (wl->if_ops->power)
+ ret = wl->if_ops->power(wl->dev, true);
if (ret == 0)
set_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next V2 3/4] net/mlx5e: Add HW timestamping (TS) support
> +void mlx5e_fill_hwstamp(struct mlx5e_tstamp *tstamp,
> + struct skb_shared_hwtstamps *hwts,
> + u64 timestamp)
> +{
> + unsigned long flags;
> + u64 nsec;
> +
> + memset(hwts, 0, sizeof(struct skb_shared_hwtstamps));
> + read_lock_irqsave(&tstamp->lock, flags);
Richard and others,
Any special reason to use read_lock_irqsave and not just read_lock?
On second thought could not see any good reason for that,
but saw many other examples which uses irqsave.
thanks,
Eran
> + nsec = timecounter_cyc2time(&tstamp->clock, timestamp);
> + read_unlock_irqrestore(&tstamp->lock, flags);
> +
> + hwts->hwtstamp = ns_to_ktime(nsec);
> +}
> +
> +static cycle_t mlx5e_read_clock(const struct cyclecounter *cc)
> +{
> + struct mlx5e_tstamp *tstamp = container_of(cc, struct mlx5e_tstamp,
> + cycles);
> + struct mlx5e_priv *priv = container_of(tstamp, struct mlx5e_priv,
> + tstamp);
> +
> + return mlx5_core_read_clock(priv->mdev) & cc->mask;
> +}
> +
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 0/2] r8169:Update RTL8168H PHY parameters
Fix typo in setting PHY parameter and update the way of reading PHY register "rg_saw_cnt". Chunhao Lin (2): r8169:Fix typo in setting RTL8168H PHY parameter r8169:Update the way of reading RTL8168H PHY register "rg_saw_cnt" drivers/net/ethernet/realtek/r8169.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/2] r8169:Fix typo in setting RTL8168H PHY parameter
In function "rtl8168h_2_hw_phy_config", there is a typo in setting
RTL8168H PHY parameter.
Signed-off-by: Chunhao Lin
---
drivers/net/ethernet/realtek/r8169.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 79ef799..11cc32b 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3947,7 +3947,7 @@ static void rtl8168h_2_hw_phy_config(struct
rtl8169_private *tp)
data = (ioffset_p3<<12)|(ioffset_p2<<8)|(ioffset_p1<<4)|(ioffset_p0);
if ((ioffset_p3 != 0x0f) || (ioffset_p2 != 0x0f) ||
- (ioffset_p1 != 0x0f) || (ioffset_p0 == 0x0f)) {
+ (ioffset_p1 != 0x0f) || (ioffset_p0 != 0x0f)) {
rtl_writephy(tp, 0x1f, 0x0bcf);
rtl_writephy(tp, 0x16, data);
rtl_writephy(tp, 0x1f, 0x);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 2/2] r8169:Update the way of reading RTL8168H PHY register "rg_saw_cnt"
The vlaue of RTL8168H PHY register "rg_saw_cnt" only valid from bit0 to bit13.
When read this register, add bitwise-anding its value with 0x3fff.
Signed-off-by: Chunhao Lin
---
drivers/net/ethernet/realtek/r8169.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 11cc32b..58365bc 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6136,7 +6136,7 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private
*tp)
rtl_pcie_state_l2l3_enable(tp, false);
rtl_writephy(tp, 0x1f, 0x0c42);
- rg_saw_cnt = rtl_readphy(tp, 0x13);
+ rg_saw_cnt = (rtl_readphy(tp, 0x13) & 0x3fff);
rtl_writephy(tp, 0x1f, 0x);
if (rg_saw_cnt > 0) {
u16 sw_cnt_1ms_ini;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH 05/10] be2net: log digital signature errors while flashing FW image
Hello.
On 12/24/2015 12:26 PM, Sathya Perla wrote:
From: Suresh Reddy
From FW version 11.0 onwards, the FW supports a new "secure mode" feature
(based on a jumper setting on the adapter.) In this mode, the FW image when
flashed is authenticated with a digital signature. This patch logs
appropriate error messages and return a status to ethtool when errors
relating to FW image authentication occur.
Signed-off-by: Suresh Reddy
Signed-off-by: Sathya Perla
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 11 +++
drivers/net/ethernet/emulex/benet/be_cmds.h | 4 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index da3b398..6fb7873 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -2959,6 +2959,17 @@ flash:
} else if (status) {
dev_err(dev, "Flashing section type 0x%x failed\n",
img_type);
+ if (addl_status(status) ==
+ MCC_ADDL_STATUS_MISSING_SIGNATURE) {
+ dev_err(dev,
+ "Digital signature missing in FW\n");
+ return -EINVAL;
+ } else if (addl_status(status) ==
+ MCC_ADDL_STATUS_INVALID_SIGNATURE) {
+ dev_err(dev,
+ "Invalid digital signature in FW\n");
+ return -EINVAL;
+ }
Asks to be a *switch* statement.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 00/28] DSA: Restructure probing
> I do not think you need the platform device because ultimately what the > DSA platform device does is bind some data to the master network device > the DSA switch tree is hanging off. Sure you need some piece of code > that is resident in kernel or module space to be able to parse and > allocate that data structure and bind multiple switch drivers together, > but that could be a consequence of probing switch driver using their bus > probe function. > > The way I would imagine this in a cluster configuration is that you > probe switches in the order in which they should appear in the final > switch tree (if this order cannot be guaranteed, then defer until it > is), and as you parse Device Tree for these switches you allocate their > resources and update the dsa_switch_tree structure "live". How do you get this ordering? You cannot control the probe order in Linux. > If we are using Device Tree this is relatively easy since we can lookup > the entire Device Tree to know the switch tree topology whenever we > probe a switch device driver. If we are using platform data, then, we > should have a way to associate a given MDIO bus address with > supplementary information, very much like what this patch does: One of my aims is to abstract away the MDIO bus from DSA. How you talk to the switch is a switch device property. SF2 has a different way to talk to the switch, memory mapped IO, etc. Anyway, who do you think the device tree binding will look? Maybe take the .dts file in patches 2 and 20 to build an example? Andrew -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2] ip_tunnel: Move stats update to iptunnel_xmit()
On Thu, Dec 24, 2015 at 10:21:27AM +0100, Nicolas Dichtel wrote:
> Le 24/12/2015 00:52, Pravin B Shelar a écrit :
> [snip]
> >diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
> >index 6af78c6..d63a911 100644
> >--- a/net/tipc/udp_media.c
> >+++ b/net/tipc/udp_media.c
> >@@ -182,15 +182,9 @@ static int tipc_udp_send_msg(struct net *net, struct
> >sk_buff *skb,
> > goto tx_error;
> > }
> > ttl = ip4_dst_hoplimit(&rt->dst);
> >-err = udp_tunnel_xmit_skb(rt, ub->ubsock->sk, skb,
> >- src->ipv4.s_addr,
> >- dst->ipv4.s_addr, 0, ttl, 0,
> >- src->udp_port, dst->udp_port,
> >- false, true);
> >-if (err < 0) {
> >-ip_rt_put(rt);
> >-goto tx_error;
> >-}
> >+udp_tunnel_xmit_skb(rt, ub->ubsock->sk, skb, src->ipv4.s_addr,
> >+dst->ipv4.s_addr, 0, ttl, 0, src->udp_port,
> >+dst->udp_port, false, true);
> I don't know how tipc works, but this change is clearly suspect. What make the
> error path not needed anymore after your patch?
I looked into it as well. As far as I see, err could only be positive or 0, so
if there is a tipc bug here, Pravin's patch introduces no regression. Or did I
fail to see how udp_tunnel_xmit_skb could return a negative value?
Cascardo.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 2/9] Drivers: hv: vmbus: define the new offer type for Hyper-V socket (hvsock)
A helper function is also added.
Signed-off-by: Dexuan Cui
---
include/linux/hyperv.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index e4867a7..c0eddd7 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -235,6 +235,7 @@ struct vmbus_channel_offer {
#define VMBUS_CHANNEL_LOOPBACK_OFFER 0x100
#define VMBUS_CHANNEL_PARENT_OFFER 0x200
#define VMBUS_CHANNEL_REQUEST_MONITORED_NOTIFICATION 0x400
+#define VMBUS_CHANNEL_TLNPI_PROVIDER_OFFER 0x2000
struct vmpacket_descriptor {
u16 type;
@@ -769,6 +770,12 @@ struct vmbus_channel {
enum hv_signal_policy signal_policy;
};
+static inline bool is_hvsock_channel(const struct vmbus_channel *c)
+{
+ return !!(c->offermsg.offer.chn_flags &
+ VMBUS_CHANNEL_TLNPI_PROVIDER_OFFER);
+}
+
static inline void set_channel_signal_state(struct vmbus_channel *c,
enum hv_signal_policy policy)
{
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 4/9] Drivers: hv: ring_buffer: enhance hv_ringbuffer_read() to support hvsock
To get the payload of hvsock, we need raw=0 to skip the level-1 header
(i.e., struct vmpacket_descriptor desc) and we also need to skip the
level-2 header (i.e., struct vmpipe_proto_header pipe_hdr).
NB: if the length of the hvsock payload is not aligned with the 8-byte
boundeary, at most 7 padding bytes are appended, so the real hvsock
payload's length must be retrieved by the pipe_hdr.data_size field.
I 'upgrade' the 'raw' parameter of hv_ringbuffer_read() to a
'read_flags', trying to share the logic of the function.
This patch is required by the next patch, which will introduce the hvsock
send/recv APIs.
Signed-off-by: Dexuan Cui
Cc: Vitaly Kuznetsov
---
drivers/hv/channel.c | 10 +
drivers/hv/hyperv_vmbus.h | 13 +++-
drivers/hv/ring_buffer.c | 54 ---
include/linux/hyperv.h| 12 +++
4 files changed, 72 insertions(+), 17 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index eaaa066..cc49966 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -940,13 +940,14 @@ EXPORT_SYMBOL_GPL(vmbus_sendpacket_multipagebuffer);
static inline int
__vmbus_recvpacket(struct vmbus_channel *channel, void *buffer,
u32 bufferlen, u32 *buffer_actual_len, u64 *requestid,
- bool raw)
+ u32 read_flags)
{
int ret;
bool signal = false;
ret = hv_ringbuffer_read(&channel->inbound, buffer, bufferlen,
-buffer_actual_len, requestid, &signal, raw);
+buffer_actual_len, requestid, &signal,
+read_flags);
if (signal)
vmbus_setevent(channel);
@@ -959,7 +960,7 @@ int vmbus_recvpacket(struct vmbus_channel *channel, void
*buffer,
u64 *requestid)
{
return __vmbus_recvpacket(channel, buffer, bufferlen,
- buffer_actual_len, requestid, false);
+ buffer_actual_len, requestid, 0);
}
EXPORT_SYMBOL(vmbus_recvpacket);
@@ -971,6 +972,7 @@ int vmbus_recvpacket_raw(struct vmbus_channel *channel,
void *buffer,
u64 *requestid)
{
return __vmbus_recvpacket(channel, buffer, bufferlen,
- buffer_actual_len, requestid, true);
+ buffer_actual_len, requestid,
+ HV_RINGBUFFER_READ_FLAG_RAW);
}
EXPORT_SYMBOL_GPL(vmbus_recvpacket_raw);
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 0411b7b..46206b6 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -619,9 +619,20 @@ int hv_ringbuffer_write(struct hv_ring_buffer_info
*ring_info,
struct kvec *kv_list,
u32 kv_count, bool *signal);
+/*
+ * By default, a read_flags of 0 means: the payload offset is
+ * sizeof(struct vmpacket_descriptor).
+ *
+ * If HV_RINGBUFFER_READ_FLAG_RAW is used, the payload offset is 0.
+ *
+ * If HV_RINGBUFFER_READ_FLAG_HVSOCK is used, the payload offset is
+ * sizeof(struct vmpacket_descriptor) + sizeof(struct vmpipe_proto_header).
+ */
+#define HV_RINGBUFFER_READ_FLAG_RAW(1 << 0)
+#define HV_RINGBUFFER_READ_FLAG_HVSOCK (1 << 1)
int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
void *buffer, u32 buflen, u32 *buffer_actual_len,
- u64 *requestid, bool *signal, bool raw);
+ u64 *requestid, bool *signal, u32 read_flags);
void hv_ringbuffer_get_debuginfo(struct hv_ring_buffer_info *ring_info,
struct hv_ring_buffer_debug_info *debug_info);
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index b53702c..03a509c 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -382,32 +382,43 @@ int hv_ringbuffer_write(struct hv_ring_buffer_info
*outring_info,
int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
void *buffer, u32 buflen, u32 *buffer_actual_len,
- u64 *requestid, bool *signal, bool raw)
+ u64 *requestid, bool *signal, u32 read_flags)
{
+ bool raw = !!(read_flags & HV_RINGBUFFER_READ_FLAG_RAW);
+ bool hvsock = !!(read_flags & HV_RINGBUFFER_READ_FLAG_HVSOCK);
+
u32 bytes_avail_towrite;
u32 bytes_avail_toread;
u32 next_read_location = 0;
u64 prev_indices = 0;
unsigned long flags;
- struct vmpacket_descriptor desc;
+ struct vmpipe_proto_header *pipe_hdr;
+ struct vmpacket_descriptor *desc;
u32 offset;
- u32 packetlen;
+ u32 packetlen, tot_hdrlen;
int ret = 0;
if (buflen <= 0)
return -EINVAL;
+ tot_hdrlen = sizeof(*desc);
+ if (hvsock)
+ tot_hdrlen += sizeof(*pipe_hdr);
+
[PATCH V5 3/9] Drivers: hv: vmbus: define a new VMBus message type for hvsock
A function to send the type of message is also added.
The coming net/hvsock driver will use this function to proactively request
the host to offer a VMBus channel for a new hvsock connection.
Signed-off-by: Dexuan Cui
---
drivers/hv/channel.c | 15 +++
drivers/hv/channel_mgmt.c | 4
include/linux/hyperv.h| 13 +
3 files changed, 32 insertions(+)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 1161d68..eaaa066 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -219,6 +219,21 @@ error0:
}
EXPORT_SYMBOL_GPL(vmbus_open);
+/* Used for Hyper-V Socket: a guest client's connect() to the host */
+int vmbus_send_tl_connect_request(const uuid_le *shv_guest_servie_id,
+ const uuid_le *shv_host_servie_id)
+{
+ struct vmbus_channel_tl_connect_request conn_msg;
+
+ memset(&conn_msg, 0, sizeof(conn_msg));
+ conn_msg.header.msgtype = CHANNELMSG_TL_CONNECT_REQUEST;
+ conn_msg.guest_endpoint_id = *shv_guest_servie_id;
+ conn_msg.host_service_id = *shv_host_servie_id;
+
+ return vmbus_post_msg(&conn_msg, sizeof(conn_msg));
+}
+EXPORT_SYMBOL_GPL(vmbus_send_tl_connect_request);
+
/*
* create_gpadl_header - Creates a gpadl for the specified buffer
*/
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 1c1ad47..4611b50 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -825,6 +825,10 @@ struct vmbus_channel_message_table_entry
{CHANNELMSG_VERSION_RESPONSE, 1, vmbus_onversion_response},
{CHANNELMSG_UNLOAD, 0, NULL},
{CHANNELMSG_UNLOAD_RESPONSE,1, vmbus_unload_response},
+ {CHANNELMSG_18, 0, NULL},
+ {CHANNELMSG_19, 0, NULL},
+ {CHANNELMSG_20, 0, NULL},
+ {CHANNELMSG_TL_CONNECT_REQUEST, 0, NULL},
};
/*
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index c0eddd7..b835d80 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -392,6 +392,10 @@ enum vmbus_channel_message_type {
CHANNELMSG_VERSION_RESPONSE = 15,
CHANNELMSG_UNLOAD = 16,
CHANNELMSG_UNLOAD_RESPONSE = 17,
+ CHANNELMSG_18 = 18,
+ CHANNELMSG_19 = 19,
+ CHANNELMSG_20 = 20,
+ CHANNELMSG_TL_CONNECT_REQUEST = 21,
CHANNELMSG_COUNT
};
@@ -562,6 +566,13 @@ struct vmbus_channel_initiate_contact {
u64 monitor_page2;
} __packed;
+/* Hyper-V socket: guest's connect()-ing to host */
+struct vmbus_channel_tl_connect_request {
+ struct vmbus_channel_message_header header;
+ uuid_le guest_endpoint_id;
+ uuid_le host_service_id;
+} __packed;
+
struct vmbus_channel_version_response {
struct vmbus_channel_message_header header;
u8 version_supported;
@@ -1255,4 +1266,6 @@ void hv_process_channel_removal(struct vmbus_channel
*channel, u32 relid);
extern __u32 vmbus_proto_version;
+int vmbus_send_tl_connect_request(const uuid_le *shv_guest_servie_id,
+ const uuid_le *shv_host_servie_id);
#endif /* _HYPERV_H */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 5/9] Drivers: hv: vmbus: add APIs to send/recv hvsock packets
This will be used by the coming net/hvsock driver.
Signed-off-by: Dexuan Cui
---
drivers/hv/channel.c | 59 ++
include/linux/hyperv.h | 9
2 files changed, 68 insertions(+)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index cc49966..ce1b885 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -924,6 +924,52 @@ int vmbus_sendpacket_multipagebuffer(struct vmbus_channel
*channel,
}
EXPORT_SYMBOL_GPL(vmbus_sendpacket_multipagebuffer);
+/*
+ * vmbus_sendpacket_hvsock - Send the hvsock payload 'buf' of a length 'len'
+ */
+int vmbus_sendpacket_hvsock(struct vmbus_channel *channel, void *buf, u32 len)
+{
+ struct vmpipe_proto_header pipe_hdr;
+ struct vmpacket_descriptor desc;
+ struct kvec bufferlist[4];
+ u32 packetlen_aligned;
+ u32 packetlen;
+ u64 aligned_data = 0;
+ bool signal = false;
+ int ret;
+
+ packetlen = HVSOCK_HEADER_LEN + len;
+ packetlen_aligned = ALIGN(packetlen, sizeof(u64));
+
+ /* Setup the descriptor */
+ desc.type = VM_PKT_DATA_INBAND;
+ /* in 8-bytes granularity */
+ desc.offset8 = sizeof(struct vmpacket_descriptor) >> 3;
+ desc.len8 = (u16)(packetlen_aligned >> 3);
+ desc.flags = 0;
+ desc.trans_id = 0;
+
+ pipe_hdr.pkt_type = 1;
+ pipe_hdr.data_size = len;
+
+ bufferlist[0].iov_base = &desc;
+ bufferlist[0].iov_len = sizeof(struct vmpacket_descriptor);
+ bufferlist[1].iov_base = &pipe_hdr;
+ bufferlist[1].iov_len = sizeof(struct vmpipe_proto_header);
+ bufferlist[2].iov_base = buf;
+ bufferlist[2].iov_len = len;
+ bufferlist[3].iov_base = &aligned_data;
+ bufferlist[3].iov_len = packetlen_aligned - packetlen;
+
+ ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 4, &signal);
+
+ if (ret == 0 && signal)
+ vmbus_setevent(channel);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vmbus_sendpacket_hvsock);
+
/**
* vmbus_recvpacket() - Retrieve the user packet on the specified channel
* @channel: Pointer to vmbus_channel structure.
@@ -976,3 +1022,16 @@ int vmbus_recvpacket_raw(struct vmbus_channel *channel,
void *buffer,
HV_RINGBUFFER_READ_FLAG_RAW);
}
EXPORT_SYMBOL_GPL(vmbus_recvpacket_raw);
+
+/*
+ * vmbus_recvpacket_hvsock - Receive the hvsock payload from the vmbus
+ * ringbuffer into the 'buffer'.
+ */
+int vmbus_recvpacket_hvsock(struct vmbus_channel *channel, void *buffer,
+ u32 bufferlen, u32 *buffer_actual_len)
+{
+ return __vmbus_recvpacket(channel, buffer, bufferlen,
+ buffer_actual_len, NULL,
+ HV_RINGBUFFER_READ_FLAG_HVSOCK);
+}
+EXPORT_SYMBOL_GPL(vmbus_recvpacket_hvsock);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index e005223..646c20d 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -908,6 +908,9 @@ extern int vmbus_sendpacket_ctl(struct vmbus_channel
*channel,
u32 flags,
bool kick_q);
+extern int vmbus_sendpacket_hvsock(struct vmbus_channel *channel,
+ void *buf, u32 len);
+
extern int vmbus_sendpacket_pagebuffer(struct vmbus_channel *channel,
struct hv_page_buffer pagebuffers[],
u32 pagecount,
@@ -958,6 +961,9 @@ extern int vmbus_recvpacket_raw(struct vmbus_channel
*channel,
u64 *requestid);
+extern int vmbus_recvpacket_hvsock(struct vmbus_channel *channel, void *buffer,
+ u32 bufferlen, u32 *buffer_actual_len);
+
extern void vmbus_ontimer(unsigned long data);
/* Base driver object */
@@ -1280,4 +1286,7 @@ struct vmpipe_proto_header {
};
} __packed;
+#define HVSOCK_HEADER_LEN (sizeof(struct vmpacket_descriptor) + \
+sizeof(struct vmpipe_proto_header))
+
#endif /* _HYPERV_H */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 6/9] Drivers: hv: vmbus: add a hvsock flag in struct hv_driver
Only the coming hv_sock driver has a "true" value for this flag.
We treat the hvsock offers/channels as special VMBus devices.
Since the hv_sock driver handles all the hvsock offers/channels, we need to
tweak vmbus_match() for hv_sock driver, so we introduce this flag.
Signed-off-by: Dexuan Cui
---
drivers/hv/vmbus_drv.c | 4
include/linux/hyperv.h | 14 ++
2 files changed, 18 insertions(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 328e4c3..c1c9d71 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -562,6 +562,10 @@ static int vmbus_match(struct device *device, struct
device_driver *driver)
struct hv_driver *drv = drv_to_hv_drv(driver);
struct hv_device *hv_dev = device_to_hv_device(device);
+ /* The hv_sock driver handles all hv_sock offers. */
+ if (is_hvsock_channel(hv_dev->channel))
+ return drv->hvsock;
+
if (hv_vmbus_get_id(drv->id_table, &hv_dev->dev_type))
return 1;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 646c20d..b4cc44c 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -970,6 +970,20 @@ extern void vmbus_ontimer(unsigned long data);
struct hv_driver {
const char *name;
+ /*
+* A hvsock offer, which has a VMBUS_CHANNEL_TLNPI_PROVIDER_OFFER
+* channel flag, actually doesn't mean a synthetic device because the
+* offer's if_type/if_instance can change for every new hvsock
+* connection.
+*
+* However, to facilitate the notification of new-offer/rescind-offer
+* from vmbus driver to hvsock driver, we can handle hvsock offer as
+* a special vmbus device, and hence we need the below flag to
+* indicate if the driver is the hvsock driver or not: we need to
+* specially treat the hvosck offer & driver in vmbus_match().
+*/
+ bool hvsock;
+
/* the device type supported by this driver */
uuid_le dev_type;
const struct hv_vmbus_device_id *id_table;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 8/9] Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()
The hvsock driver needs this API to release all the resources related
to the channel.
Signed-off-by: Dexuan Cui
---
drivers/hv/channel_mgmt.c | 33 -
drivers/hv/connection.c | 4 ++--
include/linux/hyperv.h| 2 ++
3 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 87fc7d2..f963645 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -195,6 +195,7 @@ void hv_process_channel_removal(struct vmbus_channel
*channel, u32 relid)
vmbus_release_relid(relid);
BUG_ON(!channel->rescind);
+ BUG_ON(!mutex_is_locked(&vmbus_connection.channel_mutex));
if (channel->target_cpu != get_cpu()) {
put_cpu();
@@ -206,9 +207,7 @@ void hv_process_channel_removal(struct vmbus_channel
*channel, u32 relid)
}
if (channel->primary_channel == NULL) {
- mutex_lock(&vmbus_connection.channel_mutex);
list_del(&channel->listentry);
- mutex_unlock(&vmbus_connection.channel_mutex);
primary_channel = channel;
} else {
@@ -251,6 +250,7 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
struct vmbus_channel *channel;
bool fnew = true;
unsigned long flags;
+ int ret;
/* Make sure this is a new offer */
mutex_lock(&vmbus_connection.channel_mutex);
@@ -330,7 +330,11 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
* binding which eventually invokes the device driver's AddDevice()
* method.
*/
- if (vmbus_device_register(newchannel->device_obj) != 0) {
+ mutex_lock(&vmbus_connection.channel_mutex);
+ ret = vmbus_device_register(newchannel->device_obj);
+ mutex_unlock(&vmbus_connection.channel_mutex);
+
+ if (ret != 0) {
pr_err("unable to add child device object (relid %d)\n",
newchannel->offermsg.child_relid);
kfree(newchannel->device_obj);
@@ -592,6 +596,8 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
struct device *dev;
rescind = (struct vmbus_channel_rescind_offer *)hdr;
+
+ mutex_lock(&vmbus_connection.channel_mutex);
channel = relid2channel(rescind->child_relid);
if (channel == NULL) {
@@ -600,7 +606,7 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
* vmbus_process_offer(), we have already invoked
* vmbus_release_relid() on error.
*/
- return;
+ goto out;
}
spin_lock_irqsave(&channel->lock, flags);
@@ -616,7 +622,7 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
* We can't invoke vmbus_device_unregister()
* until the socket fd is closed.
*/
- return;
+ goto out;
}
/*
* We will have to unregister this device from the
@@ -631,7 +637,24 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
hv_process_channel_removal(channel,
channel->offermsg.child_relid);
}
+
+out:
+ mutex_unlock(&vmbus_connection.channel_mutex);
+}
+
+
+void vmbus_hvsock_device_unregister(struct vmbus_channel *channel)
+{
+ mutex_lock(&vmbus_connection.channel_mutex);
+
+ BUG_ON(!is_hvsock_channel(channel));
+
+ channel->rescind = true;
+ vmbus_device_unregister(channel->device_obj);
+
+ mutex_unlock(&vmbus_connection.channel_mutex);
}
+EXPORT_SYMBOL_GPL(vmbus_hvsock_device_unregister);
/*
* vmbus_onoffers_delivered -
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 3dc5a9c..deb48e6 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -288,7 +288,8 @@ struct vmbus_channel *relid2channel(u32 relid)
struct list_head *cur, *tmp;
struct vmbus_channel *cur_sc;
- mutex_lock(&vmbus_connection.channel_mutex);
+ BUG_ON(!mutex_is_locked(&vmbus_connection.channel_mutex));
+
list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
if (channel->offermsg.child_relid == relid) {
found_channel = channel;
@@ -307,7 +308,6 @@ struct vmbus_channel *relid2channel(u32 relid)
}
}
}
- mutex_unlock(&vmbus_connection.channel_mutex);
return found_channel;
}
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 7e507bb..8e59f98 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1055,6 +1055,8 @@ int __must_check __vmbus_driver_register(struct hv_driver
*hv_driver,
co
[PATCH V5 7/9] Drivers: hv: vmbus: add a mechanism to pass hvsock events to the hvsock driver
For now only 1 event is defined: HVSOCK_RESCIND_CHANNEL.
We'll have more events in the future.
Signed-off-by: Dexuan Cui
---
drivers/hv/channel_mgmt.c | 18 ++
include/linux/hyperv.h| 17 +
2 files changed, 35 insertions(+)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 4611b50..87fc7d2 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -608,6 +608,16 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
spin_unlock_irqrestore(&channel->lock, flags);
if (channel->device_obj) {
+ if (is_hvsock_channel(channel) &&
+ channel->hvsock_event_callback) {
+ channel->hvsock_event_callback(channel,
+ HVSOCK_RESCIND_CHANNEL);
+ /*
+* We can't invoke vmbus_device_unregister()
+* until the socket fd is closed.
+*/
+ return;
+ }
/*
* We will have to unregister this device from the
* driver core.
@@ -977,3 +987,11 @@ bool vmbus_are_subchannels_present(struct vmbus_channel
*primary)
return ret;
}
EXPORT_SYMBOL_GPL(vmbus_are_subchannels_present);
+
+void vmbus_set_hvsock_event_callback(struct vmbus_channel *channel,
+ void (*hvsock_event_callback)(struct vmbus_channel *,
+ enum hvsock_event))
+{
+ channel->hvsock_event_callback = hvsock_event_callback;
+}
+EXPORT_SYMBOL_GPL(vmbus_set_hvsock_event_callback);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index b4cc44c..7e507bb 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -645,6 +645,12 @@ enum hv_signal_policy {
HV_SIGNAL_POLICY_EXPLICIT,
};
+/* hvsock related definitions */
+enum hvsock_event {
+ /* The host application is close()-ing the connection */
+ HVSOCK_RESCIND_CHANNEL,
+};
+
struct vmbus_channel {
/* Unique channel id */
int id;
@@ -740,6 +746,13 @@ struct vmbus_channel {
void (*sc_creation_callback)(struct vmbus_channel *new_sc);
/*
+* hvsock event callback.
+* For now only 1 event is defined: HVSOCK_RESCIND_CHANNEL.
+*/
+ void (*hvsock_event_callback)(struct vmbus_channel *channel,
+ enum hvsock_event event);
+
+ /*
* The spinlock to protect the structure. It is being used to protect
* test-and-set access to various attributes of the structure as well
* as all sc_list operations.
@@ -825,6 +838,10 @@ int vmbus_request_offers(void);
void vmbus_set_sc_create_callback(struct vmbus_channel *primary_channel,
void (*sc_cr_cb)(struct vmbus_channel *new_sc));
+void vmbus_set_hvsock_event_callback(struct vmbus_channel *channel,
+ void (*hvsock_event_callback)(struct vmbus_channel *,
+ enum hvsock_event));
+
/*
* Retrieve the (sub) channel on which to send an outgoing request.
* When a primary channel has multiple sub-channels, we choose a
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 9/9] hvsock: introduce Hyper-V VM Sockets feature
Hyper-V VM sockets (hvsock) supplies a byte-stream based communication
mechanism between the host and a guest. It's kind of TCP over VMBus, but
the transportation layer (VMBus) is much simpler than IP. With Hyper-V VM
Sockets, applications between the host and a guest can talk with each
other directly by the traditional BSD-style socket APIs.
Hyper-V VM Sockets is only available on Windows 10 host and later. The
patch implements the necessary support in the guest side by introducing
a new socket address family AF_HYPERV.
Signed-off-by: Dexuan Cui
---
MAINTAINERS |2 +
include/linux/hyperv.h |8 +
include/linux/socket.h |4 +-
include/net/af_hvsock.h | 44 ++
include/uapi/linux/hyperv.h | 16 +
net/Kconfig |1 +
net/Makefile|1 +
net/hv_sock/Kconfig | 10 +
net/hv_sock/Makefile|3 +
net/hv_sock/af_hvsock.c | 1473 +++
10 files changed, 1561 insertions(+), 1 deletion(-)
create mode 100644 include/net/af_hvsock.h
create mode 100644 net/hv_sock/Kconfig
create mode 100644 net/hv_sock/Makefile
create mode 100644 net/hv_sock/af_hvsock.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 44666b1..f89a4ba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5156,7 +5156,9 @@ F:drivers/input/serio/hyperv-keyboard.c
F: drivers/net/hyperv/
F: drivers/scsi/storvsc_drv.c
F: drivers/video/fbdev/hyperv_fb.c
+F: net/hv_sock/
F: include/linux/hyperv.h
+F: include/net/af_hvsock.h
F: tools/hv/
F: Documentation/ABI/stable/sysfs-bus-vmbus
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 8e59f98..3495762 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1322,4 +1322,12 @@ struct vmpipe_proto_header {
#define HVSOCK_HEADER_LEN (sizeof(struct vmpacket_descriptor) + \
sizeof(struct vmpipe_proto_header))
+/* See 'prev_indices' in hv_ringbuffer_read(), hv_ringbuffer_write() */
+#define PREV_INDICES_LEN (sizeof(u64))
+
+#define HVSOCK_PKT_LEN(payload_len)(HVSOCK_HEADER_LEN + \
+ ALIGN((payload_len), 8) + \
+ PREV_INDICES_LEN)
+#define HVSOCK_MIN_PKT_LEN HVSOCK_PKT_LEN(1)
+
#endif /* _HYPERV_H */
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 5bf59c8..d5ef612 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -200,7 +200,8 @@ struct ucred {
#define AF_ALG 38 /* Algorithm sockets*/
#define AF_NFC 39 /* NFC sockets */
#define AF_VSOCK 40 /* vSockets */
-#define AF_MAX 41 /* For now.. */
+#define AF_HYPERV 41 /* Hyper-V virtual sockets */
+#define AF_MAX 42 /* For now.. */
/* Protocol families, same as address families. */
#define PF_UNSPEC AF_UNSPEC
@@ -246,6 +247,7 @@ struct ucred {
#define PF_ALG AF_ALG
#define PF_NFC AF_NFC
#define PF_VSOCK AF_VSOCK
+#define PF_HYPERV AF_HYPERV
#define PF_MAX AF_MAX
/* Maximum queue length specifiable by listen. */
diff --git a/include/net/af_hvsock.h b/include/net/af_hvsock.h
new file mode 100644
index 000..9951658
--- /dev/null
+++ b/include/net/af_hvsock.h
@@ -0,0 +1,44 @@
+#ifndef __AF_HVSOCK_H__
+#define __AF_HVSOCK_H__
+
+#include
+#include
+#include
+
+#define VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV (5 * PAGE_SIZE)
+#define VMBUS_RINGBUFFER_SIZE_HVSOCK_SEND (5 * PAGE_SIZE)
+
+#define HVSOCK_RCV_BUF_SZ VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV
+#define HVSOCK_SND_BUF_SZ PAGE_SIZE
+
+#define sk_to_hvsock(__sk)((struct hvsock_sock *)(__sk))
+#define hvsock_to_sk(__hvsk) ((struct sock *)(__hvsk))
+
+struct hvsock_sock {
+ /* sk must be the first member. */
+ struct sock sk;
+
+ struct sockaddr_hv local_addr;
+ struct sockaddr_hv remote_addr;
+
+ /* protected by the global hvsock_mutex */
+ struct list_head bound_list;
+ struct list_head connected_list;
+
+ struct list_head accept_queue;
+ /* used by enqueue and dequeue */
+ struct mutex accept_queue_mutex;
+
+ struct delayed_work dwork;
+
+ u32 peer_shutdown;
+
+ struct vmbus_channel *channel;
+
+ char send_buf[HVSOCK_SND_BUF_SZ];
+ char recv_buf[HVSOCK_RCV_BUF_SZ];
+ unsigned int recv_data_len;
+ unsigned int recv_data_offset;
+};
+
+#endif /* __AF_HVSOCK_H__ */
diff --git a/include/uapi/linux/hyperv.h b/include/uapi/linux/hyperv.h
index e347b24..ded4c13 100644
--- a/include/uapi/linux/hyperv.h
+++ b/include/uapi/linux/hyperv.h
@@ -26,6 +26,7 @@
#define _UAPI_HYPERV_H
#include
+#include
/*
* Framework version for util services.
@@ -396,4 +397,19 @@ struct hv_kvp_ip_msg {
struct hv_kvp_ipaddr_value kvp_ip_val;
} __attribute__((packed));
+/
[PATCH V5 1/9] Drivers: hv: vmbus: add a helper function to set a channel's pending send size
This will be used by the coming net/hvsock driver.
Signed-off-by: Dexuan Cui
---
include/linux/hyperv.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 753dbad..e4867a7 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -790,6 +790,12 @@ static inline void *get_per_channel_state(struct
vmbus_channel *c)
return c->per_channel_state;
}
+static inline void set_channel_pending_send_size(struct vmbus_channel *c,
+u32 size)
+{
+ c->outbound.ring_buffer->pending_send_sz = size;
+}
+
void vmbus_onmessage(void *context);
int vmbus_request_offers(void);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 0/9] introduce Hyper-V VM Sockets(hvsock
Merry Christmas, everyone! Changes since v1: - updated "[PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature" - added __init and __exit for the module init/exit functions - net/hv_sock/Kconfig: "default m" -> "default m if HYPERV" - MODULE_LICENSE: "Dual MIT/GPL" -> "Dual BSD/GPL" Changes since v2: - fixed various coding issue pointed out by David Miller - fixed indentation issues - removed pr_debug in net/hv_sock/af_hvsock.c - used reverse-Chrismas-tree style for local variables. - EXPORT_SYMBOL -> EXPORT_SYMBOL_GPL Changes since v3: - fixed a few coding issue pointed by Vitaly Kuznetsov and Dan Carpenter - fixed the ret value in vmbus_recvpacket_hvsock on error - fixed the style of multi-line comment: vmbus_get_hvsock_rw_status() Changes since v4 (https://lkml.org/lkml/2015/7/28/404): - addressed all the comments about V4. - treat the hvsock offers/channels as special VMBus devices - add a mechanism to pass hvsock events to the hvsock driver - fixed some corner cases with proper locking when a connection is closed - rebased to the latest Greg's tree Hyper-V VM Sockets (hvsock) is a byte-stream based communication mechanism between Windowsd 10 (or later) host and a guest. It's kind of TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V VM Sockets, applications between the host and a guest can talk with each other directly by the traditional BSD-style socket APIs. The patchset implements the necessary support in the guest side by adding the necessary new APIs in the vmbus driver, and introducing a new driver hv_sock.ko, which implements_a new socket address family AF_HYPERV. I know the kernel has already had a VM Sockets driver (AF_VSOCK) based on VMware's VMCI (net/vmw_vsock/, drivers/misc/vmw_vmci), and KVM is proposing AF_VSOCK of virtio version: http://thread.gmane.org/gmane.linux.network/365205. However, though Hyper-V VM Sockets may seem conceptually similar to AF_VOSCK, there are differences in the transportation layer, and IMO these make the direct code reusing impractical: 1. In AF_VSOCK, the endpoint type is: , but in AF_HYPERV, the endpoint type is: . Here GUID is 128-bit. 2. AF_VSOCK supports SOCK_DGRAM, while AF_HYPERV doesn't. 3. AF_VSOCK supports some special sock opts, like SO_VM_SOCKETS_BUFFER_SIZE, SO_VM_SOCKETS_BUFFER_MIN/MAX_SIZE and SO_VM_SOCKETS_CONNECT_TIMEOUT. These are meaningless to AF_HYPERV. 4. Some AF_VSOCK's VMCI transportation ops are meanless to AF_HYPERV/VMBus, like.notify_recv_init .notify_recv_pre_block .notify_recv_pre_dequeue .notify_recv_post_dequeue .notify_send_init .notify_send_pre_block .notify_send_pre_enqueue .notify_send_post_enqueue etc. So I think we'd better introduce a new address family: AF_HYPERV. Please review the patchset. Looking forward to your comments! Dexuan Cui (9): Drivers: hv: vmbus: add a helper function to set a channel's pending send size Drivers: hv: vmbus: define the new offer type for Hyper-V socket (hvsock) Drivers: hv: vmbus: define a new VMBus message type for hvsock Drivers: hv: ring_buffer: enhance hv_ringbuffer_read() to support hvsock Drivers: hv: vmbus: add APIs to send/recv hvsock packets Drivers: hv: vmbus: add a hvsock flag in struct hv_driver Drivers: hv: vmbus: add a mechanism to pass hvsock events to the hvsock driver Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister() hvsock: introduce Hyper-V VM Sockets feature MAINTAINERS |2 + drivers/hv/channel.c| 84 ++- drivers/hv/channel_mgmt.c | 53 +- drivers/hv/connection.c |4 +- drivers/hv/hyperv_vmbus.h | 13 +- drivers/hv/ring_buffer.c| 54 +- drivers/hv/vmbus_drv.c |4 + include/linux/hyperv.h | 88 +++ include/linux/socket.h |4 +- include/net/af_hvsock.h | 44 ++ include/uapi/linux/hyperv.h | 16 + net/Kconfig |1 + net/Makefile|1 + net/hv_sock/Kconfig | 10 + net/hv_sock/Makefile|3 + net/hv_sock/af_hvsock.c | 1473 +++ 16 files changed, 1830 insertions(+), 24 deletions(-) create mode 100644 include/net/af_hvsock.h create mode 100644 net/hv_sock/Kconfig create mode 100644 net/hv_sock/Makefile create mode 100644 net/hv_sock/af_hvsock.c -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] cxgb4: Remove deprecated module parameters
Remove deprecated module parameters, and mark one parameter as
deprecated.
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 54 +
1 file changed, 2 insertions(+), 52 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index bfe50aa..b8a5fb0 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -162,19 +162,8 @@ MODULE_FIRMWARE(FW6_FNAME);
static uint force_init;
module_param(force_init, uint, 0644);
-MODULE_PARM_DESC(force_init, "Forcibly become Master PF and initialize
adapter");
-
-/*
- * Normally if the firmware we connect to has Configuration File support, we
- * use that and only fall back to the old Driver-based initialization if the
- * Configuration File fails for some reason. If force_old_init is set, then
- * we'll always use the old Driver-based initialization sequence.
- */
-static uint force_old_init;
-
-module_param(force_old_init, uint, 0644);
-MODULE_PARM_DESC(force_old_init, "Force old initialization sequence,
deprecated"
-" parameter");
+MODULE_PARM_DESC(force_init, "Forcibly become Master PF and initialize
adapter,"
+"deprecated parameter");
static int dflt_msg_enable = DFLT_MSG_ENABLE;
@@ -196,23 +185,6 @@ module_param(msi, int, 0644);
MODULE_PARM_DESC(msi, "whether to use INTx (0), MSI (1) or MSI-X (2)");
/*
- * Queue interrupt hold-off timer values. Queues default to the first of these
- * upon creation.
- */
-static unsigned int intr_holdoff[SGE_NTIMERS - 1] = { 5, 10, 20, 50, 100 };
-
-module_param_array(intr_holdoff, uint, NULL, 0644);
-MODULE_PARM_DESC(intr_holdoff, "values for queue interrupt hold-off timers "
-"0..4 in microseconds, deprecated parameter");
-
-static unsigned int intr_cnt[SGE_NCOUNTERS - 1] = { 4, 8, 16 };
-
-module_param_array(intr_cnt, uint, NULL, 0644);
-MODULE_PARM_DESC(intr_cnt,
-"thresholds 1..3 for queue interrupt packet counters, "
-"deprecated parameter");
-
-/*
* Normally we tell the chip to deliver Ingress Packets into our DMA buffers
* offset by 2 bytes in order to have the IP headers line up on 4-byte
* boundaries. This is a requirement for many architectures which will throw
@@ -226,13 +198,7 @@ MODULE_PARM_DESC(intr_cnt,
*/
static int rx_dma_offset = 2;
-static bool vf_acls;
-
#ifdef CONFIG_PCI_IOV
-module_param(vf_acls, bool, 0644);
-MODULE_PARM_DESC(vf_acls, "if set enable virtualization L2 ACL enforcement, "
-"deprecated parameter");
-
/* Configure the number of PCI-E Virtual Function which are to be instantiated
* on SR-IOV Capable Physical Functions.
*/
@@ -253,12 +219,6 @@ module_param(select_queue, int, 0644);
MODULE_PARM_DESC(select_queue,
"Select between kernel provided method of selecting or driver
method of selecting TX queue. Default is kernel method.");
-static unsigned int tp_vlan_pri_map = HW_TPL_FR_MT_PR_IV_P_FC;
-
-module_param(tp_vlan_pri_map, uint, 0644);
-MODULE_PARM_DESC(tp_vlan_pri_map, "global compressed filter configuration, "
-"deprecated parameter");
-
static struct dentry *cxgb4_debugfs_root;
static LIST_HEAD(adapter_list);
@@ -3141,16 +3101,6 @@ static int adap_init1(struct adapter *adap, struct
fw_caps_config_cmd *c)
if (ret < 0)
return ret;
- /* select capabilities we'll be using */
- if (c->niccaps & htons(FW_CAPS_CONFIG_NIC_VM)) {
- if (!vf_acls)
- c->niccaps ^= htons(FW_CAPS_CONFIG_NIC_VM);
- else
- c->niccaps = htons(FW_CAPS_CONFIG_NIC_VM);
- } else if (vf_acls) {
- dev_err(adap->pdev_dev, "virtualization ACLs not supported");
- return ret;
- }
c->op_to_write = htonl(FW_CMD_OP_V(FW_CAPS_CONFIG_CMD) |
FW_CMD_REQUEST_F | FW_CMD_WRITE_F);
ret = t4_wr_mbox(adap, adap->mbox, c, sizeof(*c), NULL);
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] cxgb4: Get TID calculation right for IPv6 mode
CLIP is always enabled and hardware uses 2 TID entries instead of 4 for
IPv6 in CLIP mode.
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c0dd533..bfe50aa 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -1506,7 +1506,7 @@ int cxgb4_alloc_stid(struct tid_info *t, int family, void
*data)
else
stid = -1;
} else {
- stid = bitmap_find_free_region(t->stid_bmap, t->nstids, 2);
+ stid = bitmap_find_free_region(t->stid_bmap, t->nstids, 1);
if (stid < 0)
stid = -1;
}
@@ -1520,7 +1520,7 @@ int cxgb4_alloc_stid(struct tid_info *t, int family, void
*data)
if (family == PF_INET)
t->stids_in_use++;
else
- t->stids_in_use += 4;
+ t->stids_in_use += 2;
}
spin_unlock_bh(&t->stid_lock);
return stid;
@@ -1571,13 +1571,13 @@ void cxgb4_free_stid(struct tid_info *t, unsigned int
stid, int family)
if (family == PF_INET)
__clear_bit(stid, t->stid_bmap);
else
- bitmap_release_region(t->stid_bmap, stid, 2);
+ bitmap_release_region(t->stid_bmap, stid, 1);
t->stid_tab[stid].data = NULL;
if (stid < t->nstids) {
if (family == PF_INET)
t->stids_in_use--;
else
- t->stids_in_use -= 4;
+ t->stids_in_use -= 2;
} else {
t->sftids_in_use--;
}
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netconsole: Initialize after all core networking drivers
Hi,
On 24.12.2015 00:03, Calvin Owens wrote:
> On Thursday 12/17 at 17:46 -0800, Calvin Owens wrote:
>> On Thursday 12/17 at 17:08 -0800, Eric Dumazet wrote:
>>> On Thu, 2015-12-17 at 15:52 -0800, Calvin Owens wrote:
With built-in netconsole and IXGBE, configuring netconsole via the kernel
cmdline results in the following panic at boot:
netpoll: netconsole: device eth0 not up yet, forcing it
usb 2-1: new high-speed USB device number 2 using ehci-pci
ixgbe :03:00.0: registered PHC device on eth0
BUG: unable to handle kernel NULL pointer dereference at
0810
Call Trace:
[] ? vxlan_get_rx_port+0x41/0xa0
[] ixgbe_open+0x4e8/0x540
[] __dev_open+0xac/0x120
[] dev_open+0x36/0x70
[] netpoll_setup+0x23c/0x300
[] ? netpoll_parse_options+0x19a/0x200
[] ? option_setup+0x1f/0x1f
[] init_netconsole+0xda/0x262
[] ? option_setup+0x1f/0x1f
[] do_one_initcall+0x88/0x1b0
[] kernel_init_freeable+0x14a/0x1e3
[] ? do_early_param+0x8c/0x8c
[] ? rest_init+0x80/0x80
[] kernel_init+0xe/0xe0
[] ret_from_fork+0x3f/0x70
[] ? rest_init+0x80/0x80
This happens because IXGBE assumes that vxlan has already been initialized.
The cleanest way to fix this is to just initialize netconsole after all the
other core networking stuff has completed.
Signed-off-by: Calvin Owens
---
drivers/net/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 900b0c5..31557d0 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_MACVTAP) += macvtap.o
obj-$(CONFIG_MII) += mii.o
obj-$(CONFIG_MDIO) += mdio.o
obj-$(CONFIG_NET) += Space.o loopback.o
-obj-$(CONFIG_NETCONSOLE) += netconsole.o
obj-$(CONFIG_PHYLIB) += phy/
obj-$(CONFIG_RIONET) += rionet.o
obj-$(CONFIG_NET_TEAM) += team/
@@ -26,6 +25,7 @@ obj-$(CONFIG_VXLAN) += vxlan.o
obj-$(CONFIG_GENEVE) += geneve.o
obj-$(CONFIG_NLMON) += nlmon.o
obj-$(CONFIG_NET_VRF) += vrf.o
+obj-$(CONFIG_NETCONSOLE) += netconsole.o
#
# Networking Drivers
>>>
>>>
>>> Looks odd to rely on link order, but we might already rely on this...
>>>
>>> Have you considered using device_initcall() instead of late_initcall()
>>> in vxlan ?
>>
>> I'll look.
>
> So this does work, but commit 7332a13b038be05c explicitly changed it to
> late_initcall() because of dependencies on IPv6:
>
> When vxlan is compiled as builtin, its init code
> runs before IPv6 init, this could cause problems
> if we create IPv6 socket in the latter patch.
>
> So I guess something like the following patch is needed to go that
> route? It's ugly, IMHO the Makefile patch is cleaner...
>
> Stephen / Cong, what do you think?
>
>> As-is though, I think a similar problem would happen if you
>> tried to use a virtio_net device with netconsole= cmdline (although that
>> is admittedly a bizarre use case). The Makefile patch seemed like the
>> best way to ensure this can't recur elsewhere.
>
> I misunderstood this, it works fine as is.
>
>
> ---8<---
> From: Calvin Owens
> Subject: [PATCH] vxlan: Properly depend on ipv6 and revert to module_init()
>
> Commit 7332a13b038be05c ("vxlan: defer vxlan init as late as possible")
> changed vxlan to use late_initcall(), because vxlan relies on ipv6 being
> loaded when a new device is opened.
>
> This causes netconsole to panic at boot when configured via the kernel
> cmdline on an IXGBE NIC, because ixgbe_open() assumes that vxlan has
> already been initialized:
>
> netpoll: netconsole: device eth0 not up yet, forcing it
> ixgbe :03:00.0: registered PHC device on eth0
> BUG: unable to handle kernel NULL pointer dereference at 0810
>
> Call Trace:
> [] ? vxlan_get_rx_port+0x41/0xa0
> [] ixgbe_open+0x4e8/0x540
> [] __dev_open+0xac/0x120
> [] dev_open+0x36/0x70
> [] netpoll_setup+0x23c/0x300
> [] ? netpoll_parse_options+0x19a/0x200
> [] ? option_setup+0x1f/0x1f
> [] init_netconsole+0xda/0x262
> [] ? option_setup+0x1f/0x1f
> [] do_one_initcall+0x88/0x1b0
> [] kernel_init_freeable+0x14a/0x1e3
> [] ? do_early_param+0x8c/0x8c
> [] ? rest_init+0x80/0x80
> [] kernel_init+0xe/0xe0
> [] ret_from_fork+0x3f/0x70
> [] ? rest_init+0x80/0x80
>
> This patch addresses the issue cited in 7332a13b038be05c by making vxlan
> actually check if ipv6 is loaded, and reverts it to module_init() so
> that it becomes device_initcall() when built-in, eliminating the
> netconsole issue.
>
> The ipv6 module is permanent, so there's no need to actually do the
> usual module_get/module_put dance: once we find it loaded, we can just
> assume that it always will be.
>
> AFAICS, not
[net-next PATCH 00/10] be2net: patch set
Hi David, The following patch set contains some feature additions, code re-organization and cleanup and a few non-critical fixes. Pls consider applying this to the net-next tree. Thanks. Patch 1 fixes VF link state transition from disabled to auto that did not work due to an issue in the FW. This issue could not be fixed in FW due to some backward compatibility issues it causes with released drivers. The issue has been fixed by introducing a new version (v2) of the cmd from 10.6 FW onwards. This patch adds support for v2 version of this cmd. Patch 2 reports a EOPNOTSUPP status to ethtool when the user tries to configure BE3/SRIOV in VEPA mode as it is not supported by the chip. Patch 3 cleansup FW flash image related constant definitions. Many of these definitions (such as section offset values) were defined in decimal format rather than hexa-decimal. This makes this part of the code un-readable. Also some defines related to BE2 are labeld "g2" and defines related to BE3 are labeled "g3". This patch cleans up all of this to make this code more readable. Patch 4 moves the FW cmd code to be_cmds.c. All code relating to FW cmds has been in be_cmds.[ch], excepting FW flash cmd related code. This patch moves these routines from be_main.c to be_cmds.c. Patch 5 adds a log message to report digital signature errors while flashing a FW image. From FW version 11.0 onwards, the FW supports a new "secure mode" feature (based on a jumper setting on the adapter.) In this mode, the FW image when flashed is authenticated with a digital signature. Patch 6 removes a line of code that has no effect. Patch 7 removes some unused variables. Patch 8 fixes port resource descriptor query via the GET_PROFILE FW cmd. An earlier commit passed a specific pf_num while issuing this cmd as FW returns descriptors for all functions when pf_num is zero. But, when pf_num is set to a non-zero value, FW does not return the port resource descriptor. This patch fixes this by setting pf_num to 0 while issuing the query cmd and adds code to pick the correct NIC resource descriptor from the list of descriptors returned by FW. Patch 9 adds support for ethtool get-dump feature. In the past when this option was not yet available, this feature was supported via the --register-dump option as a workaround. This patch removes support for FW-dump via --register-dump option as it is now available via --get-dump option. Even though the "ethtool --register-dump" cmd which used to work earlier, will now fail with ENOTSUPP error, we feel it is not an issue as this is used only for diagnostics purpose. Patch 10 bumps up the driver version. Sathya Perla (1): be2net: remove a line of code that has no effect Suresh Reddy (7): be2net: fix VF link state transition from disabled to auto be2net: avoid configuring VEPA mode on BE3 be2net: cleanup FW flash image related macro defines be2net: move FW flash cmd code to be_cmds.c be2net: log digital signature errors while flashing FW image be2net: fix port-res desc query of GET_PROFILE_CONFIG FW cmd be2net: bump up the driver version to 11.0.0.0 Venkat Duvvuru (2): be2net: remove unused error variables be2net: support ethtool get-dump option drivers/net/ethernet/emulex/benet/be.h | 13 +- drivers/net/ethernet/emulex/benet/be_cmds.c| 755 ++--- drivers/net/ethernet/emulex/benet/be_cmds.h| 178 +++--- drivers/net/ethernet/emulex/benet/be_ethtool.c | 82 ++- drivers/net/ethernet/emulex/benet/be_main.c| 588 +-- 5 files changed, 840 insertions(+), 776 deletions(-) -- 2.4.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 09/10] be2net: support ethtool get-dump option
From: Venkat Duvvuru
This patch adds support for ethtool's --get-dump option in be2net,
to retrieve FW dump. In the past when this option was not yet available,
this feature was supported via the --register-dump option as a workaround.
This patch removes support for FW-dump via --register-dump option as it is
now available via --get-dump option. Even though the
"ethtool --register-dump" cmd which used to work earlier, will now fail
with ENOTSUPP error, we feel it is not an issue as this is used only
for diagnostics purpose.
Signed-off-by: Venkat Duvvuru
Signed-off-by: Sathya Perla
---
drivers/net/ethernet/emulex/benet/be.h | 1 +
drivers/net/ethernet/emulex/benet/be_cmds.c| 38
drivers/net/ethernet/emulex/benet/be_cmds.h| 4 +-
drivers/net/ethernet/emulex/benet/be_ethtool.c | 82 --
drivers/net/ethernet/emulex/benet/be_main.c| 3 +
5 files changed, 71 insertions(+), 57 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h
b/drivers/net/ethernet/emulex/benet/be.h
index 66988f4..8b8212f 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -592,6 +592,7 @@ struct be_adapter {
struct rss_info rss_info;
/* Filters for packets that need to be sent to BMC */
u32 bmc_filt_mask;
+ u32 fat_dump_len;
u16 serial_num[CNTL_SERIAL_NUM_WORDS];
};
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 3ffe0c7..80fb981 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -1712,49 +1712,40 @@ err:
}
/* Uses synchronous mcc */
-int be_cmd_get_reg_len(struct be_adapter *adapter, u32 *log_size)
+int be_cmd_get_fat_dump_len(struct be_adapter *adapter, u32 *dump_size)
{
- struct be_mcc_wrb *wrb;
+ struct be_mcc_wrb wrb = {0};
struct be_cmd_req_get_fat *req;
int status;
- spin_lock_bh(&adapter->mcc_lock);
-
- wrb = wrb_from_mccq(adapter);
- if (!wrb) {
- status = -EBUSY;
- goto err;
- }
- req = embedded_payload(wrb);
+ req = embedded_payload(&wrb);
be_wrb_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
- OPCODE_COMMON_MANAGE_FAT, sizeof(*req), wrb,
- NULL);
+ OPCODE_COMMON_MANAGE_FAT, sizeof(*req),
+ &wrb, NULL);
req->fat_operation = cpu_to_le32(QUERY_FAT);
- status = be_mcc_notify_wait(adapter);
+ status = be_cmd_notify_wait(adapter, &wrb);
if (!status) {
- struct be_cmd_resp_get_fat *resp = embedded_payload(wrb);
+ struct be_cmd_resp_get_fat *resp = embedded_payload(&wrb);
- if (log_size && resp->log_size)
- *log_size = le32_to_cpu(resp->log_size) -
+ if (dump_size && resp->log_size)
+ *dump_size = le32_to_cpu(resp->log_size) -
sizeof(u32);
}
-err:
- spin_unlock_bh(&adapter->mcc_lock);
return status;
}
-int be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf)
+int be_cmd_get_fat_dump(struct be_adapter *adapter, u32 buf_len, void *buf)
{
struct be_dma_mem get_fat_cmd;
struct be_mcc_wrb *wrb;
struct be_cmd_req_get_fat *req;
u32 offset = 0, total_size, buf_size,
log_offset = sizeof(u32), payload_len;
- int status = 0;
+ int status;
if (buf_len == 0)
- return -EIO;
+ return 0;
total_size = buf_len;
@@ -1762,11 +1753,8 @@ int be_cmd_get_regs(struct be_adapter *adapter, u32
buf_len, void *buf)
get_fat_cmd.va = dma_zalloc_coherent(&adapter->pdev->dev,
get_fat_cmd.size,
&get_fat_cmd.dma, GFP_ATOMIC);
- if (!get_fat_cmd.va) {
- dev_err(&adapter->pdev->dev,
- "Memory allocation failure while reading FAT data\n");
+ if (!get_fat_cmd.va)
return -ENOMEM;
- }
spin_lock_bh(&adapter->mcc_lock);
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h
b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 5098170..241819b 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -2365,9 +2365,9 @@ int be_cmd_config_qos(struct be_adapter *adapter, u32
max_rate,
void be_detect_error(struct be_adapter *adapter);
int be_cmd_get_die_temperature(struct be_adapter *adapter);
int be_cmd_get_cntl_attributes(struct be_adapter *adapter);
+int be_cmd_get_fat_dump_len(struct be_adapter *adapter, u32 *dump_size);
+int be_cmd_get_fat_dump(struct be_adapter *adapter, u32 buf_len, void *buf);
int be_cmd_r
[net-next PATCH 02/10] be2net: avoid configuring VEPA mode on BE3
From: Suresh Reddy BE3 chip doesn't support VEPA mode. Signed-off-by: Suresh Reddy Signed-off-by: Sathya Perla --- drivers/net/ethernet/emulex/benet/be_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c index 34e324f..2f76cbe 100644 --- a/drivers/net/ethernet/emulex/benet/be_main.c +++ b/drivers/net/ethernet/emulex/benet/be_main.c @@ -5108,6 +5108,9 @@ static int be_ndo_bridge_setlink(struct net_device *dev, struct nlmsghdr *nlh, return -EINVAL; mode = nla_get_u16(attr); + if (BE3_chip(adapter) && mode == BRIDGE_MODE_VEPA) + return -EOPNOTSUPP; + if (mode != BRIDGE_MODE_VEPA && mode != BRIDGE_MODE_VEB) return -EINVAL; -- 2.4.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 07/10] be2net: remove unused error variables
From: Venkat Duvvuru
eeh_error, fw_timeout, hw_error variables in the be_adapter structure are
not used anymore. An earlier patch that introduced adapter->err_flags to
store this information missed removing these variables.
Signed-off-by: Venkat Duvvuru
Signed-off-by: Sathya Perla
---
drivers/net/ethernet/emulex/benet/be.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h
b/drivers/net/ethernet/emulex/benet/be.h
index 93e5eab..0af32f1 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -547,10 +547,6 @@ struct be_adapter {
u32 beacon_state; /* for set_phys_id */
- bool eeh_error;
- bool fw_timeout;
- bool hw_error;
-
u32 port_num;
char port_name;
u8 mc_type;
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 06/10] be2net: remove a line of code that has no effect
This patch removes a line of code that changes adapter->recommended_prio
value followed by yet another assignment.
Also, the variable is used to store the vlan priority value that is already
shifted to the PCP bits position in the vlan tag format. Hence, the name of
this variable is changed to recommended_prio_bits.
Signed-off-by: Sathya Perla
---
drivers/net/ethernet/emulex/benet/be.h | 2 +-
drivers/net/ethernet/emulex/benet/be_cmds.c | 3 +--
drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h
b/drivers/net/ethernet/emulex/benet/be.h
index d463563..93e5eab 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -521,7 +521,7 @@ struct be_adapter {
struct be_drv_stats drv_stats;
struct be_aic_obj aic_obj[MAX_EVT_QS];
u8 vlan_prio_bmap; /* Available Priority BitMap */
- u16 recommended_prio; /* Recommended Priority */
+ u16 recommended_prio_bits;/* Recommended Priority bits in vlan tag */
struct be_dma_mem rx_filter; /* Cmd DMA mem for rx-filter */
struct be_dma_mem stats_cmd;
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 6fb7873..8de876b 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -308,8 +308,7 @@ static void be_async_grp5_cos_priority_process(struct
be_adapter *adapter,
if (evt->valid) {
adapter->vlan_prio_bmap = evt->available_priority_bmap;
- adapter->recommended_prio &= ~VLAN_PRIO_MASK;
- adapter->recommended_prio =
+ adapter->recommended_prio_bits =
evt->reco_default_priority << VLAN_PRIO_SHIFT;
}
}
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
b/drivers/net/ethernet/emulex/benet/be_main.c
index 646b021..c9f9d4b 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -729,7 +729,7 @@ static inline u16 be_get_tx_vlan_tag(struct be_adapter
*adapter,
/* If vlan priority provided by OS is NOT in available bmap */
if (!(adapter->vlan_prio_bmap & (1 << vlan_prio)))
vlan_tag = (vlan_tag & ~VLAN_PRIO_MASK) |
- adapter->recommended_prio;
+ adapter->recommended_prio_bits;
return vlan_tag;
}
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 04/10] be2net: move FW flash cmd code to be_cmds.c
From: Suresh Reddy
All code relating to FW cmds is in be_cmds.[ch] excepting FW flash cmd
related code. This patch moves these routines from be_main.c to be_cmds.c
Signed-off-by: Suresh Reddy
Signed-off-by: Sathya Perla
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 583 +++-
drivers/net/ethernet/emulex/benet/be_cmds.h | 15 +-
drivers/net/ethernet/emulex/benet/be_main.c | 564 ---
3 files changed, 578 insertions(+), 584 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 8083eca..da3b398 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -2291,10 +2291,11 @@ err:
return status;
}
-int lancer_cmd_write_object(struct be_adapter *adapter, struct be_dma_mem *cmd,
- u32 data_size, u32 data_offset,
- const char *obj_name, u32 *data_written,
- u8 *change_status, u8 *addn_status)
+static int lancer_cmd_write_object(struct be_adapter *adapter,
+ struct be_dma_mem *cmd, u32 data_size,
+ u32 data_offset, const char *obj_name,
+ u32 *data_written, u8 *change_status,
+ u8 *addn_status)
{
struct be_mcc_wrb *wrb;
struct lancer_cmd_req_write_object *req;
@@ -2410,7 +2411,8 @@ int be_cmd_query_sfp_info(struct be_adapter *adapter)
return status;
}
-int lancer_cmd_delete_object(struct be_adapter *adapter, const char *obj_name)
+static int lancer_cmd_delete_object(struct be_adapter *adapter,
+ const char *obj_name)
{
struct lancer_cmd_req_delete_object *req;
struct be_mcc_wrb *wrb;
@@ -2485,9 +2487,9 @@ err_unlock:
return status;
}
-int be_cmd_write_flashrom(struct be_adapter *adapter, struct be_dma_mem *cmd,
- u32 flash_type, u32 flash_opcode, u32 img_offset,
- u32 buf_size)
+static int be_cmd_write_flashrom(struct be_adapter *adapter,
+struct be_dma_mem *cmd, u32 flash_type,
+u32 flash_opcode, u32 img_offset, u32 buf_size)
{
struct be_mcc_wrb *wrb;
struct be_cmd_write_flashrom *req;
@@ -2533,8 +2535,8 @@ err_unlock:
return status;
}
-int be_cmd_get_flash_crc(struct be_adapter *adapter, u8 *flashed_crc,
-u16 img_optype, u32 img_offset, u32 crc_offset)
+static int be_cmd_get_flash_crc(struct be_adapter *adapter, u8 *flashed_crc,
+ u16 img_optype, u32 img_offset, u32 crc_offset)
{
struct be_cmd_read_flash_crc *req;
struct be_mcc_wrb *wrb;
@@ -2571,6 +2573,567 @@ err:
return status;
}
+static char flash_cookie[2][16] = {"*** SE FLAS", "H DIRECTORY *** "};
+
+static bool phy_flashing_required(struct be_adapter *adapter)
+{
+ return (adapter->phy.phy_type == PHY_TYPE_TN_8022 &&
+ adapter->phy.interface_type == PHY_TYPE_BASET_10GB);
+}
+
+static bool is_comp_in_ufi(struct be_adapter *adapter,
+ struct flash_section_info *fsec, int type)
+{
+ int i = 0, img_type = 0;
+ struct flash_section_info_g2 *fsec_g2 = NULL;
+
+ if (BE2_chip(adapter))
+ fsec_g2 = (struct flash_section_info_g2 *)fsec;
+
+ for (i = 0; i < MAX_FLASH_COMP; i++) {
+ if (fsec_g2)
+ img_type = le32_to_cpu(fsec_g2->fsec_entry[i].type);
+ else
+ img_type = le32_to_cpu(fsec->fsec_entry[i].type);
+
+ if (img_type == type)
+ return true;
+ }
+ return false;
+}
+
+static struct flash_section_info *get_fsec_info(struct be_adapter *adapter,
+ int header_size,
+ const struct firmware *fw)
+{
+ struct flash_section_info *fsec = NULL;
+ const u8 *p = fw->data;
+
+ p += header_size;
+ while (p < (fw->data + fw->size)) {
+ fsec = (struct flash_section_info *)p;
+ if (!memcmp(flash_cookie, fsec->cookie, sizeof(flash_cookie)))
+ return fsec;
+ p += 32;
+ }
+ return NULL;
+}
+
+static int be_check_flash_crc(struct be_adapter *adapter, const u8 *p,
+ u32 img_offset, u32 img_size, int hdr_size,
+ u16 img_optype, bool *crc_match)
+{
+ u32 crc_offset;
+ int status;
+ u8 crc[4];
+
+ status = be_cmd_get_flash_crc(adapter, crc, img_optype, img_offset,
+ img_size - 4);
+ if (status)
+ return status;
+
+ crc_offset = hdr_size + img_offset + img_size - 4;
[net-next PATCH 10/10] be2net: bump up the driver version to 11.0.0.0
From: Suresh Reddy Signed-off-by: Suresh Reddy Signed-off-by: Sathya Perla --- drivers/net/ethernet/emulex/benet/be.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h index 8b8212f..22bf7af 100644 --- a/drivers/net/ethernet/emulex/benet/be.h +++ b/drivers/net/ethernet/emulex/benet/be.h @@ -37,7 +37,7 @@ #include "be_hw.h" #include "be_roce.h" -#define DRV_VER"10.6.0.3" +#define DRV_VER"11.0.0.0" #define DRV_NAME "be2net" #define BE_NAME"Emulex BladeEngine2" #define BE3_NAME "Emulex BladeEngine3" -- 2.4.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 01/10] be2net: fix VF link state transition from disabled to auto
From: Suresh Reddy
The VF link state setting transition from "disable" to "auto" does not work
due to a bug in SET_LOGICAL_LINK_CONFIG_V1 cmd in FW. This issue could not
be fixed in FW due to some backward compatibility issues it causes with
some released drivers. The issue has been fixed by introducing a new
version (v2) of the cmd from 10.6 FW onwards. In v2, to set the VF link
state to auto, both PLINK_ENABLE and PLINK_TRACK bits have to be set to 1.
The VF link state setting feature now works on Lancer chips too from
FW ver 10.6.315.0 onwards.
Signed-off-by: Suresh Reddy
Signed-off-by: Sathya Perla
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 35 +
drivers/net/ethernet/emulex/benet/be_cmds.h | 3 ++-
2 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 1795c93..8083eca 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -4260,16 +4260,13 @@ err:
return status;
}
-int be_cmd_set_logical_link_config(struct be_adapter *adapter,
- int link_state, u8 domain)
+int __be_cmd_set_logical_link_config(struct be_adapter *adapter,
+int link_state, int version, u8 domain)
{
struct be_mcc_wrb *wrb;
struct be_cmd_req_set_ll_link *req;
int status;
- if (BEx_chip(adapter) || lancer_chip(adapter))
- return -EOPNOTSUPP;
-
spin_lock_bh(&adapter->mcc_lock);
wrb = wrb_from_mccq(adapter);
@@ -4284,14 +4281,15 @@ int be_cmd_set_logical_link_config(struct be_adapter
*adapter,
OPCODE_COMMON_SET_LOGICAL_LINK_CONFIG,
sizeof(*req), wrb, NULL);
- req->hdr.version = 1;
+ req->hdr.version = version;
req->hdr.domain = domain;
- if (link_state == IFLA_VF_LINK_STATE_ENABLE)
- req->link_config |= 1;
+ if (link_state == IFLA_VF_LINK_STATE_ENABLE ||
+ link_state == IFLA_VF_LINK_STATE_AUTO)
+ req->link_config |= PLINK_ENABLE;
if (link_state == IFLA_VF_LINK_STATE_AUTO)
- req->link_config |= 1 << PLINK_TRACK_SHIFT;
+ req->link_config |= PLINK_TRACK;
status = be_mcc_notify_wait(adapter);
err:
@@ -4299,6 +4297,25 @@ err:
return status;
}
+int be_cmd_set_logical_link_config(struct be_adapter *adapter,
+ int link_state, u8 domain)
+{
+ int status;
+
+ if (BEx_chip(adapter))
+ return -EOPNOTSUPP;
+
+ status = __be_cmd_set_logical_link_config(adapter, link_state,
+ 2, domain);
+
+ /* Version 2 of the command will not be recognized by older FW.
+* On such a failure issue version 1 of the command.
+*/
+ if (base_status(status) == MCC_STATUS_ILLEGAL_REQUEST)
+ status = __be_cmd_set_logical_link_config(adapter, link_state,
+ 1, domain);
+ return status;
+}
int be_roce_mcc_cmd(void *netdev_handle, void *wrb_payload,
int wrb_payload_size, u16 *cmd_status, u16 *ext_status)
{
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h
b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 91155ea..9690c3a 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -2246,7 +2246,8 @@ struct be_cmd_resp_get_iface_list {
};
/*** Set logical link /
-#define PLINK_TRACK_SHIFT 8
+#define PLINK_ENABLEBIT(0)
+#define PLINK_TRACK BIT(8)
struct be_cmd_req_set_ll_link {
struct be_cmd_req_hdr hdr;
u32 link_config; /* Bit 0: UP_DOWN, Bit 9: PLINK */
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 05/10] be2net: log digital signature errors while flashing FW image
From: Suresh Reddy
>From FW version 11.0 onwards, the FW supports a new "secure mode" feature
(based on a jumper setting on the adapter.) In this mode, the FW image when
flashed is authenticated with a digital signature. This patch logs
appropriate error messages and return a status to ethtool when errors
relating to FW image authentication occur.
Signed-off-by: Suresh Reddy
Signed-off-by: Sathya Perla
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 11 +++
drivers/net/ethernet/emulex/benet/be_cmds.h | 4 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index da3b398..6fb7873 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -2959,6 +2959,17 @@ flash:
} else if (status) {
dev_err(dev, "Flashing section type 0x%x failed\n",
img_type);
+ if (addl_status(status) ==
+ MCC_ADDL_STATUS_MISSING_SIGNATURE) {
+ dev_err(dev,
+ "Digital signature missing in FW\n");
+ return -EINVAL;
+ } else if (addl_status(status) ==
+ MCC_ADDL_STATUS_INVALID_SIGNATURE) {
+ dev_err(dev,
+ "Invalid digital signature in FW\n");
+ return -EINVAL;
+ }
return -EFAULT;
}
}
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h
b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 4b0ca99..16415ca 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -66,7 +66,9 @@ enum mcc_addl_status {
MCC_ADDL_STATUS_INSUFFICIENT_RESOURCES = 0x16,
MCC_ADDL_STATUS_FLASH_IMAGE_CRC_MISMATCH = 0x4d,
MCC_ADDL_STATUS_TOO_MANY_INTERFACES = 0x4a,
- MCC_ADDL_STATUS_INSUFFICIENT_VLANS = 0xab
+ MCC_ADDL_STATUS_INSUFFICIENT_VLANS = 0xab,
+ MCC_ADDL_STATUS_INVALID_SIGNATURE = 0x56,
+ MCC_ADDL_STATUS_MISSING_SIGNATURE = 0x57
};
#define CQE_BASE_STATUS_MASK 0x
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 08/10] be2net: fix port-res desc query of GET_PROFILE_CONFIG FW cmd
From: Suresh Reddy
Commit 72ef3a88fa8e ("be2net: set pci_func_num while issuing
GET_PROFILE_CONFIG cmd") passed a specific pf_num while issuing a
GET_PROFILE_CONFIG cmd as FW returns descriptors for all functions when
pf_num is zero. But, when pf_num is set to a non-zero value, FW does not
return the Port resource descriptor.
This patch fixes this by setting pf_num to 0 while issuing the query cmd
and adds code to pick the correct NIC resource descriptor from the list of
descriptors returned by FW.
Fixes: 72ef3a88fa8e ("be2net: set pci_func_num while issuing
GET_PROFILE_CONFIG cmd")
Signed-off-by: Suresh Reddy
Signed-off-by: Sathya Perla
---
drivers/net/ethernet/emulex/benet/be.h | 4 +-
drivers/net/ethernet/emulex/benet/be_cmds.c | 85 -
drivers/net/ethernet/emulex/benet/be_cmds.h | 11 +---
drivers/net/ethernet/emulex/benet/be_main.c | 16 --
4 files changed, 63 insertions(+), 53 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h
b/drivers/net/ethernet/emulex/benet/be.h
index 0af32f1..66988f4 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -570,6 +570,8 @@ struct be_adapter {
struct be_resources pool_res; /* resources available for the port */
struct be_resources res;/* resources available for the func */
u16 num_vfs;/* Number of VFs provisioned by PF */
+ u8 pf_num; /* Numbering used by FW, starts at 0 */
+ u8 vf_num; /* Numbering used by FW, starts at 1 */
u8 virtfn;
struct be_vf_cfg *vf_cfg;
bool be3_native;
@@ -587,8 +589,6 @@ struct be_adapter {
u32 msg_enable;
int be_get_temp_freq;
struct be_hwmon hwmon_info;
- u8 pf_number;
- u8 pci_func_num;
struct rss_info rss_info;
/* Filters for packets that need to be sent to BMC */
u32 bmc_filt_mask;
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 8de876b..3ffe0c7 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -3465,7 +3465,6 @@ int be_cmd_get_cntl_attributes(struct be_adapter *adapter)
if (!status) {
attribs = attribs_cmd.va + sizeof(struct be_cmd_resp_hdr);
adapter->hba_port_num = attribs->hba_attribs.phy_port;
- adapter->pci_func_num = attribs->pci_func_num;
serial_num = attribs->hba_attribs.controller_serial_number;
for (i = 0; i < CNTL_SERIAL_NUM_WORDS; i++)
adapter->serial_num[i] = le32_to_cpu(serial_num[i]) &
@@ -4148,14 +4147,16 @@ int be_cmd_query_port_name(struct be_adapter *adapter)
return status;
}
-/* Descriptor type */
-enum {
- FUNC_DESC = 1,
- VFT_DESC = 2
-};
-
+/* When more than 1 NIC descriptor is present in the descriptor list,
+ * the caller must specify the pf_num to obtain the NIC descriptor
+ * corresponding to its pci function.
+ * get_vft must be true when the caller wants the VF-template desc of the
+ * PF-pool.
+ * The pf_num should be set to PF_NUM_IGNORE when the caller knows
+ * that only it's NIC descriptor is present in the descriptor list.
+ */
static struct be_nic_res_desc *be_get_nic_desc(u8 *buf, u32 desc_count,
- int desc_type)
+ bool get_vft, u8 pf_num)
{
struct be_res_desc_hdr *hdr = (struct be_res_desc_hdr *)buf;
struct be_nic_res_desc *nic;
@@ -4165,40 +4166,42 @@ static struct be_nic_res_desc *be_get_nic_desc(u8 *buf,
u32 desc_count,
if (hdr->desc_type == NIC_RESOURCE_DESC_TYPE_V0 ||
hdr->desc_type == NIC_RESOURCE_DESC_TYPE_V1) {
nic = (struct be_nic_res_desc *)hdr;
- if (desc_type == FUNC_DESC ||
- (desc_type == VFT_DESC &&
-nic->flags & (1 << VFT_SHIFT)))
+
+ if ((pf_num == PF_NUM_IGNORE ||
+nic->pf_num == pf_num) &&
+ (!get_vft || nic->flags & BIT(VFT_SHIFT)))
return nic;
}
-
hdr->desc_len = hdr->desc_len ? : RESOURCE_DESC_SIZE_V0;
hdr = (void *)hdr + hdr->desc_len;
}
return NULL;
}
-static struct be_nic_res_desc *be_get_vft_desc(u8 *buf, u32 desc_count)
+static struct be_nic_res_desc *be_get_vft_desc(u8 *buf, u32 desc_count,
+ u8 pf_num)
{
- return be_get_nic_desc(buf, desc_count, VFT_DESC);
+ return be_get_nic_desc(buf, desc_count, true, pf_num);
}
-static struct be_nic_res_desc *be_get_func_nic_desc(u8 *buf, u32 desc_count)
+static struct be_nic_res_desc *be_get_fun
[net-next PATCH 03/10] be2net: cleanup FW flash image related macro defines
From: Suresh Reddy
Many constant definitions relating to the FW-image layout
(such as section offset values) were defined in decimal format rather than
hexa-decimal. This makes this part of the code un-readable. Also some
defines related to BE2 are labeld "g2" and defines related to BE3 are
labeled "g3". This patch cleans up all of this to make this code more
readable.
Signed-off-by: Suresh Reddy
Signed-off-by: Sathya Perla
---
drivers/net/ethernet/emulex/benet/be_cmds.h | 141
drivers/net/ethernet/emulex/benet/be_main.c | 78 +++
2 files changed, 118 insertions(+), 101 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h
b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 9690c3a..8c6b606 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -1207,68 +1207,85 @@ struct be_cmd_resp_get_beacon_state {
/* Flashrom related descriptors */
#define MAX_FLASH_COMP 32
-#define OPTYPE_ISCSI_ACTIVE0
-#define OPTYPE_REDBOOT 1
-#define OPTYPE_BIOS2
-#define OPTYPE_PXE_BIOS3
-#define OPTYPE_OFFSET_SPECIFIED7
-#define OPTYPE_FCOE_BIOS 8
-#define OPTYPE_ISCSI_BACKUP9
-#define OPTYPE_FCOE_FW_ACTIVE 10
-#define OPTYPE_FCOE_FW_BACKUP 11
-#define OPTYPE_NCSI_FW 13
-#define OPTYPE_REDBOOT_DIR 18
-#define OPTYPE_REDBOOT_CONFIG 19
-#define OPTYPE_SH_PHY_FW 21
-#define OPTYPE_FLASHISM_JUMPVECTOR 22
-#define OPTYPE_UFI_DIR 23
-#define OPTYPE_PHY_FW 99
-
-#define FLASH_BIOS_IMAGE_MAX_SIZE_g2 262144 /* Max OPTION ROM image sz */
-#define FLASH_REDBOOT_IMAGE_MAX_SIZE_g2262144 /* Max Redboot image sz
*/
-#define FLASH_IMAGE_MAX_SIZE_g21310720 /* Max firmware image
size */
-
-#define FLASH_NCSI_IMAGE_MAX_SIZE_g3 262144
-#define FLASH_PHY_FW_IMAGE_MAX_SIZE_g3 262144
-#define FLASH_BIOS_IMAGE_MAX_SIZE_g3 524288 /* Max OPTION ROM image sz */
-#define FLASH_REDBOOT_IMAGE_MAX_SIZE_g31048576 /* Max Redboot image sz
*/
-#define FLASH_IMAGE_MAX_SIZE_g32097152 /* Max firmware image
size */
-
-/* Offsets for components on Flash. */
-#define FLASH_REDBOOT_START_g2 0
-#define FLASH_FCoE_BIOS_START_g2 524288
-#define FLASH_iSCSI_PRIMARY_IMAGE_START_g2 1048576
-#define FLASH_iSCSI_BACKUP_IMAGE_START_g2 2359296
-#define FLASH_FCoE_PRIMARY_IMAGE_START_g2 3670016
-#define FLASH_FCoE_BACKUP_IMAGE_START_g2 4980736
-#define FLASH_iSCSI_BIOS_START_g2 7340032
-#define FLASH_PXE_BIOS_START_g27864320
-
-#define FLASH_REDBOOT_START_g3 262144
-#define FLASH_PHY_FW_START_g3 1310720
-#define FLASH_iSCSI_PRIMARY_IMAGE_START_g3 2097152
-#define FLASH_iSCSI_BACKUP_IMAGE_START_g3 4194304
-#define FLASH_FCoE_PRIMARY_IMAGE_START_g3 6291456
-#define FLASH_FCoE_BACKUP_IMAGE_START_g3 8388608
-#define FLASH_iSCSI_BIOS_START_g3 12582912
-#define FLASH_PXE_BIOS_START_g313107200
-#define FLASH_FCoE_BIOS_START_g3 13631488
-#define FLASH_NCSI_START_g315990784
-
-#define IMAGE_NCSI 16
-#define IMAGE_OPTION_ROM_PXE 32
-#define IMAGE_OPTION_ROM_FCoE 33
-#define IMAGE_OPTION_ROM_ISCSI 34
-#define IMAGE_FLASHISM_JUMPVECTOR 48
-#define IMAGE_FIRMWARE_iSCSI 160
-#define IMAGE_FIRMWARE_FCoE162
-#define IMAGE_FIRMWARE_BACKUP_iSCSI176
-#define IMAGE_FIRMWARE_BACKUP_FCoE 178
-#define IMAGE_FIRMWARE_PHY 192
-#define IMAGE_REDBOOT_DIR 208
-#define IMAGE_REDBOOT_CONFIG 209
-#define IMAGE_UFI_DIR 210
-#define IMAGE_BOOT_CODE224
+/* Optypes of each component in the UFI */
+enum {
+ OPTYPE_ISCSI_ACTIVE = 0,
+ OPTYPE_REDBOOT = 1,
+ OPTYPE_BIOS = 2,
+ OPTYPE_PXE_BIOS = 3,
+ OPTYPE_OFFSET_SPECIFIED = 7,
+ OPTYPE_FCOE_BIOS = 8,
+ OPTYPE_ISCSI_BACKUP = 9,
+ OPTYPE_FCOE_FW_ACTIVE = 10,
+ OPTYPE_FCOE_FW_BACKUP = 11,
+ OPTYPE_NCSI_FW = 13,
+ OPTYPE_REDBOOT_DIR = 18,
+ OPTYPE_REDBOOT_CONFIG = 19,
+ OPTYPE_SH_PHY_FW = 21,
+ OPTYPE_FLASHISM_JUMPVECTOR = 22,
+ OPTYPE_UFI_DIR = 23,
+ OPTYPE_PHY_FW = 99
+};
+
+/* Maximum sizes of components in BE2 FW UFI */
+enum {
+ BE2_BIOS_COMP_MAX_SIZE = 0x4,
+ BE2_REDBOOT_COMP_MAX_SIZE = 0x4,
+ BE2_COMP_MAX_SIZE = 0x14
+};
+
+/* Maximum sizes of components in BE3 FW UFI */
+enum {
+ BE3_NCSI_COMP_MAX_SIZE = 0x4,
+ BE3_PHY_FW_COMP_MAX_SIZE = 0x4,
+ BE3_BIOS_COMP_MAX_SIZE = 0x8,
+ BE3_REDBOOT_COMP_MAX_SIZE = 0x10,
+ B
Re: [PATCH net-next v2] ip_tunnel: Move stats update to iptunnel_xmit()
Le 24/12/2015 00:52, Pravin B Shelar a écrit :
[snip]
diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index 6af78c6..d63a911 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -182,15 +182,9 @@ static int tipc_udp_send_msg(struct net *net, struct
sk_buff *skb,
goto tx_error;
}
ttl = ip4_dst_hoplimit(&rt->dst);
- err = udp_tunnel_xmit_skb(rt, ub->ubsock->sk, skb,
- src->ipv4.s_addr,
- dst->ipv4.s_addr, 0, ttl, 0,
- src->udp_port, dst->udp_port,
- false, true);
- if (err < 0) {
- ip_rt_put(rt);
- goto tx_error;
- }
+ udp_tunnel_xmit_skb(rt, ub->ubsock->sk, skb, src->ipv4.s_addr,
+ dst->ipv4.s_addr, 0, ttl, 0, src->udp_port,
+ dst->udp_port, false, true);
I don't know how tipc works, but this change is clearly suspect. What make the
error path not needed anymore after your patch?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] qlcnic: fix a loop exit condition better
In the original code, if we succeeded on the last iteration through the
loop then we still returned failure.
Fixes: 389e4e04ad2d ('qlcnic: fix a timeout loop')
Signed-off-by: Dan Carpenter
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
index b1a452f..3490675 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
@@ -252,7 +252,7 @@ int qlcnic_83xx_check_vnic_state(struct qlcnic_adapter
*adapter)
state = QLCRDX(ahw, QLC_83XX_VNIC_STATE);
}
- if (!idc->vnic_wait_limit) {
+ if (state != QLCNIC_DEV_NPAR_OPER) {
dev_err(&adapter->pdev->dev,
"vNIC mode not operational, state check timed out.\n");
return -EIO;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2] ip_tunnel: Move stats update to iptunnel_xmit()
Le 24/12/2015 00:52, Pravin B Shelar a écrit :
[snip]
@@ -83,22 +84,12 @@ int ip6_tnl_get_iflink(const struct net_device *dev);
static inline void ip6tunnel_xmit(struct sock *sk, struct sk_buff *skb,
struct net_device *dev)
{
- struct net_device_stats *stats = &dev->stats;
int pkt_len, err;
pkt_len = skb->len - skb_inner_network_offset(skb);
err = ip6_local_out(dev_net(skb_dst(skb)->dev), sk, skb);
-
- if (net_xmit_eval(err) == 0) {
- struct pcpu_sw_netstats *tstats = get_cpu_ptr(dev->tstats);
- u64_stats_update_begin(&tstats->syncp);
- tstats->tx_bytes += pkt_len;
- tstats->tx_packets++;
- u64_stats_update_end(&tstats->syncp);
- put_cpu_ptr(tstats);
- } else {
- stats->tx_errors++;
- stats->tx_aborted_errors++;
- }
+ if (likely(!net_xmit_eval(err)))
+ err = pkt_len;
+ iptunnel_xmit_stats(dev, err);
I don't think this is an equivalent change.
For example, if err == NET_XMIT_DROP, then '!net_xmit_eval(err)' is false and
iptunnel_xmit_stats() is called with err set to a positive value (NET_XMIT_DROP
value is 0x01), ie not an error.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] drivers: net: cpsw: phy-handle fixes
On Wednesday 23 December 2015 20:18:16 David Rivshin wrote: > On Thu, 24 Dec 2015 00:34:49 +0100 > > Nicolas Chauvet wrote: > > 2015-12-23 22:54 GMT+01:00 David Rivshin (Allworx) < > > > > here is the full dmesg output with this serie applied to linux-next: > > http://ur1.ca/ocvs6 Linux version 4.4.0-rc6-next-20151223-00029-g858e234 (kwizart@nchauvet- desktop) (gcc version 5.2.1 20150716 (Red Hat Cross 5.2.1-3) (GCC) ) #15 SMP Wed Dec 23 18:29:57 CET 2015 I will refer to this as 0029 > > Comparing a dmesg output where the driver work: it doesn't show any > > difference from the quoted lines: > > http://paste.fedoraproject.org/304248/45086839/ Linux version 4.4.0-rc6-next-20151223-00023-g71d15d9 (kwizart@nchauvet- desktop) (gcc version 5.2.1 20150716 (Red Hat Cross 5.2.1-3) (GCC) ) #12 SMP Wed Dec 23 10:36:46 CET 2015 I will refer to this as 0023 I made a "grep fail" on both dmesg and 0023 seems to lack edma, mmc and usb. I wonder how ethernet could have worked. There seems also to be a problem with the clocks. fails that are specific to 0023: ti_dt_clocks_register: failed to lookup clock node sysclk5_ck ti_dt_clocks_register: failed to lookup clock node sysclk8_ck platform 4740.usb: clk_get for pll260dcoclkldo failed platform 4806.mmc: clk_get for sysclk8_ck failed platform 481d8000.mmc: clk_get for sysclk8_ck failed platform 4781.mmc: clk_get for sysclk8_ck failed edma 4900.edma: pm_runtime_get_sync() failed edma: probe of 4900.edma failed with error -22 musb-dsps: probe of 47401400.usb failed with error -16 musb-dsps: probe of 47401c00.usb failed with error -16 cppi41-dma-engine: probe of 4740.dma-controller failed with error -16 omap_hsmmc: probe of 4806.mmc failed with error -2 omap_hsmmc: probe of 481d8000.mmc failed with error -2 omap_hsmmc: probe of 4781.mmc failed with error -2 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vxlan: Properly depend on ipv6 and revert to module_init()
Hi Calvin,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.4-rc6 next-20151223]
url:
https://github.com/0day-ci/linux/commits/Calvin-Owens/vxlan-Properly-depend-on-ipv6-and-revert-to-module_init/20151224-070557
config: i386-randconfig-b0-12241357 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from include/linux/linkage.h:4:0,
from include/linux/kernel.h:6,
from drivers/net/vxlan.c:13:
drivers/net/vxlan.c: In function 'vxlan_create_sock':
>> drivers/net/vxlan.c:2661:8: error: implicit declaration of function
>> 'vxlan_ipv6_is_loaded' [-Werror=implicit-function-declaration]
if (!vxlan_ipv6_is_loaded())
^
include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
if (__builtin_constant_p((cond)) ? !!(cond) : \
^
>> drivers/net/vxlan.c:2661:3: note: in expansion of macro 'if'
if (!vxlan_ipv6_is_loaded())
^
cc1: some warnings being treated as errors
vim +/vxlan_ipv6_is_loaded +2661 drivers/net/vxlan.c
2655 struct udp_port_cfg udp_conf;
2656 int err;
2657
2658 memset(&udp_conf, 0, sizeof(udp_conf));
2659
2660 if (ipv6) {
> 2661 if (!vxlan_ipv6_is_loaded())
2662 return ERR_PTR(-EAFNOSUPPORT);
2663
2664 udp_conf.family = AF_INET6;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH net-next v2] ip_tunnel: Move stats update to iptunnel_xmit()
Le 24/12/2015 05:37, Pravin Shelar a écrit :
On Wed, Dec 23, 2015 at 6:57 PM, David Miller wrote:
From: Pravin B Shelar
Date: Wed, 23 Dec 2015 15:52:03 -0800
} else {
- err_stats->tx_dropped++;
+ struct net_device_stats *err_stats = &dev->stats;
+
+ if (err < 0) {
+ err_stats->tx_errors++;
+ err_stats->tx_aborted_errors++;
+ } else {
+ err_stats->tx_dropped++;
+ }
The original code did not have this "tx_dropped" code path
and you aren't explaining in your commit message why you
are adding this new behavior.
There is "tx_dropped" code path in existing iptunnel_xmit_stats(). I
have only moved err_stats variable definition to local block.
There is no new behavior in this patch.
Yes, I think it's ok now. There is no functional change. The prototype
of the function has changed: err_stats is not provided anymore in the arguments.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: Make addr const in SET_IEEE80211_PERM_ADDR()
Make the addr parameter const in SET_IEEE80211_PERM_ADDR() to save
clients from having to cast away a const qualifier.
Signed-off-by: Bjorn Andersson
---
include/net/mac80211.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7c30faff245f..a6f3c9c4b7c2 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2167,7 +2167,7 @@ static inline void SET_IEEE80211_DEV(struct ieee80211_hw
*hw, struct device *dev
* @hw: the &struct ieee80211_hw to set the MAC address for
* @addr: the address to set
*/
-static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, u8 *addr)
+static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, const u8
*addr)
{
memcpy(hw->wiphy->perm_addr, addr, ETH_ALEN);
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V1 15/16] i40iw: add entry in rdma_netlink
On 12/24/2015 9:05 AM, Faisal Latif wrote:
>Why the iwarp port mapper implementationhas to be repeated in each
>driver? can you join your code in a common place and avoid the duplication?
>
>root@r-dcs58 hw]# git grep RDMA_NL_ nes
>nes/nes.c: [RDMA_NL_IWPM_REG_PID] = {.dump = iwpm_register_pid_cb},
>nes/nes.c: [RDMA_NL_IWPM_ADD_MAPPING] = {.dump = iwpm_add_mapping_cb},
>nes/nes.c: [RDMA_NL_IWPM_QUERY_MAPPING] = {.dump =
>iwpm_add_and_query_mapping_cb},
>nes/nes.c: [RDMA_NL_IWPM_REMOTE_INFO] = {.dump = iwpm_remote_info_cb},
>nes/nes.c: [RDMA_NL_IWPM_HANDLE_ERR] = {.dump = iwpm_mapping_error_cb},
>nes/nes.c: [RDMA_NL_IWPM_MAPINFO] = {.dump = iwpm_mapping_info_cb},
>nes/nes.c: [RDMA_NL_IWPM_MAPINFO_NUM] = {.dump =
>iwpm_ack_mapping_info_cb}
>nes/nes.c: if (ibnl_add_client(RDMA_NL_NES, RDMA_NL_IWPM_NUM_OPS,
>nes_nl_cb_table))
>nes/nes.c: ret = iwpm_init(RDMA_NL_NES);
>nes/nes.c: ibnl_remove_client(RDMA_NL_NES);
>nes/nes.c: ibnl_remove_client(RDMA_NL_NES);
>nes/nes.c: iwpm_exit(RDMA_NL_NES);
>nes/nes_cm.c: &mapped_sockaddr, RDMA_NL_NES);
>nes/nes_cm.c: return iwpm_remove_mapping(&local_sockaddr, RDMA_NL_NES);
>nes/nes_cm.c: &remote_addr, RDMA_NL_NES);
>nes/nes_cm.c: iwpm_err = iwpm_register_pid(&pm_reg_msg,
>RDMA_NL_NES);
>nes/nes_cm.c: iwpm_err = iwpm_add_mapping(&pm_msg,
>RDMA_NL_NES);
>nes/nes_cm.c: iwpm_err = iwpm_register_pid(&pm_reg_msg, RDMA_NL_NES);
>nes/nes_cm.c: iwpm_err = iwpm_add_and_query_mapping(&pm_msg,
>RDMA_NL_NES);
>
i40iw iwarp driver registers with port mapper and uses its services. Beside
that it is not the scope of the patch series.
You are asked a question by reviewer and your reply is
(1) YES, I did C & P from driver X to my driver
(2) explaining why C&P is right goes beyond the scope of reviewing my driver
This isn't how things work in upstream.
If needed, talk to the upstream Intel networking folks, they can assist
you catching up on upstream practices.
Or.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V1 08/16] i40iw: add files for iwarp interface
On 12/24/2015 9:31 AM, Faisal Latif wrote:
On Wed, Dec 23, 2015 at 08:42:01AM -0800, Or Gerlitz wrote:
On 12/22/2015 1:13 AM, Faisal Latif wrote:
+
+enum i40iw_memreg_type {
+ IW_MEMREG_TYPE_MEM = 0x,
+ IW_MEMREG_TYPE_QP = 0x0001,
+ IW_MEMREG_TYPE_CQ = 0x0002,
+ IW_MEMREG_TYPE_MW = 0x0003,
+ IW_MEMREG_TYPE_FMR = 0x0004,
+ IW_MEMREG_TYPE_FMEM = 0x0005,
+};
Can't you re-use IB core values or derive that from the actual uverbs
command?
I did not see anything which will have types that I needed.
what do you need? what is the role of this enum?
It will be confusing otherwise.
I will be reducing number of types from here though.
so why some of it can go? is that deal values which aren't used by the code
Or.
Thanks
Faisal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
