* Re: [PATCH 0/4] support GMAC driver for RK3288
From: Kever Yang @ 2014-11-26 4:05 UTC (permalink / raw)
To: Roger Chen, heiko
Cc: peppe.cavallaro, netdev, linux-kernel, linux-rockchip, mark.yao,
eddie.cai
In-Reply-To: <1416906460-26078-1-git-send-email-roger.chen@rock-chips.com>
Hi Roger,
Please use the --in-reply-to option for patches other than 0/4
with the git send-email.
On 11/25/2014 05:07 PM, Roger Chen wrote:
> Roger Chen (4):
> patch1: add driver for Rockchip RK3288 SoCs integrated GMAC
> patch2: modify CRU config for Rockchip RK3288 SoCs integrated GMAC
> patch3: dts: add gmac info for rk3288
> patch4: dts: enable gmac on RK3288 evb board
>
> tested on rk3288 SDK board:
> busybox ifconfig eth0 up
> busybox ifconfig eth0 192.168.1.111
> ping 192.168.1.1
>
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Scott Feldman @ 2014-11-26 4:18 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Thomas Graf, Jiri Pirko, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <54754A10.6020601@mojatatu.com>
On Tue, Nov 25, 2014 at 5:33 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 11/25/14 16:54, Thomas Graf wrote:
>>
>> On 11/25/14 at 12:08pm, Jamal Hadi Salim wrote:
>
>
>> It would definitely help if you could expose some more details on the
>> "some network processor" you have. We're all very eager ;-)
>>
>
> Well, this thing doesnt run ovs ;-> (/me runs). If you come
> to netdev i may let you play with it ;-> Its a humongous device
> (think multi 100G ports).
>
> On a serious note: Even if you took what Simon/Netronome has
> (yes, I know they use ovs;->) - there is really no need for a switch
> abstraction *at all* if all you want to is hang a packet
> processing graph that ingresses at a port and egress at another port.
> As you know, Linux supports it just fine with tc.
You have a pointer to the kernel driver for that HW? Can you show how
you're using Linux tc netlink msg in kernel to program HW? I'd like
to see the in-kernel API.
^ permalink raw reply
* Multiple DSA switch on shared MII
From: Rajib Karmakar @ 2014-11-26 4:52 UTC (permalink / raw)
To: netdev
Hello,
I am developing a DSA driver for Marvell 6172 and need to create 2 dsa
switch chip (one for WAN and one for LAN).
My device has 2 MACs and one shared mii_bus. I have added two
dsa_platform_data structures and registered them but cannot probe as
dsa_probe tries mdio_register() on the same bus and fails.
Is it possible to create two DSA switch on same (shared) mii?
Regards,
Rajib
^ permalink raw reply
* [PATCH net-next 0/3] net: bcmgenet: EEE support
From: Florian Fainelli @ 2014-11-26 5:16 UTC (permalink / raw)
To: netdev; +Cc: davem, pgynther, Florian Fainelli
Hi David,
This patch series add EEE support to the Broadcom GENET driver, first patch
basically adds register definitions for the hardware, the second patch does the
actual implementation and hooks the {get,set}_eee ethtool callbacks, the last
patch adds auto-negotiation restart capability.
Thanks!
Florian Fainelli (3):
net: bcmgenet: add register definitions for EEE
net: bcmgenet: add EEE support
net: bcmgenet: support restarting auto-negotiation
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 104 +++++++++++++++++++++++++
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 26 +++++++
2 files changed, 130 insertions(+)
--
2.1.0
^ permalink raw reply
* [PATCH net-next 1/3] net: bcmgenet: add register definitions for EEE
From: Florian Fainelli @ 2014-11-26 5:16 UTC (permalink / raw)
To: netdev; +Cc: davem, pgynther, Florian Fainelli
In-Reply-To: <1416978996-24808-1-git-send-email-f.fainelli@gmail.com>
Add register definitions to control EEE in the UniMAC, RBUF and TBUF
register ranges.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index c4ca7282a601..ea6f0ab566bf 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -185,6 +185,21 @@ struct bcmgenet_mib_counters {
#define UMAC_MAC1 0x010
#define UMAC_MAX_FRAME_LEN 0x014
+#define UMAC_EEE_CTRL 0x064
+#define EN_LPI_RX_PAUSE (1 << 0)
+#define EN_LPI_TX_PFC (1 << 1)
+#define EN_LPI_TX_PAUSE (1 << 2)
+#define EEE_EN (1 << 3)
+#define RX_FIFO_CHECK (1 << 4)
+#define EEE_TX_CLK_DIS (1 << 5)
+#define DIS_EEE_10M (1 << 6)
+#define LP_IDLE_PREDICTION_MODE (1 << 7)
+
+#define UMAC_EEE_LPI_TIMER 0x068
+#define UMAC_EEE_WAKE_TIMER 0x06C
+#define UMAC_EEE_REF_COUNT 0x070
+#define EEE_REFERENCE_COUNT_MASK 0xffff
+
#define UMAC_TX_FLUSH 0x334
#define UMAC_MIB_START 0x400
@@ -232,6 +247,10 @@ struct bcmgenet_mib_counters {
#define RBUF_RXCHK_EN (1 << 0)
#define RBUF_SKIP_FCS (1 << 4)
+#define RBUF_ENERGY_CTRL 0x9c
+#define RBUF_EEE_EN (1 << 0)
+#define RBUF_PM_EN (1 << 1)
+
#define RBUF_TBUF_SIZE_CTRL 0xb4
#define RBUF_HFB_CTRL_V1 0x38
@@ -247,6 +266,9 @@ struct bcmgenet_mib_counters {
#define TBUF_CTRL 0x00
#define TBUF_BP_MC 0x0C
+#define TBUF_ENERGY_CTRL 0x14
+#define TBUF_EEE_EN (1 << 0)
+#define TBUF_PM_EN (1 << 1)
#define TBUF_CTRL_V1 0x80
#define TBUF_BP_MC_V1 0xA0
--
2.1.0
^ permalink raw reply related
* [PATCH net-next 2/3] net: bcmgenet: add EEE support
From: Florian Fainelli @ 2014-11-26 5:16 UTC (permalink / raw)
To: netdev; +Cc: davem, pgynther, Florian Fainelli
In-Reply-To: <1416978996-24808-1-git-send-email-f.fainelli@gmail.com>
Allow enabling and disabling EEE using the designated ethtool getters
and setters. GENET allows controlling EEE at the UniMAC, RBUF and TBUF
levels. We also take care of restoring EEE after a suspend/resume cycle
if it was enabled prior to suspending.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 96 ++++++++++++++++++++++++++
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 4 ++
2 files changed, 100 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index fcbf1255ae5a..bf44e0e23799 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -714,6 +714,91 @@ static void bcmgenet_get_ethtool_stats(struct net_device *dev,
}
}
+static void bcmgenet_eee_enable_set(struct net_device *dev, bool enable)
+{
+ struct bcmgenet_priv *priv = netdev_priv(dev);
+ u32 off = priv->hw_params->tbuf_offset + TBUF_ENERGY_CTRL;
+ u32 reg;
+
+ if (enable && !priv->clk_eee_enabled) {
+ clk_prepare_enable(priv->clk_eee);
+ priv->clk_eee_enabled = true;
+ }
+
+ reg = bcmgenet_umac_readl(priv, UMAC_EEE_CTRL);
+ if (enable)
+ reg |= EEE_EN;
+ else
+ reg &= ~EEE_EN;
+ bcmgenet_umac_writel(priv, reg, UMAC_EEE_CTRL);
+
+ /* Enable EEE and switch to a 27Mhz clock automatically */
+ reg = __raw_readl(priv->base + off);
+ if (enable)
+ reg |= TBUF_EEE_EN | TBUF_PM_EN;
+ else
+ reg &= ~(TBUF_EEE_EN | TBUF_PM_EN);
+ __raw_writel(reg, priv->base + off);
+
+ /* Do the same for thing for RBUF */
+ reg = bcmgenet_rbuf_readl(priv, RBUF_ENERGY_CTRL);
+ if (enable)
+ reg |= RBUF_EEE_EN | RBUF_PM_EN;
+ else
+ reg &= ~(RBUF_EEE_EN | RBUF_PM_EN);
+ bcmgenet_rbuf_writel(priv, reg, RBUF_ENERGY_CTRL);
+
+ if (!enable && priv->clk_eee_enabled) {
+ clk_disable_unprepare(priv->clk_eee);
+ priv->clk_eee_enabled = false;
+ }
+
+ priv->eee.eee_enabled = enable;
+ priv->eee.eee_active = enable;
+}
+
+static int bcmgenet_get_eee(struct net_device *dev, struct ethtool_eee *e)
+{
+ struct bcmgenet_priv *priv = netdev_priv(dev);
+ struct ethtool_eee *p = &priv->eee;
+
+ if (GENET_IS_V1(priv))
+ return -EOPNOTSUPP;
+
+ e->eee_enabled = p->eee_enabled;
+ e->eee_active = p->eee_active;
+ e->tx_lpi_timer = bcmgenet_umac_readl(priv, UMAC_EEE_LPI_TIMER);
+
+ return phy_ethtool_get_eee(priv->phydev, e);
+}
+
+static int bcmgenet_set_eee(struct net_device *dev, struct ethtool_eee *e)
+{
+ struct bcmgenet_priv *priv = netdev_priv(dev);
+ struct ethtool_eee *p = &priv->eee;
+ int ret = 0;
+
+ if (GENET_IS_V1(priv))
+ return -EOPNOTSUPP;
+
+ p->eee_enabled = e->eee_enabled;
+
+ if (!p->eee_enabled) {
+ bcmgenet_eee_enable_set(dev, false);
+ } else {
+ ret = phy_init_eee(priv->phydev, 0);
+ if (ret) {
+ netif_err(priv, hw, dev, "EEE initialization failed\n");
+ return ret;
+ }
+
+ bcmgenet_umac_writel(priv, e->tx_lpi_timer, UMAC_EEE_LPI_TIMER);
+ bcmgenet_eee_enable_set(dev, true);
+ }
+
+ return phy_ethtool_set_eee(priv->phydev, e);
+}
+
/* standard ethtool support functions. */
static struct ethtool_ops bcmgenet_ethtool_ops = {
.get_strings = bcmgenet_get_strings,
@@ -727,6 +812,8 @@ static struct ethtool_ops bcmgenet_ethtool_ops = {
.set_msglevel = bcmgenet_set_msglevel,
.get_wol = bcmgenet_get_wol,
.set_wol = bcmgenet_set_wol,
+ .get_eee = bcmgenet_get_eee,
+ .set_eee = bcmgenet_set_eee,
};
/* Power down the unimac, based on mode. */
@@ -2585,6 +2672,12 @@ static int bcmgenet_probe(struct platform_device *pdev)
if (IS_ERR(priv->clk_wol))
dev_warn(&priv->pdev->dev, "failed to get enet-wol clock\n");
+ priv->clk_eee = devm_clk_get(&priv->pdev->dev, "enet-eee");
+ if (IS_ERR(priv->clk_eee)) {
+ dev_warn(&priv->pdev->dev, "failed to get enet-eee clock\n");
+ priv->clk_eee = NULL;
+ }
+
err = reset_umac(priv);
if (err)
goto err_clk_disable;
@@ -2735,6 +2828,9 @@ static int bcmgenet_resume(struct device *d)
phy_resume(priv->phydev);
+ if (priv->eee.eee_enabled)
+ bcmgenet_eee_enable_set(dev, true);
+
bcmgenet_netif_start(dev);
return 0;
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index ea6f0ab566bf..b36ddec0cc0a 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -573,6 +573,8 @@ struct bcmgenet_priv {
struct device_node *phy_dn;
struct mii_bus *mii_bus;
u16 gphy_rev;
+ struct clk *clk_eee;
+ bool clk_eee_enabled;
/* PHY device variables */
int old_link;
@@ -609,6 +611,8 @@ struct bcmgenet_priv {
u32 wolopts;
struct bcmgenet_mib_counters mib;
+
+ struct ethtool_eee eee;
};
#define GENET_IO_MACRO(name, offset) \
--
2.1.0
^ permalink raw reply related
* [PATCH net-next 3/3] net: bcmgenet: support restarting auto-negotiation
From: Florian Fainelli @ 2014-11-26 5:16 UTC (permalink / raw)
To: netdev; +Cc: davem, pgynther, Florian Fainelli
In-Reply-To: <1416978996-24808-1-git-send-email-f.fainelli@gmail.com>
Hook a nway_reset ethtool callback to allow restarting the
auto-negotiation process when asked to. We defer to the PHY library call
to do the heavy lifting.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index bf44e0e23799..f2fadb053d52 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -799,6 +799,13 @@ static int bcmgenet_set_eee(struct net_device *dev, struct ethtool_eee *e)
return phy_ethtool_set_eee(priv->phydev, e);
}
+static int bcmgenet_nway_reset(struct net_device *dev)
+{
+ struct bcmgenet_priv *priv = netdev_priv(dev);
+
+ return genphy_restart_aneg(priv->phydev);
+}
+
/* standard ethtool support functions. */
static struct ethtool_ops bcmgenet_ethtool_ops = {
.get_strings = bcmgenet_get_strings,
@@ -814,6 +821,7 @@ static struct ethtool_ops bcmgenet_ethtool_ops = {
.set_wol = bcmgenet_set_wol,
.get_eee = bcmgenet_get_eee,
.set_eee = bcmgenet_set_eee,
+ .nway_reset = bcmgenet_nway_reset,
};
/* Power down the unimac, based on mode. */
--
2.1.0
^ permalink raw reply related
* Re: Multiple DSA switch on shared MII
From: Florian Fainelli @ 2014-11-26 5:22 UTC (permalink / raw)
To: Rajib Karmakar; +Cc: netdev
In-Reply-To: <CAOi_9k8NwpVFxg=9VOagVt3m6hn2uLKuCZ_0-+4PciJNRWuTmA@mail.gmail.com>
2014-11-25 20:52 GMT-08:00 Rajib Karmakar <rajibkit@gmail.com>:
> Hello,
>
> I am developing a DSA driver for Marvell 6172 and need to create 2 dsa
> switch chip (one for WAN and one for LAN).
This is not typically how it is designed to work, you would register
one dsa switch chip with the ports assignment in this data structure.
Right now, DSA does not support a dual Ethernet MAC configuration,
although you could probably do per-port VLAN membership and create two
default VLANs to allow that.
>
> My device has 2 MACs and one shared mii_bus. I have added two
> dsa_platform_data structures and registered them but cannot probe as
> dsa_probe tries mdio_register() on the same bus and fails.
>
> Is it possible to create two DSA switch on same (shared) mii?
Not in its current form, and I am not exactly sure how we would support that.
>
> Regards,
> Rajib
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Florian
^ permalink raw reply
* [PATCH net-next] ipvlan: fix sparse warnings
From: Mahesh Bandewar @ 2014-11-26 5:24 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Mahesh Bandewar
Fix sparse warnings reported by kbuild robot
drivers/net/ipvlan/ipvlan_main.c:172:13: warning: symbol 'ipvlan_start_xmit' was not declared. Should it be static?
drivers/net/ipvlan/ipvlan_main.c:256:33: warning: incorrect type in initializer (different address spaces)
drivers/net/ipvlan/ipvlan_main.c:256:33: expected void const [noderef] <asn:3>*__vpp_verify
drivers/net/ipvlan/ipvlan_main.c:256:33: got struct ipvl_pcpu_stats *<noident>
drivers/net/ipvlan/ipvlan_main.c:544:5: warning: symbol 'ipvlan_link_register' was not declared. Should it be static
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/ipvlan/ipvlan_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index c3df84bd2857..96b71b0d78f6 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -169,7 +169,8 @@ static int ipvlan_stop(struct net_device *dev)
return 0;
}
-netdev_tx_t ipvlan_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t ipvlan_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
const struct ipvl_dev *ipvlan = netdev_priv(dev);
int skblen = skb->len;
@@ -541,7 +542,7 @@ static struct rtnl_link_ops ipvlan_link_ops = {
.dellink = ipvlan_link_delete,
};
-int ipvlan_link_register(struct rtnl_link_ops *ops)
+static int ipvlan_link_register(struct rtnl_link_ops *ops)
{
return rtnl_link_register(ops);
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next] tun/macvtap: use consume_skb() instead of kfree_skb() in tun/macvtap_do_read()
From: Jason Wang @ 2014-11-26 6:08 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: mst, Jason Wang
To be more friendly with drop monitor, we should use comsume_skb() instead
of kfree_skb() in tun/macvtap_do_read(). Otherwise, the packets will be
marked as dropped.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 2 +-
drivers/net/tun.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 42a80d3..74d1b23 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -862,7 +862,7 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
}
iov_iter_init(&iter, READ, iv, segs, len);
ret = macvtap_put_user(q, skb, &iter);
- kfree_skb(skb);
+ consume_skb(skb);
break;
}
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ac53a73..d7edeaf 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1363,7 +1363,7 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
iov_iter_init(&iter, READ, iv, segs, len);
ret = tun_put_user(tun, tfile, skb, &iter);
- kfree_skb(skb);
+ consume_skb(skb);
return ret;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next] tun/macvtap: use consume_skb() instead of kfree_skb() in tun/macvtap_do_read()
From: Eric Dumazet @ 2014-11-26 6:26 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, mst
In-Reply-To: <1416982084-12212-1-git-send-email-jasowang@redhat.com>
On Wed, 2014-11-26 at 14:08 +0800, Jason Wang wrote:
> To be more friendly with drop monitor, we should use comsume_skb() instead
> of kfree_skb() in tun/macvtap_do_read(). Otherwise, the packets will be
> marked as dropped.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/macvtap.c | 2 +-
> drivers/net/tun.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 42a80d3..74d1b23 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -862,7 +862,7 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
> }
> iov_iter_init(&iter, READ, iv, segs, len);
> ret = macvtap_put_user(q, skb, &iter);
> - kfree_skb(skb);
> + consume_skb(skb);
> break;
> }
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index ac53a73..d7edeaf 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1363,7 +1363,7 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
>
> iov_iter_init(&iter, READ, iv, segs, len);
> ret = tun_put_user(tun, tfile, skb, &iter);
> - kfree_skb(skb);
> + consume_skb(skb);
>
> return ret;
> }
These patches keep going on, but they are wrong.
If you care about drop monitor, then you want to not hide drops but
precisely report them.
Surely tun_put_user() can return an error, and then packet _is_ dropped.
^ permalink raw reply
* Re: [PATCH net-next] tun/macvtap: use consume_skb() instead of kfree_skb() in tun/macvtap_do_read()
From: Jason Wang @ 2014-11-26 6:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, linux-kernel, mst
In-Reply-To: <1416983160.29427.52.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/26/2014 02:26 PM, Eric Dumazet wrote:
> On Wed, 2014-11-26 at 14:08 +0800, Jason Wang wrote:
>> To be more friendly with drop monitor, we should use comsume_skb() instead
>> of kfree_skb() in tun/macvtap_do_read(). Otherwise, the packets will be
>> marked as dropped.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/net/macvtap.c | 2 +-
>> drivers/net/tun.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>> index 42a80d3..74d1b23 100644
>> --- a/drivers/net/macvtap.c
>> +++ b/drivers/net/macvtap.c
>> @@ -862,7 +862,7 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
>> }
>> iov_iter_init(&iter, READ, iv, segs, len);
>> ret = macvtap_put_user(q, skb, &iter);
>> - kfree_skb(skb);
>> + consume_skb(skb);
>> break;
>> }
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index ac53a73..d7edeaf 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1363,7 +1363,7 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
>>
>> iov_iter_init(&iter, READ, iv, segs, len);
>> ret = tun_put_user(tun, tfile, skb, &iter);
>> - kfree_skb(skb);
>> + consume_skb(skb);
>>
>> return ret;
>> }
>
> These patches keep going on, but they are wrong.
>
> If you care about drop monitor, then you want to not hide drops but
> precisely report them.
>
> Surely tun_put_user() can return an error, and then packet _is_ dropped.
True, I miss this. Will post V2. Thanks
^ permalink raw reply
* Re: [PATCH net-next v4] ipvlan: Initial check-in of the IPVLAN driver.
From: Toshiaki Makita @ 2014-11-26 6:41 UTC (permalink / raw)
To: Mahesh Bandewar, netdev
Cc: Eric Dumazet, Maciej Zenczykowski, Laurent Chavey, Tim Hockin,
David Miller, Brandon Philips, Pavel Emelianov
In-Reply-To: <1416812866-13401-1-git-send-email-maheshb@google.com>
Hi Mahesh,
I found that deleting the last ipvlan device triggers WARN_ON() in
rtmsg_ifinfo().
ipvlan_nl_fillinfo() seems to return -EINVAL in that case.
> +static int ipvlan_nl_fillinfo(struct sk_buff *skb,
> + const struct net_device *dev)
> +{
> + struct ipvl_dev *ipvlan = netdev_priv(dev);
> + struct ipvl_port *port = ipvlan_port_get_rtnl(ipvlan->phy_dev);
> + int ret = -EINVAL;
> +
> + if (!port)
> + goto err;
> +
> + ret = -EMSGSIZE;
> + if (nla_put_u16(skb, IFLA_IPVLAN_MODE, port->mode))
> + goto err;
> +
> + return 0;
> +
> +err:
> + return ret;
> +}
rollback_registered_many() calls rtmsg_ifinfo() after calling ndo_uninit().
ndo_uninit() (ipvlan_uninit() -> ipvlan_port_destroy() ->
netdev_rx_handler_unregister()) sets rx_handler_data into NULL.
So, we cannot dereference "port" in ipvlan_nl_fillinfo().
Maybe "mode" should belong to struct ipvl_dev?
Thanks,
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH 1/2] virito: introduce methods of fixing device features
From: Jason Wang @ 2014-11-26 7:09 UTC (permalink / raw)
To: Rusty Russell; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <87sih9xv5u.fsf@rustcorp.com.au>
----- Original Message -----
> Jason Wang <jasowang@redhat.com> writes:
> > Buggy host may advertised buggy host features (a usual case is that host
> > advertise a feature whose dependencies were missed). In this case, driver
> > should detect and disable the buggy features by itself.
>
> Sorry, I've been focussing elsewhere.
>
> I would really prefer that drivers offer a "feature_depends" table,
> which can indicate that feature A depends on feature B, and have the
> core iterate, complain and fixup as necessary.
>
> Is that expressive enough, or do we need more?
>
> Thanks,
> Rusty.
I suggested something like this in https://lkml.org/lkml/2014/11/19/132, but
Michael does not like it ...
^ permalink raw reply
* Re: Multiple DSA switch on shared MII
From: Rajib Karmakar @ 2014-11-26 7:33 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <CAGVrzcaG_uYpmmgC252ObHJ9Cmt91-BUtB3uOfPJHV6RhkRU1Q@mail.gmail.com>
Hello Florian,
Thanks for your reply.
On Wed, Nov 26, 2014 at 10:52 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> 2014-11-25 20:52 GMT-08:00 Rajib Karmakar <rajibkit@gmail.com>:
>> Hello,
>>
>> I am developing a DSA driver for Marvell 6172 and need to create 2 dsa
>> switch chip (one for WAN and one for LAN).
>
> This is not typically how it is designed to work, you would register
> one dsa switch chip with the ports assignment in this data structure.
> Right now, DSA does not support a dual Ethernet MAC configuration,
> although you could probably do per-port VLAN membership and create two
> default VLANs to allow that.
>
>>
>> My device has 2 MACs and one shared mii_bus. I have added two
>> dsa_platform_data structures and registered them but cannot probe as
>> dsa_probe tries mdio_register() on the same bus and fails.
>>
>> Is it possible to create two DSA switch on same (shared) mii?
>
> Not in its current form, and I am not exactly sure how we would support that.
Yes, not with the current DSA implementation, but I can manage to
solve this by a small (ugly) patch - renamed the slave mii bus as
"<master_bus->id>:<pd->sw_addr>:<platform_device->id>" instead of
"<master_bus->id>:<pd->sw_addr>". Though I am not yet sure enough if
this could have any negative impact or not.
Comments please.
>
>>
>> Regards,
>> Rajib
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Florian
----
diff -rup org/net/dsa/dsa.c mod/net/dsa/dsa.c
--- org/net/dsa/dsa.c
+++ mod/net/dsa/dsa.c
@@ -68,7 +68,7 @@ dsa_switch_probe(struct mii_bus *bus, in
/* basic switch operations **************************************************/
static struct dsa_switch *
-dsa_switch_setup(struct dsa_switch_tree *dst, int index,
+dsa_switch_setup(struct dsa_switch_tree *dst, int index, int id,
struct device *parent, struct mii_bus *bus)
{
struct dsa_chip_data *pd = dst->pd->chip + index;
@@ -156,7 +156,7 @@ dsa_switch_setup(struct dsa_switch_tree
ret = -ENOMEM;
goto out;
}
- dsa_slave_mii_bus_init(ds);
+ dsa_slave_mii_bus_init(ds, id);
ret = mdiobus_register(ds->slave_mii_bus);
if (ret < 0)
@@ -349,7 +349,7 @@ static int dsa_probe(struct platform_dev
continue;
}
- ds = dsa_switch_setup(dst, i, &pdev->dev, bus);
+ ds = dsa_switch_setup(dst, i, pdev->id, &pdev->dev, bus);
if (IS_ERR(ds)) {
printk(KERN_ERR "%s[%d]: couldn't create dsa switch "
"instance (error %ld)\n", dev->name, i,
diff -rup org/net/dsa/dsa_priv.h mod/net/dsa/dsa_priv.h
--- org/net/dsa/dsa_priv.h
+++ mod/net/dsa/dsa_priv.h
@@ -163,7 +163,7 @@ void register_switch_driver(struct dsa_s
void unregister_switch_driver(struct dsa_switch_driver *type);
/* slave.c */
-void dsa_slave_mii_bus_init(struct dsa_switch *ds);
+void dsa_slave_mii_bus_init(struct dsa_switch *ds, int id);
struct net_device *dsa_slave_create(struct dsa_switch *ds,
struct device *parent,
int port, char *name);
diff -rup org/net/dsa/slave.c mod/net/dsa/slave.c
--- org/net/dsa/slave.c
+++ mod/net/dsa/slave.c
@@ -35,14 +35,14 @@ static int dsa_slave_phy_write(struct mi
return 0;
}
-void dsa_slave_mii_bus_init(struct dsa_switch *ds)
+void dsa_slave_mii_bus_init(struct dsa_switch *ds, int id)
{
ds->slave_mii_bus->priv = (void *)ds;
ds->slave_mii_bus->name = "dsa slave smi";
ds->slave_mii_bus->read = dsa_slave_phy_read;
ds->slave_mii_bus->write = dsa_slave_phy_write;
- snprintf(ds->slave_mii_bus->id, MII_BUS_ID_SIZE, "%s:%.2x",
- ds->master_mii_bus->id, ds->pd->sw_addr);
+ snprintf(ds->slave_mii_bus->id, MII_BUS_ID_SIZE, "%s:%.2x:%.1x",
+ ds->master_mii_bus->id, ds->pd->sw_addr, id);
ds->slave_mii_bus->parent = &ds->master_mii_bus->dev;
}
^ permalink raw reply
* RE: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Arad, Ronen @ 2014-11-26 7:35 UTC (permalink / raw)
To: netdev@vger.kernel.org
>@@ -2312,7 +2313,7 @@ errout:
> int ndo_dflt_fdb_add(struct ndmsg *ndm,
> struct nlattr *tb[],
> struct net_device *dev,
>- const unsigned char *addr,
>+ const unsigned char *addr, u16 vid,
> u16 flags)
> {
> int err = -EINVAL;
>@@ -2409,7 +2439,7 @@ out:
> int ndo_dflt_fdb_del(struct ndmsg *ndm,
> struct nlattr *tb[],
> struct net_device *dev,
>- const unsigned char *addr)
>+ const unsigned char *addr, u16 vid)
> {
> int err = -EINVAL;
What is the expected role of vid in ndo_dflt_fdb_add/ndo_dflt_fdb_del?
It is ignored in both functions.
Will the vid be passed to dev_uc_add/dev_uc_add_excl/dev_uc_del and similar dev_mc_xxx functions?
Will the device address lists become VLAN-aware?
^ permalink raw reply
* RE: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Arad, Ronen @ 2014-11-26 7:37 UTC (permalink / raw)
To: netdev@vger.kernel.org
> >>>
> >>> Is there any case where this fdb entry gets re-used and is no
> >>> longer added by an external learning? Should we clear this flag somewhere?
> >>
> >> Once the FDB entry is marked "added_by_external_learn" it stays
> >> marked as such until removed by aging cleanup process (or flushed
> >> due to interface down, etc). If aged out (and now deleted), the
> >> FDB entry may come back either by SW learn or by HW learn. If SW
> >> learn comes first, and then HW learn, HW learn will override and
> >> mark the existing FDB entry "added_by_external_learn". So there is
> >> take-over by HW but no give-back to SW. And there is no explicit
> >> clearing of the mark short of deleting the FDB entry. The mark is
> >> mostly for letting user's know which FDB entries where learned by
> >> HW and synced to the bridge's FDB.
> >
> > Thanks, makes sense now. This is probably obvious in this context,
> > but maybe it would not hurt to come up with a documentation that
> > describe the offload API, FDB entry lifetime and HW/SW ownership etc...
>
> I have an updated Documentation/networking/switchdev.txt that covers
> the swdev APIs and usage and notes, but Jiri is being stingy with it.
> Will get this out, either in v4 or follow-on patches. There is enough
> going on just with L2 offload that we're going to need some good
> documentation to guide implementers.
> --
To control the lifetime of an externally learned FDB entry, the bridge shall provide an API for the switch driver to update the freshness of externally learned entries. Otherwise, the bridge aging will age entries which are currently or frequently used by the HW.
Is this covered in the updated document?
Is this functionality planned for v4?
^ permalink raw reply
* Re: [PATCH v2 net-next 3/3] tuntap: reduce the size of tun_struct by using flex array.
From: Pankaj Gupta @ 2014-11-26 7:40 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, netdev, jasowang, dgibson, vfalico, edumazet,
vyasevic, hkchu, xemul, therbert, bhutchings, xii, stephen, jiri,
sergei shtylyov, Michael S. Tsirkin
In-Reply-To: <20141125.132717.122094133335261929.davem@davemloft.net>
>
> From: Pankaj Gupta <pagupta@redhat.com>
> Date: Tue, 25 Nov 2014 00:04:04 +0530
>
> > This patch switches to flex array to implement the flow caches, it brings
> > several advantages:
> >
> > - Reduce the size of the tun_struct structure, which allows us to increase
> > the
> > upper limit of queues in future.
> > - Avoid higher order memory allocation. It will be useful when switching to
> > pure hashing in flow cache which may demand a larger size array in
> > future.
> >
> > After this patch, the size of tun_struct on x86_64 reduced from 8512 to
> > 328
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> > Reviewed-by: David Gibson <dgibson@redhat.com>
>
> I see no reason to use flex arrays for this, you are preallocaing the
> memory so if anything flex array is adding an unnecessary level of
> redirection for every access in return for no real gains.
>
> Just allocate the thing normally using kzalloc() or whatever.
I agree. Will do the changes and submit v3.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH net-next V2] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
From: Jason Wang @ 2014-11-26 7:43 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: mst, Jason Wang, Eric Dumazet
To be more friendly with drop monitor, we should only call kfree_skb() when
the packets were dropped and use consume_skb() in other cases.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Changes from V1:
- check the return value of tun/macvtap_put_user()
---
drivers/net/macvtap.c | 5 ++++-
drivers/net/tun.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 42a80d3..c171ab6 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -862,7 +862,10 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
}
iov_iter_init(&iter, READ, iv, segs, len);
ret = macvtap_put_user(q, skb, &iter);
- kfree_skb(skb);
+ if (ret < 0)
+ kfree_skb(skb);
+ else
+ consume_skb(skb);
break;
}
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ac53a73..a21c130 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1363,7 +1363,10 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
iov_iter_init(&iter, READ, iv, segs, len);
ret = tun_put_user(tun, tfile, skb, &iter);
- kfree_skb(skb);
+ if (ret < 0)
+ kfree_skb(skb);
+ else
+ consume_skb(skb);
return ret;
}
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Jiri Pirko @ 2014-11-26 7:54 UTC (permalink / raw)
To: Thomas Graf
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <20141125221417.GF3912@casper.infradead.org>
Tue, Nov 25, 2014 at 11:14:17PM CET, tgraf@suug.ch wrote:
>On 11/25/14 at 11:28am, Jiri Pirko wrote:
>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass simple
>> u16 vid to drivers from there.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>I'm slightly confused ;-)
>
>We both argued that parsing Netlink attributes in the drivers is wrong.
>What happened to the plan of renaming ndo_fdb_ to ndo_neigh_ and
>introducing a non-Netlink in-kernel API for advanced usage by swdev?
Well the thing is that at the moment, it is not needed to call ndo_fdb_*
from inside the kernel. So the whole plan does not have to happen now.
Plus I saw the patches (Scott sent me) and I believe that they are
unnecessary complex. We can do this later if needed. Now, I would like
to stick with what we have so far, keep things simple.
^ permalink raw reply
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Jiri Pirko @ 2014-11-26 8:16 UTC (permalink / raw)
To: Scott Feldman
Cc: Florian Fainelli, Netdev, David S. Miller, nhorman@tuxdriver.com,
Andy Gospodarek, Thomas Graf, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim, Roopa Prabhu,
John Linville
In-Reply-To: <CAE4R7bCcB+HHDtULEdYA9uZUOtNJYL7edQQtfjh74wKQxxy-Lw@mail.gmail.com>
Wed, Nov 26, 2014 at 03:40:59AM CET, sfeldma@gmail.com wrote:
>On Tue, Nov 25, 2014 at 4:34 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 25/11/14 18:03, Scott Feldman wrote:
>>> On Tue, Nov 25, 2014 at 12:44 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>> On 25/11/14 02:28, Jiri Pirko wrote:
>>>>> From: Scott Feldman <sfeldma@gmail.com>
>>>>>
>>>>> When the swdev device learns a new mac/vlan on a port, it sends some async
>>>>> notification to the driver and the driver installs an FDB in the device.
>>>>> To give a holistic system view, the learned mac/vlan should be reflected
>>>>> in the bridge's FBD table, so the user, using normal iproute2 cmds, can view
>>>>> what is currently learned by the device. This API on the bridge driver gives
>>>>> a way for the swdev driver to install an FBD entry in the bridge FBD table.
>>>>> (And remove one).
>>>>>
>>>>> This is equivalent to the device running these cmds:
>>>>>
>>>>> bridge fdb [add|del] <mac> dev <dev> vid <vlan id> master
>>>>>
>>>>> This patch needs some extra eyeballs for review, in paricular around the
>>>>> locking and contexts.
>>>>>
>>>>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>>>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>>>> ---
>>>>
>>>> [snip]
>>>>
>>>>> + head = &br->hash[br_mac_hash(addr, vid)];
>>>>> + fdb = fdb_find(head, addr, vid);
>>>>> + if (!fdb) {
>>>>> + fdb = fdb_create(head, p, addr, vid);
>>>>> + if (!fdb) {
>>>>> + err = -ENOMEM;
>>>>> + goto err_unlock;
>>>>> + }
>>>>> + fdb->added_by_external_learn = 1;
>>>>> + fdb_notify(br, fdb, RTM_NEWNEIGH);
>>>>> + } else if (fdb->added_by_external_learn) {
>>>>> + /* Refresh entry */
>>>>> + fdb->updated = fdb->used = jiffies;
>>>>> + } else if (!fdb->added_by_user) {
>>>>> + /* Take over SW learned entry */
>>>>> + fdb->added_by_external_learn = 1;
>>>>> + fdb->updated = jiffies;
>>>>> + fdb_notify(br, fdb, RTM_NEWNEIGH);
>>>>> + }
>>>>
>>>> Is there any case where this fdb entry gets re-used and is no longer
>>>> added by an external learning? Should we clear this flag somewhere?
>>>
>>> Once the FDB entry is marked "added_by_external_learn" it stays marked
>>> as such until removed by aging cleanup process (or flushed due to
>>> interface down, etc). If aged out (and now deleted), the FDB entry
>>> may come back either by SW learn or by HW learn. If SW learn comes
>>> first, and then HW learn, HW learn will override and mark the existing
>>> FDB entry "added_by_external_learn". So there is take-over by HW but
>>> no give-back to SW. And there is no explicit clearing of the mark
>>> short of deleting the FDB entry. The mark is mostly for letting
>>> user's know which FDB entries where learned by HW and synced to the
>>> bridge's FDB.
>>
>> Thanks, makes sense now. This is probably obvious in this context, but
>> maybe it would not hurt to come up with a documentation that describe
>> the offload API, FDB entry lifetime and HW/SW ownership etc...
>
>I have an updated Documentation/networking/switchdev.txt that covers
>the swdev APIs and usage and notes, but Jiri is being stingy with it.
The doc update you mention includes also fib offload which we are not
pushing now. I have that patches in queue.
>Will get this out, either in v4 or follow-on patches. There is enough
>going on just with L2 offload that we're going to need some good
>documentation to guide implementers.
^ permalink raw reply
* Re: [PATCH 3/4] GMAC: dts: add gmac info for rk3288
From: Heiko Stübner @ 2014-11-26 8:47 UTC (permalink / raw)
To: Roger
Cc: Sergei Shtylyov, peppe.cavallaro, netdev, linux-kernel,
linux-rockchip, kever.yang, mark.yao, eddie.cai
In-Reply-To: <54753FAD.8040908@rock-chips.com>
Am Mittwoch, 26. November 2014, 10:49:17 schrieb Roger:
> On 2014/11/25 22:39, Heiko Stübner wrote:
> > Am Dienstag, 25. November 2014, 16:40:59 schrieb Sergei Shtylyov:
> >> Hello.
> >>
> >> On 11/25/2014 12:08 PM, Roger Chen wrote:
> >>> add gmac info in rk3288.dtsi for GMAC driver
> >>>
> >>> Signed-off-by: Roger Chen <roger.chen@rock-chips.com>
> >>> ---
> >>>
> >>> arch/arm/boot/dts/rk3288.dtsi | 59
> >>> +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59
> >>> insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/rk3288.dtsi
> >>> b/arch/arm/boot/dts/rk3288.dtsi
> >>> index 0f50d5d..949675d 100644
> >>> --- a/arch/arm/boot/dts/rk3288.dtsi
> >>> +++ b/arch/arm/boot/dts/rk3288.dtsi
> >>
> >> [...]
> >>
> >>> @@ -490,6 +497,25 @@
> >>>
> >>> reg = <0xff740000 0x1000>;
> >>>
> >>> };
> >>>
> >>> + gmac: eth@ff290000 {
> >>>
> >> Please name the node "ethernet@ff290000" to comply with the ePAPR
> >>
> >> standard.
> >>
> >>> + compatible = "rockchip,rk3288-gmac";
> >>> + reg = <0xff290000 0x10000>;
> >>> + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>; /*irq=59*/
> >>> + interrupt-names = "macirq";
> >>> + rockchip,grf = <&grf>;
> >>> + clocks = <&cru SCLK_MAC>, <&cru SCLK_MAC_PLL>,
> >>> + <&cru SCLK_MAC_RX>, <&cru SCLK_MAC_TX>,
> >>> + <&cru SCLK_MACREF>, <&cru SCLK_MACREF_OUT>,
> >>> + <&cru ACLK_GMAC>, <&cru PCLK_GMAC>;
> >>> + clock-names = "stmmaceth", "clk_mac_pll",
> >>> + "mac_clk_rx", "mac_clk_tx",
> >>> + "clk_mac_ref", "clk_mac_refout",
> >>> + "aclk_mac", "pclk_mac";
> >>> + phy-mode = "rgmii";
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&rgmii_pin /*&rmii_pin*/>;
> >>>
> >> Hm, pinctrl props in a .dtsi file? Those are usually board
> >> dependent.
> >
> > yep, especially as there is a board-dependent selection needed of what to
> > use [rgmii or rmii] depending on the phy on the board.
>
> of course pinctrl props is redefined in the rk3288-evb-rk808.dts,
> IMO, pinctrl props in .dtsi is used to fit for the "phy-mode" prop as
> default. if pinctrl props should be removed, how about "phy-mode" prop?
yep, the phy-mode should also move to the board file - as it of course also
depends on the phy-chip used there.
^ permalink raw reply
* [PATCH] x86: bpf_jit_comp: simplify trivial boolean return
From: Quentin Lambert @ 2014-11-26 9:18 UTC (permalink / raw)
To: David S. Miller
Cc: Quentin Lambert, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, netdev, linux-kernel
Remove if then else statements preceding
boolean return. Occurences were found using
Coccinelle.
The semantic patch used was:
@@
expression expr;
@@
- if ( expr )
- return true;
- else
- return false;
+ return expr;
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
---
arch/x86/net/bpf_jit_comp.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 3f62734..1542f39 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -135,11 +135,9 @@ static const int reg2hex[] = {
*/
static inline bool is_ereg(u32 reg)
{
- if (reg == BPF_REG_5 || reg == AUX_REG ||
- (reg >= BPF_REG_7 && reg <= BPF_REG_9))
- return true;
- else
- return false;
+ return (reg == BPF_REG_5 ||
+ reg == AUX_REG ||
+ (reg >= BPF_REG_7 && reg <= BPF_REG_9));
}
/* add modifiers if 'reg' maps to x64 registers r8..r15 */
^ permalink raw reply related
* [PATCH net-next] macvlan: delay the header check for dodgy packets into lower device
From: Jason Wang @ 2014-11-26 9:21 UTC (permalink / raw)
To: kaber, netdev, linux-kernel; +Cc: mst, vyasevic, Jason Wang
We do header check twice for a dodgy packet. One is done before
macvlan_start_xmit(), another is done before lower device's
ndo_start_xmit(). The first one seems redundant so this patch tries to
delay header check until a packet reaches its lower device (or macvtap)
through always enabling NETIF_F_GSO_ROBUST for macvlan device.
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvlan.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index bfb0b6e..11d4b35 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -742,11 +742,12 @@ static struct lock_class_key macvlan_netdev_xmit_lock_key;
static struct lock_class_key macvlan_netdev_addr_lock_key;
#define ALWAYS_ON_FEATURES \
- (NETIF_F_SG | NETIF_F_GEN_CSUM | NETIF_F_GSO_SOFTWARE | NETIF_F_LLTX)
+ (NETIF_F_SG | NETIF_F_GEN_CSUM | NETIF_F_GSO_SOFTWARE | NETIF_F_LLTX | \
+ NETIF_F_GSO_ROBUST)
#define MACVLAN_FEATURES \
(NETIF_F_SG | NETIF_F_ALL_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
- NETIF_F_GSO | NETIF_F_TSO | NETIF_F_UFO | NETIF_F_GSO_ROBUST | \
+ NETIF_F_GSO | NETIF_F_TSO | NETIF_F_UFO | \
NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next v3 16/17] bridge: add brport flags to dflt bridge_getlink
From: Jiri Pirko @ 2014-11-26 9:25 UTC (permalink / raw)
To: Thomas Graf
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <20141125220753.GD3912@casper.infradead.org>
Tue, Nov 25, 2014 at 11:07:53PM CET, tgraf@suug.ch wrote:
>On 11/25/14 at 11:28am, Jiri Pirko wrote:
>> From: Scott Feldman <sfeldma@gmail.com>
>>
>> To allow brport device to return current brport flags set on port. Add
>> returned flags to nested IFLA_PROTINFO netlink msg built in dflt getlink.
>> With this change, netlink msg returned for bridge_getlink contains the port's
>> offloaded flag settings (the port's SELF settings).
>>
>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>Minor nit below. Otherwise:
>
>Acked-by: Thomas Graf <tgraf@suug.ch>
>
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index bd5e783..91e5368 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -2687,12 +2687,22 @@ static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
>> return skb->len;
>> }
>>
>> +static int brport_nla_put_flag(struct sk_buff *skb, u32 flags, u32 mask,
>> + unsigned int attrnum, unsigned int flag)
>> +{
>> + if (mask & flag)
>> + return nla_put_u8(skb, attrnum, !!(flags & flag));
>
>nla_put_flag()?
No, that is not the same. nla_put_flag works differently. The attr is
either present or not. But in this case, attr is always present and has
value of either 0 or 1.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox