Re: [PATCH net-next] ip_tunnel: Move stats update to iptunnel_xmit()

[Nicolas Dichtel]

Le 22/12/2015 01:34, Pravin B Shelar a écrit :

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 
---

[snip]

+static inline void iptunnel_xmit_stats(struct net_device *dev, int err)
  {
if (err > 0) {
-   struct pcpu_sw_netstats *tstats = get_cpu_ptr(stats);
+   struct pcpu_sw_netstats *tstats = get_cpu_ptr(dev->tstats);

u64_stats_update_begin(>syncp);
tstats->tx_bytes += err;
tstats->tx_packets++;
u64_stats_update_end(>syncp);
put_cpu_ptr(tstats);
-   } else if (err < 0) {
+   } else {
+   struct net_device_stats *err_stats = >stats;
+
err_stats->tx_errors++;
err_stats->tx_aborted_errors++;
-   } else {
-   err_stats->tx_dropped++;
}
  }

Why do you remove the case 'err == 0'?
At least, it needs an explanation in the commit log.
--
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 2/2] ixgbe: Use core to device locality interface

[Daniel J Blueman]

Rather than assuming cores starting from 0 are local to the ethernet
device, use the introduced interface to find near cores.

Not only does this improve performance due to spreading interrupts via near
NUMA nodes, it prevents assigning cores on distant NUMA nodes, which aren't
reachable by device interrupts due to the 8-bit APIC ID limitation.

With Numascale NumaConnect2 systems with Intel ixgbe cards on
non-primary PCI domains, all ixgbe NICs would previously revector
interrupts to cores 0 to 63 (cores 0 to 47 would be considered
near the primary PCI domain). Now, cores 48 to 95 are used, increasing
performance and addressing interrupt delivery issues:

do_IRQ: 79.180 No irq handler for vector (irq -1)
do_IRQ: 78.42 No irq handler for vector (irq -1)
do_IRQ: 71.172 No irq handler for vector (irq -1)
do_IRQ: 70.236 No irq handler for vector (irq -1)
do_IRQ: 69.109 No irq handler for vector (irq -1)
do_IRQ: 68.189 No irq handler for vector (irq -1)
do_IRQ: 72.92 No irq handler for vector (irq -1)
do_IRQ: 73.235 No irq handler for vector (irq -1)
do_IRQ: 66.185 No irq handler for vector (irq -1)
do_IRQ: 67.62 No irq handler for vector (irq -1)
do_IRQ: 197 callbacks suppressed

Signed-off-by: Daniel J Blueman 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
index f3168bc..12c4ce1 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
@@ -817,10 +817,8 @@ static int ixgbe_alloc_q_vector(struct ixgbe_adapter 
*adapter,
if ((tcs <= 1) && !(adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)) {
u16 rss_i = adapter->ring_feature[RING_F_RSS].indices;
if (rss_i > 1 && adapter->atr_sample_rate) {
-   if (cpu_online(v_idx)) {
-   cpu = v_idx;
-   node = cpu_to_node(cpu);
-   }
+   cpu = cpu_near_dev(adapter->pdev, v_idx);
+   node = cpu_to_node(cpu);
}
}

--
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 1/2] PCI: Add mechanism to find topologically near cores

[Daniel J Blueman]

Some devices (eg ixgbe) make assumptions about device to core locality when
specifying interrupts locality hints and allocate starting from core 0.
Moreover, interrupts may not be routable to distant NUMA nodes due to the
8-bit APIC ID space limitations.

Provide a mechanism drivers can use to find cores with reasonable locality
to a device; use the existing precendent of RECLAIM_DISTANCE (30), wrapping
the offset.

Signed-off-by: Daniel J Blueman 
---
 drivers/pci/pci.c   | 15 +++
 include/linux/pci.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 314db8c..d5535d1 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4833,6 +4833,22 @@ void __weak pci_fixup_cardbus(struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pci_fixup_cardbus);

+int cpu_near_dev(const struct pci_dev *pdev, unsigned offset)
+{
+   /* Start search from node device is on for optimal locality */
+   int localnode = pcibus_to_node(pdev->bus);
+   int cpu = cpumask_first(cpumask_of_node(localnode));
+
+   while (offset--) {
+   do {
+   cpu = (cpu + 1) % nr_cpu_ids;
+   } while (!cpu_online(cpu) || node_distance(cpu_to_node(cpu),
+   localnode) > RECLAIM_DISTANCE);
+   }
+
+   return cpu;
+}
+
 static int __init pci_setup(char *str)
 {
while (str) {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6ae25aa..f7491bd 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -842,6 +842,7 @@ void pci_stop_root_bus(struct pci_bus *bus);
 void pci_remove_root_bus(struct pci_bus *bus);
 void pci_setup_cardbus(struct pci_bus *bus);
 void pci_sort_breadthfirst(void);
+int cpu_near_dev(const struct pci_dev *pdev, unsigned offset);
 #define dev_is_pci(d) ((d)->bus == _bus_type)
 #define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)->is_physfn : false))
 #define dev_num_vf(d) ((dev_is_pci(d) ? pci_num_vf(to_pci_dev(d)) : 0))
--
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 net-next 0/3] Ethtool support for phy stats

[Andrew Lunn]

This patchset add ethtool support for reading statistics from the PHY.
The Marvell and Micrel Phys are then extended to report receiver
packet errors and idle errors.

Patches to ethtool(1) to follow.

Andrew Lunn (3):
  ethtool: Add phy statistics
  phy: marvell: Add ethtool statistics counters
  phy: micrel: Add ethtool statistics counters

 drivers/net/phy/marvell.c| 135 +++
 drivers/net/phy/micrel.c |  96 ++
 drivers/net/phy/phy.c|  35 +++
 include/linux/phy.h  |  11 +++-
 include/uapi/linux/ethtool.h |   3 +
 net/core/ethtool.c   |  55 +-
 6 files changed, 333 insertions(+), 2 deletions(-)

-- 
2.6.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 net-next 2/3] phy: marvell: Add ethtool statistics counters

[Andrew Lunn]

The PHY counters receiver errors and errors while idle.

Signed-off-by: Andrew Lunn 
---
 drivers/net/phy/marvell.c | 135 ++
 1 file changed, 135 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 0240552b50f3..50b5eac75854 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -137,6 +137,22 @@ MODULE_DESCRIPTION("Marvell PHY driver");
 MODULE_AUTHOR("Andy Fleming");
 MODULE_LICENSE("GPL");
 
+struct marvell_hw_stat {
+   const char *string;
+   u8 page;
+   u8 reg;
+   u8 bits;
+};
+
+static struct marvell_hw_stat marvell_hw_stats[] = {
+   { "phy_receive_errors", 0, 21, 16},
+   { "phy_idle_errors", 0, 10, 8 },
+};
+
+struct marvell_priv {
+   u64 stats[ARRAY_SIZE(marvell_hw_stats)];
+};
+
 static int marvell_ack_interrupt(struct phy_device *phydev)
 {
int err;
@@ -986,12 +1002,80 @@ static int m88e1318_set_wol(struct phy_device *phydev, 
struct ethtool_wolinfo *w
return 0;
 }
 
+static int marvell_get_sset_count(struct phy_device *phydev)
+{
+   return ARRAY_SIZE(marvell_hw_stats);
+}
+
+static void marvell_get_strings(struct phy_device *phydev, u8 *data)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(marvell_hw_stats); i++) {
+   memcpy(data + i * ETH_GSTRING_LEN,
+  marvell_hw_stats[i].string, ETH_GSTRING_LEN);
+   }
+}
+
+#ifndef UINT64_MAX
+#define UINT64_MAX  (u64)(~((u64)0))
+#endif
+static u64 marvell_get_stat(struct phy_device *phydev, int i)
+{
+   struct marvell_hw_stat stat = marvell_hw_stats[i];
+   struct marvell_priv *priv = phydev->priv;
+   int err, oldpage;
+   u64 val;
+
+   oldpage = phy_read(phydev, MII_MARVELL_PHY_PAGE);
+   err = phy_write(phydev, MII_MARVELL_PHY_PAGE,
+   stat.page);
+   if (err < 0)
+   return UINT64_MAX;
+
+   val = phy_read(phydev, stat.reg);
+   if (val < 0) {
+   val = UINT64_MAX;
+   } else {
+   val = val & ((1 << stat.bits) - 1);
+   priv->stats[i] += val;
+   val = priv->stats[i];
+   }
+
+   phy_write(phydev, MII_MARVELL_PHY_PAGE, oldpage);
+
+   return val;
+}
+
+static void marvell_get_stats(struct phy_device *phydev,
+ struct ethtool_stats *stats, u64 *data)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(marvell_hw_stats); i++)
+   data[i] = marvell_get_stat(phydev, i);
+}
+
+static int marvell_probe(struct phy_device *phydev)
+{
+   struct marvell_priv *priv;
+
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   phydev->priv = priv;
+
+   return 0;
+}
+
 static struct phy_driver marvell_drivers[] = {
{
.phy_id = MARVELL_PHY_ID_88E1101,
.phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1101",
.features = PHY_GBIT_FEATURES,
+   .probe = marvell_probe,
.flags = PHY_HAS_INTERRUPT,
.config_aneg = _config_aneg,
.read_status = _read_status,
@@ -999,6 +1083,9 @@ static struct phy_driver marvell_drivers[] = {
.config_intr = _config_intr,
.resume = _resume,
.suspend = _suspend,
+   .get_sset_count = marvell_get_sset_count,
+   .get_strings = marvell_get_strings,
+   .get_stats = marvell_get_stats,
.driver = { .owner = THIS_MODULE },
},
{
@@ -1007,6 +1094,7 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1112",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
+   .probe = marvell_probe,
.config_init = _config_init,
.config_aneg = _config_aneg,
.read_status = _read_status,
@@ -1014,6 +1102,9 @@ static struct phy_driver marvell_drivers[] = {
.config_intr = _config_intr,
.resume = _resume,
.suspend = _suspend,
+   .get_sset_count = marvell_get_sset_count,
+   .get_strings = marvell_get_strings,
+   .get_stats = marvell_get_stats,
.driver = { .owner = THIS_MODULE },
},
{
@@ -1022,6 +1113,7 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
+   .probe = marvell_probe,
.config_init = _config_init,
.config_aneg = _config_aneg,
.read_status = _read_status,
@@ -1029,6 +1121,9 @@ static struct phy_driver marvell_drivers[] = {
.config_intr = _config_intr,
.resume = _resume,
  

[PATCH net-next 1/3] ethtool: Add phy statistics

[Andrew Lunn]

Ethernet PHYs can maintain statistics, for example errors while idle
and receive errors. Add an ethertool mechanism to retrieve these
statistics, using the same model as MAC statistics.

Signed-off-by: Andrew Lunn 
---
 drivers/net/phy/phy.c| 35 
 include/linux/phy.h  | 11 -
 include/uapi/linux/ethtool.h |  3 +++
 net/core/ethtool.c   | 55 +++-
 4 files changed, 102 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 47cd306dbb3c..fc6a770adf40 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1262,3 +1262,38 @@ void phy_ethtool_get_wol(struct phy_device *phydev, 
struct ethtool_wolinfo *wol)
phydev->drv->get_wol(phydev, wol);
 }
 EXPORT_SYMBOL(phy_ethtool_get_wol);
+
+int phy_get_sset_count(struct phy_device *phydev)
+{
+   int ret;
+
+   if (phydev->drv->get_sset_count &&
+   phydev->drv->get_strings &&
+   phydev->drv->get_stats) {
+   mutex_lock(>lock);
+   ret = phydev->drv->get_sset_count(phydev);
+   mutex_unlock(>lock);
+
+   return ret;
+   }
+
+   return -EOPNOTSUPP;
+}
+EXPORT_SYMBOL(phy_get_sset_count);
+
+void phy_get_strings(struct phy_device *phydev, u8 *data)
+{
+   mutex_lock(>lock);
+   phydev->drv->get_strings(phydev, data);
+   mutex_unlock(>lock);
+}
+EXPORT_SYMBOL(phy_get_strings);
+
+void phy_get_stats(struct phy_device *phydev, struct ethtool_stats *stats,
+  u64 *data)
+{
+   mutex_lock(>lock);
+   phydev->drv->get_stats(phydev, stats, data);
+   mutex_unlock(>lock);
+}
+EXPORT_SYMBOL(phy_get_stats);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 05fde31b6dc6..d457c6efbbd5 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -589,6 +589,12 @@ struct phy_driver {
int (*module_eeprom)(struct phy_device *dev,
 struct ethtool_eeprom *ee, u8 *data);
 
+   /* Get statistics from the phy using ethtool */
+   int (*get_sset_count)(struct phy_device *dev);
+   void (*get_strings)(struct phy_device *dev, u8 *data);
+   void (*get_stats)(struct phy_device *dev,
+ struct ethtool_stats *stats, u64 *data);
+
struct device_driver driver;
 };
 #define to_phy_driver(d) container_of(d, struct phy_driver, driver)
@@ -816,7 +822,10 @@ int phy_ethtool_get_eee(struct phy_device *phydev, struct 
ethtool_eee *data);
 int phy_ethtool_set_wol(struct phy_device *phydev, struct ethtool_wolinfo 
*wol);
 void phy_ethtool_get_wol(struct phy_device *phydev,
 struct ethtool_wolinfo *wol);
-
+int phy_get_sset_count(struct phy_device *phydev);
+void phy_get_strings(struct phy_device *phydev, u8 *data);
+void phy_get_stats(struct phy_device *phydev, struct ethtool_stats *stats,
+  u64 *data);
 int __init mdio_bus_init(void);
 void mdio_bus_exit(void);
 
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index cd1629170103..57fa39005e79 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -542,6 +542,7 @@ struct ethtool_pauseparam {
  * now deprecated
  * @ETH_SS_FEATURES: Device feature names
  * @ETH_SS_RSS_HASH_FUNCS: RSS hush function names
+ * @ETH_SS_PHY_STATS: Statistic names, for use with %ETHTOOL_GPHYSTATS
  */
 enum ethtool_stringset {
ETH_SS_TEST = 0,
@@ -551,6 +552,7 @@ enum ethtool_stringset {
ETH_SS_FEATURES,
ETH_SS_RSS_HASH_FUNCS,
ETH_SS_TUNABLES,
+   ETH_SS_PHY_STATS,
 };
 
 /**
@@ -1225,6 +1227,7 @@ enum ethtool_sfeatures_retval_bits {
 #define ETHTOOL_SRSSH  0x0047 /* Set RX flow hash configuration */
 #define ETHTOOL_GTUNABLE   0x0048 /* Get tunable configuration */
 #define ETHTOOL_STUNABLE   0x0049 /* Set tunable configuration */
+#define ETHTOOL_GPHYSTATS  0x004a /* get PHY-specific statistics */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 09948a726347..9dd6fec35e5a 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -204,6 +204,13 @@ static int __ethtool_get_sset_count(struct net_device 
*dev, int sset)
if (sset == ETH_SS_TUNABLES)
return ARRAY_SIZE(tunable_strings);
 
+   if (sset == ETH_SS_PHY_STATS) {
+   if (dev->phydev)
+   return phy_get_sset_count(dev->phydev);
+   else
+   return -EOPNOTSUPP;
+   }
+
if (ops->get_sset_count && ops->get_strings)
return ops->get_sset_count(dev, sset);
else
@@ -223,7 +230,10 @@ static void __ethtool_get_strings(struct net_device *dev,
   sizeof(rss_hash_func_strings));
else if (stringset == ETH_SS_TUNABLES)
   

[PATCH net-next 3/3] phy: micrel: Add ethtool statistics counters

[Andrew Lunn]

The PHY counters receiver errors and errors while idle.

Signed-off-by: Andrew Lunn 
---
 drivers/net/phy/micrel.c | 96 
 1 file changed, 96 insertions(+)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index e13ad6cdcc22..1a6048a8c29d 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -73,6 +73,17 @@
 
 #define PS_TO_REG  200
 
+struct kszphy_hw_stat {
+   const char *string;
+   u8 reg;
+   u8 bits;
+};
+
+static struct kszphy_hw_stat kszphy_hw_stats[] = {
+   { "phy_receive_errors", 21, 16},
+   { "phy_idle_errors", 10, 8 },
+};
+
 struct kszphy_type {
u32 led_mode_reg;
u16 interrupt_level_mask;
@@ -86,6 +97,7 @@ struct kszphy_priv {
int led_mode;
bool rmii_ref_clk_sel;
bool rmii_ref_clk_sel_val;
+   u64 stats[ARRAY_SIZE(kszphy_hw_stats)];
 };
 
 static const struct kszphy_type ksz8021_type = {
@@ -569,6 +581,51 @@ ksz9021_wr_mmd_phyreg(struct phy_device *phydev, int 
ptrad, int devnum,
 {
 }
 
+static int kszphy_get_sset_count(struct phy_device *phydev)
+{
+   return ARRAY_SIZE(kszphy_hw_stats);
+}
+
+static void kszphy_get_strings(struct phy_device *phydev, u8 *data)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(kszphy_hw_stats); i++) {
+   memcpy(data + i * ETH_GSTRING_LEN,
+  kszphy_hw_stats[i].string, ETH_GSTRING_LEN);
+   }
+}
+
+#ifndef UINT64_MAX
+#define UINT64_MAX  (u64)(~((u64)0))
+#endif
+static u64 kszphy_get_stat(struct phy_device *phydev, int i)
+{
+   struct kszphy_hw_stat stat = kszphy_hw_stats[i];
+   struct kszphy_priv *priv = phydev->priv;
+   u64 val;
+
+   val = phy_read(phydev, stat.reg);
+   if (val < 0) {
+   val = UINT64_MAX;
+   } else {
+   val = val & ((1 << stat.bits) - 1);
+   priv->stats[i] += val;
+   val = priv->stats[i];
+   }
+
+   return val;
+}
+
+static void kszphy_get_stats(struct phy_device *phydev,
+struct ethtool_stats *stats, u64 *data)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(kszphy_hw_stats); i++)
+   data[i] = kszphy_get_stat(phydev, i);
+}
+
 static int kszphy_probe(struct phy_device *phydev)
 {
const struct kszphy_type *type = phydev->drv->driver_data;
@@ -642,6 +699,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -659,6 +719,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -676,6 +739,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -693,6 +759,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -710,6 +779,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -727,6 +799,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,

[PATCH 1/2] ethtool-copy.h: sync with net

[Andrew Lunn]

This covers kernel changes up to:

commit eff3cddc222c88943ff515ae9335687c9e2cbaf6
Author: Jacob Keller 
Date:   Wed Apr 22 14:40:30 2015 -0700

clarify implementation of ethtool's get_ts_info op

Signed-off-by: Andrew Lunn 
---
 ethtool-copy.h | 55 +--
 1 file changed, 49 insertions(+), 6 deletions(-)

diff --git a/ethtool-copy.h b/ethtool-copy.h
index d23ffc4..57fa390 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -10,8 +10,8 @@
  * Portions Copyright (C) Sun Microsystems 2008
  */
 
-#ifndef _LINUX_ETHTOOL_H
-#define _LINUX_ETHTOOL_H
+#ifndef _UAPI_LINUX_ETHTOOL_H
+#define _UAPI_LINUX_ETHTOOL_H
 
 #include 
 #include 
@@ -110,7 +110,7 @@ struct ethtool_cmd {
__u32   reserved[2];
 };
 
-static __inline__ void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
+static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
 __u32 speed)
 {
 
@@ -118,7 +118,7 @@ static __inline__ void ethtool_cmd_speed_set(struct 
ethtool_cmd *ep,
ep->speed_hi = (__u16)(speed >> 16);
 }
 
-static __inline__ __u32 ethtool_cmd_speed(const struct ethtool_cmd *ep)
+static inline __u32 ethtool_cmd_speed(const struct ethtool_cmd *ep)
 {
return (ep->speed_hi << 16) | ep->speed;
 }
@@ -215,6 +215,11 @@ enum tunable_id {
ETHTOOL_ID_UNSPEC,
ETHTOOL_RX_COPYBREAK,
ETHTOOL_TX_COPYBREAK,
+   /*
+* Add your fresh new tubale attribute above and remember to update
+* tunable_strings[] in net/core/ethtool.c
+*/
+   __ETHTOOL_TUNABLE_COUNT,
 };
 
 enum tunable_type_id {
@@ -537,6 +542,7 @@ struct ethtool_pauseparam {
  * now deprecated
  * @ETH_SS_FEATURES: Device feature names
  * @ETH_SS_RSS_HASH_FUNCS: RSS hush function names
+ * @ETH_SS_PHY_STATS: Statistic names, for use with %ETHTOOL_GPHYSTATS
  */
 enum ethtool_stringset {
ETH_SS_TEST = 0,
@@ -545,6 +551,8 @@ enum ethtool_stringset {
ETH_SS_NTUPLE_FILTERS,
ETH_SS_FEATURES,
ETH_SS_RSS_HASH_FUNCS,
+   ETH_SS_TUNABLES,
+   ETH_SS_PHY_STATS,
 };
 
 /**
@@ -796,6 +804,31 @@ struct ethtool_rx_flow_spec {
__u32   location;
 };
 
+/* How rings are layed out when accessing virtual functions or
+ * offloaded queues is device specific. To allow users to do flow
+ * steering and specify these queues the ring cookie is partitioned
+ * into a 32bit queue index with an 8 bit virtual function id.
+ * This also leaves the 3bytes for further specifiers. It is possible
+ * future devices may support more than 256 virtual functions if
+ * devices start supporting PCIe w/ARI. However at the moment I
+ * do not know of any devices that support this so I do not reserve
+ * space for this at this time. If a future patch consumes the next
+ * byte it should be aware of this possiblity.
+ */
+#define ETHTOOL_RX_FLOW_SPEC_RING  0xLL
+#define ETHTOOL_RX_FLOW_SPEC_RING_VF   0x00FFLL
+#define ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF 32
+static inline __u64 ethtool_get_flow_spec_ring(__u64 ring_cookie)
+{
+   return ETHTOOL_RX_FLOW_SPEC_RING & ring_cookie;
+};
+
+static inline __u64 ethtool_get_flow_spec_ring_vf(__u64 ring_cookie)
+{
+   return (ETHTOOL_RX_FLOW_SPEC_RING_VF & ring_cookie) >>
+   ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF;
+};
+
 /**
  * struct ethtool_rxnfc - command to get or set RX flow classification rules
  * @cmd: Specific command number - %ETHTOOL_GRXFH, %ETHTOOL_SRXFH,
@@ -1062,6 +1095,11 @@ struct ethtool_sfeatures {
  * the 'hwtstamp_tx_types' and 'hwtstamp_rx_filters' enumeration values,
  * respectively.  For example, if the device supports HWTSTAMP_TX_ON,
  * then (1 << HWTSTAMP_TX_ON) in 'tx_types' will be set.
+ *
+ * Drivers should only report the filters they actually support without
+ * upscaling in the SIOCSHWTSTAMP ioctl. If the SIOCSHWSTAMP request for
+ * HWTSTAMP_FILTER_V1_SYNC is supported by HWTSTAMP_FILTER_V1_EVENT, then the
+ * driver should only report HWTSTAMP_FILTER_V1_EVENT in this op.
  */
 struct ethtool_ts_info {
__u32   cmd;
@@ -1189,6 +1227,7 @@ enum ethtool_sfeatures_retval_bits {
 #define ETHTOOL_SRSSH  0x0047 /* Set RX flow hash configuration */
 #define ETHTOOL_GTUNABLE   0x0048 /* Get tunable configuration */
 #define ETHTOOL_STUNABLE   0x0049 /* Set tunable configuration */
+#define ETHTOOL_GPHYSTATS  0x004a /* get PHY-specific statistics */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET ETHTOOL_GSET
@@ -1264,15 +1303,19 @@ enum ethtool_sfeatures_retval_bits {
  * it was forced up into this mode or autonegotiated.
  */
 
-/* The forced speed, 10Mb, 100Mb, gigabit, [2.5|10|20|40|56]GbE. */
+/* The forced speed, 10Mb, 100Mb, gigabit, [2.5|5|10|20|25|40|50|56|100]GbE. */
 #define SPEED_10   10
 #define SPEED_100  100
 #define 

[PATCH 0/2] ethtool(1) support for reading Phy stats

[Andrew Lunn]

Add support to ethertool(1) for reading phy statistics. The mechanism
is the same for reading MAC stats.

Andrew Lunn (2):
  ethtool-copy.h: sync with net
  ethtool: Add PHY statistics support

 ethtool-copy.h | 55 +++--
 ethtool.8.in   |  6 ++
 ethtool.c  | 60 ++
 3 files changed, 115 insertions(+), 6 deletions(-)

-- 
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 2/2] ethtool: Add PHY statistics support

[Andrew Lunn]

This adds support for printing statistics from the network devices PHY.

Signed-off-by: Andrew Lunn 
---
 ethtool.8.in |  6 ++
 ethtool.c| 60 
 2 files changed, 66 insertions(+)

diff --git a/ethtool.8.in b/ethtool.8.in
index eeffa70..2316556 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -220,6 +220,9 @@ ethtool \- query or control network driver and hardware 
settings
 .B ethtool \-S|\-\-statistics
 .I devname
 .HP
+.B ethtool \-I|\-\-phy-statistics
+.I devname
+.HP
 .B ethtool \-t|\-\-test
 .I devname
 .RI [\*(SD]
@@ -492,6 +495,9 @@ auto-negotiation is enabled.
 Queries the specified network device for NIC- and driver-specific
 statistics.
 .TP
+.B \-I \-\-phy\-statistics
+Queries the specified network device for PHY specific statistics.
+.TP
 .B \-t \-\-test
 Executes adapter selftest on the specified network device. Possible test modes 
are:
 .TP
diff --git a/ethtool.c b/ethtool.c
index 92c40b8..480c14c 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -2995,6 +2995,64 @@ static int do_gstats(struct cmd_context *ctx)
return 0;
 }
 
+static int do_gphystats(struct cmd_context *ctx)
+{
+   struct ethtool_gstrings *strings;
+   struct ethtool_stats *stats;
+   unsigned int n_stats, sz_stats, i;
+   int err;
+
+   if (ctx->argc != 0)
+   exit_bad_args();
+
+   strings = get_stringset(ctx, ETH_SS_PHY_STATS,
+   offsetof(struct ethtool_drvinfo, n_stats),
+   0);
+   if (!strings) {
+   perror("Cannot get stats strings information");
+   return 96;
+   }
+
+   n_stats = strings->len;
+   if (n_stats < 1) {
+   fprintf(stderr, "no stats available\n");
+   free(strings);
+   return 94;
+   }
+
+   sz_stats = n_stats * sizeof(u64);
+
+   stats = calloc(1, sz_stats + sizeof(struct ethtool_stats));
+   if (!stats) {
+   fprintf(stderr, "no memory available\n");
+   free(strings);
+   return 95;
+   }
+
+   stats->cmd = ETHTOOL_GPHYSTATS;
+   stats->n_stats = n_stats;
+   err = send_ioctl(ctx, stats);
+   if (err < 0) {
+   perror("Cannot get stats information");
+   free(strings);
+   free(stats);
+   return 97;
+   }
+
+   /* todo - pretty-print the strings per-driver */
+   fprintf(stdout, "PHY statistics:\n");
+   for (i = 0; i < n_stats; i++) {
+   fprintf(stdout, " %.*s: %llu\n",
+   ETH_GSTRING_LEN,
+   >data[i * ETH_GSTRING_LEN],
+   stats->data[i]);
+   }
+   free(strings);
+   free(stats);
+
+   return 0;
+}
+
 static int do_srxntuple(struct cmd_context *ctx,
struct ethtool_rx_flow_spec *rx_rule_fs);
 
@@ -4078,6 +4136,8 @@ static const struct option {
{ "-t|--test", 1, do_test, "Execute adapter self test",
  "   [ online | offline | external_lb ]\n" },
{ "-S|--statistics", 1, do_gstats, "Show adapter statistics" },
+   { "-I|--phy-statistics", 1, do_gphystats,
+ "Show phy statistics" },
{ "-n|-u|--show-nfc|--show-ntuple", 1, do_grxclass,
  "Show Rx network flow classification options or rules",
  " [ rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|"
-- 
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

Re: [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex

[Sergei Shtylyov]

Hello.

On 12/23/2015 9:46 AM, zyjzyj2...@gmail.com wrote:


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);
+   }
+


   {} not needed here. And you do the same thing regardless of whether your 
check succeeds or not, this doesn't make sense.


[...]

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 net] geneve: initialize needed_headroom

[Paolo Abeni]

On Wed, 2015-12-23 at 16:35 +0100, Hannes Frederic Sowa wrote:
> On 23.12.2015 16:21, Paolo Abeni wrote:
> > @@ -1187,6 +1187,14 @@ static int geneve_configure(struct net *net, struct 
> > net_device *dev,
> > if (t)
> > return -EBUSY;
> >  
> > +   /* make enough headroom for basic scenario */
> > +   encap_len = GENEVE_BASE_HLEN + ETH_HLEN;
> > +   if (remote->sa.sa_family == AF_INET)
> > +   encap_len += sizeof(struct iphdr);
> > +   else
> > +   encap_len += sizeof(struct ipv6hdr);
> > +   dev->needed_headroom = encap_len;
> > +
> 
> We are missing one time ETH_HLEN or hard_header_len of the lower_dev (if
> available) in here AFAIK.

You are right. Most probably performance numbers where good even with
the missing ETH_HLEN due to some rounding. I'll send a v2.

Paolo

--
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 01/28] component: remove old add_components method

[Russell King - ARM Linux]

Why are you sending this?  I'm confused.

On Wed, Dec 23, 2015 at 01:56:15PM +0100, Andrew Lunn wrote:
> From: Russell King 
> 
> Now that drivers create an array of component matches at probe time, we
> can retire the old methods.  This involves removing the add_components
> master method, and removing component_master_add_child() from public
> view.  We also remove component_add_master() as that interface is no
> longer useful.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/base/component.c  | 31 +--
>  include/linux/component.h |  5 -
>  2 files changed, 5 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index f748430bb654..2ca22738ae92 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -84,7 +84,7 @@ static void component_detach_master(struct master *master, 
> struct component *c)
>   * function and compare data.  This is safe to call for duplicate matches
>   * and will not result in the same component being added multiple times.
>   */
> -int component_master_add_child(struct master *master,
> +static int component_master_add_child(struct master *master,
>   int (*compare)(struct device *, void *), void *compare_data)
>  {
>   struct component *c;
> @@ -104,7 +104,6 @@ int component_master_add_child(struct master *master,
>  
>   return ret;
>  }
> -EXPORT_SYMBOL_GPL(component_master_add_child);
>  
>  static int find_components(struct master *master)
>  {
> @@ -112,14 +111,6 @@ static int find_components(struct master *master)
>   size_t i;
>   int ret = 0;
>  
> - if (!match) {
> - /*
> -  * Search the list of components, looking for components that
> -  * belong to this master, and attach them to the master.
> -  */
> - return master->ops->add_components(master->dev, master);
> - }
> -
>   /*
>* Scan the array of match functions and attach
>* any components which are found to this master.
> @@ -290,15 +281,10 @@ int component_master_add_with_match(struct device *dev,
>   struct master *master;
>   int ret;
>  
> - if (ops->add_components && match)
> - return -EINVAL;
> -
> - if (match) {
> - /* Reallocate the match array for its true size */
> - match = component_match_realloc(dev, match, match->num);
> - if (IS_ERR(match))
> - return PTR_ERR(match);
> - }
> + /* Reallocate the match array for its true size */
> + match = component_match_realloc(dev, match, match->num);
> + if (IS_ERR(match))
> + return PTR_ERR(match);
>  
>   master = kzalloc(sizeof(*master), GFP_KERNEL);
>   if (!master)
> @@ -326,13 +312,6 @@ int component_master_add_with_match(struct device *dev,
>  }
>  EXPORT_SYMBOL_GPL(component_master_add_with_match);
>  
> -int component_master_add(struct device *dev,
> - const struct component_master_ops *ops)
> -{
> - return component_master_add_with_match(dev, ops, NULL);
> -}
> -EXPORT_SYMBOL_GPL(component_master_add);
> -
>  void component_master_del(struct device *dev,
>   const struct component_master_ops *ops)
>  {
> diff --git a/include/linux/component.h b/include/linux/component.h
> index c00dcc302611..71c434a6a5ee 100644
> --- a/include/linux/component.h
> +++ b/include/linux/component.h
> @@ -17,18 +17,13 @@ void component_unbind_all(struct device *, void *);
>  struct master;
>  
>  struct component_master_ops {
> - int (*add_components)(struct device *, struct master *);
>   int (*bind)(struct device *);
>   void (*unbind)(struct device *);
>  };
>  
> -int component_master_add(struct device *, const struct component_master_ops 
> *);
>  void component_master_del(struct device *,
>   const struct component_master_ops *);
>  
> -int component_master_add_child(struct master *master,
> - int (*compare)(struct device *, void *), void *compare_data);
> -
>  struct component_match;
>  
>  int component_master_add_with_match(struct device *,
> -- 
> 2.6.3
> 

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 v2] geneve: initialize needed_headroom

[Paolo Abeni]

Currently the needed_headroom field for the geneve device is left
to the default value.

This patch set it to space required for basic geneve encapsulation,
so that we can avoid the skb head re-allocation on xmit.

This give a 6% speedup for unsegment traffic on geneve tunnel.

v1 -> v2:
  - add ETH_HLEN for the lower device to the needed headroom

Signed-off-by: Paolo Abeni 
Acked-by: Hannes Frederic Sowa 
---
 drivers/net/geneve.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index c2b79f5..58efdec 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -1155,7 +1155,7 @@ static int geneve_configure(struct net *net, struct 
net_device *dev,
struct geneve_net *gn = net_generic(net, geneve_net_id);
struct geneve_dev *t, *geneve = netdev_priv(dev);
bool tun_collect_md, tun_on_same_port;
-   int err;
+   int err, encap_len;
 
if (!remote)
return -EINVAL;
@@ -1187,6 +1187,14 @@ static int geneve_configure(struct net *net, struct 
net_device *dev,
if (t)
return -EBUSY;
 
+   /* make enough headroom for basic scenario */
+   encap_len = GENEVE_BASE_HLEN + ETH_HLEN;
+   if (remote->sa.sa_family == AF_INET)
+   encap_len += sizeof(struct iphdr);
+   else
+   encap_len += sizeof(struct ipv6hdr);
+   dev->needed_headroom = encap_len + ETH_HLEN;
+
if (metadata) {
if (tun_on_same_port)
return -EPERM;
-- 
1.8.3.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: [PATCH 1/2] PCI: Add mechanism to find topologically near cores

[Bjorn Helgaas]

Hi Daniel,

On Wed, Dec 23, 2015 at 06:01:40PM +0800, Daniel J Blueman wrote:
> Some devices (eg ixgbe) make assumptions about device to core locality when
> specifying interrupts locality hints and allocate starting from core 0.
> Moreover, interrupts may not be routable to distant NUMA nodes due to the
> 8-bit APIC ID space limitations.

The APIC ID issue is the primary problem you're trying to solve, but
this patch doesn't solve it directly because it doesn't look at
anything related to the APIC ID domain.  Anything you do here is a
guess that might work better, but it still won't necessarily work in
all cases.

Also, can you add a note about how this relates to the "call driver
probe function on node where device is attached" functionality in
pci_call_probe()?  It seems like that should be enough to keep us from
always allocating interrupts on core 0.  Maybe that's broken, or maybe
ixgbe isn't taking advantage of that?

> Provide a mechanism drivers can use to find cores with reasonable locality
> to a device; use the existing precendent of RECLAIM_DISTANCE (30), wrapping
> the offset.

I don't think it's a benefit to reuse RECLAIM_DISTANCE, because that
is a different concept that doesn't seem directly related to what
you're doing.  The name and the existing uses are related to memory
zone reclaiming, so I know I would be confused to see it also used for
IRQ assignment.

> Signed-off-by: Daniel J Blueman 
> ---
>  drivers/pci/pci.c   | 15 +++
>  include/linux/pci.h |  1 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 314db8c..d5535d1 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4833,6 +4833,22 @@ void __weak pci_fixup_cardbus(struct pci_bus *bus)
>  }
>  EXPORT_SYMBOL(pci_fixup_cardbus);
> 
> +int cpu_near_dev(const struct pci_dev *pdev, unsigned offset)

If this becomes a PCI interface, please add a "pci_" prefix to the
name.

The distance concept also applies to non-PCI devices, so ideally I
think a "pci_nearby_cpu()" or similar interface would be a wrapper
around a more generic interface that takes a "struct device *".

I don't really understand what the "offset" parameter is for.  It
looks like you're using it to spread across CPUs on a node, but that
seems like something that should be done internally to this interface.

> +{
> + /* Start search from node device is on for optimal locality */
> + int localnode = pcibus_to_node(pdev->bus);
> + int cpu = cpumask_first(cpumask_of_node(localnode));
> +
> + while (offset--) {
> + do {
> + cpu = (cpu + 1) % nr_cpu_ids;
> + } while (!cpu_online(cpu) || node_distance(cpu_to_node(cpu),
> + localnode) > RECLAIM_DISTANCE);
> + }
> +
> + return cpu;
> +}
> +
>  static int __init pci_setup(char *str)
>  {
>   while (str) {
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 6ae25aa..f7491bd 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -842,6 +842,7 @@ void pci_stop_root_bus(struct pci_bus *bus);
>  void pci_remove_root_bus(struct pci_bus *bus);
>  void pci_setup_cardbus(struct pci_bus *bus);
>  void pci_sort_breadthfirst(void);
> +int cpu_near_dev(const struct pci_dev *pdev, unsigned offset);
>  #define dev_is_pci(d) ((d)->bus == _bus_type)
>  #define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)->is_physfn : false))
>  #define dev_num_vf(d) ((dev_is_pci(d) ? pci_num_vf(to_pci_dev(d)) : 0))
> --
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 00/16] add Intel(R) X722 iWARP driver

[Doug Ledford]

On 12/21/2015 06:13 PM, Faisal Latif wrote:
> This (V1) series contains the addition of the i40iw.ko driver after
> incorporating the feedback from Christoph Hellwig and Joe Perches for
> initial series.
> 
> This driver provides iWARP RDMA functionality for the Intel(R) X722 Ethernet
> controller for PCI Physical Functions. It also has support for Virtual
> Function driver (i40iwvf.ko), which that will be part of separate patch
> series.
> 
> It cooperates with the Intel(R) X722 base driver (i40e.ko) to allocate
> resources and program the controller.
> 
> This series include 1 patch to i40e.ko to provide interface support to
> i40iw.ko. The interface provides a driver registration mechanism, resource
> allocations, and device reset coordination mechanisms.
> 
> This patch series is based on Doug Ledford's k.o/for-4.5.

My apologies Faisal.  I had pushed that branch to github to get 0-day
testing, but hadn't committed it to my k.o tree as it wasn't fully
finalized (I was waiting for Or to get his chance to respond to it).
Once Or responded, I ended up taking his patchset instead, which means
you need to adjust your patches accordingly.

> 
> Anjali Singhai Jain (1)
> net/ethernet/intel/i40e: Add support for client interface for IWARP driver
> 
> Faisal Latif(15):
> infiniband/hw/i40iw: add main, hdr, status
> infiniband/hw/i40iw: add connection management code
> infiniband/hw/i40iw: add puda code
> infiniband/hw/i40iw: add pble resource files
> infiniband/hw/i40iw: add hmc resource files
> infiniband/hw/i40iw: add hw and utils files
> infiniband/hw/i40iw: add files for iwarp interface
> infiniband/hw/i40iw: add file to handle cqp calls
> infiniband/hw/i40iw: add hardware related header files
> infiniband/hw/i40iw: add X722 register file
> infiniband/hw/i40iw: user kernel shared files
> infiniband/hw/i40iw: virtual channel handling files
> infiniband/hw/i40iw: Kconfig and Kbuild for iwarp module
> infiniband/hw/i40iw: Add entry for I40IW rdma_netlink.h
> infiniband/hw/i40iw: changes for build of i40iw module
> 
> Changes done from initial version to V1 are following.
> 
> Feedback received from Christoph Hellwig
> *Remove pointless braces -improved after code review and changing
> *kmap()/kunmap() - made it very short lived
> *less casts -improved 
> *Remove unused routine stubs - done
> *no initialize to 0 or NULL when struct field were zeroed - done
> *define UNREFERENCED_PARAMETER not needed -done
> *remove define I40eE_MASK  -done
> *rd32(), wr32() make them inline -done
> *readq() use magic in linux/io-64-nonatomic-lo-hi.h -done
> *SLEEP() define -done by removing it
> *entry in rdma_netlink.h for I40IW should be in proper location
>   and separate patch -done
> 
> Feedback received from Joe Perches
> *series to respuun re-spun against next - done with
>   Doug's Ledford's k.o/for-4.5
> *Change to i40e client patch regarding mailing list - this is consistent
>   with other i40e files.
> *Removed error from i40iw_pr_err() -done
> *cqp_request() change from bitfields to bool -done
> 


-- 
Doug Ledford 
  GPG KeyID: 0E572FDD




signature.asc
Description: OpenPGP digital signature

Re: [PATCH net v2] geneve: initialize needed_headroom

[John W. Linville]

On Wed, Dec 23, 2015 at 04:54:27PM +0100, Paolo Abeni wrote:
> Currently the needed_headroom field for the geneve device is left
> to the default value.
> 
> This patch set it to space required for basic geneve encapsulation,
> so that we can avoid the skb head re-allocation on xmit.
> 
> This give a 6% speedup for unsegment traffic on geneve tunnel.
> 
> v1 -> v2:
>   - add ETH_HLEN for the lower device to the needed headroom
> 
> Signed-off-by: Paolo Abeni 
> Acked-by: Hannes Frederic Sowa 

This time I really mean it... ;-)

Acked-by: John W. Linville 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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] geneve: initialize needed_headroom

[Paolo Abeni]

Currently the needed_headroom field for the geneve device is left
to the default value.

This patch set it to space required for basic geneve encapsulation,
so that we can avoid the skb head re-allocation on xmit.

This give a 6% speedup for unsegment traffic on geneve tunnel.

Signed-off-by: Paolo Abeni 
Acked-by: Hannes Frederic Sowa 
---
 drivers/net/geneve.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index c2b79f5..bb3e6ed 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -1155,7 +1155,7 @@ static int geneve_configure(struct net *net, struct 
net_device *dev,
struct geneve_net *gn = net_generic(net, geneve_net_id);
struct geneve_dev *t, *geneve = netdev_priv(dev);
bool tun_collect_md, tun_on_same_port;
-   int err;
+   int err, encap_len;
 
if (!remote)
return -EINVAL;
@@ -1187,6 +1187,14 @@ static int geneve_configure(struct net *net, struct 
net_device *dev,
if (t)
return -EBUSY;
 
+   /* make enough headroom for basic scenario */
+   encap_len = GENEVE_BASE_HLEN + ETH_HLEN;
+   if (remote->sa.sa_family == AF_INET)
+   encap_len += sizeof(struct iphdr);
+   else
+   encap_len += sizeof(struct ipv6hdr);
+   dev->needed_headroom = encap_len;
+
if (metadata) {
if (tun_on_same_port)
return -EPERM;
-- 
1.8.3.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: [PATCH net] geneve: initialize needed_headroom

[John W. Linville]

On Wed, Dec 23, 2015 at 04:21:48PM +0100, Paolo Abeni wrote:
> Currently the needed_headroom field for the geneve device is left
> to the default value.
> 
> This patch set it to space required for basic geneve encapsulation,
> so that we can avoid the skb head re-allocation on xmit.
> 
> This give a 6% speedup for unsegment traffic on geneve tunnel.
> 
> Signed-off-by: Paolo Abeni 
> Acked-by: Hannes Frederic Sowa 

Acked-by: John W. Linville 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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] geneve: initialize needed_headroom

[Hannes Frederic Sowa]

On 23.12.2015 16:21, Paolo Abeni wrote:
> Currently the needed_headroom field for the geneve device is left
> to the default value.
> 
> This patch set it to space required for basic geneve encapsulation,
> so that we can avoid the skb head re-allocation on xmit.
> 
> This give a 6% speedup for unsegment traffic on geneve tunnel.
> 
> Signed-off-by: Paolo Abeni 
> Acked-by: Hannes Frederic Sowa 

(Sorry, just saw this.)

> ---
>  drivers/net/geneve.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index c2b79f5..bb3e6ed 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -1155,7 +1155,7 @@ static int geneve_configure(struct net *net, struct 
> net_device *dev,
>   struct geneve_net *gn = net_generic(net, geneve_net_id);
>   struct geneve_dev *t, *geneve = netdev_priv(dev);
>   bool tun_collect_md, tun_on_same_port;
> - int err;
> + int err, encap_len;
>  
>   if (!remote)
>   return -EINVAL;
> @@ -1187,6 +1187,14 @@ static int geneve_configure(struct net *net, struct 
> net_device *dev,
>   if (t)
>   return -EBUSY;
>  
> + /* make enough headroom for basic scenario */
> + encap_len = GENEVE_BASE_HLEN + ETH_HLEN;
> + if (remote->sa.sa_family == AF_INET)
> + encap_len += sizeof(struct iphdr);
> + else
> + encap_len += sizeof(struct ipv6hdr);
> + dev->needed_headroom = encap_len;
> +

We are missing one time ETH_HLEN or hard_header_len of the lower_dev (if
available) in here AFAIK.

Thanks,
Hannes

--
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

netdev antiblue protect eye for distributor

[lcdaccessory]

Dear netdev  MD,

New LCD/LED TV defender blocker for year 2016.
huge profits reserve for first distributor there, a lots request from end-users 
especial for antiblue protector.
New and hottest model refer to  http://www.emetal.tw/protect/p1-blue.htm 

inquire email to Eric from eMetal Technology
www.lcdaccessory.com i...@emetal.tw 

 



































































--
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 01/28] component: remove old add_components method

[Andrew Lunn]

On Wed, Dec 23, 2015 at 01:21:24PM +, Russell King - ARM Linux wrote:
> Why are you sending this?  I'm confused.

Hi Russell

It is part of a bigger series, which i just sent as RFC. I need the
functionality of your patch, but it not yet available upstream. By the
time my patch series leaves RFC and is ready for acceptance, i expect
your patch will be upstream, and i will drop it.

 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 1/3] ethtool: Add phy statistics

[kbuild test robot]

Hi Andrew,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Andrew-Lunn/ethtool-Add-phy-statistics/20151223-195714
config: i386-randconfig-i0-201551 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   net/built-in.o: In function `__ethtool_get_sset_count':
>> ethtool.c:(.text+0x1a260): undefined reference to `phy_get_sset_count'
   net/built-in.o: In function `dev_ethtool':
>> (.text+0x1b164): undefined reference to `phy_get_strings'
   net/built-in.o: In function `dev_ethtool':
>> (.text+0x1bbfa): undefined reference to `phy_get_sset_count'
   net/built-in.o: In function `dev_ethtool':
>> (.text+0x1becb): undefined reference to `phy_get_stats'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[linux-review:Andrew-Lunn/ethtool-Add-phy-statistics/20151223-195714] 5d5686595a5cbf1ccfd334bc472bfa1d1441b849 BUILD DONE

[kbuild test robot]

https://github.com/0day-ci/linux  
Andrew-Lunn/ethtool-Add-phy-statistics/20151223-195714
5d5686595a5cbf1ccfd334bc472bfa1d1441b849  phy: micrel: Add ethtool statistics 
counters

ethtool.c:(.text+0x17a0a): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x18b92): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x18df4): undefined reference to `phy_get_stats'
ethtool.c:(.text+0x1a260): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x1be0e): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x1c0b6): undefined reference to `phy_get_strings'
ethtool.c:(.text+0x1c1f4): undefined reference to `phy_get_stats'
ethtool.c:(.text+0x1c79e): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x1ca46): undefined reference to `phy_get_strings'
ethtool.c:(.text+0x1cb84): undefined reference to `phy_get_stats'
ethtool.c:(.text+0x1d330): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x1d96c): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x207f0): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x23548): undefined reference to `phy_get_strings'
ethtool.c:(.text+0x24314): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x25ad4): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x275fc): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x37b96): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x3dd44): undefined reference to `phy_get_sset_count'
ethtool.c:(.text+0x3df06): undefined reference to `phy_get_strings'
ethtool.c:(.text+0x454af): undefined reference to `phy_get_sset_count'
net/core/ethtool.c:(.text+0x1696a): undefined reference to `phy_get_sset_count'
net/core/ethtool.c:(.text+0x169d2): undefined reference to `phy_get_stats'
net/core/ethtool.c:(.text+0x16e52): undefined reference to `phy_get_strings'
net/core/ethtool.o:(.text.dev_ethtool+0x1660): undefined reference to 
`phy_get_stats'
net/core/ethtool.o:(.text.dev_ethtool+0x1720): undefined reference to 
`phy_get_strings'
net/core/ethtool.o:(.text.dev_ethtool+0x3d8): undefined reference to 
`phy_get_sset_count'
net/core/ethtool.o:(.text.__ethtool_get_sset_count+0x6c): undefined reference 
to `phy_get_sset_count'
net/core/.tmp_ethtool.o:(.text.dev_ethtool+0x1540): undefined reference to 
`phy_get_stats'
net/core/.tmp_ethtool.o:(.text.dev_ethtool+0x15d4): undefined reference to 
`phy_get_strings'
net/core/.tmp_ethtool.o:(.text.dev_ethtool+0x3d8): undefined reference to 
`phy_get_sset_count'
net/core/.tmp_ethtool.o:(.text.__ethtool_get_sset_count+0x68): undefined 
reference to `phy_get_sset_count'
(.text+0x1b164): undefined reference to `phy_get_strings'
(.text+0x1bbfa): undefined reference to `phy_get_sset_count'
(.text+0x1becb): undefined reference to `phy_get_stats'
(.text+0x1d5a4): undefined reference to `phy_get_sset_count'
(.text+0x1dbdc): undefined reference to `phy_get_sset_count'
(.text+0x1e450): undefined reference to `phy_get_stats'
(.text+0x1e500): undefined reference to `phy_get_strings'
(.text+0x1ea60): undefined reference to `phy_get_stats'
(.text+0x1eb10): undefined reference to `phy_get_strings'
(.text+0x20b04): undefined reference to `phy_get_sset_count'
(.text+0x22028): undefined reference to `phy_get_stats'
(.text+0x221d4): undefined reference to `phy_get_strings'
(.text+0x24948): undefined reference to `phy_get_sset_count'
(.text+0x25dec): undefined reference to `phy_get_sset_count'
(.text+0x25e50): undefined reference to `phy_get_stats'
(.text+0x26288): undefined reference to `phy_get_strings'
(.text+0x26344): undefined reference to `phy_get_stats'
(.text+0x26998): undefined reference to `phy_get_strings'
(.text+0x27a14): undefined reference to `phy_get_sset_count'
(.text+0x2844c): undefined reference to `phy_get_strings'
(.text+0x28de8): undefined reference to `phy_get_stats'
(.text+0x38671): undefined reference to `phy_get_sset_count'
(.text+0x38770): undefined reference to `phy_get_stats'
(.text+0x39376): undefined reference to `phy_get_strings'
(.text+0x40a2f): undefined reference to `phy_get_sset_count'
(.text+0x40b04): undefined reference to `phy_get_stats'
(.text+0x439c): undefined reference to `phy_get_sset_count'
(.text+0x4548): undefined reference to `phy_get_strings'
(.text+0x4654): undefined reference to `phy_get_stats'
(.text+0x468c): undefined reference to `phy_get_sset_count'
(.text+0x476a8): undefined reference to `phy_get_strings'
(.text+0x47ec): undefined reference to `phy_get_strings'
(.text+0x48884): undefined reference to `phy_get_sset_count'
(.text+0x48940): undefined reference to `phy_get_stats'
(.text+0x48f8): undefined reference to `phy_get_stats'

Error ids grouped by kconfigs:

recent_errors
├── blackfin-TCM-BF537_defconfig
│   ├── net-core-ethtool.c:(.text):undefined-reference-to-phy_get_sset_count
│   ├── net-core-ethtool.c:(.text):undefined-reference-to-phy_get_stats
│   └── net-core-ethtool.c:(.text):undefined-reference-to-phy_get_strings
├── cris-etrax

Re: [PATCH V1 00/16] add Intel(R) X722 iWARP driver

[Doug Ledford]

On 12/23/2015 11:35 AM, Faisal Latif wrote:
> On Wed, Dec 23, 2015 at 11:09:56AM -0500, Doug Ledford wrote:
>> On 12/21/2015 06:13 PM, Faisal Latif wrote:
>>> This (V1) series contains the addition of the i40iw.ko driver after
>>> incorporating the feedback from Christoph Hellwig and Joe Perches for
>>> initial series.
>>>
>>> This driver provides iWARP RDMA functionality for the Intel(R) X722 Ethernet
>>> controller for PCI Physical Functions. It also has support for Virtual
>>> Function driver (i40iwvf.ko), which that will be part of separate patch
>>> series.
>>>
>>> It cooperates with the Intel(R) X722 base driver (i40e.ko) to allocate
>>> resources and program the controller.
>>>
>>> This series include 1 patch to i40e.ko to provide interface support to
>>> i40iw.ko. The interface provides a driver registration mechanism, resource
>>> allocations, and device reset coordination mechanisms.
>>>
>>> This patch series is based on Doug Ledford's k.o/for-4.5.
>>
>> My apologies Faisal.  I had pushed that branch to github to get 0-day
>> testing, but hadn't committed it to my k.o tree as it wasn't fully
>> finalized (I was waiting for Or to get his chance to respond to it).
>> Once Or responded, I ended up taking his patchset instead, which means
>> you need to adjust your patches accordingly.
>>
> 
> Thanks Doug for the update, I will provide new patch series for latest
> k.o. Also will make sure of shallow threading for the series. I should
> have used V2 for this series instead of V1 and next series with k.o will
> make it proper with V3.

I'm going to repush my tree in 10 or 15 minutes if you haven't done the
rebase yet.  If so, the tree I pushed earlier this morning should be
good enough.


-- 
Doug Ledford 
  GPG KeyID: 0E572FDD




signature.asc
Description: OpenPGP digital signature

[PATCH net] sctp: label accepted/peeled off sockets

[Marcelo Ricardo Leitner]

From: Marcelo Ricardo Leitner 

Accepted or peeled off sockets were missing a security label (e.g.
SELinux) which means that socket was in "unlabeled" state.

This patch clones the sock's label from the parent sock and resolves the
issue (similar to AF_BLUETOOTH protocol family).

Cc: Paul Moore 
Cc: David Teigland 
Signed-off-by: Marcelo Ricardo Leitner 
---
 net/sctp/socket.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 
400a14d744834c7a503b338bc68f5f8b5b5dae8e..b67162767b7957b3e9f4f7bf52ab51fc1a3499c8
 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -7202,6 +7202,8 @@ void sctp_copy_sock(struct sock *newsk, struct sock *sk,
 
if (newsk->sk_flags & SK_FLAGS_TIMESTAMP)
net_enable_timestamp();
+
+   security_sk_clone(sk, newsk);
 }
 
 static inline void sctp_copy_descendant(struct sock *sk_to,
-- 
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 00/16] add Intel(R) X722 iWARP driver

[Faisal Latif]

On Wed, Dec 23, 2015 at 11:09:56AM -0500, Doug Ledford wrote:
> On 12/21/2015 06:13 PM, Faisal Latif wrote:
> > This (V1) series contains the addition of the i40iw.ko driver after
> > incorporating the feedback from Christoph Hellwig and Joe Perches for
> > initial series.
> > 
> > This driver provides iWARP RDMA functionality for the Intel(R) X722 Ethernet
> > controller for PCI Physical Functions. It also has support for Virtual
> > Function driver (i40iwvf.ko), which that will be part of separate patch
> > series.
> > 
> > It cooperates with the Intel(R) X722 base driver (i40e.ko) to allocate
> > resources and program the controller.
> > 
> > This series include 1 patch to i40e.ko to provide interface support to
> > i40iw.ko. The interface provides a driver registration mechanism, resource
> > allocations, and device reset coordination mechanisms.
> > 
> > This patch series is based on Doug Ledford's k.o/for-4.5.
> 
> My apologies Faisal.  I had pushed that branch to github to get 0-day
> testing, but hadn't committed it to my k.o tree as it wasn't fully
> finalized (I was waiting for Or to get his chance to respond to it).
> Once Or responded, I ended up taking his patchset instead, which means
> you need to adjust your patches accordingly.
> 

Thanks Doug for the update, I will provide new patch series for latest
k.o. Also will make sure of shallow threading for the series. I should
have used V2 for this series instead of V1 and next series with k.o will
make it proper with V3.

> > 
> > Anjali Singhai Jain (1)
> > net/ethernet/intel/i40e: Add support for client interface for IWARP driver
> > 
> > Faisal Latif(15):
> > infiniband/hw/i40iw: add main, hdr, status
> > infiniband/hw/i40iw: add connection management code
> > infiniband/hw/i40iw: add puda code
> > infiniband/hw/i40iw: add pble resource files
> > infiniband/hw/i40iw: add hmc resource files
> > infiniband/hw/i40iw: add hw and utils files
> > infiniband/hw/i40iw: add files for iwarp interface
> > infiniband/hw/i40iw: add file to handle cqp calls
> > infiniband/hw/i40iw: add hardware related header files
> > infiniband/hw/i40iw: add X722 register file
> > infiniband/hw/i40iw: user kernel shared files
> > infiniband/hw/i40iw: virtual channel handling files
> > infiniband/hw/i40iw: Kconfig and Kbuild for iwarp module
> > infiniband/hw/i40iw: Add entry for I40IW rdma_netlink.h
> > infiniband/hw/i40iw: changes for build of i40iw module
> > 
> > Changes done from initial version to V1 are following.
> > 
> > Feedback received from Christoph Hellwig
> > *Remove pointless braces -improved after code review and changing
> > *kmap()/kunmap() - made it very short lived
> > *less casts -improved 
> > *Remove unused routine stubs - done
> > *no initialize to 0 or NULL when struct field were zeroed - done
> > *define UNREFERENCED_PARAMETER not needed -done
> > *remove define I40eE_MASK  -done
> > *rd32(), wr32() make them inline -done
> > *readq() use magic in linux/io-64-nonatomic-lo-hi.h -done
> > *SLEEP() define -done by removing it
> > *entry in rdma_netlink.h for I40IW should be in proper location
> > and separate patch -done
> > 
> > Feedback received from Joe Perches
> > *series to respuun re-spun against next - done with
> > Doug's Ledford's k.o/for-4.5
> > *Change to i40e client patch regarding mailing list - this is consistent
> > with other i40e files.
> > *Removed error from i40iw_pr_err() -done
> > *cqp_request() change from bitfields to bool -done
> > 
> 
> 
> -- 
> Doug Ledford 
>   GPG KeyID: 0E572FDD
> 
> 

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

Re: [PATCH V1 15/16] i40iw: add entry in rdma_netlink

[Or Gerlitz]

On 12/22/2015 1:13 AM, Faisal Latif wrote:

Add entry for port mapper services.

Signed-off-by: Faisal Latif 
---
  include/uapi/rdma/rdma_netlink.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/uapi/rdma/rdma_netlink.h b/include/uapi/rdma/rdma_netlink.h
index c19a5dc..4fa418d 100644
--- a/include/uapi/rdma/rdma_netlink.h
+++ b/include/uapi/rdma/rdma_netlink.h
@@ -8,6 +8,7 @@ enum {
RDMA_NL_NES,
RDMA_NL_C4IW,
RDMA_NL_LS, /* RDMA Local Services */
+   RDMA_NL_I40IW,
RDMA_NL_NUM_CLIENTS
  };
  
Do you use this value in down-stream patches of the series? if yes, 
change the order to have this and other IB core changes before the code 
that use that.


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: _sockaddr, RDMA_NL_NES);
nes/nes_cm.c:   return iwpm_remove_mapping(_sockaddr, RDMA_NL_NES);
nes/nes_cm.c:   _addr, RDMA_NL_NES);
nes/nes_cm.c:   iwpm_err = iwpm_register_pid(_reg_msg, 
RDMA_NL_NES);
nes/nes_cm.c:   iwpm_err = iwpm_add_mapping(_msg, 
RDMA_NL_NES);

nes/nes_cm.c:   iwpm_err = iwpm_register_pid(_reg_msg, RDMA_NL_NES);
nes/nes_cm.c:   iwpm_err = iwpm_add_and_query_mapping(_msg, 
RDMA_NL_NES);


[root@r-dcs58 hw]# git grep RDMA_NL_ cxgb4/

cxgb4/cm.c: iwpm_remove_mapping(>com.local_addr, RDMA_NL_C4IW);
cxgb4/cm.c: _ep->com.remote_addr, RDMA_NL_C4IW);
cxgb4/cm.c: iwpm_err = iwpm_register_pid(_reg_msg, RDMA_NL_C4IW);
cxgb4/cm.c: iwpm_err = iwpm_add_and_query_mapping(_msg, 
RDMA_NL_C4IW);

cxgb4/cm.c: >com.mapped_local_addr, RDMA_NL_C4IW)) {
cxgb4/cm.c: iwpm_remove_mapping(>com.local_addr, RDMA_NL_C4IW);
cxgb4/cm.c: iwpm_err = iwpm_register_pid(_reg_msg, RDMA_NL_C4IW);
cxgb4/cm.c: iwpm_err = iwpm_add_mapping(_msg, RDMA_NL_C4IW);
cxgb4/cm.c: >com.mapped_local_addr, RDMA_NL_C4IW)) {
cxgb4/device.c: [RDMA_NL_IWPM_REG_PID] = {.dump = iwpm_register_pid_cb},
cxgb4/device.c: [RDMA_NL_IWPM_ADD_MAPPING] = {.dump = iwpm_add_mapping_cb},
cxgb4/device.c: [RDMA_NL_IWPM_QUERY_MAPPING] = {.dump = 
iwpm_add_and_query_mapping_cb},

cxgb4/device.c: [RDMA_NL_IWPM_HANDLE_ERR] = {.dump = iwpm_mapping_error_cb},
cxgb4/device.c: [RDMA_NL_IWPM_REMOTE_INFO] = {.dump = iwpm_remote_info_cb},
cxgb4/device.c: [RDMA_NL_IWPM_MAPINFO] = {.dump = iwpm_mapping_info_cb},
cxgb4/device.c: [RDMA_NL_IWPM_MAPINFO_NUM] = {.dump = 
iwpm_ack_mapping_info_cb}

cxgb4/device.c: if (ibnl_add_client(RDMA_NL_C4IW, RDMA_NL_IWPM_NUM_OPS,
cxgb4/device.c: err = iwpm_init(RDMA_NL_C4IW);
cxgb4/device.c: ibnl_remove_client(RDMA_NL_C4IW);
cxgb4/device.c: iwpm_exit(RDMA_NL_C4IW);
cxgb4/device.c: ibnl_remove_client(RDMA_NL_C4IW);

--
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: [PATCHv2 net-next 0/4] Trivial enhancements for cxgb4

[David Miller]

From: Hariprasad Shenai 
Date: Wed, 23 Dec 2015 11:29:52 +0530

> This series adds a debug message if adapter isn't inserted in right PCI
> slot. Changes naming conventions for iSCSI rx queues, use node info while
> allocating rx queue and use napi_complete_done() api in napi handler.
> 
> This patch series has been created against net-next tree and includes
> patches on cxgb4 driver.
> 
> We have included all the maintainers of respective drivers. Kindly review
> the change and let us know in case of any review comments.
> 
> Thanks
> 
> V2: Dropped 'dcb_info' debug entry patch, since the same can be achieved
> using lldp tool.
> Based on review comments by Or Gerlitz  and
> David Miller.

Series applied, 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 0/2] new maintainers for Mellanox mlx4/mlx5 core and IB drivers

[Or Gerlitz]

Hi Dave, Doug
 
We're happily assigning new maintainers for mlx4/mlx5 core and IB drivers.

This is aligned with Eli (mlx5) and Roland (mlx4).

FWIW, I did the whole change to go through netdev. 

Or.

Or Gerlitz (2):
  MAINTAINERS: Assign new maintainers to Mellanox mlx5 core and IB drivers
  MAINTAINERS: Assign maintainer to Mellanox mlx4 core and IB drivers

 MAINTAINERS | 32 +---
 1 file changed, 25 insertions(+), 7 deletions(-)

-- 
2.3.7

--
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 3/9] cxgb4/cxgb4vf: Update Ingress padding boundary values for T6 adapter

[Hariprasad Shenai]

Ingress padding boundary values got changed for T6.
T5: 0=32B 1=64B 2=128B 3=256B 4=512B 5=1024B 6=2048B 7=4096B
T6: 0=8B  1=16B 2=32B  3=64B  4=128B 5=128B  6=256B  7=512B

Updating the driver to set the correct boundary values in SGE_CONTROL to
32B.
Also, need to take care of this fl alignment change when calculating the
next packet offset.

Signed-off-by: Hariprasad Shenai 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |  1 +
 drivers/net/ethernet/chelsio/cxgb4/sge.c   | 33 +-
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 62 +-
 drivers/net/ethernet/chelsio/cxgb4/t4_values.h |  3 ++
 drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 11 -
 5 files changed, 76 insertions(+), 34 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index eab57cf..5c193a5 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1256,6 +1256,7 @@ int t4_phy_fw_ver(struct adapter *adap, int *phy_fw_ver);
 int t4_fwcache(struct adapter *adap, enum fw_params_param_dev_fwcache op);
 int t4_fw_upgrade(struct adapter *adap, unsigned int mbox,
  const u8 *fw_data, unsigned int size, int force);
+int t4_fl_pkt_align(struct adapter *adap);
 unsigned int t4_flash_cfg_addr(struct adapter *adapter);
 int t4_check_fw_version(struct adapter *adap);
 int t4_get_fw_version(struct adapter *adapter, u32 *vers);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 5e3ffa7..099b946 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -3173,8 +3173,7 @@ static int t4_sge_init_soft(struct adapter *adap)
 int t4_sge_init(struct adapter *adap)
 {
struct sge *s = >sge;
-   u32 sge_control, sge_control2, sge_conm_ctrl;
-   unsigned int ingpadboundary, ingpackboundary;
+   u32 sge_control, sge_conm_ctrl;
int ret, egress_threshold;
 
/*
@@ -3185,35 +3184,7 @@ int t4_sge_init(struct adapter *adap)
s->pktshift = PKTSHIFT_G(sge_control);
s->stat_len = (sge_control & EGRSTATUSPAGESIZE_F) ? 128 : 64;
 
-   /* T4 uses a single control field to specify both the PCIe Padding and
-* Packing Boundary.  T5 introduced the ability to specify these
-* separately.  The actual Ingress Packet Data alignment boundary
-* within Packed Buffer Mode is the maximum of these two
-* specifications.  (Note that it makes no real practical sense to
-* have the Pading Boudary be larger than the Packing Boundary but you
-* could set the chip up that way and, in fact, legacy T4 code would
-* end doing this because it would initialize the Padding Boundary and
-* leave the Packing Boundary initialized to 0 (16 bytes).)
-*/
-   ingpadboundary = 1 << (INGPADBOUNDARY_G(sge_control) +
-  INGPADBOUNDARY_SHIFT_X);
-   if (is_t4(adap->params.chip)) {
-   s->fl_align = ingpadboundary;
-   } else {
-   /* T5 has a different interpretation of one of the PCIe Packing
-* Boundary values.
-*/
-   sge_control2 = t4_read_reg(adap, SGE_CONTROL2_A);
-   ingpackboundary = INGPACKBOUNDARY_G(sge_control2);
-   if (ingpackboundary == INGPACKBOUNDARY_16B_X)
-   ingpackboundary = 16;
-   else
-   ingpackboundary = 1 << (ingpackboundary +
-   INGPACKBOUNDARY_SHIFT_X);
-
-   s->fl_align = max(ingpadboundary, ingpackboundary);
-   }
-
+   s->fl_align = t4_fl_pkt_align(adap);
ret = t4_sge_init_soft(adap);
if (ret < 0)
return ret;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c 
b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 5266011..42754c0 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -6097,6 +6097,59 @@ int t4_fw_upgrade(struct adapter *adap, unsigned int 
mbox,
 }
 
 /**
+ * t4_fl_pkt_align - return the fl packet alignment
+ * @adap: the adapter
+ *
+ * T4 has a single field to specify the packing and padding boundary.
+ * T5 onwards has separate fields for this and hence the alignment for
+ * next packet offset is maximum of these two.
+ *
+ */
+int t4_fl_pkt_align(struct adapter *adap)
+{
+   u32 sge_control, sge_control2;
+   unsigned int ingpadboundary, ingpackboundary, fl_align, ingpad_shift;
+
+   sge_control = t4_read_reg(adap, SGE_CONTROL_A);
+
+   /* T4 uses a single control field to specify both the PCIe Padding and
+* Packing Boundary.  T5 introduced the ability to specify these
+* separately.  The actual Ingress Packet Data alignment boundary
+* within 

[PATCH net-next 0/9] Update support for T6 adapters

[Hariprasad Shenai]

Hi

This patch changes updates the various code changes related to
register, stats and hardware related changes for T6 family of
adapters.

This patch series has been created against net-next tree and includes
patches on cxgb4 and cxgb4vf driver.

We have included all the maintainers of respective drivers. Kindly review
the change and let us know in case of any review comments.

Thanks

Hariprasad Shenai (9):
  cxgb4: Pass correct argument to t4_link_l1cfg()
  cxgb4: Update pm_stats for T6 adapter family
  cxgb4/cxgb4vf: Update Ingress padding boundary values for T6 adapter
  cxgb4: Update register range and SGE registers for T6 adapter
  cxgb4: Update Congestion Channel map for T6 adapter
  cxgb4: Update correct encoding of SGE Ingress DMA States for T6
adapter
  cxgb4: Update mps_tcam output to include T6 fields
  cxgb4: Update SGE context congestion map change for T6 adapter
  cxgb4vf: Update to 128 byte mailbox size for T6 adapter

 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |   3 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 130 ++---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c |   2 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c|   5 +-
 drivers/net/ethernet/chelsio/cxgb4/sge.c   |  55 +++
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 162 +++--
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.h |   1 +
 drivers/net/ethernet/chelsio/cxgb4/t4_regs.h   |  27 
 drivers/net/ethernet/chelsio/cxgb4/t4_values.h |   3 +
 drivers/net/ethernet/chelsio/cxgb4vf/sge.c |  11 +-
 drivers/net/ethernet/chelsio/cxgb4vf/t4vf_defs.h   |   1 +
 drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c |  11 +-
 12 files changed, 338 insertions(+), 73 deletions(-)

-- 
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 6/9] cxgb4: Update correct encoding of SGE Ingress DMA States for T6 adapter

[Hariprasad Shenai]

Signed-off-by: Hariprasad Shenai 
---
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 59 ++
 1 file changed, 59 insertions(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c 
b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 2f8c736..0132b64 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -5702,6 +5702,39 @@ void t4_sge_decode_idma_state(struct adapter *adapter, 
int state)
"IDMA_FL_SEND_PADDING",
"IDMA_FL_SEND_COMPLETION_TO_IMSG",
};
+   static const char * const t6_decode[] = {
+   "IDMA_IDLE",
+   "IDMA_PUSH_MORE_CPL_FIFO",
+   "IDMA_PUSH_CPL_MSG_HEADER_TO_FIFO",
+   "IDMA_SGEFLRFLUSH_SEND_PCIEHDR",
+   "IDMA_PHYSADDR_SEND_PCIEHDR",
+   "IDMA_PHYSADDR_SEND_PAYLOAD_FIRST",
+   "IDMA_PHYSADDR_SEND_PAYLOAD",
+   "IDMA_FL_REQ_DATA_FL",
+   "IDMA_FL_DROP",
+   "IDMA_FL_DROP_SEND_INC",
+   "IDMA_FL_H_REQ_HEADER_FL",
+   "IDMA_FL_H_SEND_PCIEHDR",
+   "IDMA_FL_H_PUSH_CPL_FIFO",
+   "IDMA_FL_H_SEND_CPL",
+   "IDMA_FL_H_SEND_IP_HDR_FIRST",
+   "IDMA_FL_H_SEND_IP_HDR",
+   "IDMA_FL_H_REQ_NEXT_HEADER_FL",
+   "IDMA_FL_H_SEND_NEXT_PCIEHDR",
+   "IDMA_FL_H_SEND_IP_HDR_PADDING",
+   "IDMA_FL_D_SEND_PCIEHDR",
+   "IDMA_FL_D_SEND_CPL_AND_IP_HDR",
+   "IDMA_FL_D_REQ_NEXT_DATA_FL",
+   "IDMA_FL_SEND_PCIEHDR",
+   "IDMA_FL_PUSH_CPL_FIFO",
+   "IDMA_FL_SEND_CPL",
+   "IDMA_FL_SEND_PAYLOAD_FIRST",
+   "IDMA_FL_SEND_PAYLOAD",
+   "IDMA_FL_REQ_NEXT_DATA_FL",
+   "IDMA_FL_SEND_NEXT_PCIEHDR",
+   "IDMA_FL_SEND_PADDING",
+   "IDMA_FL_SEND_COMPLETION_TO_IMSG",
+   };
static const u32 sge_regs[] = {
SGE_DEBUG_DATA_LOW_INDEX_2_A,
SGE_DEBUG_DATA_LOW_INDEX_3_A,
@@ -5710,6 +5743,32 @@ void t4_sge_decode_idma_state(struct adapter *adapter, 
int state)
const char **sge_idma_decode;
int sge_idma_decode_nstates;
int i;
+   unsigned int chip_version = CHELSIO_CHIP_VERSION(adapter->params.chip);
+
+   /* Select the right set of decode strings to dump depending on the
+* adapter chip type.
+*/
+   switch (chip_version) {
+   case CHELSIO_T4:
+   sge_idma_decode = (const char **)t4_decode;
+   sge_idma_decode_nstates = ARRAY_SIZE(t4_decode);
+   break;
+
+   case CHELSIO_T5:
+   sge_idma_decode = (const char **)t5_decode;
+   sge_idma_decode_nstates = ARRAY_SIZE(t5_decode);
+   break;
+
+   case CHELSIO_T6:
+   sge_idma_decode = (const char **)t6_decode;
+   sge_idma_decode_nstates = ARRAY_SIZE(t6_decode);
+   break;
+
+   default:
+   dev_err(adapter->pdev_dev,
+   "Unsupported chip version %d\n", chip_version);
+   return;
+   }
 
if (is_t4(adapter->params.chip)) {
sge_idma_decode = (const char **)t4_decode;
-- 
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 2/9] cxgb4: Update pm_stats for T6 adapter family

[Hariprasad Shenai]

Updated pm_stats code to display input FIFO wait (index 5) and read
latency (index 7) counters for T6 adapters

Signed-off-by: Hariprasad Shenai 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |  1 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 30 --
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c |  7 +++--
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.h |  1 +
 4 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 3b59bc4..eab57cf 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -301,6 +301,7 @@ struct devlog_params {
 /* Stores chip specific parameters */
 struct arch_specific_params {
u8 nchan;
+   u8 pm_stats_cnt;
u16 mps_rplc_size;
u16 vfcount;
u32 sge_fl_db;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index a008afdb..98965a4 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -758,8 +758,8 @@ static int pm_stats_show(struct seq_file *seq, void *v)
};
 
int i;
-   u32 tx_cnt[PM_NSTATS], rx_cnt[PM_NSTATS];
-   u64 tx_cyc[PM_NSTATS], rx_cyc[PM_NSTATS];
+   u32 tx_cnt[T6_PM_NSTATS], rx_cnt[T6_PM_NSTATS];
+   u64 tx_cyc[T6_PM_NSTATS], rx_cyc[T6_PM_NSTATS];
struct adapter *adap = seq->private;
 
t4_pmtx_get_stats(adap, tx_cnt, tx_cyc);
@@ -774,6 +774,32 @@ static int pm_stats_show(struct seq_file *seq, void *v)
for (i = 0; i < PM_NSTATS - 1; i++)
seq_printf(seq, "%-13s %10u  %20llu\n",
   rx_pm_stats[i], rx_cnt[i], rx_cyc[i]);
+
+   if (CHELSIO_CHIP_VERSION(adap->params.chip) > CHELSIO_T5) {
+   /* In T5 the granularity of the total wait is too fine.
+* It is not useful as it reaches the max value too fast.
+* Hence display this Input FIFO wait for T6 onwards.
+*/
+   seq_printf(seq, "%13s %10s  %20s\n",
+  " ", "Total wait", "Total Occupancy");
+   seq_printf(seq, "Tx FIFO wait  %10u  %20llu\n",
+  tx_cnt[i], tx_cyc[i]);
+   seq_printf(seq, "Rx FIFO wait  %10u  %20llu\n",
+  rx_cnt[i], rx_cyc[i]);
+
+   /* Skip index 6 as there is nothing useful ihere */
+   i += 2;
+
+   /* At index 7, a new stat for read latency (count, total wait)
+* is added.
+*/
+   seq_printf(seq, "%13s %10s  %20s\n",
+  " ", "Reads", "Total wait");
+   seq_printf(seq, "Tx latency%10u  %20llu\n",
+  tx_cnt[i], tx_cyc[i]);
+   seq_printf(seq, "Rx latency%10u  %20llu\n",
+  rx_cnt[i], rx_cyc[i]);
+   }
return 0;
 }
 
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c 
b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index cf61a58..5266011 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -5254,7 +5254,7 @@ void t4_pmtx_get_stats(struct adapter *adap, u32 cnt[], 
u64 cycles[])
int i;
u32 data[2];
 
-   for (i = 0; i < PM_NSTATS; i++) {
+   for (i = 0; i < adap->params.arch.pm_stats_cnt; i++) {
t4_write_reg(adap, PM_TX_STAT_CONFIG_A, i + 1);
cnt[i] = t4_read_reg(adap, PM_TX_STAT_COUNT_A);
if (is_t4(adap->params.chip)) {
@@ -5281,7 +5281,7 @@ void t4_pmrx_get_stats(struct adapter *adap, u32 cnt[], 
u64 cycles[])
int i;
u32 data[2];
 
-   for (i = 0; i < PM_NSTATS; i++) {
+   for (i = 0; i < adap->params.arch.pm_stats_cnt; i++) {
t4_write_reg(adap, PM_RX_STAT_CONFIG_A, i + 1);
cnt[i] = t4_read_reg(adap, PM_RX_STAT_COUNT_A);
if (is_t4(adap->params.chip)) {
@@ -7060,6 +7060,7 @@ int t4_prep_adapter(struct adapter *adapter)
 NUM_MPS_CLS_SRAM_L_INSTANCES;
adapter->params.arch.mps_rplc_size = 128;
adapter->params.arch.nchan = NCHAN;
+   adapter->params.arch.pm_stats_cnt = PM_NSTATS;
adapter->params.arch.vfcount = 128;
break;
case CHELSIO_T5:
@@ -7069,6 +7070,7 @@ int t4_prep_adapter(struct adapter *adapter)
 NUM_MPS_T5_CLS_SRAM_L_INSTANCES;
adapter->params.arch.mps_rplc_size = 128;
adapter->params.arch.nchan = NCHAN;
+   adapter->params.arch.pm_stats_cnt = PM_NSTATS;
adapter->params.arch.vfcount = 128;
break;
case CHELSIO_T6:
@@ -7078,6 +7080,7 @@ int 

[PATCH net-next 1/9] cxgb4: Pass correct argument to t4_link_l1cfg()

[Hariprasad Shenai]

Signed-off-by: Hariprasad Shenai 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c
index 2a61a42..7a0b92b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c
@@ -686,7 +686,7 @@ static int set_pauseparam(struct net_device *dev,
if (epause->tx_pause)
lc->requested_fc |= PAUSE_TX;
if (netif_running(dev))
-   return t4_link_l1cfg(p->adapter, p->adapter->pf, p->tx_chan,
+   return t4_link_l1cfg(p->adapter, p->adapter->mbox, p->tx_chan,
 lc);
return 0;
 }
-- 
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] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

[Cong Wang]

On Tue, Dec 22, 2015 at 11:37 PM, Vijay Pandurangan  wrote:
> Cool, thanks! I see it in the -stable queue. Is there anything else I need
> to do to help with getting this into main or backporting?  Happy to pitch in
> if I can be helpful.
>

DaveM usually just backports it to a few recent stable tree, if you want
to backport further, for example 3.14, you probably need to send
the commit ID to Greg KH.

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] sctp: use GFP_USER for user-controlled kmalloc

[Marcelo Ricardo Leitner]

Commit cacc06215271 ("sctp: use GFP_USER for user-controlled kmalloc")
missed two other spots.

For connectx, as it's more likely to be used by kernel users of the API,
it detects if GFP_USER should be used or not.

Fixes: cacc06215271 ("sctp: use GFP_USER for user-controlled kmalloc")
Reported-by: Dmitry Vyukov 
Signed-off-by: Marcelo Ricardo Leitner 
---
 net/sctp/socket.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 
2a1e8ba2808cab3bb29d670f155bcef243f85922..400a14d744834c7a503b338bc68f5f8b5b5dae8e
 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1301,8 +1301,9 @@ static int __sctp_setsockopt_connectx(struct sock *sk,
  int addrs_size,
  sctp_assoc_t *assoc_id)
 {
-   int err = 0;
struct sockaddr *kaddrs;
+   gfp_t gfp = GFP_KERNEL;
+   int err = 0;
 
pr_debug("%s: sk:%p addrs:%p addrs_size:%d\n",
 __func__, sk, addrs, addrs_size);
@@ -1315,7 +1316,9 @@ static int __sctp_setsockopt_connectx(struct sock *sk,
return -EFAULT;
 
/* Alloc space for the address array in kernel memory.  */
-   kaddrs = kmalloc(addrs_size, GFP_KERNEL);
+   if (sk->sk_socket->file)
+   gfp = GFP_USER | __GFP_NOWARN;
+   kaddrs = kmalloc(addrs_size, gfp);
if (unlikely(!kaddrs))
return -ENOMEM;
 
@@ -5773,7 +5776,7 @@ static int sctp_getsockopt_assoc_ids(struct sock *sk, int 
len,
 
len = sizeof(struct sctp_assoc_ids) + sizeof(sctp_assoc_t) * num;
 
-   ids = kmalloc(len, GFP_KERNEL);
+   ids = kmalloc(len, GFP_USER | __GFP_NOWARN);
if (unlikely(!ids))
return -ENOMEM;
 
-- 
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] poll.2: timeout_ts is a pointer, so use -> not . for member access

[richardvo...@gmail.com]

>From the context, it is apparent that in the code explaining ppoll in
terms of poll, timeout_ts must be a pointer.

Usage #1:   ready = ppoll(, nfds, timeout_ts, );

Usage #2:(timeout_ts == NULL)

Thus member access in (timeout_ts.tv_sec * 1000 + timeout_ts.tv_nsec /
100) is an error.

Ben



man2/poll.2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man2/poll.2 b/man2/poll.2
index bcbecad..34b55a6 100644
--- a/man2/poll.2
+++ b/man2/poll.2
@@ -266,7 +266,7 @@ executing the following calls:
 int timeout;

 timeout = (timeout_ts == NULL) ? \-1 :
-  (timeout_ts.tv_sec * 1000 + timeout_ts.tv_nsec / 100);
+  (timeout_ts\->tv_sec * 1000 + timeout_ts\->tv_nsec / 100);
 pthread_sigmask(SIG_SETMASK, , );
 ready = poll(, nfds, timeout);
 pthread_sigmask(SIG_SETMASK, , NULL);
--
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

[Or Gerlitz]

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?


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: [E1000-devel] [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex

[Stephen Hemminger]

On Wed, 23 Dec 2015 15:59:24 +
"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.

Kernel has netdev notifiers, these should really always be used rather than
polling. The polling stuff was added back in ancient kernel days when netdev
notifiers didn't work because most drivers were broken.
--
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 0/2] new maintainers for Mellanox mlx4/mlx5 core and IB drivers

[Doug Ledford]

On 12/23/2015 11:30 AM, Or Gerlitz wrote:
> Hi Dave, Doug
>  
> We're happily assigning new maintainers for mlx4/mlx5 core and IB drivers.
> 
> This is aligned with Eli (mlx5) and Roland (mlx4).
> 
> FWIW, I did the whole change to go through netdev. 

Hi Dave, I've picked these up.

Thanks Or.

> Or.
> 
> Or Gerlitz (2):
>   MAINTAINERS: Assign new maintainers to Mellanox mlx5 core and IB drivers
>   MAINTAINERS: Assign maintainer to Mellanox mlx4 core and IB drivers
> 
>  MAINTAINERS | 32 +---
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 


-- 
Doug Ledford 
  GPG KeyID: 0E572FDD




signature.asc
Description: OpenPGP digital signature

[PATCH net-next 2/2] MAINTAINERS: Assign maintainer to Mellanox mlx4 core and IB drivers

[Or Gerlitz]

The driver was written originally by Roland Dreier, currently there's
no official maintainer. Yishai steps in as maintainer.

Signed-off-by: Or Gerlitz 
Cc: Roland Dreier 
---
 MAINTAINERS | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c7586a5..d9274ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7057,6 +7057,25 @@ W:   http://linuxtv.org
 S: Odd Fixes
 F: drivers/media/radio/radio-miropcm20*
 
+MELLANOX MLX4 core VPI driver
+M: Yishai Hadas 
+L: netdev@vger.kernel.org
+L: linux-r...@vger.kernel.org
+W: http://www.mellanox.com
+Q: http://patchwork.ozlabs.org/project/netdev/list/
+S: Supported
+F: drivers/net/ethernet/mellanox/mlx4/
+F: include/linux/mlx4/
+
+MELLANOX MLX4 IB driver
+M: Yishai Hadas 
+L: linux-r...@vger.kernel.org
+W: http://www.mellanox.com
+Q: http://patchwork.kernel.org/project/linux-rdma/list/
+S: Supported
+F: drivers/infiniband/hw/mlx4/
+F: include/linux/mlx4/
+
 MELLANOX MLX5 core VPI driver
 M: Matan Barak 
 M: Leon Romanovsky 
-- 
2.3.7

--
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 00/16] add Intel(R) X722 iWARP driver

[Or Gerlitz]

On 12/23/2015 6:35 PM, Faisal Latif wrote:

I will provide new patch series for latest k.o. Also will make sure of shallow 
threading for the series.


Please make sure that the cover letter will include the full output of 
the git generated cover-letter so we can see the location of changes you 
did to the IB core and the overall LOC volume of the driver.


Did you run the driver through 0-day testing to avoid zillion small 
follow up patches in a later point when this isin?


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

[PATCH net-next 1/2] MAINTAINERS: Assign new maintainers to Mellanox mlx5 core and IB drivers

[Or Gerlitz]

Matan and Leon step in as co-maintainers to replace Eli Cohen
who wrote and maintained the core and IB drivers.

Signed-off-by: Or Gerlitz 
---
 MAINTAINERS | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c6b78b0..c7586a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7057,27 +7057,26 @@ W:  http://linuxtv.org
 S: Odd Fixes
 F: drivers/media/radio/radio-miropcm20*
 
-Mellanox MLX5 core VPI driver
-M: Eli Cohen 
+MELLANOX MLX5 core VPI driver
+M: Matan Barak 
+M: Leon Romanovsky 
 L: netdev@vger.kernel.org
 L: linux-r...@vger.kernel.org
 W: http://www.mellanox.com
 Q: http://patchwork.ozlabs.org/project/netdev/list/
-Q: http://patchwork.kernel.org/project/linux-rdma/list/
-T: git git://openfabrics.org/~eli/connect-ib.git
 S: Supported
 F: drivers/net/ethernet/mellanox/mlx5/core/
 F: include/linux/mlx5/
 
-Mellanox MLX5 IB driver
-M: Eli Cohen 
+MELLANOX MLX5 IB driver
+M: Matan Barak 
+M: Leon Romanovsky 
 L: linux-r...@vger.kernel.org
 W: http://www.mellanox.com
 Q: http://patchwork.kernel.org/project/linux-rdma/list/
-T: git git://openfabrics.org/~eli/connect-ib.git
 S: Supported
-F: include/linux/mlx5/
 F: drivers/infiniband/hw/mlx5/
+F: include/linux/mlx5/
 
 MELEXIS MLX90614 DRIVER
 M: Crt Mori 
-- 
2.3.7

--
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 1/1] phy: micrel: Fix finding PHY properties in MAC node for KSZ9031.

[David Miller]

From: Henri Roosen 
Date: Wed, 23 Dec 2015 09:11:22 +0100

> On 12/22/2015 11:14 PM, David Miller wrote:
>> From: Andrew Lunn 
>> Date: Tue, 22 Dec 2015 12:06:34 +0100
>>
>>> On Tue, Dec 22, 2015 at 11:58:40AM +0100, Henri Roosen wrote:
 Commit 651df2183543 ("phy: micrel: Fix finding PHY properties in MAC
   node.") only fixes finding PHY properties in MAC node for
   KSZ9021. This
 commit applies the same fix for KSZ9031.

 Signed-off-by: Henri Roosen 
>>>
>>> Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus,
>>> not the bus' parent.")
>>>
>>> Acked-by: Andrew Lunn 
>>
>> This does not apply cleanly to any of my trees.
> 
> David, does the original patch not apply cleanly or is your comment
> only
> on the message from Andrew?
> 
> Else please let me know what is wrong with the original patch. I've
> tested it applies cleanly to v4.4-rc6 and to v4.3.

Your original patch did not apply cleanly.

All patches must be against either my 'net' or 'net-next' trees.  And
you must explicitly state what tree your patch is against and therefore
which tree you expect me to apply it too.
--
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

[David Miller]

From: "David Rivshin (Allworx)" 
Date: Tue, 22 Dec 2015 19:36:31 -0500

> Testing by anyone who has real hardware using phy-handle or dual_emac
> with fixed-link would be appreciated.

I'm going to wait for such testing before applying this series.

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

Re: [PATCH V1 00/16] add Intel(R) X722 iWARP driver

[Or Gerlitz]

On 12/22/2015 1:13 AM, Faisal Latif wrote:

This driver provides iWARP RDMA functionality for the Intel(R) X722 Ethernet
controller for PCI Physical Functions.


Is there any public info on the X722, I didn't manage to find such.


It also has support for Virtual Function driver (i40iwvf.ko), which that will 
be part of separate patch series.


can you explain why do you need a separate rdma driver for VFs?

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

[PATCH net-next 9/9] cxgb4vf: Update to 128 byte mailbox size for T6 adapter

[Hariprasad Shenai]

Signed-off-by: Hariprasad Shenai 
---
 drivers/net/ethernet/chelsio/cxgb4vf/t4vf_defs.h |  1 +
 drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c   | 11 +--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_defs.h 
b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_defs.h
index b516b12..f859db3 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_defs.h
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_defs.h
@@ -54,6 +54,7 @@
 #define T4VF_MPS_BASE_ADDR 0x0100
 #define T4VF_PL_BASE_ADDR  0x0200
 #define T4VF_MBDATA_BASE_ADDR  0x0240
+#define T6VF_MBDATA_BASE_ADDR  0x0280
 #define T4VF_CIM_BASE_ADDR 0x0300
 
 #define T4VF_REGMAP_START  0x
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
index 63dd5fd..b6fa74a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
@@ -120,12 +120,19 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void 
*cmd, int size,
1, 1, 3, 5, 10, 10, 20, 50, 100
};
 
-   u32 v;
+   u32 v, mbox_data;
int i, ms, delay_idx;
const __be64 *p;
-   u32 mbox_data = T4VF_MBDATA_BASE_ADDR;
u32 mbox_ctl = T4VF_CIM_BASE_ADDR + CIM_VF_EXT_MAILBOX_CTRL;
 
+   /* In T6, mailbox size is changed to 128 bytes to avoid
+* invalidating the entire prefetch buffer.
+*/
+   if (CHELSIO_CHIP_VERSION(adapter->params.chip) <= CHELSIO_T5)
+   mbox_data = T4VF_MBDATA_BASE_ADDR;
+   else
+   mbox_data = T6VF_MBDATA_BASE_ADDR;
+
/*
 * Commands must be multiples of 16 bytes in length and may not be
 * larger than the size of the Mailbox Data register array.
-- 
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 4/9] cxgb4: Update register range and SGE registers for T6 adapter

[Hariprasad Shenai]

Signed-off-by: Hariprasad Shenai 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c |  5 +++--
 drivers/net/ethernet/chelsio/cxgb4/sge.c| 15 +--
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c  | 16 +++-
 drivers/net/ethernet/chelsio/cxgb4/t4_regs.h|  3 +++
 4 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 2642593..c0dd533 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4855,8 +4855,9 @@ static int init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
/* configure SGE_STAT_CFG_A to read WC stats */
if (!is_t4(adapter->params.chip))
-   t4_write_reg(adapter, SGE_STAT_CFG_A,
-STATSOURCE_T5_V(7) | STATMODE_V(0));
+   t4_write_reg(adapter, SGE_STAT_CFG_A, STATSOURCE_T5_V(7) |
+(is_t5(adapter->params.chip) ? STATMODE_V(0) :
+ T6_STATMODE_V(0)));
 
for_each_port(adapter, i) {
struct net_device *netdev;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 099b946..5829c9c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -3202,10 +3202,21 @@ int t4_sge_init(struct adapter *adap)
 * buffers.
 */
sge_conm_ctrl = t4_read_reg(adap, SGE_CONM_CTRL_A);
-   if (is_t4(adap->params.chip))
+   switch (CHELSIO_CHIP_VERSION(adap->params.chip)) {
+   case CHELSIO_T4:
egress_threshold = EGRTHRESHOLD_G(sge_conm_ctrl);
-   else
+   break;
+   case CHELSIO_T5:
egress_threshold = EGRTHRESHOLDPACKING_G(sge_conm_ctrl);
+   break;
+   case CHELSIO_T6:
+   egress_threshold = T6_EGRTHRESHOLDPACKING_G(sge_conm_ctrl);
+   break;
+   default:
+   dev_err(adap->pdev_dev, "Unsupported Chip version %d\n",
+   CHELSIO_CHIP_VERSION(adap->params.chip));
+   return -EINVAL;
+   }
s->fl_starve_thres = 2*egress_threshold + 1;
 
t4_idma_monitor_init(adap, >idma_monitor);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c 
b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 42754c0..c613bd6 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -1942,8 +1942,12 @@ void t4_get_regs(struct adapter *adap, void *buf, size_t 
buf_size)
0x1190, 0x1194,
0x11a0, 0x11a4,
0x11b0, 0x11b4,
-   0x11fc, 0x1254,
-   0x1280, 0x133c,
+   0x11fc, 0x1258,
+   0x1280, 0x12d4,
+   0x12d9, 0x12d9,
+   0x12de, 0x12de,
+   0x12e3, 0x12e3,
+   0x12e8, 0x133c,
0x1800, 0x18fc,
0x3000, 0x302c,
0x3060, 0x30b0,
@@ -1973,7 +1977,7 @@ void t4_get_regs(struct adapter *adap, void *buf, size_t 
buf_size)
0x5e50, 0x5e94,
0x5ea0, 0x5eb0,
0x5ec0, 0x5ec0,
-   0x5ec8, 0x5ecc,
+   0x5ec8, 0x5ed0,
0x6000, 0x6020,
0x6028, 0x6040,
0x6058, 0x609c,
@@ -2048,7 +2052,8 @@ void t4_get_regs(struct adapter *adap, void *buf, size_t 
buf_size)
0x19150, 0x19194,
0x1919c, 0x191b0,
0x191d0, 0x191e8,
-   0x19238, 0x192b0,
+   0x19238, 0x19290,
+   0x192a4, 0x192b0,
0x192bc, 0x192bc,
0x19348, 0x1934c,
0x193f8, 0x19418,
@@ -2442,7 +2447,8 @@ void t4_get_regs(struct adapter *adap, void *buf, size_t 
buf_size)
0x40280, 0x40280,
0x40304, 0x40304,
0x40330, 0x4033c,
-   0x41304, 0x413c8,
+   0x41304, 0x413b8,
+   0x413c0, 0x413c8,
0x413d0, 0x413dc,
0x413f0, 0x413f0,
0x41400, 0x4140c,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h 
b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
index 91b52a2..0971cc4 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
@@ -492,6 +492,9 @@
 #define STATSOURCE_T5_V(x) ((x) << STATSOURCE_T5_S)
 #define STATSOURCE_T5_G(x) (((x) >> STATSOURCE_T5_S) & STATSOURCE_T5_M)
 
+#define T6_STATMODE_S0
+#define T6_STATMODE_V(x) ((x) << T6_STATMODE_S)
+
 #define SGE_DBFIFO_STATUS2_A 0x1118
 
 #define HP_INT_THRESH_T5_S10
-- 
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  

[PATCH net-next 7/9] cxgb4: Update mps_tcam output to include T6 fields

[Hariprasad Shenai]

In T6, MPS classification has a 512 deep TCAM to do the match lookup.
Each entry has 80x2b sets containing 48 bit MAC address, port number,
VLAN Valid/ID, VNI, lookup type (outer or inner packet header).
[71:48] bit locations are overloaded for outer vs. inner lookup types.

Signed-off-by: Hariprasad Shenai 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 100 +
 drivers/net/ethernet/chelsio/cxgb4/t4_regs.h   |  24 +
 2 files changed, 105 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 98965a4..1fe2db7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -1586,25 +1586,35 @@ static int mps_tcam_show(struct seq_file *seq, void *v)
 {
struct adapter *adap = seq->private;
unsigned int chip_ver = CHELSIO_CHIP_VERSION(adap->params.chip);
-
if (v == SEQ_START_TOKEN) {
-   if (adap->params.arch.mps_rplc_size > 128)
+   if (chip_ver > CHELSIO_T5) {
seq_puts(seq, "Idx  Ethernet address Mask "
+"  VNI   Mask   IVLAN Vld "
+"DIP_Hit   Lookup  Port "
 "Vld Ports PF  VF   "
 "Replication"
 "P0 P1 P2 P3  ML\n");
-   else
-   seq_puts(seq, "Idx  Ethernet address Mask "
-"Vld Ports PF  VF  Replication"
-"   P0 P1 P2 P3  ML\n");
+   } else {
+   if (adap->params.arch.mps_rplc_size > 128)
+   seq_puts(seq, "Idx  Ethernet address Mask   
  "
+"Vld Ports PF  VF  
 "
+"Replication   
 "
+"P0 P1 P2 P3  ML\n");
+   else
+   seq_puts(seq, "Idx  Ethernet address Mask   
  "
+"Vld Ports PF  VF  
Replication"
+"   P0 P1 P2 P3  ML\n");
+   }
} else {
u64 mask;
u8 addr[ETH_ALEN];
-   bool replicate;
+   bool replicate, dip_hit = false, vlan_vld = false;
unsigned int idx = (uintptr_t)v - 2;
u64 tcamy, tcamx, val;
-   u32 cls_lo, cls_hi, ctl;
+   u32 cls_lo, cls_hi, ctl, data2, vnix = 0, vniy = 0;
u32 rplc[8] = {0};
+   u8 lookup_type = 0, port_num = 0;
+   u16 ivlan = 0;
 
if (chip_ver > CHELSIO_T5) {
/* CtlCmdType - 0: Read, 1: Write
@@ -1623,6 +1633,22 @@ static int mps_tcam_show(struct seq_file *seq, void *v)
val = t4_read_reg(adap, MPS_CLS_TCAM_DATA1_A);
tcamy = DMACH_G(val) << 32;
tcamy |= t4_read_reg(adap, MPS_CLS_TCAM_DATA0_A);
+   data2 = t4_read_reg(adap, MPS_CLS_TCAM_DATA2_CTL_A);
+   lookup_type = DATALKPTYPE_G(data2);
+   /* 0 - Outer header, 1 - Inner header
+* [71:48] bit locations are overloaded for
+* outer vs. inner lookup types.
+*/
+   if (lookup_type && (lookup_type != DATALKPTYPE_M)) {
+   /* Inner header VNI */
+   vniy = ((data2 & DATAVIDH2_F) << 23) |
+  (DATAVIDH1_G(data2) << 16) | VIDL_G(val);
+   dip_hit = data2 & DATADIPHIT_F;
+   } else {
+   vlan_vld = data2 & DATAVIDH2_F;
+   ivlan = VIDL_G(val);
+   }
+   port_num = DATAPORTNUM_G(data2);
 
/* Read tcamx. Change the control param */
ctl |= CTLXYBITSEL_V(1);
@@ -1630,6 +1656,12 @@ static int mps_tcam_show(struct seq_file *seq, void *v)
val = t4_read_reg(adap, MPS_CLS_TCAM_DATA1_A);
tcamx = DMACH_G(val) << 32;
tcamx |= t4_read_reg(adap, MPS_CLS_TCAM_DATA0_A);
+   data2 = t4_read_reg(adap, MPS_CLS_TCAM_DATA2_CTL_A);
+   if (lookup_type && (lookup_type != DATALKPTYPE_M)) {
+   /* Inner header VNI mask */
+   vnix = ((data2 & DATAVIDH2_F) << 23) 

Re: [RFC PATCH 00/17] CALIPSO implementation

[Paul Moore]

On Tue, Dec 22, 2015 at 12:28 PM, Casey Schaufler
 wrote:
> On 12/22/2015 3:46 AM, Huw Davies wrote:
>> This patch series implements RFC 5570 - Common Architecture Label IPv6
>> Security Option (CALIPSO).  Its goal is to set MLS sensitivity labels
>> on IPv6 packets using a hop-by-hop option.  CALIPSO very similar to
>> its IPv4 cousin CIPSO and much of this series is based on that code.
>
> There's a one line change to the Smack code in 15/17 due to
> a change in the api, but I assume that there has been no
> attempt to verify that this works with Smack. It's not 100%
> clear that this won't break a Smack kernel, but I haven't
> tried it.
>
> You'll need to provide sufficient information (or code!) so
> that security modules other than SELinux can use this. If
> you look at how Smack uses netlabel for IPv4 you will see
> that it differs substantially from the way SELinux uses it.

Smack is going to have some difficulties implementing CALIPSO due to
some previous design decisions and inconsistencies between how Smack
handles both IPv4 and IPv6 packet labeling today.  I think we can all
agree that asking Huw to resolve these problems isn't quite fair,
although asking Huw to make sure he doesn't break existing
functionality *is* fair, and a requirement for patch acceptance.

Huw, I would suggest you ensure that the NetLabel/CALIPSO changes
don't break the existing Smack code, and that everything is commented
appropriately.  Adding CALIPSO support to the netlbl_cfg_*() functions
in netlabel_kapi.c would also be a good idea, and shouldn't be too
difficult (I should have commented on this earlier, my mistake).
However, I think resolving the Smack IPv6 design issues is something
best left to Casey and the rest of the Smack developers.

> Thank you for tackling RFC 5570. The lack of something like
> this has put IPv6 at a real disadvantage.

Agreed, thanks Huw for all the hard work you put into this
implementation.  I started a similar effort on two separate occasions
but never had the time to see it through to the end; I'm happy that
someone was finally able to get it finished.

-- 
paul moore
www.paul-moore.com
--
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

[Markus Brunner]

On Wednesday 23 December 2015 12:04:25 David Miller wrote:
> From: "David Rivshin (Allworx)" 
> Date: Tue, 22 Dec 2015 19:36:31 -0500
> 
> > Testing by anyone who has real hardware using phy-handle or dual_emac
> > with fixed-link would be appreciated.
> 
> I'm going to wait for such testing before applying this series.
> 
> Thanks.

Successfully tested the following 3 configurations.
1. emac0 with phy_id and emac1 with fixed phy
2. emac0 with phy-handle and emac1 with fixed phy
3. emac0 with fixed phy and emac1 with fixed phy


Below are the affected DT nodes, with one cpsw_emac0 node choosen for each 
test.

_emac0 {
phy_id = <_mdio>, <5>;
phy-mode = "mii";
dual_emac_res_vlan = <4093>;
};

_emac0 {
phy-mode = "mii";
dual_emac_res_vlan = <4093>;
phy-handle = <>;
};

_emac0 {
phy-mode = "mii";
dual_emac_res_vlan = <4093>;
fixed-link {
speed = <100>;
full-duplex;
};
};

_emac1 {
dual_emac_res_vlan = <4094>;
phy-mode = "mii";
fixed-link {
speed = <100>;
full-duplex;
};
};

_mdio {
status = "okay";
phy0: ethernet-phy@0 {
reg = <5>;
};
};

ps: I don't have access to the board for the next 2 weeks.
--
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 05/28] net: dsa: Pass the dsa device to the switch drivers

[Florian Fainelli]

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> By passing a device structure to the switch devices, it allows them
> to use devm_* methods for resource management.
> 
> Signed-off-by: Andrew Lunn 

Acked-by: Florian Fainelli 
-- 
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: [PATCH RFC 27/28] dsa: slave: Don't reference NULL pointer during phy_disconnect

[Florian Fainelli]

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> When the phy is disconnected, the parent pointer to the netdev it was
> attached to is set to NULL. The code then tries to suspend the phy,
> but dsa_slave_fixed_link_update needs the parent pointer to determine
> which switch the phy is connected to. So it dereferenced a NULL
> pointer. Check for this condition.
> 
> Signed-off-by: Andrew Lunn 

Acked-by: Florian Fainelli 
-- 
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

[PATCH net] ipv6: honor ifindex in case we receive ll addresses in router advertisements

[Hannes Frederic Sowa]

Marc Haber reported we don't honor interface indexes when we receive link
local router addresses in router advertisements. Luckily the non-strict
version of ipv6_chk_addr already does the correct job here, so we can
simply use it to lighten the checks and use those addresses by default
without any configuration change.

Link: 
Reported-by: Marc Haber 
Cc: Marc Haber 
Signed-off-by: Hannes Frederic Sowa 
---
 net/ipv6/ndisc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index d6161e1c48c86f..84afb9a7727848 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1183,7 +1183,7 @@ static void ndisc_router_discovery(struct sk_buff *skb)
 */
if (!in6_dev->cnf.accept_ra_from_local &&
ipv6_chk_addr(dev_net(in6_dev->dev), _hdr(skb)->saddr,
- NULL, 0)) {
+ in6_dev->dev, 0)) {
ND_PRINTK(2, info,
  "RA from local address detected on dev: %s: default 
router ignored\n",
  skb->dev->name);
@@ -1337,7 +1337,7 @@ skip_linkparms:
 #ifdef CONFIG_IPV6_ROUTE_INFO
if (!in6_dev->cnf.accept_ra_from_local &&
ipv6_chk_addr(dev_net(in6_dev->dev), _hdr(skb)->saddr,
- NULL, 0)) {
+ in6_dev->dev, 0)) {
ND_PRINTK(2, info,
  "RA from local address detected on dev: %s: router 
info ignored.\n",
  skb->dev->name);
-- 
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] poll.2: timeout_ts is a pointer, so use -> not . for member access

[Michael Kerrisk (man-pages)]

Hello Richard,

On 23 December 2015 at 20:30, richardvo...@gmail.com
 wrote:
> From the context, it is apparent that in the code explaining ppoll in
> terms of poll, timeout_ts must be a pointer.
>
> Usage #1:   ready = ppoll(, nfds, timeout_ts, );
>
> Usage #2:(timeout_ts == NULL)
>
> Thus member access in (timeout_ts.tv_sec * 1000 + timeout_ts.tv_nsec /
> 100) is an error.

Thanks. Patch applied.

Cheers,

Michael


> man2/poll.2 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/man2/poll.2 b/man2/poll.2
> index bcbecad..34b55a6 100644
> --- a/man2/poll.2
> +++ b/man2/poll.2
> @@ -266,7 +266,7 @@ executing the following calls:
>  int timeout;
>
>  timeout = (timeout_ts == NULL) ? \-1 :
> -  (timeout_ts.tv_sec * 1000 + timeout_ts.tv_nsec / 100);
> +  (timeout_ts\->tv_sec * 1000 + timeout_ts\->tv_nsec / 100);
>  pthread_sigmask(SIG_SETMASK, , );
>  ready = poll(, nfds, timeout);
>  pthread_sigmask(SIG_SETMASK, , NULL);



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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()

[David Miller]

From: Pravin B Shelar 
Date: Wed, 23 Dec 2015 15:52:03 -0800

>   } else {
> - err_stats->tx_dropped++;
> + struct net_device_stats *err_stats = >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.
--
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

[V2 PATCH 1/1] ixgbe: force to synchronize reporting "link on" and

[zyjzyj2000]

Hi, Jeff

Thanks for your reply.

Changes:
Since there is a time span between link_up and link_speed to X540 NIC, it is 
not appropriate to continue in the function ixgbe_watchdog_link_is_up if only 
link_up is ready.

Best Regards!
Zhu Yanjun
--
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 1/1] ixgbe: force to synchronize reporting "link on" and getting speed

[zyjzyj2000]

From: yzhu1 

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: yzhu1 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index aed8d02..2b58a33 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6426,6 +6426,21 @@ static void ixgbe_watchdog_link_is_up(struct 
ixgbe_adapter *adapter)
if (netif_carrier_ok(netdev))
return;
 
+   /* 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.
+* To other NICs, the link_up and link_speed are gotten at the same
+* time. To X540 NIC, there is a time span between link_up and
+* link_speed. As such, only continue if link_up and link_speed are
+* ready to X540 NIC.
+*/
+   if (hw->mac.type == ixgbe_mac_X540)
+   if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
+   return;
+
adapter->flags2 &= ~IXGBE_FLAG2_SEARCH_FOR_SFP;
 
switch (hw->mac.type) {
-- 
1.7.9.5

--
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 0/2] new maintainers for Mellanox mlx4/mlx5 core and IB drivers

[David Miller]

From: Doug Ledford 
Date: Wed, 23 Dec 2015 13:31:06 -0500

> On 12/23/2015 11:30 AM, Or Gerlitz wrote:
>> Hi Dave, Doug
>>  
>> We're happily assigning new maintainers for mlx4/mlx5 core and IB drivers.
>> 
>> This is aligned with Eli (mlx5) and Roland (mlx4).
>> 
>> FWIW, I did the whole change to go through netdev. 
> 
> Hi Dave, I've picked these up.

Ok, 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 v2] ip_tunnel: Move stats update to iptunnel_xmit()

[Pravin B Shelar]

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 
---
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  | 24 +---
 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, 54 insertions(+), 76 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(>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, >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,
-  , , prio, ttl,
-  sport, geneve->dst_port,
-  !!(flags & GENEVE_F_UDP_ZERO_CSUM6_TX));
+   udp_tunnel6_xmit_skb(dst, gs6->sock->sk, skb, dev,
+, , 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, >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..2ef06cd 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 = >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(>syncp);
-   tstats->tx_bytes += pkt_len;
-   tstats->tx_packets++;
-   u64_stats_update_end(>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);
 }
 #endif
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h

Re: [PATCH 0/3] drivers: net: cpsw: phy-handle fixes

[David Rivshin (Allworx)]

On Thu, 24 Dec 2015 00:34:49 +0100
Nicolas Chauvet  wrote:

> 2015-12-23 22:54 GMT+01:00 David Rivshin (Allworx) <
> drivshin.allw...@gmail.com>:
> 
> > On Wed, 23 Dec 2015 22:20:58 +0100
> > Nicolas Chauvet  wrote:
> >
> > > 2015-12-23 1:36 GMT+01:00 David Rivshin (Allworx) <
> > > drivshin.allw...@gmail.com>:
> > >
> > > > From: David Rivshin 
> > > >
> > > > This series is based on the tip of the net tree.
> > > >
> > > > The first patch fixes a bug that makes dual_emac mode break if
> > > > either slave uses the phy-handle property in the devicetree.
> > > >
> > > > The second patch fixes some cosmetic problems with error
> > > > messages, and also makes the binding documentation more
> > > > explicit.
> > > >
> > > > The third patch cleans up the fixed-link case to work like
> > > > the now-fixed phy-handle case.
> > > >
> > > > I have tested on the following hardware configurations:
> > > >  - (EVMSK) dual emac, phy_id property in both slaves
> > > >  - (BeagleBoneBlack) single emac, phy_id property
> > > >  - (custom) single emac, fixed-link subnode
> > > > Note that I don't have a board which would uses a phy-handle
> > > > property, though I have used hacked devicetrees to exercise the
> > > > code paths. Testing by anyone who has real hardware using
> > > > phy-handle or dual_emac with fixed-link would be appreciated.
> > > >
> > > > David Rivshin (3):
> > > >   drivers: net: cpsw: fix parsing of phy-handle DT property in
> > > > dual_emac config
> > > >   drivers: net: cpsw: fix error messages when using phy-handle
> > > > DT property
> > > >   drivers: net: cpsw: use of_phy_connect() in fixed-link case
> > > >
> > > >  Documentation/devicetree/bindings/net/cpsw.txt |  4 +--
> > > >  drivers/net/ethernet/ti/cpsw.c | 40
> > > > +-
> > > >  drivers/net/ethernet/ti/cpsw.h |  1 +
> > > >  3 files changed, 23 insertions(+), 22 deletions(-)
> > > >
> > > >
> > > This serie failed with me on dm8418 hp-t410 on top of linux-next
> > > from today whereas the same patch level and same methods without
> > > this serie is working fine.
> > > I wasn't able to ping anything on a minimal rootfs with static ip
> > > set from cmdline from kernel.
> > >
> > > Sorry for  the lack of details, feel free to add me to any other
> > > revision of the patch if any.
> > > I will be able to do more testing next month.
> >
> > (Sorry for the duplicate, doing a reply-all this time. Not sure why
> > it looked like a non-list email the first time)
> >
> My bad, I've replied twice, but only last on-list.
> 
> 
> > Thanks for testing. I found the dm8148-t410.dts devicetree in the
> > kernel source, and it uses the phy_id for both slaves, just like the
> > EVMSK board I tested. So I can't think of an obvious reason for the
> > problem.
> > Would you be able to send the 'dmesg' log from right after bootup?
> > I'm hoping there is an error message in there with some clue.
> >
> here is the full dmesg output with this serie applied to linux-next:
> http://ur1.ca/ocvs6
> 
> [2.281524] davinci_mdio 4a100800.mdio: davinci mdio revision 1.6
> [2.287909] davinci_mdio 4a100800.mdio: detected phy mask fffe
> [2.302663] Atheros 8031 ethernet 4a100800.mdio:00: GPIO lookup for
> consumer reset
> [2.302686] Atheros 8031 ethernet 4a100800.mdio:00: using lookup
> tables for GPIO lookup
> [2.302732] Atheros 8031 ethernet 4a100800.mdio:00: lookup for GPIO
> reset failed
> [2.302860] libphy: 4a100800.mdio: probed
> [2.307063] davinci_mdio 4a100800.mdio: phy[0]: device
> 4a100800.mdio:00, driver Atheros 8031 ethernet
> [2.317945] cpsw 4a10.ethernet: Detected MACID =
> 00:18:32:60:8e:38
> 
> * 19:06 < nchauvet> btw with this dmesg, I've tried to apply this
> serie: http://marc.info/?l=linux-omap=145032865615589=2, but it
> doesn't seem to work for me (I cannot ping my gateway anymore)

That particular email was about a v1 patch, which was then replaced
by a 3-patch series for v2:
http://marc.info/?l=linux-netdev=145032497014944=2
That is already in linux-next, and below you show that you have it.

> So I've remembered that I've double checked the Ethernet wire, but I
> agree it can also be another random issue.

If it works without this series, but fails with it, that is strong
evidence that something in this series either is a bug or exposes
one.

> > Just to verify, is your linux-next tree up-to-date? This series
> > needs to be applied is based on another recent series of 3 patches
> > to cpsw.c. Although I doubt it would apply cleanly at all without
> > those.
> 
> From my linux-next base, related to cpsw, I have:
> git log --oneline cpsw*
> a6b257c Merge remote-tracking branch 'net-next/master'
> dfc0a6d drivers: net: cpsw: increment reference count on fixed-link
> PHY node 
> f1eea5c drivers: net: cpsw: fix RMII/RGMII mode when used
> with fixed-link PHY
> 1873c58 ethernet:ti:cpsw: fix phy 

RE: [PATCH v2] r8152: fix lockup when runtime PM is enabled

[Alan Stern]

On Wed, 23 Dec 2015, Hayes Wang wrote:

> Oliver Neukum [mailto:oneu...@suse.de]
> > Sent: Wednesday, December 23, 2015 4:20 PM
> [...]
> > No, step (2) does not exist. Calls to suspend() and [reset_]resume()
> > always balance. Usually a driver shouldn't care about system suspend.
> > The way the driver is currently coded will also fail for Port-Power Off.
> 
> It is different with Windows. The Windows would resume the device before
> system suspend, if the system suspend follows the autosuspend.
> 
> Would this be a problem? After system suspend, the device may wake up
> the system when receiving any packet, not only magic packet. The wake
> events are different for system suspend and autosuspend. However, I
> couldn't change the wake event, because the autosuspend occurs first,
> and the suspend() is only called once.

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.

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

[zhuyj]

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 to "speed and duplex". That is, the physical NIC 
reports "link up" while
the speed is unknown at the same time. We can run "ethtool ethx" to 
confirm it.


Any way, thanks a lot.

Zhu Yanjun


If there is a case where link_speed is unknown when entering this function it's 
probably
better to just bail rather than have this hack around the netif_carrier_on() 
especially
after the driver already reported link status change. Rapid link changes can 
occur between
link partners and not just for X540.

Thanks,
Emil



--
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] ipv6: honor ifindex in case we receive ll addresses in router advertisements

[David Miller]

From: Hannes Frederic Sowa 
Date: Wed, 23 Dec 2015 22:44:37 +0100

> Marc Haber reported we don't honor interface indexes when we receive link
> local router addresses in router advertisements. Luckily the non-strict
> version of ipv6_chk_addr already does the correct job here, so we can
> simply use it to lighten the checks and use those addresses by default
> without any configuration change.
> 
> Link: 
> Reported-by: Marc Haber 
> Cc: Marc Haber 
> Signed-off-by: Hannes Frederic Sowa 

Applied, thanks Hannes.
--
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 0/5] sfc: additional virtual function support​

[David Miller]

From: Bert Kenward 
Date: Wed, 23 Dec 2015 08:55:12 +

> This introduces the client side of a mechanism to defer authorisation of
> operations, for example multicast subscription. Although primarily aimed at
> SRIOV VFs this can also apply to unprivileged PFs.
> 
> Also handle reboot ordering corner cases better and reduce the level of some
> logging.
> 
> v2: remove #ifdef DEBUG around new WARN_ON in mcdi.c.

Series applied, 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

Re: [PATCH net-next] dsa: mv88e6xxx: Add Second back of statistics

[David Miller]

From: Andrew Lunn 
Date: Wed, 23 Dec 2015 13:23:17 +0100

> The 6320 family of switch chips has a second bank for statistics, but
> is missing three statistics in the port registers. Generalise and
> extend the code:
> 
> * adding a field to the statistics table indicating the bank/register
>   set where each statistics is.
> * add a function indicating if an individual statistics
>   is available on this device
> * calculate at run time the sset_count.
> * return strings based on the available statistics of the device
> * return statistics based on the available statistics of the device
> * Add support for reading from the second bank.
> 
> Signed-off-by: Andrew Lunn 

Applied, 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

Re: [PATCH 1/2] bonding: drop unused to_dev macro in bond_sysfs.c

[David Miller]

From: Geliang Tang 
Date: Wed, 23 Dec 2015 20:42:20 +0800

> to_dev is not used anymore so drop it.
> 
> Signed-off-by: Geliang Tang 

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 2/2] bridge: use kobj_to_dev instead of to_dev

[David Miller]

From: Geliang Tang 
Date: Wed, 23 Dec 2015 20:42:21 +0800

> kobj_to_dev has been defined in linux/device.h, so I replace to_dev
> with it.
> 
> Signed-off-by: Geliang Tang 

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 v2] geneve: initialize needed_headroom

[David Miller]

From: Paolo Abeni 
Date: Wed, 23 Dec 2015 16:54:27 +0100

> Currently the needed_headroom field for the geneve device is left
> to the default value.
> 
> This patch set it to space required for basic geneve encapsulation,
> so that we can avoid the skb head re-allocation on xmit.
> 
> This give a 6% speedup for unsegment traffic on geneve tunnel.
> 
> v1 -> v2:
>   - add ETH_HLEN for the lower device to the needed headroom
> 
> Signed-off-by: Paolo Abeni 
> Acked-by: Hannes Frederic Sowa 

Applied, thank you.
--
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 1/1] phy: micrel: Fix finding PHY properties in MAC node for KSZ9031.

[David Miller]

From: Henri Roosen 
Date: Wed, 23 Dec 2015 11:42:29 +0100

> + do {
> + of_node = dev_walker->of_node;
> + dev_walker = dev_walker->parent;
> +
> + } while (!of_node && dev_walker);

Please remove the unnecessary empty line in this loop.

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

Re: [PATCH net-next 0/9] Update support for T6 adapters

[David Miller]

From: Hariprasad Shenai 
Date: Wed, 23 Dec 2015 22:47:10 +0530

> This patch changes updates the various code changes related to
> register, stats and hardware related changes for T6 family of
> adapters.
> 
> This patch series has been created against net-next tree and includes
> patches on cxgb4 and cxgb4vf driver.
> 
> We have included all the maintainers of respective drivers. Kindly review
> the change and let us know in case of any review comments.

Series applied, 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

Re: [PATCH net,stable] net: cdc_ncm: avoid changing RX/TX buffers on MTU changes

[David Miller]

From: Bjørn Mork 
Date: Wed, 23 Dec 2015 13:42:43 +0100

> NCM buffer sizes are negotiated with the device independently of
> the network device MTU.  The RX buffers are allocated by the
> usbnet framework based on the rx_urb_size value set by cdc_ncm. A
> single RX buffer can hold a number of MTU sized packets.
> 
> The default usbnet change_mtu ndo only modifies rx_urb_size if it
> is equal to hard_mtu.  And the cdc_ncm driver will set rx_urb_size
> and hard_mtu independently of each other, based on dwNtbInMaxSize
> and dwNtbOutMaxSize respectively. It was therefore assumed that
> usbnet_change_mtu() would never touch rx_urb_size.  This failed to
> consider the case where dwNtbInMaxSize and dwNtbOutMaxSize happens
> to be equal.
> 
> Fix by implementing an NCM specific change_mtu ndo, modifying the
> netdev MTU without touching the buffer size settings.
> 
> Signed-off-by: Bjørn Mork 

Applied and queued up for -stable, 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

Re: [PATCH net-next v2] ip_tunnel: Move stats update to iptunnel_xmit()

[Pravin Shelar]

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 = >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.
--
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

[David Rivshin (Allworx)]

On Wed, 23 Dec 2015 19:35:37 +0100
Markus Brunner  wrote:

> On Wednesday 23 December 2015 12:04:25 David Miller wrote:
> > From: "David Rivshin (Allworx)" 
> > Date: Tue, 22 Dec 2015 19:36:31 -0500
> > 
> > > Testing by anyone who has real hardware using phy-handle or
> > > dual_emac with fixed-link would be appreciated.
> > 
> > I'm going to wait for such testing before applying this series.
> > 
> > Thanks.
> 
> Successfully tested the following 3 configurations.
> 1. emac0 with phy_id and emac1 with fixed phy
> 2. emac0 with phy-handle and emac1 with fixed phy
> 3. emac0 with fixed phy and emac1 with fixed phy

Great, thanks for testing. Using the same technique
for the phy-handle case as you, I also just tested:
 - (EVMSK) dual emac, phy-handle property in both slaves

I think that covers all the interesting cases.

Dave,
 I actually just received a note off-list reporting a problem  
with this series on the dm8148-t410 board. So please hold off  
applying this series for now. If it turns out to be a real  
problem I'll have a v2. 

[...]

> _mdio {
>   status = "okay";
>   phy0: ethernet-phy@0 {
>   reg = <5>;
>   };
> };

I was unaware that the davinci-mdio driver creates PHY devices
from child nodes. The davinci-mdio.txt binding documentation 
makes no mention of that. By comparison the emac_rockchip.txt 
file does talk about it.

Now that I take a closer look at the code, it looks like that 
capability was added in commit 0a0ea0687281 ("net: davinci_mdio: 
allow to create phys from dt"), but it didn't update the binding.

Grygorii, was that just an oversight, or capability that's not
supposed to be used? 

--
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] openvswitch: Fix template leak in error cases.

[Joe Stringer]

Commit 5b48bb8506c5 ("openvswitch: Fix helper reference leak") fixed a
reference leak on helper objects, but inadvertently introduced a leak on
the ct template.

Previously, ct_info.ct->general.use was initialized to 0 by
nf_ct_tmpl_alloc() and only incremented when ovs_ct_copy_action()
returned successful. If an error occurred while adding the helper or
adding the action to the actions buffer, the __ovs_ct_free_action()
cleanup would use nf_ct_put() to free the entry; However, this relies on
atomic_dec_and_test(ct_info.ct->general.use). This reference must be
incremented first, or nf_ct_put() will never free it.

Fix the issue by acquiring a reference to the template immediately after
allocation.

Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
Fixes: 5b48bb8506c5 ("openvswitch: Fix helper reference leak")
Signed-off-by: Joe Stringer 
---
 net/openvswitch/conntrack.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 8fc1bafc99fd..c6d8738d6970 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -683,6 +683,10 @@ int ovs_ct_copy_action(struct net *net, const struct 
nlattr *attr,
OVS_NLERR(log, "Failed to allocate conntrack template");
return -ENOMEM;
}
+
+   __set_bit(IPS_CONFIRMED_BIT, _info.ct->status);
+   nf_conntrack_get(_info.ct->ct_general);
+
if (helper) {
err = ovs_ct_add_helper(_info, helper, key, log);
if (err)
@@ -694,8 +698,6 @@ int ovs_ct_copy_action(struct net *net, const struct nlattr 
*attr,
if (err)
goto err_free_ct;
 
-   __set_bit(IPS_CONFIRMED_BIT, _info.ct->status);
-   nf_conntrack_get(_info.ct->ct_general);
return 0;
 err_free_ct:
__ovs_ct_free_action(_info);
-- 
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

Re: [PATCH RFC 00/28] DSA: Restructure probing

[Florian Fainelli]

Le 23/12/2015 14:33, Andrew Lunn a écrit :
> On Wed, Dec 23, 2015 at 12:44:59PM -0800, Florian Fainelli wrote:
>> Hi Andrew,
>>
>> Le 23/12/2015 04:56, Andrew Lunn a écrit :
>>> As noted in Documentation/networking/dsa/dsa.txt, the current DSA
>>> architecture has a few architecture problems:
>>>
>>> DSA is implemented as a DSA platform device driver which is convenient 
>>> because
>>> it will register the entire DSA switch tree attached to a master network 
>>> device
>>> in one-shot, facilitating the device creation and simplifying the device 
>>> driver
>>> model a bit, this comes however with a number of limitations:
>>>
>>> - building DSA and its switch drivers as modules is currently not working
>>> - the device driver parenting does not necessarily reflect the original
>>>   bus/device the switch can be created from
>>> - supporting non-MDIO and non-MMIO (platform) switches is not possible
>>>
>>> This RFC patchset attempts to address this. It allows the switch
>>> device to be true Linux devices, and use of the device component
>>> framework to bind the switch devices to the DSA framework, similar to
>>> the way GPU engines are bound to the master GPU driver. The drivers
>>> are now modules, which can be loaded and unloaded. Reloading however
>>> currently causes an Opps, hence RFC.
>>>
>>> The code remains backwards compatible with the old binding, and adds a
>>> new property to facilitate the component framework. Switch drivers get
>>> there own binding, allowing them to be probed independent of DSA.
> 
> Hi Florian
> 
>> Well, sort of, and that is the part that gives me mixed feelings right
>> now. Your conversion of the bcm_sf2 driver, although it looks good and
>> gets us where we should go, still poses a major problem for my platforms
>> where a wrong DTB is frozen (at least for some time).
> 
> I hope i've not broken backwards compatibility, so your old DT blobs
> should still work. If they don't work, we should debug why.
> 
>> I still think that using a 'dsa' platform device and having to bind
>> other drivers to it is just an artifact and relic from the original
>> design that we do not necessarily need anymore but with the components
>> framework, it seems to get us in a better shape.
> 
> I don't really see how we can do without a dsa platform driver. We
> need something that brings together all the switches in a cluster. We
> need somewhere which holds the information about how these switches
> are connected together and connected to the host.

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".

So for the first switch in tree:
- master network device has no dsa_ptr assigned yet, allocate
dsa_platform_data and this switch's platform data, assign dev->dsa_ptr
so subsequent switches can be attached

For secondary switches in tree:
- locate their index, fetch the master network device dsa_ptr and add
them to the switch tree

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:

https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-4.3/710-phy-add-mdio_register_board_info.patch

Does that make sense?
-- 
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: [PATCH RFC 00/28] DSA: Restructure probing

[Florian Fainelli]

Hi Andrew,

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> As noted in Documentation/networking/dsa/dsa.txt, the current DSA
> architecture has a few architecture problems:
> 
> DSA is implemented as a DSA platform device driver which is convenient because
> it will register the entire DSA switch tree attached to a master network 
> device
> in one-shot, facilitating the device creation and simplifying the device 
> driver
> model a bit, this comes however with a number of limitations:
> 
> - building DSA and its switch drivers as modules is currently not working
> - the device driver parenting does not necessarily reflect the original
>   bus/device the switch can be created from
> - supporting non-MDIO and non-MMIO (platform) switches is not possible
> 
> This RFC patchset attempts to address this. It allows the switch
> device to be true Linux devices, and use of the device component
> framework to bind the switch devices to the DSA framework, similar to
> the way GPU engines are bound to the master GPU driver. The drivers
> are now modules, which can be loaded and unloaded. Reloading however
> currently causes an Opps, hence RFC.
> 
> The code remains backwards compatible with the old binding, and adds a
> new property to facilitate the component framework. Switch drivers get
> there own binding, allowing them to be probed independent of DSA.

Well, sort of, and that is the part that gives me mixed feelings right
now. Your conversion of the bcm_sf2 driver, although it looks good and
gets us where we should go, still poses a major problem for my platforms
where a wrong DTB is frozen (at least for some time).

I would very much like to make it possible for the bcm_sf2 driver to be
a real platform driver, call into dsa_switch_register(), yet remain
compatible with the old binding by using dsa_of_probe(), it could be
based on the compatible string we get probed with, it could be up to the
caller or the callee to attempt both bindings to be parsed etc.

I still think that using a 'dsa' platform device and having to bind
other drivers to it is just an artifact and relic from the original
design that we do not necessarily need anymore but with the components
framework, it seems to get us in a better shape.

That being said, thanks a lot for getting the patches out!
-- 
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: [PATCH RFC 28/28] dsa: Destroy fixed link phys after the phy has been disconnected

[Florian Fainelli]

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> The phy is disconnected from the slave in dsa_slave_destroy(). Don't
> destroy fixed link phys until after this, since there can be fixed
> linked phys connected to ports.
> 
> Signed-off-by: Andrew Lunn 

Acked-by: Florian Fainelli 
-- 
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: [PATCH 0/3] drivers: net: cpsw: phy-handle fixes

[David Rivshin (Allworx)]

On Wed, 23 Dec 2015 22:20:58 +0100
Nicolas Chauvet  wrote:

> 2015-12-23 1:36 GMT+01:00 David Rivshin (Allworx) <
> drivshin.allw...@gmail.com>:
> 
> > From: David Rivshin 
> >
> > This series is based on the tip of the net tree.
> >
> > The first patch fixes a bug that makes dual_emac mode break if
> > either slave uses the phy-handle property in the devicetree.
> >
> > The second patch fixes some cosmetic problems with error messages,
> > and also makes the binding documentation more explicit.
> >
> > The third patch cleans up the fixed-link case to work like
> > the now-fixed phy-handle case.
> >
> > I have tested on the following hardware configurations:
> >  - (EVMSK) dual emac, phy_id property in both slaves
> >  - (BeagleBoneBlack) single emac, phy_id property
> >  - (custom) single emac, fixed-link subnode
> > Note that I don't have a board which would uses a phy-handle
> > property, though I have used hacked devicetrees to exercise the
> > code paths. Testing by anyone who has real hardware using
> > phy-handle or dual_emac with fixed-link would be appreciated.
> >
> > David Rivshin (3):
> >   drivers: net: cpsw: fix parsing of phy-handle DT property in
> > dual_emac config
> >   drivers: net: cpsw: fix error messages when using phy-handle DT
> > property
> >   drivers: net: cpsw: use of_phy_connect() in fixed-link case
> >
> >  Documentation/devicetree/bindings/net/cpsw.txt |  4 +--
> >  drivers/net/ethernet/ti/cpsw.c | 40
> > +-
> >  drivers/net/ethernet/ti/cpsw.h |  1 +
> >  3 files changed, 23 insertions(+), 22 deletions(-)
> >
> >
> This serie failed with me on dm8418 hp-t410 on top of linux-next from
> today whereas the same patch level and same methods without this
> serie is working fine.
> I wasn't able to ping anything on a minimal rootfs with static ip set
> from cmdline from kernel.
> 
> Sorry for  the lack of details, feel free to add me to any other
> revision of the patch if any.
> I will be able to do more testing next month.

(Sorry for the duplicate, doing a reply-all this time. Not sure why it 
looked like a non-list email the first time)

Thanks for testing. I found the dm8148-t410.dts devicetree in the
kernel source, and it uses the phy_id for both slaves, just like the
EVMSK board I tested. So I can't think of an obvious reason for the
problem. 
Would you be able to send the 'dmesg' log from right after bootup? 
I'm hoping there is an error message in there with some clue.

Just to verify, is your linux-next tree up-to-date? This series needs
to be applied is based on another recent series of 3 patches to cpsw.c. 
Although I doubt it would apply cleanly at all without those.

--
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

[Andrew Lunn]

On Wed, Dec 23, 2015 at 12:44:59PM -0800, Florian Fainelli wrote:
> Hi Andrew,
> 
> Le 23/12/2015 04:56, Andrew Lunn a écrit :
> > As noted in Documentation/networking/dsa/dsa.txt, the current DSA
> > architecture has a few architecture problems:
> > 
> > DSA is implemented as a DSA platform device driver which is convenient 
> > because
> > it will register the entire DSA switch tree attached to a master network 
> > device
> > in one-shot, facilitating the device creation and simplifying the device 
> > driver
> > model a bit, this comes however with a number of limitations:
> > 
> > - building DSA and its switch drivers as modules is currently not working
> > - the device driver parenting does not necessarily reflect the original
> >   bus/device the switch can be created from
> > - supporting non-MDIO and non-MMIO (platform) switches is not possible
> > 
> > This RFC patchset attempts to address this. It allows the switch
> > device to be true Linux devices, and use of the device component
> > framework to bind the switch devices to the DSA framework, similar to
> > the way GPU engines are bound to the master GPU driver. The drivers
> > are now modules, which can be loaded and unloaded. Reloading however
> > currently causes an Opps, hence RFC.
> > 
> > The code remains backwards compatible with the old binding, and adds a
> > new property to facilitate the component framework. Switch drivers get
> > there own binding, allowing them to be probed independent of DSA.

Hi Florian

> Well, sort of, and that is the part that gives me mixed feelings right
> now. Your conversion of the bcm_sf2 driver, although it looks good and
> gets us where we should go, still poses a major problem for my platforms
> where a wrong DTB is frozen (at least for some time).

I hope i've not broken backwards compatibility, so your old DT blobs
should still work. If they don't work, we should debug why.

> I still think that using a 'dsa' platform device and having to bind
> other drivers to it is just an artifact and relic from the original
> design that we do not necessarily need anymore but with the components
> framework, it seems to get us in a better shape.

I don't really see how we can do without a dsa platform driver. We
need something that brings together all the switches in a cluster. We
need somewhere which holds the information about how these switches
are connected together and connected to the host.

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 0/2] ppp: add netlink support

[Guillaume Nault]

On Wed, Dec 23, 2015 at 09:04:46PM +0100, Guillaume Nault wrote:
> This series adds netlink support for creating PPP devices.
> 
And I forgot to mention that it applies to net-next. Sorry.
--
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 1/2] openvswitch: Fix helper reference leak

[Joe Stringer]

On 9 December 2015 at 15:33, Pravin Shelar  wrote:
> On Wed, Dec 9, 2015 at 3:10 PM, Joe Stringer  wrote:
>> On 9 December 2015 at 14:50, Pravin Shelar  wrote:
>>> On Wed, Dec 9, 2015 at 2:07 PM, Joe Stringer  wrote:
 If the actions (re)allocation fails, or the actions list is larger than the
 maximum size, and the conntrack action is the last action when these
 problems are hit, then references to helper modules may be leaked. Fix
 the issue.

 Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
 Signed-off-by: Joe Stringer 
 ---
  net/openvswitch/conntrack.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
 index c2cc11168fd5..585a5aa81f89 100644
 --- a/net/openvswitch/conntrack.c
 +++ b/net/openvswitch/conntrack.c
 @@ -53,6 +53,8 @@ struct ovs_conntrack_info {
 struct md_labels labels;
  };

 +static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info);
 +
  static u16 key_to_nfproto(const struct sw_flow_key *key)
  {
 switch (ntohs(key->eth.type)) {
 @@ -708,7 +710,7 @@ int ovs_ct_copy_action(struct net *net, const struct 
 nlattr *attr,
 nf_conntrack_get(_info.ct->ct_general);
>>>
>>> I see another issue here. Updates to ct_info are done after it is
>>> copied to action list. ct action on the action list and ct_info are
>>> inconsistent, So it is still leaking nf-conntrack reference.
>>
>> You're referring to the below?
>>
>>  __set_bit(IPS_CONFIRMED_BIT, _info.ct->status);
>>  nf_conntrack_get(_info.ct->ct_general);
>>
>> ct_info.ct points to the same location as the version that has been
>> copied into the action list. I agree it's a bit misleading though. If
>> you're not seeing something else, it seems cosmetic so I can (should?)
>> follow up on net-next.
>
> Right, there is no leak, cosmetic changes can be done later. I do not
> have problem with this patch as it is.
>
> Acked-by: Pravin B Shelar 

Turns out that there wasn't a leak on nf-conntrack, but on the
template. I sent a 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

Re: [PATCH RFC 19/28] net: dsa: bcm_sf2: make it a real platform driver

[Florian Fainelli]

Hi Andrew,

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> diff --git a/Documentation/devicetree/bindings/net/dsa/broadcom.txt 
> b/Documentation/devicetree/bindings/net/dsa/broadcom.txt
> new file mode 100644
> index ..bd92be0ef2c8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/broadcom.txt
> @@ -0,0 +1,48 @@
> +* Broadcom Starfighter 2 integrated switch device
> +
> +Required properties:
> +
> +- compatible: should be "brcm,brcm-sf2"
> +- reg: addresses and length of the register sets for the device, must be 6
> +  pairs of register addresses and lengths
> +- interrupts: interrupts for the devices, must be two interrupts
> +
> +Optional properties:
> +
> +- reg-names: litteral names for the device base register addresses,
> +  when present must be: "core", "reg", "intrl2_0", "intrl2_1", "fcb",
> +  "acb"

These are in fact mandatory properties.

> +
> +- interrupt-names: litternal names for the device interrupt lines,
> +  when present must be: "switch_0" and "switch_1"

Likewise

> +
> +- brcm,num-gphy: specify the maximum number of integrated gigabit PHYs
> +  in the switch

Likewise

> +
> +- brcm,num-rgmii-ports: specify the maximum number of RGMII interfaces
> +  supported by the switch
> +
> +- brcm,fcb-pause-override: boolean property, if present indicates that
> +  the switch supports Failover Control Block pause override capability
> +
> +- brcm,acb-packets-inflight: boolean property, if present indicates
> +  that the switch Admission Control Block supports reporting the
> +  number of packets in-flight in a switch queue

All of these above are indeed optional.

Having to introduce a new binding for this driver to be converted is a
major deal breaker, the platforms I use have a frozen, yet wrongly
specified Device Tree binding, but still, we need to keep backward
compatibility with it.

My initial attempt, if you remove the part where I tried to convert
every switch driver into a PHY device handled that:

https://github.com/ffainelli/linux/commit/287fc1b33cdd6155c507a95531fd820a5c6dbaf4

Since we have dsa_of_probe(), that alone should be enough to allow us to
maintain a dsa_platform_data structure along with the old binding. This
is not a whole lot different from your patch 13.

Thanks!
-- 
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: [PATCH RFC 21/28] net: dsa: Add some debug prints for error cases

[Florian Fainelli]

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> Due to the complexity it can be hard to know why DSA fails to probe.
> Add some debug prints for the common error cases.
> 
> Signed-off-by: Andrew Lunn 

Acked-by: Florian Fainelli 

I had something similar here since, thanks!
-- 
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: [PATCH RFC 12/28] net: dsa: Make dsa,mii-bus optional

[Florian Fainelli]

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> When all the switches are devices and register to the DSA framework,
> having a dsa,mii-bus property is not required.
> 
> Signed-off-by: Andrew Lunn 

Acked-by: Florian Fainelli 
-- 
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: [iproute PATCH v3 1/2] libnetlink: add a variant of rtnl_send_check that consumes ACKs

[Stephen Hemminger]

On Tue, 22 Dec 2015 17:31:33 +0900
Lorenzo Colitti  wrote:

> The new variant is identical to rtnl_send_check, except it also
> consumes the kernel response instead of using MSG_PEEK. This is
> useful for callers that send simple commands that never cause a
> response but only ACKs, and that expect to receive and deal
> with errors without printing them to stderr like rtnl_talk does.
> 
> Signed-off-by: Lorenzo Colitti 

Originally, iproute2 used netlink so that every request had an ACK and
this is the API in rtnl_talk. Then as an optimization it was observed
that ACK from kernel is not necessary (all error reports are handled in
send), but that for some asynchronous errors a check was necessary.

Therefore, I wonder why you need this, either:
 * don't ask kernel for ACK's (like most other ip commands),
 * or use rtnl_talk() and expect ACK.



--
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] mac802154: constify ieee802154_llsec_ops structure

[Julia Lawall]

The ieee802154_llsec_ops structure is never modified, so declare it as
const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 include/net/ieee802154_netdev.h |2 +-
 net/mac802154/mac_cmd.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index a62a051..c4b3160 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -337,7 +337,7 @@ struct ieee802154_mlme_ops {
void (*get_mac_params)(struct net_device *dev,
   struct ieee802154_mac_params *params);
 
-   struct ieee802154_llsec_ops *llsec;
+   const struct ieee802154_llsec_ops *llsec;
 };
 
 static inline struct ieee802154_mlme_ops *
diff --git a/net/mac802154/mac_cmd.c b/net/mac802154/mac_cmd.c
index 8606da4..3db1634 100644
--- a/net/mac802154/mac_cmd.c
+++ b/net/mac802154/mac_cmd.c
@@ -126,7 +126,7 @@ static void mac802154_get_mac_params(struct net_device *dev,
params->lbt = wpan_dev->lbt;
 }
 
-static struct ieee802154_llsec_ops mac802154_llsec_ops = {
+static const struct ieee802154_llsec_ops mac802154_llsec_ops = {
.get_params = mac802154_get_params,
.set_params = mac802154_set_params,
.add_key = mac802154_add_key,

--
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 25/28] Documentation: DSA: Describe how probe of DSA and switches work.

[Andrew Lunn]

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.

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?

 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] sctp: label accepted/peeled off sockets

[Paul Moore]

On Wednesday, December 23, 2015 04:44:09 PM Marcelo Ricardo Leitner wrote:
> From: Marcelo Ricardo Leitner 
> 
> Accepted or peeled off sockets were missing a security label (e.g.
> SELinux) which means that socket was in "unlabeled" state.
> 
> This patch clones the sock's label from the parent sock and resolves the
> issue (similar to AF_BLUETOOTH protocol family).
> 
> Cc: Paul Moore 
> Cc: David Teigland 
> Signed-off-by: Marcelo Ricardo Leitner 
> ---
>  net/sctp/socket.c | 2 ++
>  1 file changed, 2 insertions(+)

[NOTE: added the LSM and SELinux lists to the CC line as a FYI]

Proper SCTP support is on the SELinux todo list, but in the meantime it looks 
like the patch below should at least ensure that SCTP sockets inherit their 
parent's label which is probably the best we can hope for right now.

Acked-by: Paul Moore 

> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index
> 400a14d744834c7a503b338bc68f5f8b5b5dae8e..b67162767b7957b3e9f4f7bf52ab51fc1
> a3499c8 100644 --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -7202,6 +7202,8 @@ void sctp_copy_sock(struct sock *newsk, struct sock
> *sk,
> 
>   if (newsk->sk_flags & SK_FLAGS_TIMESTAMP)
>   net_enable_timestamp();
> +
> + security_sk_clone(sk, newsk);
>  }
> 
>  static inline void sctp_copy_descendant(struct sock *sk_to,

-- 
paul moore
www.paul-moore.com

--
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 2/2] ppp: implement rtnetlink device handling

[Guillaume Nault]

Define PPP device handler for use with rtnetlink.

The only PPP specific attribute is IFLA_PPP_DEV_FD. It is mandatory and
contains the file descriptor of the associated /dev/ppp instance (the
file descriptor which would have been used for ioctl(PPPIOCNEWUNIT) in
the ioctl-based API).

PPP devices created with the rtnetlink API behave like the ones created
with ioctl(PPPIOCNEWUNIT). In particular existing ioctls still apply to
PPP units created with the rtnetlink API.

Signed-off-by: Guillaume Nault 
---
 drivers/net/ppp/ppp_generic.c | 109 --
 include/uapi/linux/if_link.h  |   8 
 2 files changed, 113 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index bc24537..19476d6 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -185,7 +186,9 @@ struct channel {
 
 struct ppp_config {
struct file *file;
+   s32 fd;
s32 unit;
+   bool ifname_is_set;
 };
 
 /*
@@ -286,6 +289,7 @@ static int unit_get(struct idr *p, void *ptr);
 static int unit_set(struct idr *p, void *ptr, int n);
 static void unit_put(struct idr *p, int n);
 static void *unit_find(struct idr *p, int n);
+static void ppp_setup(struct net_device *dev);
 
 static const struct net_device_ops ppp_netdev_ops;
 
@@ -954,7 +958,7 @@ static struct pernet_operations ppp_net_ops = {
.size = sizeof(struct ppp_net),
 };
 
-static int ppp_unit_register(struct ppp *ppp, int unit)
+static int ppp_unit_register(struct ppp *ppp, int unit, bool ifname_is_set)
 {
struct ppp_net *pn = ppp_pernet(ppp->ppp_net);
int ret;
@@ -984,7 +988,8 @@ static int ppp_unit_register(struct ppp *ppp, int unit)
 
ppp->file.index = ret;
 
-   snprintf(ppp->dev->name, IFNAMSIZ, "ppp%i", ppp->file.index);
+   if (!ifname_is_set)
+   snprintf(ppp->dev->name, IFNAMSIZ, "ppp%i", ppp->file.index);
 
ret = register_netdevice(ppp->dev);
if (ret)
@@ -1012,7 +1017,24 @@ static int ppp_dev_configure(struct net *src_net, struct 
net_device *dev,
int indx;
int err;
 
-   file = conf->file;
+   if (conf->fd >= 0) {
+   file = fget(conf->fd);
+   if (file) {
+   if (file->f_op != _device_fops) {
+   fput(file);
+   return -EBADF;
+   }
+
+   /* Don't hold reference on file: ppp_release() is
+* responsible for safely freeing the associated
+* resources upon release. So file won't go away
+* from under us.
+*/
+   fput(file);
+   }
+   } else {
+   file = conf->file;
+   }
if (!file)
return -EBADF;
if (file->private_data)
@@ -1040,7 +1062,7 @@ static int ppp_dev_configure(struct net *src_net, struct 
net_device *dev,
ppp->mru = PPP_MRU;
ppp->ppp_net = src_net;
 
-   err = ppp_unit_register(ppp, conf->unit);
+   err = ppp_unit_register(ppp, conf->unit, conf->ifname_is_set);
if (err < 0)
return err;
 
@@ -1049,6 +1071,73 @@ static int ppp_dev_configure(struct net *src_net, struct 
net_device *dev,
return 0;
 }
 
+static const struct nla_policy ppp_nl_policy[IFLA_PPP_MAX + 1] = {
+   [IFLA_PPP_DEV_FD]   = { .type = NLA_S32 },
+};
+
+static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[])
+{
+   if (!data)
+   return -EINVAL;
+
+   if (!data[IFLA_PPP_DEV_FD])
+   return -EINVAL;
+   if (nla_get_s32(data[IFLA_PPP_DEV_FD]) < 0)
+   return -EBADF;
+
+   return 0;
+}
+
+static int ppp_nl_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+   struct ppp_config conf = {
+   .file = NULL,
+   .unit = -1,
+   .ifname_is_set = true,
+   };
+
+   conf.fd = nla_get_s32(data[IFLA_PPP_DEV_FD]);
+
+   return ppp_dev_configure(src_net, dev, );
+}
+
+static void ppp_nl_dellink(struct net_device *dev, struct list_head *head)
+{
+   unregister_netdevice_queue(dev, head);
+}
+
+static size_t ppp_nl_get_size(const struct net_device *dev)
+{
+   return 0;
+}
+
+static int ppp_nl_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+   return 0;
+}
+
+static struct net *ppp_nl_get_link_net(const struct net_device *dev)
+{
+   struct ppp *ppp = netdev_priv(dev);
+
+   return ppp->ppp_net;
+}
+
+static struct rtnl_link_ops ppp_link_ops __read_mostly = {
+   .kind   = "ppp",
+   .maxtype= IFLA_PPP_MAX,
+   .policy = ppp_nl_policy,
+   

[PATCH 0/2] ppp: add netlink support

[Guillaume Nault]

This series adds netlink support for creating PPP devices.

It doesn't implement any PPP specific attribute beyond IFLA_PPP_DEV_FD,
which is necessary in the PPP device model for passing control plane
packets to user space.

Guillaume Nault (2):
  ppp: define reusable device creation functions
  ppp: implement rtnetlink device handling

 drivers/net/ppp/ppp_generic.c | 319 ++
 include/uapi/linux/if_link.h  |   8 ++
 2 files changed, 237 insertions(+), 90 deletions(-)

-- 
2.6.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 1/2] ppp: define reusable device creation functions

[Guillaume Nault]

Move PPP device initialisation and registration out of
ppp_create_interface().
This prepares code for device registration with rtnetlink.

While there, cleanup ppp_create_interface() prototype to return an
error code rather than the ppp structure. The unit parameter is now
read/write so that caller can retrieve the unit identifier without
accessing the new ppp structure.

Signed-off-by: Guillaume Nault 
---
 drivers/net/ppp/ppp_generic.c | 216 +-
 1 file changed, 127 insertions(+), 89 deletions(-)

diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index fc8ad00..bc24537 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -183,6 +183,11 @@ struct channel {
 #endif /* CONFIG_PPP_MULTILINK */
 };
 
+struct ppp_config {
+   struct file *file;
+   s32 unit;
+};
+
 /*
  * SMP locking issues:
  * Both the ppp.rlock and ppp.wlock locks protect the ppp.channels
@@ -269,8 +274,7 @@ static void ppp_ccp_peek(struct ppp *ppp, struct sk_buff 
*skb, int inbound);
 static void ppp_ccp_closed(struct ppp *ppp);
 static struct compressor *find_compressor(int type);
 static void ppp_get_stats(struct ppp *ppp, struct ppp_stats *st);
-static struct ppp *ppp_create_interface(struct net *net, int unit,
-   struct file *file, int *retp);
+static int ppp_create_interface(struct net *net, int *unit, struct file *file);
 static void init_ppp_file(struct ppp_file *pf, int kind);
 static void ppp_destroy_interface(struct ppp *ppp);
 static struct ppp *ppp_find_unit(struct ppp_net *pn, int unit);
@@ -842,12 +846,13 @@ static int ppp_unattached_ioctl(struct net *net, struct 
ppp_file *pf,
/* Create a new ppp unit */
if (get_user(unit, p))
break;
-   ppp = ppp_create_interface(net, unit, file, );
-   if (!ppp)
+
+   err = ppp_create_interface(net, , file);
+   if (err)
break;
-   file->private_data = >file;
+
err = -EFAULT;
-   if (put_user(ppp->file.index, p))
+   if (put_user(unit, p))
break;
err = 0;
break;
@@ -949,6 +954,101 @@ static struct pernet_operations ppp_net_ops = {
.size = sizeof(struct ppp_net),
 };
 
+static int ppp_unit_register(struct ppp *ppp, int unit)
+{
+   struct ppp_net *pn = ppp_pernet(ppp->ppp_net);
+   int ret;
+
+   mutex_lock(>all_ppp_mutex);
+
+   if (unit < 0) {
+   ret = unit_get(>units_idr, ppp);
+   if (ret < 0)
+   goto err;
+   } else {
+   /* Caller asked for a specific unit number. Fail with -EEXIST
+* if unavailable. For backward compatibility, return -EEXIST
+* too if idr allocation fails; this makes pppd retry without
+* requesting a specific unit number.
+*/
+   if (unit_find(>units_idr, unit)) {
+   ret = -EEXIST;
+   goto err;
+   }
+   ret = unit_set(>units_idr, ppp, unit);
+   if (ret < 0) {
+   ret = -EEXIST; /* rewrite error for backward compat. */
+   goto err;
+   }
+   }
+
+   ppp->file.index = ret;
+
+   snprintf(ppp->dev->name, IFNAMSIZ, "ppp%i", ppp->file.index);
+
+   ret = register_netdevice(ppp->dev);
+   if (ret)
+   goto err_unit;
+
+   atomic_inc(_unit_count);
+
+   mutex_unlock(>all_ppp_mutex);
+
+   return 0;
+
+err_unit:
+   unit_put(>units_idr, ppp->file.index);
+err:
+   mutex_unlock(>all_ppp_mutex);
+
+   return ret;
+}
+
+static int ppp_dev_configure(struct net *src_net, struct net_device *dev,
+const struct ppp_config *conf)
+{
+   struct ppp *ppp = netdev_priv(dev);
+   struct file *file;
+   int indx;
+   int err;
+
+   file = conf->file;
+   if (!file)
+   return -EBADF;
+   if (file->private_data)
+   return -EBUSY;
+
+   init_ppp_file(>file, INTERFACE);
+   ppp->file.hdrlen = PPP_HDRLEN - 2; /* don't count proto bytes */
+   ppp->owner = file;
+
+   for (indx = 0; indx < NUM_NP; ++indx)
+   ppp->npmode[indx] = NPMODE_PASS;
+   INIT_LIST_HEAD(>channels);
+   spin_lock_init(>rlock);
+   spin_lock_init(>wlock);
+#ifdef CONFIG_PPP_MULTILINK
+   ppp->minseq = -1;
+   skb_queue_head_init(>mrq);
+#endif /* CONFIG_PPP_MULTILINK */
+#ifdef CONFIG_PPP_FILTER
+   ppp->pass_filter = NULL;
+   ppp->active_filter = NULL;
+#endif /* CONFIG_PPP_FILTER */
+
+   ppp->dev = dev;
+   ppp->mru = PPP_MRU;
+   ppp->ppp_net = src_net;
+
+   err = ppp_unit_register(ppp, conf->unit);
+   if (err < 0)
+   

Re: [PATCH RFC 06/28] net: dsa: Have the switch driver allocate there own private memory

[Florian Fainelli]

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> Now the switch devices have a dev pointer, make use if it for allocating
> the drivers private data structures using a devm_kzalloc().
> 
> Signed-off-by: Andrew Lunn 
> ---
>  drivers/net/dsa/bcm_sf2.c   |  7 +--
>  drivers/net/dsa/mv88e6123.c |  6 +++---
>  drivers/net/dsa/mv88e6131.c |  6 +++---
>  drivers/net/dsa/mv88e6171.c |  6 +++---
>  drivers/net/dsa/mv88e6352.c |  6 +++---
>  drivers/net/dsa/mv88e6xxx.c | 13 ++---
>  drivers/net/dsa/mv88e6xxx.h |  5 -
>  include/net/dsa.h   |  8 +++-
>  8 files changed, 38 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> index 6925b3c13895..23326c2a01b8 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -929,7 +929,7 @@ static void bcm_sf2_identify_ports(struct bcm_sf2_priv 
> *priv,
>  static int bcm_sf2_sw_setup(struct dsa_switch *ds, struct device *dev)
>  {
>   const char *reg_names[BCM_SF2_REGS_NUM] = BCM_SF2_REGS_NAME;
> - struct bcm_sf2_priv *priv = ds_to_priv(ds);
> + struct bcm_sf2_priv *priv;
>   struct device_node *dn;
>   void __iomem **base;
>   unsigned int port;
> @@ -937,6 +937,10 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds, 
> struct device *dev)
>   u32 reg, rev;
>   int ret;
>  
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;

This looks fine overall, except that part, there is an earlier priv =
ds_to_priv() in the function so we might be missing a ds->priv = priv
here once the allocation is successful.

With that fixed: Acked-by: Florian Fainelli 
-- 
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: [PATCH RFC 07/28] net: dsa: Remove allocation of driver private memory

[Florian Fainelli]

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> The drivers now allocate their own memory for private usage. Remove
> the allocation from the core code.
> 
> Signed-off-by: Andrew Lunn 

Acked-by: Florian Fainelli 
-- 
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: [PATCH RFC 08/28] net: dsa: Keep the mii bus and address in the private structure

[Florian Fainelli]

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> Rather than looking up the mii bus and address every time, do it once
> and setup, and keep it in the private structure.
> 
> Signed-off-by: Andrew Lunn 

Acked-by: Florian Fainelli 
-- 
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: [PATCH RFC 25/28] Documentation: DSA: Describe how probe of DSA and switches work.

[Florian Fainelli]

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.

Thanks!
-- 
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: [PATCH net-next] ip_tunnel: Move stats update to iptunnel_xmit()

[Pravin Shelar]

On Wed, Dec 23, 2015 at 1:49 AM, Nicolas Dichtel
 wrote:
> Le 22/12/2015 01:34, Pravin B Shelar a écrit :
>>
>> 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 
>> ---
>
> [snip]
>>
>> +static inline void iptunnel_xmit_stats(struct net_device *dev, int err)
>>   {
>> if (err > 0) {
>> -   struct pcpu_sw_netstats *tstats = get_cpu_ptr(stats);
>> +   struct pcpu_sw_netstats *tstats =
>> get_cpu_ptr(dev->tstats);
>>
>> u64_stats_update_begin(>syncp);
>> tstats->tx_bytes += err;
>> tstats->tx_packets++;
>> u64_stats_update_end(>syncp);
>> put_cpu_ptr(tstats);
>> -   } else if (err < 0) {
>> +   } else {
>> +   struct net_device_stats *err_stats = >stats;
>> +
>> err_stats->tx_errors++;
>> err_stats->tx_aborted_errors++;
>> -   } else {
>> -   err_stats->tx_dropped++;
>> }
>>   }
>
> Why do you remove the case 'err == 0'?
> At least, it needs an explanation in the commit log.

I wanted to unify all ip_out() error stats under single count, But now
I think it is better to separate that change into another patch. I
will send updated patch without this change.
--
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 24/28] net: dsa: If a switch fails to probe, defer probing

[Florian Fainelli]

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> Switches are either listed in device tree of platform_data. They
> should exist. If the probe fails, defer the probe, which is the likely
> cause of failure, not broken device tree or platform data.
> 
> Signed-off-by: Andrew Lunn 

Acked-by: Florian Fainelli 
-- 
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: [PATCH] netconsole: Initialize after all core networking drivers

[Calvin Owens]

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, nothing actually ends up calling vxlan_open() during