RE: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

[Yuval Mintz]

> Fundamentally I believe that robust, responsive hardware LRO is not workable 
> as
> the hardware would have to decide to hold onto packets in the hope of merge
> candidates arriving soon after.  Whereas in the software layer (GRO,
> bundling...), the packets are already coming in bursts thanks to the way napi
> polling behaves.

Sounds like an additional coalescing configuration to me [assuming HW supports 
it].

[PATCH] geneve: fix max_mtu setting

[Haishuang Yan]

For ipv6+udp+geneve encapsulation data, the max_mtu should subtract
sizeof(ipv6hdr), instead of sizeof(iphdr).

Signed-off-by: Haishuang Yan 
---
 drivers/net/geneve.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index aa61708..c676d23 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -1036,12 +1036,17 @@ static netdev_tx_t geneve_xmit(struct sk_buff *skb, 
struct net_device *dev)
 
 static int __geneve_change_mtu(struct net_device *dev, int new_mtu, bool 
strict)
 {
+   struct geneve_dev *geneve = netdev_priv(dev);
/* The max_mtu calculation does not take account of GENEVE
 * options, to avoid excluding potentially valid
 * configurations.
 */
-   int max_mtu = IP_MAX_MTU - GENEVE_BASE_HLEN - sizeof(struct iphdr)
-   - dev->hard_header_len;
+   int max_mtu = IP_MAX_MTU - GENEVE_BASE_HLEN - dev->hard_header_len;
+
+   if (geneve->remote.sa.sa_family == AF_INET)
+   max_mtu -= sizeof(struct iphdr);
+   else
+   max_mtu -= sizeof(struct ipv6hdr);
 
if (new_mtu < 68)
return -EINVAL;
-- 
1.8.3.1

Re: DMA from stack in virtio_net and virtio_console

[Michael S. Tsirkin]

On Fri, Jun 24, 2016 at 06:45:50PM -0700, Andy Lutomirski wrote:
> virtio_net does DMA on the stack when it calls sg_init_one in
> virtio_set_queues, virtnet_vlan_rx_add_vid, and
> virtnet_vlan_rx_kill_vid.  Michael, I think these are examples we
> missed somehow when fixing these issues earlier on.
> 
> virtio_console does it here:
> 
> sg_init_one(sg, &cpkt, sizeof(cpkt));
> 
> This will cause problems on some architectures (Xen at the very least,
> and it'll cause more subtle problems on other architectures if they
> start using the DMA API), and it will blow up horribly with virtually
> mapped stacks.
> 
> Could you fix these, please?
> 
> Thanks,
> Andy

Will do, thanks for the report.

-- 
MST

Re: [PATCH v2 ethtool 0/2] IPv6 RXNFC

[Ben Hutchings]

On Thu, 2016-03-17 at 19:09 +, Edward Cree wrote:
> This series adds support for steering of IPv6 receive flows.
> 
> Changes since v1:
> * Fixed and simplified IPv6 address and mask parsing
> * Made help text / man page more consistent
> * Dropped ethtool-copy.h patch as upstream is now newer

Applied these two, and added the patch below.  Thanks for your
patience.

Ben.

---
Change IP parameter syntax in documentation to just 'ip-address'

Writing out the IPv4 address syntax repeatedly is not really
necessary, and extending it to cover IPv6 addresses will just make the
documentation harder to read.

Signed-off-by: Ben Hutchings 
---
 ethtool.8.in | 2 +-
 ethtool.c| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/ethtool.8.in b/ethtool.8.in
index 36da10ed6c87..9dc5e252a1dc 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -54,7 +54,7 @@
 .\"
 .\"\(*PA - IP address
 .\"
-.ds PA \fIx\fP\fB.\fP\fIx\fP\fB.\fP\fIx\fP\fB.\fP\fIx\fP
+.ds PA \fIip-address\fP
 .\"
 .\"\(*WO - wol flags
 .\"
diff --git a/ethtool.c b/ethtool.c
index a92137f7f5b1..d04bf9fedafd 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4163,8 +4163,8 @@ static const struct option {
  " [ src %x:%x:%x:%x:%x:%x [m %x:%x:%x:%x:%x:%x] 
]\n"
  " [ dst %x:%x:%x:%x:%x:%x [m %x:%x:%x:%x:%x:%x] 
]\n"
  " [ proto %d [m %x] ]\n"
- " [ src-ip %d.%d.%d.%d [m %d.%d.%d.%d] ]\n"
- " [ dst-ip %d.%d.%d.%d [m %d.%d.%d.%d] ]\n"
+ " [ src-ip IP-ADDRESS [m IP-ADDRESS] ]\n"
+ " [ dst-ip IP-ADDRESS [m IP-ADDRESS] ]\n"
  " [ tos %d [m %x] ]\n"
  " [ tclass %d [m %x] ]\n"
  " [ l4proto %d [m %x] ]\n"

-- 

Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


signature.asc
Description: This is a digitally signed message part

[PATCH] rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code size

[Joe Perches]

This debugging macro can expand to a lot of code.
Make it a function to reduce code size.

(x86-64 defconfig w/ all rtlwifi drivers and allyesconfig)
$ size drivers/net/wireless/realtek/rtlwifi/built-in.o*
   textdata bss dec hex filename
 900083  2004991907 1102489  10d299 
drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.new
1113597  2004991907 1316003  1414a3 
drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.old
1746879  4535038512 2208894  21b47e 
drivers/net/wireless/realtek/rtlwifi/built-in.o.new
2051965  5033118512 2563788  271ecc 
drivers/net/wireless/realtek/rtlwifi/built-in.o.old

Signed-off-by: Joe Perches 
---
 drivers/net/wireless/realtek/rtlwifi/debug.c | 25 +
 drivers/net/wireless/realtek/rtlwifi/debug.h | 17 +
 2 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/debug.c 
b/drivers/net/wireless/realtek/rtlwifi/debug.c
index fd25aba..33905bb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/debug.c
+++ b/drivers/net/wireless/realtek/rtlwifi/debug.c
@@ -48,3 +48,28 @@ void rtl_dbgp_flag_init(struct ieee80211_hw *hw)
/*Init Debug flag enable condition */
 }
 EXPORT_SYMBOL_GPL(rtl_dbgp_flag_init);
+
+#ifdef CONFIG_RTLWIFI_DEBUG
+void _rtl_dbg_trace(struct rtl_priv *rtlpriv, int comp, int level,
+   const char *modname, const char *fmt, ...)
+{
+   if (unlikely((comp & rtlpriv->dbg.global_debugcomponents) &&
+(level <= rtlpriv->dbg.global_debuglevel))) {
+   struct va_format vaf;
+   va_list args;
+
+   va_start(args, fmt);
+
+   vaf.fmt = fmt;
+   vaf.va = &args;
+
+   printk(KERN_DEBUG "%s:%ps:<%lx-%x> %pV",
+  modname, __builtin_return_address(0),
+  in_interrupt(), in_atomic(),
+  &vaf);
+
+   va_end(args);
+   }
+}
+EXPORT_SYMBOL_GPL(_rtl_dbg_trace);
+#endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/debug.h 
b/drivers/net/wireless/realtek/rtlwifi/debug.h
index fc794b3..6156a79 100644
--- a/drivers/net/wireless/realtek/rtlwifi/debug.h
+++ b/drivers/net/wireless/realtek/rtlwifi/debug.h
@@ -174,15 +174,16 @@ do {  
\
}   \
 } while (0)
 
+
+struct rtl_priv;
+
+__printf(5, 6)
+void _rtl_dbg_trace(struct rtl_priv *rtlpriv, int comp, int level,
+   const char *modname, const char *fmt, ...);
+
 #define RT_TRACE(rtlpriv, comp, level, fmt, ...)   \
-do {   \
-   if (unlikely(((comp) & rtlpriv->dbg.global_debugcomponents) &&  \
-((level) <= rtlpriv->dbg.global_debuglevel))) {\
-   printk(KERN_DEBUG KBUILD_MODNAME ":%s():<%lx-%x> " fmt, \
-  __func__, in_interrupt(), in_atomic(),   \
-  ##__VA_ARGS__);  \
-   }   \
-} while (0)
+   _rtl_dbg_trace(rtlpriv, comp, level,\
+  KBUILD_MODNAME, fmt, ##__VA_ARGS__)
 
 #define RTPRINT(rtlpriv, dbgtype, dbgflag, fmt, ...)   \
 do {   \
-- 
2.8.0.rc4.16.g56331f8

[PATCH 2/2] net: ethernet: dwc_eth_qos: use phy_ethtool_{get|set}_link_ksettings

[Philippe Reynes]

There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/synopsys/dwc_eth_qos.c |   26 ++
 1 files changed, 2 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/synopsys/dwc_eth_qos.c 
b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
index 094234f..c14fa91 100644
--- a/drivers/net/ethernet/synopsys/dwc_eth_qos.c
+++ b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
@@ -2524,28 +2524,6 @@ dwceqos_get_stats64(struct net_device *ndev, struct 
rtnl_link_stats64 *s)
return s;
 }
 
-static int
-dwceqos_get_settings(struct net_device *ndev, struct ethtool_cmd *ecmd)
-{
-   struct phy_device *phydev = ndev->phydev;
-
-   if (!phydev)
-   return -ENODEV;
-
-   return phy_ethtool_gset(phydev, ecmd);
-}
-
-static int
-dwceqos_set_settings(struct net_device *ndev, struct ethtool_cmd *ecmd)
-{
-   struct phy_device *phydev = ndev->phydev;
-
-   if (!phydev)
-   return -ENODEV;
-
-   return phy_ethtool_sset(phydev, ecmd);
-}
-
 static void
 dwceqos_get_drvinfo(struct net_device *ndev, struct ethtool_drvinfo *ed)
 {
@@ -2764,8 +2742,6 @@ static void dwceqos_set_msglevel(struct net_device *ndev, 
u32 msglevel)
 }
 
 static struct ethtool_ops dwceqos_ethtool_ops = {
-   .get_settings   = dwceqos_get_settings,
-   .set_settings   = dwceqos_set_settings,
.get_drvinfo= dwceqos_get_drvinfo,
.get_link   = ethtool_op_get_link,
.get_pauseparam = dwceqos_get_pauseparam,
@@ -2779,6 +2755,8 @@ static struct ethtool_ops dwceqos_ethtool_ops = {
.set_eee= dwceqos_set_eee,
.get_msglevel   = dwceqos_get_msglevel,
.set_msglevel   = dwceqos_set_msglevel,
+   .get_link_ksettings = phy_ethtool_get_link_ksettings,
+   .set_link_ksettings = phy_ethtool_set_link_ksettings,
 };
 
 static struct net_device_ops netdev_ops = {
-- 
1.7.4.4

[PATCH 1/2] net: ethernet: dwc_eth_qos: use phydev from struct net_device

[Philippe Reynes]

The private structure contain a pointer to phydev, but the structure
net_device already contain such pointer. So we can remove the pointer
phydev in the private structure, and update the driver to use the
one contained in struct net_device.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/synopsys/dwc_eth_qos.c |   47 +--
 1 files changed, 23 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/synopsys/dwc_eth_qos.c 
b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
index 158213c..094234f 100644
--- a/drivers/net/ethernet/synopsys/dwc_eth_qos.c
+++ b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
@@ -598,7 +598,6 @@ struct net_local {
struct work_struct txtimeout_reinit;
 
phy_interface_t phy_interface;
-   struct phy_device *phy_dev;
struct mii_bus *mii_bus;
 
unsigned int link;
@@ -816,7 +815,7 @@ static int dwceqos_mdio_write(struct mii_bus *bus, int 
mii_id, int phyreg,
 static int dwceqos_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
 {
struct net_local *lp = netdev_priv(ndev);
-   struct phy_device *phydev = lp->phy_dev;
+   struct phy_device *phydev = ndev->phydev;
 
if (!netif_running(ndev))
return -EINVAL;
@@ -850,6 +849,7 @@ static void dwceqos_link_down(struct net_local *lp)
 
 static void dwceqos_link_up(struct net_local *lp)
 {
+   struct net_device *ndev = lp->ndev;
u32 regval;
unsigned long flags;
 
@@ -860,7 +860,7 @@ static void dwceqos_link_up(struct net_local *lp)
dwceqos_write(lp, REG_DWCEQOS_MAC_LPI_CTRL_STATUS, regval);
spin_unlock_irqrestore(&lp->hw_lock, flags);
 
-   lp->eee_active = !phy_init_eee(lp->phy_dev, 0);
+   lp->eee_active = !phy_init_eee(ndev->phydev, 0);
 
/* Check for changed EEE capability */
if (!lp->eee_active && lp->eee_enabled) {
@@ -876,7 +876,8 @@ static void dwceqos_link_up(struct net_local *lp)
 
 static void dwceqos_set_speed(struct net_local *lp)
 {
-   struct phy_device *phydev = lp->phy_dev;
+   struct net_device *ndev = lp->ndev;
+   struct phy_device *phydev = ndev->phydev;
u32 regval;
 
regval = dwceqos_read(lp, REG_DWCEQOS_MAC_CFG);
@@ -903,7 +904,7 @@ static void dwceqos_set_speed(struct net_local *lp)
 static void dwceqos_adjust_link(struct net_device *ndev)
 {
struct net_local *lp = netdev_priv(ndev);
-   struct phy_device *phydev = lp->phy_dev;
+   struct phy_device *phydev = ndev->phydev;
int status_change = 0;
 
if (lp->phy_defer)
@@ -987,7 +988,6 @@ static int dwceqos_mii_probe(struct net_device *ndev)
lp->link= 0;
lp->speed   = 0;
lp->duplex  = DUPLEX_UNKNOWN;
-   lp->phy_dev = phydev;
 
return 0;
 }
@@ -1531,6 +1531,7 @@ static void dwceqos_configure_bus(struct net_local *lp)
 
 static void dwceqos_init_hw(struct net_local *lp)
 {
+   struct net_device *ndev = lp->ndev;
u32 regval;
u32 buswidth;
u32 dma_skip;
@@ -1645,10 +1646,10 @@ static void dwceqos_init_hw(struct net_local *lp)
  regval | DWCEQOS_MAC_CFG_TE | DWCEQOS_MAC_CFG_RE);
 
lp->phy_defer = false;
-   mutex_lock(&lp->phy_dev->lock);
-   phy_read_status(lp->phy_dev);
+   mutex_lock(&ndev->phydev->lock);
+   phy_read_status(ndev->phydev);
dwceqos_adjust_link(lp->ndev);
-   mutex_unlock(&lp->phy_dev->lock);
+   mutex_unlock(&ndev->phydev->lock);
 }
 
 static void dwceqos_tx_reclaim(unsigned long data)
@@ -1898,7 +1899,7 @@ static int dwceqos_open(struct net_device *ndev)
 * hence the unusual init order with phy_start first.
 */
lp->phy_defer = true;
-   phy_start(lp->phy_dev);
+   phy_start(ndev->phydev);
dwceqos_init_hw(lp);
napi_enable(&lp->napi);
 
@@ -1943,7 +1944,7 @@ static int dwceqos_stop(struct net_device *ndev)
 
dwceqos_drain_dma(lp);
dwceqos_reset_hw(lp);
-   phy_stop(lp->phy_dev);
+   phy_stop(ndev->phydev);
 
dwceqos_descriptor_free(lp);
 
@@ -2526,8 +2527,7 @@ dwceqos_get_stats64(struct net_device *ndev, struct 
rtnl_link_stats64 *s)
 static int
 dwceqos_get_settings(struct net_device *ndev, struct ethtool_cmd *ecmd)
 {
-   struct net_local *lp = netdev_priv(ndev);
-   struct phy_device *phydev = lp->phy_dev;
+   struct phy_device *phydev = ndev->phydev;
 
if (!phydev)
return -ENODEV;
@@ -2538,8 +2538,7 @@ dwceqos_get_settings(struct net_device *ndev, struct 
ethtool_cmd *ecmd)
 static int
 dwceqos_set_settings(struct net_device *ndev, struct ethtool_cmd *ecmd)
 {
-   struct net_local *lp = netdev_priv(ndev);
-   struct phy_device *phydev = lp->phy_dev;
+   struct phy_device *phydev = ndev->phydev;
 
if (!phydev)
return -ENODEV;
@@ -2574,17 +2573,17 @@ static int dwceqos_set_pauseparam(struct net_device 
*ndev,
 
lp->flowcontrol.autoneg = pp->a

[PATCH 1/2] net: ethernet: sxgbe: use phydev from struct net_device

[Philippe Reynes]

The private structure contain a pointer to phydev, but the structure
net_device already contain such pointer. So we can remove the pointer
phydev in the private structure, and update the driver to use the
one contained in struct net_device.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h  |1 -
 drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c |   18 ---
 drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c|   32 +--
 3 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h 
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
index 4501964..5cb51b6 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
@@ -475,7 +475,6 @@ struct sxgbe_priv_data {
int rxcsum_insertion;
spinlock_t stats_lock;  /* lock for tx/rx statatics */
 
-   struct phy_device *phydev;
int oldlink;
int speed;
int oldduplex;
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c 
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
index c0981ae..72c9108 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
@@ -147,7 +147,7 @@ static int sxgbe_get_eee(struct net_device *dev,
edata->eee_active = priv->eee_active;
edata->tx_lpi_timer = priv->tx_lpi_timer;
 
-   return phy_ethtool_get_eee(priv->phydev, edata);
+   return phy_ethtool_get_eee(dev->phydev, edata);
 }
 
 static int sxgbe_set_eee(struct net_device *dev,
@@ -172,7 +172,7 @@ static int sxgbe_set_eee(struct net_device *dev,
priv->tx_lpi_timer = edata->tx_lpi_timer;
}
 
-   return phy_ethtool_set_eee(priv->phydev, edata);
+   return phy_ethtool_set_eee(dev->phydev, edata);
 }
 
 static void sxgbe_getdrvinfo(struct net_device *dev,
@@ -185,20 +185,16 @@ static void sxgbe_getdrvinfo(struct net_device *dev,
 static int sxgbe_getsettings(struct net_device *dev,
 struct ethtool_cmd *cmd)
 {
-   struct sxgbe_priv_data *priv = netdev_priv(dev);
-
-   if (priv->phydev)
-   return phy_ethtool_gset(priv->phydev, cmd);
+   if (dev->phydev)
+   return phy_ethtool_gset(dev->phydev, cmd);
 
return -EOPNOTSUPP;
 }
 
 static int sxgbe_setsettings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
-   struct sxgbe_priv_data *priv = netdev_priv(dev);
-
-   if (priv->phydev)
-   return phy_ethtool_sset(priv->phydev, cmd);
+   if (dev->phydev)
+   return phy_ethtool_sset(dev->phydev, cmd);
 
return -EOPNOTSUPP;
 }
@@ -255,7 +251,7 @@ static void sxgbe_get_ethtool_stats(struct net_device *dev,
char *p;
 
if (priv->eee_enabled) {
-   int val = phy_get_eee_err(priv->phydev);
+   int val = phy_get_eee_err(dev->phydev);
 
if (val)
priv->xstats.eee_wakeup_error_n = val;
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c 
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 413ea14a..ea44a24 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -124,12 +124,13 @@ static void sxgbe_eee_ctrl_timer(unsigned long arg)
  */
 bool sxgbe_eee_init(struct sxgbe_priv_data * const priv)
 {
+   struct net_device *ndev = priv->dev;
bool ret = false;
 
/* MAC core supports the EEE feature. */
if (priv->hw_cap.eee) {
/* Check if the PHY supports EEE */
-   if (phy_init_eee(priv->phydev, 1))
+   if (phy_init_eee(ndev->phydev, 1))
return false;
 
priv->eee_active = 1;
@@ -152,12 +153,14 @@ bool sxgbe_eee_init(struct sxgbe_priv_data * const priv)
 
 static void sxgbe_eee_adjust(const struct sxgbe_priv_data *priv)
 {
+   struct net_device *ndev = priv->dev;
+
/* When the EEE has been already initialised we have to
 * modify the PLS bit in the LPI ctrl & status reg according
 * to the PHY link status. For this reason.
 */
if (priv->eee_enabled)
-   priv->hw->mac->set_eee_pls(priv->ioaddr, priv->phydev->link);
+   priv->hw->mac->set_eee_pls(priv->ioaddr, ndev->phydev->link);
 }
 
 /**
@@ -203,7 +206,7 @@ static inline u32 sxgbe_tx_avail(struct sxgbe_tx_queue 
*queue, int tx_qsize)
 static void sxgbe_adjust_link(struct net_device *dev)
 {
struct sxgbe_priv_data *priv = netdev_priv(dev);
-   struct phy_device *phydev = priv->phydev;
+   struct phy_device *phydev = dev->phydev;
u8 new_state = 0;
u8 speed = 0xff;
 
@@ -306,9 +309,6 @@ static int sxgbe_init_phy(struct net_device *ndev)
netdev_dbg(ndev, "%s: attached to PHY (UID 0x%x) Link = %d\n",
   __func__, phydev->phy_id, phyd

[PATCH 2/2] net: ethernet: sxgbe: use phy_ethtool_{get|set}_link_ksettings

[Philippe Reynes]

There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c |   21 +--
 1 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c 
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
index 72c9108..542b67d 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
@@ -182,23 +182,6 @@ static void sxgbe_getdrvinfo(struct net_device *dev,
strlcpy(info->version, DRV_VERSION, sizeof(info->version));
 }
 
-static int sxgbe_getsettings(struct net_device *dev,
-struct ethtool_cmd *cmd)
-{
-   if (dev->phydev)
-   return phy_ethtool_gset(dev->phydev, cmd);
-
-   return -EOPNOTSUPP;
-}
-
-static int sxgbe_setsettings(struct net_device *dev, struct ethtool_cmd *cmd)
-{
-   if (dev->phydev)
-   return phy_ethtool_sset(dev->phydev, cmd);
-
-   return -EOPNOTSUPP;
-}
-
 static u32 sxgbe_getmsglevel(struct net_device *dev)
 {
struct sxgbe_priv_data *priv = netdev_priv(dev);
@@ -495,8 +478,6 @@ static int sxgbe_get_regs_len(struct net_device *dev)
 
 static const struct ethtool_ops sxgbe_ethtool_ops = {
.get_drvinfo = sxgbe_getdrvinfo,
-   .get_settings = sxgbe_getsettings,
-   .set_settings = sxgbe_setsettings,
.get_msglevel = sxgbe_getmsglevel,
.set_msglevel = sxgbe_setmsglevel,
.get_link = ethtool_op_get_link,
@@ -512,6 +493,8 @@ static const struct ethtool_ops sxgbe_ethtool_ops = {
.get_regs_len = sxgbe_get_regs_len,
.get_eee = sxgbe_get_eee,
.set_eee = sxgbe_set_eee,
+   .get_link_ksettings = phy_ethtool_get_link_ksettings,
+   .set_link_ksettings = phy_ethtool_set_link_ksettings,
 };
 
 void sxgbe_set_ethtool_ops(struct net_device *netdev)
-- 
1.7.4.4

Re: [PATCH] mac80211_hwsim: Added vendor echo command

[Johannes Berg]

On Sat, 2016-06-25 at 21:32 +0300, Jouni Malinen wrote:
> 
> All you need to do is to prepare a hostap.git contribution that
> requests a new subcommand/attribute to be assigned and once that gets
> applied to the hostap.git master branch, the values have been
> assigned and can be used for whatever purpose they were assigned,
> e.g., in mac80211_hwsim.
> 

Assuming, of course, that there's actually a point in the original
patch. I haven't quite figured out any reason to actually have this
facility.

johannes

[PATCH] net: stmmac: Fix null-function call in ISR on stmmac1000

[Matt Corallo]

At least on Meson GXBB, the CORE_IRQ_MTL_RX_OVERFLOW interrupt is thrown
with the stmmac1000 driver, which does not support set_rx_tail_ptr. With
this patch and the clock fixes, 1G ethernet works on ODROID-C2.

Signed-off-by: Matt Corallo 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a473c18..e407126 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2804,7 +2804,7 @@ static irqreturn_t stmmac_interrupt(int irq, void
*dev_id)
priv->tx_path_in_lpi_mode = true;
if (status & CORE_IRQ_TX_PATH_EXIT_LPI_MODE)
priv->tx_path_in_lpi_mode = false;
-   if (status & CORE_IRQ_MTL_RX_OVERFLOW)
+   if (status & CORE_IRQ_MTL_RX_OVERFLOW && 
priv->hw->dma->set_rx_tail_ptr)
priv->hw->dma->set_rx_tail_ptr(priv->ioaddr,
priv->rx_tail_addr,
STMMAC_CHAN0);
-- 
2.1.4

Re: [PATCH net-next] tcp: md5: do not use stack storage in crypto operations

[Andy Lutomirski]

On Sat, Jun 25, 2016 at 9:09 AM, Eric Dumazet  wrote:
> From: Eric Dumazet 
>
> Some arches have virtually mapped kernel stacks, or will soon have.
>
> tcp_md5_hash_header() uses an automatic variable to copy tcp header
> before mangling th->check and calling crypto function, which might
> be problematic on such arches.
>
> So use percpu storage as we already do for the pseudo header,
> and reduce number of crypto functions calls, as these headers
> are ridiculously small.

Thanks!

Should this go in via net-next or -tip?

--Andy

[PATCH 1/2] net: ethernet: r6040: use phydev from struct net_device

[Philippe Reynes]

The private structure contain a pointer to phydev, but the structure
net_device already contain such pointer. So we can remove the pointer
phydev in the private structure, and update the driver to use the
one contained in struct net_device.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/rdc/r6040.c |   22 +++---
 1 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index 6b541e5..f2bc7b0 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -200,7 +200,6 @@ struct r6040_private {
struct mii_bus *mii_bus;
struct napi_struct napi;
void __iomem *base;
-   struct phy_device *phydev;
int old_link;
int old_duplex;
 };
@@ -474,7 +473,7 @@ static void r6040_down(struct net_device *dev)
iowrite16(adrp[1], ioaddr + MID_0M);
iowrite16(adrp[2], ioaddr + MID_0H);
 
-   phy_stop(lp->phydev);
+   phy_stop(dev->phydev);
 }
 
 static int r6040_close(struct net_device *dev)
@@ -515,12 +514,10 @@ static int r6040_close(struct net_device *dev)
 
 static int r6040_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 {
-   struct r6040_private *lp = netdev_priv(dev);
-
-   if (!lp->phydev)
+   if (!dev->phydev)
return -EINVAL;
 
-   return phy_mii_ioctl(lp->phydev, rq, cmd);
+   return phy_mii_ioctl(dev->phydev, rq, cmd);
 }
 
 static int r6040_rx(struct net_device *dev, int limit)
@@ -732,7 +729,7 @@ static int r6040_up(struct net_device *dev)
/* Initialize all MAC registers */
r6040_init_mac_regs(dev);
 
-   phy_start(lp->phydev);
+   phy_start(dev->phydev);
 
return 0;
 }
@@ -959,16 +956,12 @@ static void netdev_get_drvinfo(struct net_device *dev,
 
 static int netdev_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
-   struct r6040_private *rp = netdev_priv(dev);
-
-   return  phy_ethtool_gset(rp->phydev, cmd);
+   return  phy_ethtool_gset(dev->phydev, cmd);
 }
 
 static int netdev_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
-   struct r6040_private *rp = netdev_priv(dev);
-
-   return phy_ethtool_sset(rp->phydev, cmd);
+   return phy_ethtool_sset(dev->phydev, cmd);
 }
 
 static const struct ethtool_ops netdev_ethtool_ops = {
@@ -998,7 +991,7 @@ static const struct net_device_ops r6040_netdev_ops = {
 static void r6040_adjust_link(struct net_device *dev)
 {
struct r6040_private *lp = netdev_priv(dev);
-   struct phy_device *phydev = lp->phydev;
+   struct phy_device *phydev = dev->phydev;
int status_changed = 0;
void __iomem *ioaddr = lp->base;
 
@@ -1057,7 +1050,6 @@ static int r6040_mii_probe(struct net_device *dev)
| SUPPORTED_TP);
 
phydev->advertising = phydev->supported;
-   lp->phydev = phydev;
lp->old_link = 0;
lp->old_duplex = -1;
 
-- 
1.7.4.4

[PATCH 2/2] net: ethernet: r6040: use phy_ethtool_{get|set}_link_ksettings

[Philippe Reynes]

There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/rdc/r6040.c |   14 ++
 1 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index f2bc7b0..7a7a395 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -954,22 +954,12 @@ static void netdev_get_drvinfo(struct net_device *dev,
strlcpy(info->bus_info, pci_name(rp->pdev), sizeof(info->bus_info));
 }
 
-static int netdev_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
-{
-   return  phy_ethtool_gset(dev->phydev, cmd);
-}
-
-static int netdev_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
-{
-   return phy_ethtool_sset(dev->phydev, cmd);
-}
-
 static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo= netdev_get_drvinfo,
-   .get_settings   = netdev_get_settings,
-   .set_settings   = netdev_set_settings,
.get_link   = ethtool_op_get_link,
.get_ts_info= ethtool_op_get_ts_info,
+   .get_link_ksettings = phy_ethtool_get_link_ksettings,
+   .set_link_ksettings = phy_ethtool_set_link_ksettings,
 };
 
 static const struct net_device_ops r6040_netdev_ops = {
-- 
1.7.4.4

Re: [PATCH] mac80211_hwsim: Added vendor echo command

[Jouni Malinen]

On Sat, Jun 25, 2016 at 06:08:01PM +0200, Erik Stromdahl wrote:
> The mac80211_hwsim driver is currently defining the QCA vendor ID
> 0x001374 for some reason.

That is used for allowing nl80211 vendor specific commands and events to
be tested. The particular vendor command was properly assigned from the
QCA 00:13:74 OUI.

> Also, all current vendor commands are using the "QCA_" prefix, hence
> the reason why I decided to add the new vendor command with the
> "QCA_" prefix as well.
> 
> Anyway, I understand that you don't want the hwsim driver bloated
> with definitions that does not belong there.

That's not the issue here; the issue is in getting vendor subcommands
assigned by the entity who controls the OUI that is used. 

> Is there any reason why hwsim uses the QCA vendor id?

Yes, that's an OUI for which there is a process that allows new values
to be assigned.. I happen to be the one who is in control of assigning
such values.

> Perhaps it would be best if the hwsim driver would define its own vendor id?

That would need an OUI which are a bit expensive to acquire. I don't see
any point for mac80211_hwsim to need a different OUI since there is
already a friendly vendor who has provided an OUI that can be used for
this type of purposes.

In other words, you just need to follow the process defined for
assigning unique vendor subcommands/attribute identifiers for this OUI
00:13:74 and that process is what I pointed out in the previous email:

> >As far as the QCA vendor specific identifiers are concerned, their
> >assignment process is described here:
> >http://w1.fi/cgit/hostap/plain/src/common/qca-vendor.h

All you need to do is to prepare a hostap.git contribution that requests
a new subcommand/attribute to be assigned and once that gets applied to
the hostap.git master branch, the values have been assigned and can be
used for whatever purpose they were assigned, e.g., in mac80211_hwsim.

More details on how to make such a hostap.git contribution:
http://w1.fi/cgit/hostap/plain/CONTRIBUTIONS

-- 
Jouni MalinenPGP id EFC895FA

Re: [PATCH 1/2] net: ethernet: ethoc: use phydev from struct net_device

[Max Filippov]

On Sat, Jun 25, 2016 at 04:33:41PM +0200, Philippe Reynes wrote:
> The private structure contain a pointer to phydev, but the structure
> net_device already contain such pointer. So we can remove the pointer
> phy in the private structure, and update the driver to use the
> one contained in struct net_device.
> 
> Signed-off-by: Philippe Reynes 
> ---

Series:
Tested-by: Max Filippov 

-- 
Thanks.
-- Max

Re: [PATCH] of_mdio: select fixed phy support unconditionally

[Randy Dunlap]

On 06/24/16 02:24, Arnd Bergmann wrote:
> Calling the fixed-phy functions when CONFIG_FIXED_PHY=m as a previous
> change tried cannot work if the caller is in built-in code:
> 
> drivers/of/built-in.o: In function `of_phy_register_fixed_link':
> of_reserved_mem.c:(.text+0x85e0): undefined reference to `fixed_phy_register'
> 
> Making of_mdio depend on 'FIXED_PHY || !FIXED_PHY' would solve this
> dependency by enforcing that OF_MDIO itself becomes a loadable module
> when FIXED_PHY=y, but that creates a different dependency as it
> breaks any built-in ethernet driver that uses of_mdio.
> 
> Making FIXED_PHY a bool option also cannot work, since it depends on
> PHYLIB, which again is tristate.
> 
> This version now uses 'select FIXED_PHY' to ensure that the fixed-phy
> portion of of_mdio is not optional. The main downside of this is
> a small increase in code size for cases that do not need fixed phy
> support, but it should avoid all of the link-time problems.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: d1bd330a229f ("of_mdio: Enable fixed PHY support if driver is a 
> module")

Fixes the build errors that I was seeing.  Thanks.

Acked-by: Randy Dunlap 


> ---
>  drivers/of/Kconfig  | 1 +
>  drivers/of/of_mdio.c| 2 --
>  include/linux/of_mdio.h | 8 ++--
>  3 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index b3bec3aaa45d..bc07ad30c9bf 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -74,6 +74,7 @@ config OF_NET
>  config OF_MDIO
>   def_tristate PHYLIB
>   depends on PHYLIB
> + select FIXED_PHY
>   help
> OpenFirmware MDIO bus (Ethernet PHY) accessors
>  
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index de68707a99c7..e2b50bc12f23 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -361,7 +361,6 @@ struct phy_device *of_phy_attach(struct net_device *dev,
>  }
>  EXPORT_SYMBOL(of_phy_attach);
>  
> -#if IS_ENABLED(CONFIG_FIXED_PHY)
>  /*
>   * of_phy_is_fixed_link() and of_phy_register_fixed_link() must
>   * support two DT bindings:
> @@ -451,4 +450,3 @@ int of_phy_register_fixed_link(struct device_node *np)
>   return -ENODEV;
>  }
>  EXPORT_SYMBOL(of_phy_register_fixed_link);
> -#endif
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 6c8cb9aa4c00..4b04587d0441 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -25,6 +25,8 @@ struct phy_device *of_phy_attach(struct net_device *dev,
>  
>  extern struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np);
>  extern int of_mdio_parse_addr(struct device *dev, const struct device_node 
> *np);
> +extern int of_phy_register_fixed_link(struct device_node *np);
> +extern bool of_phy_is_fixed_link(struct device_node *np);
>  
>  #else /* CONFIG_OF */
>  static inline int of_mdiobus_register(struct mii_bus *mdio, struct 
> device_node *np)
> @@ -67,12 +69,6 @@ static inline int of_mdio_parse_addr(struct device *dev,
>  {
>   return -ENOSYS;
>  }
> -#endif /* CONFIG_OF */
> -
> -#if defined(CONFIG_OF) && IS_ENABLED(CONFIG_FIXED_PHY)
> -extern int of_phy_register_fixed_link(struct device_node *np);
> -extern bool of_phy_is_fixed_link(struct device_node *np);
> -#else
>  static inline int of_phy_register_fixed_link(struct device_node *np)
>  {
>   return -ENOSYS;
> 


-- 
~Randy

[PATCH RFC 3/3] ARM64: dts: meson-gxbb: use the new meson8b DWMAC glue

[Martin Blumenstingl]

The Amlogic reference driver uses the "mc_val" devicetree property to
configure the PRG_ETHERNET_ADDR0 register. Unfortunately it uses magic
values for this configuration.

According to the datasheet the PRG_ETHERNET_ADDR0 register is at address
0xc8834108. However, the reference driver uses 0xc8834540 instead.
According to my tests, the value from the reference driver is correct.

The updated examples are representing 0x1621 from the reference driver's
mc_val property, which is used when there is an external gbit PHY
connected.
For RMII mode PHYs mc_val 0x1800 is used in the reference driver, which
translates  would translate to "do not set any of the following
properties" (as the two bits are configured automatically):
- amlogic,enable-25mhz-phy-clk
- amlogic,mp2-clock
- amlogic,tx-delay

Signed-off-by: Martin Blumenstingl 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts  |  4 
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi |  4 
 arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi |  4 
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 12 +---
 4 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index b06bf8a..8d540ff 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -103,6 +103,10 @@
status = "okay";
pinctrl-0 = <ð_pins>;
pinctrl-names = "default";
+
+   amlogic,enable-25mhz-phy-clk;
+   amlogic,mp2-clock = ;
+   amlogic,tx-delay = ;
 };
 
 &sd_emmc_b {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 5dfd849..4574677 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -85,6 +85,10 @@
status = "okay";
pinctrl-0 = <ð_pins>;
pinctrl-names = "default";
+
+   amlogic,enable-25mhz-phy-clk;
+   amlogic,mp2-clock = ;
+   amlogic,tx-delay = ;
 };
 
 &sd_emmc_b {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index 3a77829..31ae35e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -83,6 +83,10 @@
status = "okay";
pinctrl-0 = <ð_pins>;
pinctrl-names = "default";
+
+   amlogic,enable-25mhz-phy-clk;
+   amlogic,mp2-clock = ;
+   amlogic,tx-delay = ;
 };
 
 &sd_emmc_b {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 6c23965..463c2cd 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "amlogic,meson-gxbb";
@@ -308,6 +309,11 @@
};
};
};
+
+   prg_ethernet: prg_ethernet@540 {
+   compatible = "syscon";
+   reg = <0x0 0x00540 0x0 0x8>;
+   };
};
 
hiubus: hiubus@c883c000 {
@@ -354,14 +360,14 @@
};
 
ethmac: ethernet@c941 {
-   compatible = "amlogic,meson6-dwmac", "snps,dwmac";
-   reg = <0x0 0xc941 0x0 0x1
-  0x0 0xc8834540 0x0 0x4>;
+   compatible = "amlogic,meson8b-dwmac", "snps,dwmac";
+   reg = <0x0 0xc941 0x0 0x1>;
interrupts = <0 8 1>;
interrupt-names = "macirq";
clocks = <&clkc CLKID_ETH>;
clock-names = "stmmaceth";
phy-mode = "rgmii";
+   amlogic,prg-ethernet = <&prg_ethernet>;
status = "disabled";
};
};
-- 
2.9.0

[PATCH RFC 2/3] net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC

[Martin Blumenstingl]

The Ethernet controller available in Meson8b and GXBB SoCs is a Synopsys
DesignWare MAC IP core which is already supported by the stmmac driver.

In addition to the standard stmmac driver some Meson8b / GXBB specific
registers have to be configured for the PHY clocks. These SoC specific
registers are called PRG_ETHERNET_ADDR0 and PRG_ETHERNET_ADDR1 in the
datasheet.
These registers are not backwards compatible with those on Meson 6b,
which is why a new glue driver was introduced.

Signed-off-by: Martin Blumenstingl 
---
 drivers/net/ethernet/stmicro/stmmac/Makefile   |   2 +-
 .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c| 219 +
 include/dt-bindings/net/amlogic-meson8b-dwmac.h|  33 
 3 files changed, 253 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
 create mode 100644 include/dt-bindings/net/amlogic-meson8b-dwmac.h

diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile 
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 0fb362d..79e5d0c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -9,7 +9,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o 
ring_mode.o  \
 obj-$(CONFIG_STMMAC_PLATFORM)  += stmmac-platform.o
 obj-$(CONFIG_DWMAC_IPQ806X)+= dwmac-ipq806x.o
 obj-$(CONFIG_DWMAC_LPC18XX)+= dwmac-lpc18xx.o
-obj-$(CONFIG_DWMAC_MESON)  += dwmac-meson.o
+obj-$(CONFIG_DWMAC_MESON)  += dwmac-meson.o dwmac-meson8b.o
 obj-$(CONFIG_DWMAC_ROCKCHIP)   += dwmac-rk.o
 obj-$(CONFIG_DWMAC_SOCFPGA)+= dwmac-socfpga.o
 obj-$(CONFIG_DWMAC_STI)+= dwmac-sti.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
new file mode 100644
index 000..4c2d1e1
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -0,0 +1,219 @@
+/*
+ * Amlogic Meson S805/S905 DWMAC glue layer
+ *
+ * Copyright (C) 20016 Martin Blumenstingl 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "stmmac_platform.h"
+
+#define PRG_ETH0   0x0
+#define PRG_ETH0_RGMII_MODEBIT(0)
+#define PRG_ETH0_TXDLY_SHIFT   5 /* 2 bits [5-6] */
+#define PRG_ETH0_TXDLY_MASK(0x3 << PRG_ETH0_TXDLY_SHIFT)
+#define PRG_ETH0_MP2_CLK_SHIFT 7 /* 3 bits [7-9] */
+#define PRG_ETH0_MP2_CLK_MASK  (0x7 << PRG_ETH0_MP2_CLK_SHIFT)
+#define PRG_ETH0_GEN_25MHZ_PHY_CLK BIT(10)
+#define PRG_ETH0_TX_CLK_SPEED_100  BIT(11)
+#define PRG_ETH0_TX_AND_PHY_REF_CLKBIT(12)
+
+struct meson8b_dwmac {
+   struct platform_device  *pdev;
+   struct regmap   *prg_ethernet;
+   phy_interface_t phy_mode;
+   u32 tx_delay;
+   u32 mp2_clk;
+   boolenable_25mhz_phy_clk;
+};
+
+static void meson8b_dwmac_fix_mac_speed(void *priv, unsigned int speed)
+{
+   struct meson8b_dwmac *dwmac = priv;
+
+   /* MAC speed adjustment is only needed in RMII mode */
+   if (dwmac->phy_mode != PHY_INTERFACE_MODE_RMII)
+   return;
+
+   switch (speed) {
+   case SPEED_10:
+   /* 2.5MHz */
+   regmap_update_bits(dwmac->prg_ethernet, PRG_ETH0,
+  PRG_ETH0_TX_CLK_SPEED_100, 0);
+   break;
+   case SPEED_100:
+   /* 25MHz */
+   regmap_update_bits(dwmac->prg_ethernet, PRG_ETH0,
+  PRG_ETH0_TX_CLK_SPEED_100,
+  PRG_ETH0_TX_CLK_SPEED_100);
+   break;
+   }
+}
+
+static int meson8b_dwmac_of_parse(struct meson8b_dwmac *dwmac)
+{
+   struct device *dev = &dwmac->pdev->dev;
+   struct device_node *np = dev->of_node;
+
+   dwmac->phy_mode = of_get_phy_mode(np);
+   if (dwmac->phy_mode < 0) {
+   dev_err(dev, "missing phy-mode property\n");
+   return -EINVAL;
+   }
+
+   /* register map for MAC configuration */
+   dwmac->prg_ethernet = syscon_regmap_lookup_by_phandle(np,
+   "amlogic,prg-ethernet");
+   if (IS_ERR(dwmac->prg_ethernet)) {
+   dev_err(dev, "missing amlogic,prg-ethernet property\n");
+   return PTR_ERR(dwmac->prg_ethernet);
+   }
+
+   if (of_property_read_bool(np, "amlogic,enable-25mhz-phy-clk"))
+   dwmac->enable_25mhz_phy_clk = true;
+
+   /* TX delay is optional */
+   of_property_read_u32(np, "a

[RFC] meson: add support for configuring the ethernet clocks

[Martin Blumenstingl]

This adds support for configuring the PRG_ETHERNET_ADDR registers on
Meson 8b (S805) and GXBB (S905) devices. The registers there are
completely different from those found in the earlier Meson 6b SoC
series, which is why a new driver was implemented.

This configuration is required when the bootloader does not configure
these registers based on the connected PHY. Symptoms are that the
DWMAC device is detected, but no packets are getting through, even
though everything else is configured correctly.

[PATCH RFC 1/3] net: dt-bindings: add the amlogic,meson8b-dwmac binding

[Martin Blumenstingl]

This patch adds the documentation for the DWMAC ethernet controller
found in Amlogic Meson 8b (S805) and GXBB (S905) SoCs.
Compared to the standard stmmac/dwmac configuration this requires some
some additional parameters for configuring the clock-generator
depending on the actual ethernet PHY on the board.

Signed-off-by: Martin Blumenstingl 
---
 .../bindings/net/amlogic,meson8b-dwmac.txt | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/amlogic,meson8b-dwmac.txt

diff --git a/Documentation/devicetree/bindings/net/amlogic,meson8b-dwmac.txt 
b/Documentation/devicetree/bindings/net/amlogic,meson8b-dwmac.txt
new file mode 100644
index 000..4164753e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson8b-dwmac.txt
@@ -0,0 +1,44 @@
+* Amlogic Meson 8b/GXBB DWMAC Ethernet controller
+
+The device inherits all the properties of the dwmac/stmmac devices
+described in the file net/stmmac.txt with the following changes.
+
+Required properties:
+- compatible: should be "amlogic,meson8b-dwmac" along with "snps,dwmac"
+ and any applicable more detailed version number
+ described in net/stmmac.txt
+- prg-ethernet: should contain a phandle to a syscon device mapping the
+   PRG_ETHERNET registers.
+
+
+Optional properties:
+- amlogic,enable-tx-phy-ref-clk: Enables the TX_CLK and PHY_REF_CLK
+clock generator.
+- amlogic,mp2-clock: Sets the frequency for the mp2_clk_out clock. See
+the MESON8B_DWMAC_MP2_CLOCK_* definitions in
+"include/dt-bindings/net/amlogic-meson8b-dwmac.h".
+- amlogic,tx-delay: Configures the TX clock delay. See the
+   MESON8B_DWMAC_TX_CLK_DELAY_* definitions in
+   "include/dt-bindings/net/amlogic-meson8b-dwmac.h".
+
+
+Example:
+
+#include 
+
+   gmac: ethernet@3700 {
+   compatible = "amlogic,meson8b-dwmac", "snps,dwmac";
+   reg = <0x0 0xc941 0x0 0x1>;
+   interrupts = <0 8 1>;
+   interrupt-names = "macirq";
+
+   clocks = <&clkc CLKID_ETH>;
+   clock-names = "stmmaceth";
+
+   phy-mode = "rgmii";
+   
+   amlogic,prg-ethernet = <&prg_ethernet>;
+   amlogic,enable-25mhz-phy-clk;
+   amlogic,mp2-clock = ;
+   amlogic,tx-delay = ;
+   };
-- 
2.9.0

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

[Tom Herbert]

On Fri, Jun 24, 2016 at 5:01 PM, Rick Jones  wrote:
> On 06/24/2016 04:43 PM, Tom Herbert wrote:
>>
>> Here's Christoph's slides on TFO in the wild which presents a good
>> summary of the middlebox problem. There is one significant difference
>> in that ECN needs network support whereas TFO didn't. Given that
>> experience, I'm doubtful other new features at L4 could ever be
>> productively use (like EDO or maybe TCP-ENO).
>>
>> https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf
>
>
> Perhaps I am being overly optimistic, but my takeaway from those slides is
> Apple were able to come-up with ways to deal with the middleboxes and so
> could indeed productively use TCP FastOpen.
>
They do it by detecting that TFO packets are being dropped and so
fallback to not using TFO. Clients behind such a middlebox can't use
the feature.

> "Overall, very good success-rate"
> though tempered by
> "But... middleboxes were a big issue in some ISPs..."
>
> Though it doesn't get into how big (some connections, many, most, all?) and
> how many ISPs.
>
Note that this not just about TCP. TCP was never ordained to be the
one an only transport protocol on the Internet, in fact the intent of
the Internet architecture and a layered protocol stack was to
encourage innovation in protocol design not to ossify to just one in
perpetuity. SCTP for instance has some very interesting features like
sub streams to avoid HOL block, reliable messages model. But we can't
even consider the possibility of deploying it for our applications,
firewalls and NAT boxes will likely drop; not all major client OSes
(e.g. WIndows) even provide support for it.

ECN, TFO, and SCTP issues are just anecdotes of problems that have the
same root cause: middleboxes are invasive in transport protocols in
non-standard ways so that extending or changing transport protocols
difficult or infeasible to deploy. This is protocol ossification, and
IMO the solution is to eliminate middleboxes have visibility of L4.

Tom

Re: [PATCH net-next 0/4] net_sched: bulk dequeue and deferred drops

[David Miller]

From: Eric Dumazet 
Date: Tue, 21 Jun 2016 23:16:48 -0700

> First patch adds an additional parameter to ->enqueue() qdisc method
> so that drops can be done outside of critical section
> (after locks are released).
> 
> Then fq_codel can have a small optimization to reduce number of cache
> lines misses during a drop event
> (possibly accumulating hundreds of packets to be freed).
> 
> A small htb change exports the backlog in class dumps.
> 
> Final patch adds bulk dequeue to qdiscs that were lacking this feature.
> 
> This series brings a nice qdisc performance increase (more than 80 %
> in some cases).

Series applied, thanks Eric.

[PATCH net-next] tcp: md5: do not use stack storage in crypto operations

[Eric Dumazet]

From: Eric Dumazet 

Some arches have virtually mapped kernel stacks, or will soon have.

tcp_md5_hash_header() uses an automatic variable to copy tcp header
before mangling th->check and calling crypto function, which might
be problematic on such arches.

So use percpu storage as we already do for the pseudo header,
and reduce number of crypto functions calls, as these headers
are ridiculously small.

Signed-off-by: Eric Dumazet 
Reported-by: Andy Lutomirski 
---
I am not sure the md5 crypto functions have a problem with data backed
in virtually mapped stacks, but this patch seems to remove the doubt.

 include/net/tcp.h   |2 +-
 net/ipv4/tcp.c  |   17 -
 net/ipv4/tcp_ipv4.c |   29 +
 net/ipv6/tcp_ipv6.c |   27 +++
 4 files changed, 29 insertions(+), 46 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 
a79894b667265cdf9e3fe793b4757e2f932b378a..2dd919e0289839130d2c5435b7925592082d62b5
 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1385,6 +1385,7 @@ union tcp_md5sum_block {
 struct tcp_md5sig_pool {
struct ahash_request*md5_req;
union tcp_md5sum_block  md5_blk;
+   struct tcphdr   tcp_hdr;
 };
 
 /* - functions */
@@ -1420,7 +1421,6 @@ static inline void tcp_put_md5sig_pool(void)
local_bh_enable();
 }
 
-int tcp_md5_hash_header(struct tcp_md5sig_pool *, const struct tcphdr *);
 int tcp_md5_hash_skb_data(struct tcp_md5sig_pool *, const struct sk_buff *,
  unsigned int header_len);
 int tcp_md5_hash_key(struct tcp_md5sig_pool *hp,
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 
5c7ed147449c1b7ba029b12e033ad779a631460a..5fc9336934a11387e725300d6bca4aabd3991f19
 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3025,23 +3025,6 @@ struct tcp_md5sig_pool *tcp_get_md5sig_pool(void)
 }
 EXPORT_SYMBOL(tcp_get_md5sig_pool);
 
-int tcp_md5_hash_header(struct tcp_md5sig_pool *hp,
-   const struct tcphdr *th)
-{
-   struct scatterlist sg;
-   struct tcphdr hdr;
-
-   /* We are not allowed to change tcphdr, make a local copy */
-   memcpy(&hdr, th, sizeof(hdr));
-   hdr.check = 0;
-
-   /* options aren't included in the hash */
-   sg_init_one(&sg, &hdr, sizeof(hdr));
-   ahash_request_set_crypt(hp->md5_req, &sg, NULL, sizeof(hdr));
-   return crypto_ahash_update(hp->md5_req);
-}
-EXPORT_SYMBOL(tcp_md5_hash_header);
-
 int tcp_md5_hash_skb_data(struct tcp_md5sig_pool *hp,
  const struct sk_buff *skb, unsigned int header_len)
 {
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 
3708de2a66833cf1d4a221a2b6ce3923bde978c4..8eb360c9b4a8dc6393e1dfa04957273ec7ac1e97
 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1018,27 +1018,28 @@ static int tcp_v4_parse_md5_keys(struct sock *sk, char 
__user *optval,
  GFP_KERNEL);
 }
 
-static int tcp_v4_md5_hash_pseudoheader(struct tcp_md5sig_pool *hp,
-   __be32 daddr, __be32 saddr, int nbytes)
+static int tcp_v4_md5_hash_headers(struct tcp_md5sig_pool *hp,
+  __be32 daddr, __be32 saddr,
+  const struct tcphdr *th, int nbytes)
 {
struct tcp4_pseudohdr *bp;
struct scatterlist sg;
+   struct tcphdr *_th;
 
bp = &hp->md5_blk.ip4;
-
-   /*
-* 1. the TCP pseudo-header (in the order: source IP address,
-* destination IP address, zero-padded protocol number, and
-* segment length)
-*/
bp->saddr = saddr;
bp->daddr = daddr;
bp->pad = 0;
bp->protocol = IPPROTO_TCP;
bp->len = cpu_to_be16(nbytes);
 
-   sg_init_one(&sg, bp, sizeof(*bp));
-   ahash_request_set_crypt(hp->md5_req, &sg, NULL, sizeof(*bp));
+   _th = (struct tcphdr *)(bp + 1);
+   memcpy(_th, th, sizeof(*th));
+   _th->check = 0;
+
+   sg_init_one(&sg, bp, sizeof(*bp) + sizeof(*th));
+   ahash_request_set_crypt(hp->md5_req, &sg, NULL,
+   sizeof(*bp) + sizeof(*th));
return crypto_ahash_update(hp->md5_req);
 }
 
@@ -1055,9 +1056,7 @@ static int tcp_v4_md5_hash_hdr(char *md5_hash, const 
struct tcp_md5sig_key *key,
 
if (crypto_ahash_init(req))
goto clear_hash;
-   if (tcp_v4_md5_hash_pseudoheader(hp, daddr, saddr, th->doff << 2))
-   goto clear_hash;
-   if (tcp_md5_hash_header(hp, th))
+   if (tcp_v4_md5_hash_headers(hp, daddr, saddr, th, th->doff << 2))
goto clear_hash;
if (tcp_md5_hash_key(hp, key))
goto clear_hash;
@@ -1101,9 +1100,7 @@ int tcp_v4_md5_hash_skb(char *md5_hash, const struct 
tcp_md5sig_key *key,
if (crypto_ahash_init(req))
goto clear_hash;
 
-   if (tcp_v4_md5_hash_pseudoheader(hp, daddr, saddr, skb->len))
-   goto clear_

Re: [PATCH net-next 00/13] liquidio: updates and bug fixes

[David Miller]

From: Raghu Vatsavayi 
Date: Tue, 21 Jun 2016 22:53:02 -0700

> Please consider following patch series for liquidio bug fixes
> and updates on top of net-next. Following patches should be
> applied in the following order as some of them depend on
> earlier patches in the series.

Series applied, thanks.

Please don't put double-signoffs on your patches in future
submissions, that is completely unnecessary.

Re: [PATCH] mac80211_hwsim: Added vendor echo command

[Erik Stromdahl]

The mac80211_hwsim driver is currently defining the QCA vendor ID 
0x001374 for some reason.


Also, all current vendor commands are using the "QCA_" prefix, hence the 
reason why I decided to add the new vendor command with the "QCA_" 
prefix as well.


Anyway, I understand that you don't want the hwsim driver bloated with 
definitions that does not belong there.


Is there any reason why hwsim uses the QCA vendor id?
Perhaps it would be best if the hwsim driver would define its own vendor id?

On 06/24/2016 10:47 PM, Jouni Malinen wrote:

On Fri, Jun 24, 2016 at 10:13:54AM +0200, Erik Stromdahl wrote:

The purpose of the echo command is to provide a test
facility for user space programs.



diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
@@ -332,14 +332,16 @@ static const struct ieee80211_rate hwsim_rates[] = {
  #define QCA_NL80211_SUBCMD_TEST 1
+#define QCA_NL80211_SUBCMD_ECHO 2


NAK. That QCA vendor specific value has not been assigned nor have I
even seen a request to assign such a value.


  enum qca_nl80211_vendor_subcmds {
QCA_WLAN_VENDOR_ATTR_TEST = 8,
-   QCA_WLAN_VENDOR_ATTR_MAX = QCA_WLAN_VENDOR_ATTR_TEST
+   QCA_WLAN_VENDOR_ATTR_ECHO,


And this vendor attribute value has already been assigned for another
purpose.

It is no acceptable to pick arbitrary values of identifiers without
proper request to the owner of the OUI that is used to assign the
values.

As far as the QCA vendor specific identifiers are concerned, their
assignment process is described here:
http://w1.fi/cgit/hostap/plain/src/common/qca-vendor.h

Please do not submit kernel changes that use any unassigned vendor
identifier or even worse, a value that have already been assigned for a
completely different purpose.

Re: [PATCH net-next] cxgb4vf: Synchronize access to mailbox

[David Miller]

From: Hariprasad Shenai 
Date: Wed, 22 Jun 2016 09:39:29 +0530

> The issue comes when there are multiple threads attempting to use the
> mailbox facility at the same time. The issue is the for the Virtual
> Function Driver, the only way to get the Virtual Interface statistics
> is to issue mailbox commands to ask the firmware for the VI Stats.
> And, because the VI Stats command can only retrieve a smallish number of
> stats per mailbox command, we have to issue three mailbox commands in quick
> succession. When ethtool or netstat command to get interface stats and
> interface up/down is run in a loop for every 0.1 sec, we observed
> mailbox collisions. And out of the two commands one would fail with
> the present code, since we don't queue the second command.
> 
> To overcome the above issue, added a queue to access the mailbox.
> Whenever a mailbox command is issued add it to the queue. If its at the
> head issue the mailbox command, else wait for the existing command to
> complete. Usually command takes less than a milli-second to complete.
> Also timeout from the loop, if the command under execution takes
> long time to run.
> 
> In reality, the number of mailbox access collisions is going to be very
> rare since no one runs such abusive script.
> 
> Signed-off-by: Hariprasad Shenai 

Applied.

Re: [net-next] samples/bpf: set max locked memory to ulimited

[David Miller]

From: William Tu 
Date: Tue, 21 Jun 2016 21:05:58 -0700

> Signed-off-by: William Tu 

Applied.

Re: [PATCH v2] ibmvnic: fix to use list_for_each_safe() when delete items

[David Miller]

From: Wei Yongjun 
Date: Wed, 22 Jun 2016 10:51:46 +0800

> Since we will remove items off the list using list_del() we need
> to use a safe version of the list_for_each() macro aptly named
> list_for_each_safe().
> 
> Signed-off-by: Wei Yongjun 

Your email client has corrupted the spacing in this patch, making
it unusable.

Re: [PATCH 1/2] net: ethernet: macb: use phydev from struct net_device

[David Miller]

From: Philippe Reynes 
Date: Wed, 22 Jun 2016 00:32:35 +0200

> The private structure contain a pointer to phydev, but the structure
> net_device already contain such pointer. So we can remove the pointer
> phydev in the private structure, and update the driver to use the
> one contained in struct net_device.
> 
> Signed-off-by: Philippe Reynes 

Applied.

Re: [PATCH 2/2] net: ethernet: macb: use phy_ethtool_{get|set}_link_ksettings

[David Miller]

From: Philippe Reynes 
Date: Wed, 22 Jun 2016 00:32:36 +0200

> There are two generics functions phy_ethtool_{get|set}_link_ksettings,
> so we can use them instead of defining the same code in the driver.
> 
> Signed-off-by: Philippe Reynes 

Applied.

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

[Tom Herbert]

On Wed, Jun 22, 2016 at 12:23 PM, David Miller  wrote:
> From: Jerry Chu 
> Date: Tue, 21 Jun 2016 20:42:19 -0700
>
>> I don't believe TOU will lead to a proliferation of TCP
>> implementations in the userland - getting a solid TCP implementation
>> is hard.
>
> The fear isn't doing legitimate things.
>
> It's making TCP stacks that do evil stuff on purpose.
>
> Also, making proprietary TCP stacks that override the kernel one.
>
There is no "kernel one", there are many client kernels, many
different stacks on the Internet, many implementations of TCP. Some of
these are poorly engineered, years behind in technology, and otherwise
horribly insecure. There are even still people running WIndows95 for
heaven's sake! There is simply no way we can just implicitly trust
kernels to be doing the right thing. Neither is there any requirement
for us to do so, you will not find a requirement in any Internet
standard that TCP MUST be implemented in the kernel. The same
characteristics hold for middleboxes and firewalls, there are many
implementations, many don't follow standards, and the SW/FW upgrade
issue is potentially catastrophic to the Internet.  We have no
requirement and can never assume that a robust sufficient firewall is
the in the path of our packets.

Bottom line: if you're developing a business critical application on
the Internet, you cannot assume that the OSes or the network provide
adequate security; you need to take ownership of security for your
application. TOU is a step in that direction.

> And finally, here's the best part, all of the above can be done as a
> new, huge, potential attack vector for hackers.
>
I disagree that there is a new attack vector here. Yes, a malicious
program can open up an unconnected UDP socket and send to any
destination although they should not be able to spoof source address
easily. This is well known and attacks against DNS and other current
uses of UDP already exit. But, a major part of TOU is that the
transport layer header is encrypted so this makes it impossible to
inject packets into a TOU connection even if the program is able to
snoop packets on the wire. TOU is be protected against injection
attacks unlike TCP since headers are in cleartext. So the worse case
attack should be a form of SYN attack which we already have to deal
with for existing transport protocols.

Thanks,
Tom

Re: [patch net-next v5 0/4] return offloaded stats as default and expose original sw stats

[Roopa Prabhu]

On Thu, Jun 23, 2016 at 8:40 AM, Jiri Pirko  wrote:
> Thu, Jun 23, 2016 at 05:11:26PM CEST, anurad...@cumulusnetworks.com wrote:
>> we can't separate CPU and HW stats there. In some cases (or ASICs) HW
>> counters do
>> not include CPU generated packetsyou will have to add CPU
>> generated pkt counters to the
>> hw counters for such virtual device stats.
> Can you please provide and example how that could happen?

example is the bridge vlan stats I mention below. These are usually counted
by attaching hw virtual counter resources. And CPU generated packets
in some cases maybe setup to bypass the ASIC pipeline because the CPU
has already made the required decisions. So, they may not be counted by
by such hw virtual counters.
>>>
>>> Bypass ASIC? How do the packets get on the wire?
>>>
>>
>>Bypass the "forwarding pipeline" in the ASIC that is. Obviously the
>>ASIC ships the CPU generated packet out of the switch/front-panel
>>port. Continuing Roopa's example of vlan netdev stats To get the
>>HW stats counters are typically tied to the ingress and egress vlan hw
>>entries. All the incoming packets are subject to the ingress vlan
>>lookup irrespective of whether they get punted to the CPU or whether
>>they are forwarded to another front panel port. In that case the
>>ingress HW stats does represent all packets. However for CPU
>>originated packets egress vlan lookups are bypassed in the ASIC (this
>>is common forwarding option in most ASICs) and the packet shipped as
>>is out of front-panel port specified by the CPU. Which means these
>>packets will NOT be counted against the egress VLAN HW counter; hence
>>the need for summation.
>
> Driver will know about this, and will provide the stats accordignly to
> the core. Who else than driver should resolve this.
>

The point was/is that there should be only two categories:
1) the base default stats: can contain 'only sw', 'only hw' or 'a
summation of hw and sw' in some cases.
The user does not care about the breakdown.

2) everything else falls into the second category: driver provided
breakdown of stats for easier debugging.
This today is ethtool stats and we can have an equivalent nested
attribute for this in the new stats api.
Lets call it IFLA_STATS_LINK_DRIVER or you pick a name. Lets make it
nested and extensible (like ethtool is) and
driver can expose any kind of stats there.
ie lets move the stats you are proposing to this category of stats.
instead of introducing a third category 'SW stats'.

Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: move driver in its own folder

[David Miller]

From: Vivien Didelot 
Date: Tue, 21 Jun 2016 12:28:19 -0400

> With the upcoming support for cross-chip operations and other mv88e6xxx
> enhancements, new files will be added.
> 
> Similarly to mlxsw or b53, move mv88e6xxx files into their own folder.
> 
> In the meantime, update the MAINTAINERS entry to please checkpatch.pl,
> by replacing the invalid 88E6352 entry with 88E6XXX, maintained by
> Andrew and myself.
> 
> Signed-off-by: Vivien Didelot 

Applied.

Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: rename single-chip support

[David Miller]

From: Vivien Didelot 
Date: Tue, 21 Jun 2016 12:28:20 -0400

> With the upcoming support for cross-chip operations, it will be hard to
> distinguish portions of code supporting a single-chip or a switch fabric
> of interconnected chips.
> 
> Make the code clearer now, by renaming the mv88e6xxx_priv_state chip
> structure to mv88e6xxx_chip. This patch brings no functional changes.
> 
> Signed-off-by: Vivien Didelot 

Applied.

[PATCH 2/2] net: ethernet: hix5hd2: use phy_ethtool_{get|set}_link_ksettings

[Philippe Reynes]

There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c |   22 ++
 1 files changed, 2 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c 
b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
index fed1c0f..275618b 100644
--- a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
@@ -750,28 +750,10 @@ static const struct net_device_ops hix5hd2_netdev_ops = {
.ndo_set_mac_address= hix5hd2_net_set_mac_address,
 };
 
-static int hix5hd2_get_settings(struct net_device *net_dev,
-   struct ethtool_cmd *cmd)
-{
-   if (!net_dev->phydev)
-   return -ENODEV;
-
-   return phy_ethtool_gset(net_dev->phydev, cmd);
-}
-
-static int hix5hd2_set_settings(struct net_device *net_dev,
-   struct ethtool_cmd *cmd)
-{
-   if (!net_dev->phydev)
-   return -ENODEV;
-
-   return phy_ethtool_sset(net_dev->phydev, cmd);
-}
-
 static struct ethtool_ops hix5hd2_ethtools_ops = {
.get_link   = ethtool_op_get_link,
-   .get_settings   = hix5hd2_get_settings,
-   .set_settings   = hix5hd2_set_settings,
+   .get_link_ksettings = phy_ethtool_get_link_ksettings,
+   .set_link_ksettings = phy_ethtool_set_link_ksettings,
 };
 
 static int hix5hd2_mdio_wait_ready(struct mii_bus *bus)
-- 
1.7.4.4

[PATCH 1/2] net: ethernet: hix5hd2: use phydev from struct net_device

[Philippe Reynes]

The private structure contain a pointer to phydev, but the structure
net_device already contain such pointer. So we can remove the pointer
phy in the private structure, and update the driver to use the
one contained in struct net_device.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c |   30 ++--
 1 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c 
b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
index b9f2ea5..fed1c0f 100644
--- a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
@@ -218,7 +218,6 @@ struct hix5hd2_priv {
struct device *dev;
struct net_device *netdev;
 
-   struct phy_device *phy;
struct device_node *phy_node;
phy_interface_t phy_mode;
 
@@ -402,7 +401,7 @@ static int hix5hd2_net_set_mac_address(struct net_device 
*dev, void *p)
 static void hix5hd2_adjust_link(struct net_device *dev)
 {
struct hix5hd2_priv *priv = netdev_priv(dev);
-   struct phy_device *phy = priv->phy;
+   struct phy_device *phy = dev->phydev;
 
if ((priv->speed != phy->speed) || (priv->duplex != phy->duplex)) {
hix5hd2_config_port(dev, phy->speed, phy->duplex);
@@ -679,6 +678,7 @@ static void hix5hd2_free_dma_desc_rings(struct hix5hd2_priv 
*priv)
 static int hix5hd2_net_open(struct net_device *dev)
 {
struct hix5hd2_priv *priv = netdev_priv(dev);
+   struct phy_device *phy;
int ret;
 
ret = clk_prepare_enable(priv->clk);
@@ -687,12 +687,12 @@ static int hix5hd2_net_open(struct net_device *dev)
return ret;
}
 
-   priv->phy = of_phy_connect(dev, priv->phy_node,
-  &hix5hd2_adjust_link, 0, priv->phy_mode);
-   if (!priv->phy)
+   phy = of_phy_connect(dev, priv->phy_node,
+&hix5hd2_adjust_link, 0, priv->phy_mode);
+   if (!phy)
return -ENODEV;
 
-   phy_start(priv->phy);
+   phy_start(phy);
hix5hd2_hw_init(priv);
hix5hd2_rx_refill(priv);
 
@@ -716,9 +716,9 @@ static int hix5hd2_net_close(struct net_device *dev)
netif_stop_queue(dev);
hix5hd2_free_dma_desc_rings(priv);
 
-   if (priv->phy) {
-   phy_stop(priv->phy);
-   phy_disconnect(priv->phy);
+   if (dev->phydev) {
+   phy_stop(dev->phydev);
+   phy_disconnect(dev->phydev);
}
 
clk_disable_unprepare(priv->clk);
@@ -753,23 +753,19 @@ static const struct net_device_ops hix5hd2_netdev_ops = {
 static int hix5hd2_get_settings(struct net_device *net_dev,
struct ethtool_cmd *cmd)
 {
-   struct hix5hd2_priv *priv = netdev_priv(net_dev);
-
-   if (!priv->phy)
+   if (!net_dev->phydev)
return -ENODEV;
 
-   return phy_ethtool_gset(priv->phy, cmd);
+   return phy_ethtool_gset(net_dev->phydev, cmd);
 }
 
 static int hix5hd2_set_settings(struct net_device *net_dev,
struct ethtool_cmd *cmd)
 {
-   struct hix5hd2_priv *priv = netdev_priv(net_dev);
-
-   if (!priv->phy)
+   if (!net_dev->phydev)
return -ENODEV;
 
-   return phy_ethtool_sset(priv->phy, cmd);
+   return phy_ethtool_sset(net_dev->phydev, cmd);
 }
 
 static struct ethtool_ops hix5hd2_ethtools_ops = {
-- 
1.7.4.4

[PATCH 1/2] net: ethernet: ethoc: use phydev from struct net_device

[Philippe Reynes]

The private structure contain a pointer to phydev, but the structure
net_device already contain such pointer. So we can remove the pointer
phy in the private structure, and update the driver to use the
one contained in struct net_device.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/ethoc.c |   19 +++
 1 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 4edb98c..fe09021 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -219,7 +219,6 @@ struct ethoc {
 
spinlock_t lock;
 
-   struct phy_device *phy;
struct mii_bus *mdio;
struct clk *clk;
s8 phy_id;
@@ -694,7 +693,6 @@ static int ethoc_mdio_probe(struct net_device *dev)
return err;
}
 
-   priv->phy = phy;
phy->advertising &= ~(ADVERTISED_1000baseT_Full |
  ADVERTISED_1000baseT_Half);
phy->supported &= ~(SUPPORTED_1000baseT_Full |
@@ -724,7 +722,7 @@ static int ethoc_open(struct net_device *dev)
netif_start_queue(dev);
}
 
-   phy_start(priv->phy);
+   phy_start(dev->phydev);
napi_enable(&priv->napi);
 
if (netif_msg_ifup(priv)) {
@@ -741,8 +739,8 @@ static int ethoc_stop(struct net_device *dev)
 
napi_disable(&priv->napi);
 
-   if (priv->phy)
-   phy_stop(priv->phy);
+   if (dev->phydev)
+   phy_stop(dev->phydev);
 
ethoc_disable_rx_and_tx(priv);
free_irq(dev->irq, dev);
@@ -770,7 +768,7 @@ static int ethoc_ioctl(struct net_device *dev, struct ifreq 
*ifr, int cmd)
if (!phy)
return -ENODEV;
} else {
-   phy = priv->phy;
+   phy = dev->phydev;
}
 
return phy_mii_ioctl(phy, ifr, cmd);
@@ -899,8 +897,7 @@ out:
 
 static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
-   struct ethoc *priv = netdev_priv(dev);
-   struct phy_device *phydev = priv->phy;
+   struct phy_device *phydev = dev->phydev;
 
if (!phydev)
return -EOPNOTSUPP;
@@ -910,8 +907,7 @@ static int ethoc_get_settings(struct net_device *dev, 
struct ethtool_cmd *cmd)
 
 static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
-   struct ethoc *priv = netdev_priv(dev);
-   struct phy_device *phydev = priv->phy;
+   struct phy_device *phydev = dev->phydev;
 
if (!phydev)
return -EOPNOTSUPP;
@@ -1261,8 +1257,7 @@ static int ethoc_remove(struct platform_device *pdev)
 
if (netdev) {
netif_napi_del(&priv->napi);
-   phy_disconnect(priv->phy);
-   priv->phy = NULL;
+   phy_disconnect(netdev->phydev);
 
if (priv->mdio) {
mdiobus_unregister(priv->mdio);
-- 
1.7.4.4

[PATCH 2/2] net: ethernet: ethoc: use phy_ethtool_{get|set}_link_ksettings

[Philippe Reynes]

There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/ethoc.c |   24 ++--
 1 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index fe09021..37fbf51 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -895,26 +895,6 @@ out:
return NETDEV_TX_OK;
 }
 
-static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
-{
-   struct phy_device *phydev = dev->phydev;
-
-   if (!phydev)
-   return -EOPNOTSUPP;
-
-   return phy_ethtool_gset(phydev, cmd);
-}
-
-static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
-{
-   struct phy_device *phydev = dev->phydev;
-
-   if (!phydev)
-   return -EOPNOTSUPP;
-
-   return phy_ethtool_sset(phydev, cmd);
-}
-
 static int ethoc_get_regs_len(struct net_device *netdev)
 {
return ETH_END;
@@ -979,14 +959,14 @@ static int ethoc_set_ringparam(struct net_device *dev,
 }
 
 const struct ethtool_ops ethoc_ethtool_ops = {
-   .get_settings = ethoc_get_settings,
-   .set_settings = ethoc_set_settings,
.get_regs_len = ethoc_get_regs_len,
.get_regs = ethoc_get_regs,
.get_link = ethtool_op_get_link,
.get_ringparam = ethoc_get_ringparam,
.set_ringparam = ethoc_set_ringparam,
.get_ts_info = ethtool_op_get_ts_info,
+   .get_link_ksettings = phy_ethtool_get_link_ksettings,
+   .set_link_ksettings = phy_ethtool_set_link_ksettings,
 };
 
 static const struct net_device_ops ethoc_netdev_ops = {
-- 
1.7.4.4

Re: [PATCH net] Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address

[Linus Lüssing]

On Fri, Jun 24, 2016 at 12:35:18PM +0200, Daniel Danzberger wrote:
> The bridge is falsly dropping ipv6 mulitcast packets if there is:
>  1. No ipv6 address assigned on the brigde.
>  2. No external mld querier present.
>  3. The internal querier enabled.
> 
> When the bridge fails to build mld queries, because it has no
> ipv6 address, it slilently returns, but keeps the local querier enabled.
> This specific case causes confusing packet loss.
> 
> Ipv6 multicast snooping can only work if:
>  a) An external querier is present
>  OR
>  b) The bridge has an ipv6 address an is capable of sending own queries
> 
> Otherwise it has to forward/flood the ipv6 multicast traffic,
> because snooping cannot work.
> 
> This patch fixes the issue by adding a flag to the bridge struct that
> indicates that there is currently no ipv6 address assinged to the bridge
> and returns a false state for the local querier in
> __br_multicast_querier_exists().

Fixes: 1d81d4c3dd88 ("bridge: check return value of ipv6_dev_get_saddr()")

Re: [PATCH] samples/bpf: set resource limit to infinity.

[William Tu]

Hi Alexei,

Thanks. I will do it next time.
William

On Sat, Jun 25, 2016 at 3:14 AM, Alexei Starovoitov
 wrote:
> On Fri, Jun 24, 2016 at 03:55:24PM -0700, William Tu wrote:
>> Signed-off-by: William Tu 
>
> Acked-by: Alexei Starovoitov 
>
> please provide a proper patch description next time.
> subj line alone is not enough.
> Not only explain 'what' the patch does, but 'why' as well.
>

Re: [PATCH] samples/bpf: set resource limit to infinity.

[Alexei Starovoitov]

On Fri, Jun 24, 2016 at 03:55:24PM -0700, William Tu wrote:
> Signed-off-by: William Tu 

Acked-by: Alexei Starovoitov 

please provide a proper patch description next time.
subj line alone is not enough.
Not only explain 'what' the patch does, but 'why' as well.

Re: [PATCH iptables 3/3] libxt_hashlimit: iptables-restore does not work as expected with xt_hashlimit

[Pablo Neira Ayuso]

Hi,

On Fri, Jun 24, 2016 at 02:24:18PM -0400, Vishwanath Pai wrote:
> On 06/23/2016 06:25 AM, Pablo Neira Ayuso wrote:
> > On Wed, Jun 01, 2016 at 08:17:59PM -0400, Vishwanath Pai wrote:
> >> libxt_hashlimit: iptables-restore does not work as expected with 
> >> xt_hashlimit
> >>
> >> Add the following iptables rule.
> >>
> >> $ iptables -A INPUT -m hashlimit --hashlimit-above 200/sec \
> >>   --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name hashlimit1 \
> >>   --hashlimit-htable-expire 3 -j DROP
> >>
> >> $ iptables-save > save.txt
> >>
> >> Edit save.txt and change the value of --hashlimit-above to 300:
> >>
> >> -A INPUT -m hashlimit --hashlimit-above 300/sec --hashlimit-burst 5 \
> >> --hashlimit-mode srcip --hashlimit-name hashlimit2 \
> >> --hashlimit-htable-expire 3 -j DROP
> >>
> >> Now restore save.txt
> >>
> >> $ iptables-restore < save.txt
> > 
> > In this case, we don't end up with two rules, we actually get one
> > single hashlimit rule, given the sequence you provide.
> > 
> > $ iptables-save > save.txt
> > ... edit save.txt
> > $ iptables-restore < save.txt
> > 
> 
> Yes, we end up with just one rule, but the kernel data structure is not
> updated. Userspace thinks the value is 300/s but in the kernel it is
> still 200/s.

Right, but the main point of this is to honor the new rule
configuration, ie. to update the internal hashlimit configuration of
the previous rules.

> >> Now userspace thinks that the value of --hashlimit-above is 300 but it is
> >> actually 200 in the kernel. This happens because when we add multiple
> >> hash-limit rules with the same name they will share the same hashtable
> >> internally. The kernel module tries to re-use the old hashtable without
> >> updating the values.
> >>
> >> There are multiple problems here:
> >> 1) We can add two iptables rules with the same name, but kernel does not
> >>handle this well, one procfs file cannot work with two rules
> >> 2) If the second rule has no effect because the hashtable has values from
> >>rule 1
> >> 3) hashtable-restore does not work (as described above)
> >>
> >> To fix this I have made the following design change:
> >> 1) If a second rule is added with the same name as an existing rule,
> >>append a number when we create the procfs, for example hashlimit_1,
> >>hashlimit_2 etc
> >> 2) Two rules will not share the same hashtable unless they are similar in
> >>every possible way
> >> 3) This behavior has to be forced with a new userspace flag:
> >>--hashlimit-ehanced-procfs, if this flag is not passed we default to
> >>the old behavior. This is to make sure we do not break existing scripts
> >>that rely on the existing behavior.
> > 
> > We discussed this in netdev0.1, and I think we agreed on adding a new
> > option, something like --hashlimit-update that would force an update
> > to the existing hashlimit internal state (that is identified by the
> > hashlimit name).
> > 
> > I think the problem here is that you may want to update the internal
> > state of an existing hashlimit object, and currently this is not
> > actually happening.
> > 
> > With the explicit --hashlimit-update flag, from the kernel we really
> > know that the user wants an update.
> > 
> > Let me know, thanks.
> 
> Yes, I believe you had a discussion about this with Josh Hunt. This
> patch does add a new option, but it is called -enhanced-procfs instead.
> I am open to renaming this to something else. I chose this name because
> this patch will affect the names of the procfs files when multiple rules
> with the same name exist. This generally does not happen, but is a side
> effect of the way we create these files. In the case of restore example
> above - we get the call to "hashlimit_mt_check" for the new rule before
> the old rule is deleted, so there is a short window where we have two
> rules in the kernel with the same name.

I see, but I'm not convinced about this /proc rename feature.

I think the main point of this, as well as other entries in bugzilla
related to this, is ability to update an existing hashlimit state.

So, I'm not proposing to rename --enhanced-procfs to something else,
I think that a different approach consisting on adding a new option
like --hashlimit-update that will update the internal state of an
existing hashlimit object is just fine for your usecase, right?

> Other than that, we are doing exactly what you said, but creating a new
> entry in the hashtable instead of updating it. The previous entry will
> automatically be removed when the old rule is flushed/deleted.

What I'm missing is why we need this /proc rename at all.

Re: [PATCH] net: ethernet: ti: cpdma: switch to use genalloc

[Afzal Mohammed]

Hi,

On Fri, Jun 24, 2016 at 12:15:41PM -0400, Lennart Sorensen wrote:

> although the style does require using brackets for the else if the
> if required them.

As an aside, though most of the style rationale is K & R, K & R
consistently uses unbalanced braces for if-else-*

For a one that learns C unadultered from K & R, probably Kernel coding
style comes naturally, except for trivial things like above.

...a brick for the shed.

Regards
afzal