* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Scott Feldman @ 2014-11-26 2:36 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: John Fastabend, Jiri Pirko, 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, Eric Dumazet, Florian Fainelli,
Roopa Prabhu, John Linville
In-Reply-To: <5474B353.10802@mojatatu.com>
On Tue, Nov 25, 2014 at 6:50 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 11/25/14 11:30, John Fastabend wrote:
>>
>> On 11/25/2014 08:18 AM, Jamal Hadi Salim wrote:
>>>
>>> On 11/25/14 11:01, John Fastabend wrote:
>>>>
>>>> On 11/25/2014 07:38 AM, Jamal Hadi Salim wrote:
>>>>>
>>>>> On 11/25/14 05:28, Jiri Pirko wrote:
>>>>>>
>>>>>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass
>>>>>> simple
>>>>>> u16 vid to drivers from there.
>>>>>>
>>>>>
>
>
>> Actually (after having some coffee) this becomes much more useful
>> if you return which items failed. Then you can slam the hardware
>> with your 100 entries, probably a lot more then that, and come back
>> later and clean it up.
>>
>
> Yes, that is the general use case.
> Unfortunately at the moment we only return codes on a netlink set
> direction - but would be a beauty if we could return what succeeded
> and didnt in some form of vector.
> Note: all is not lost because you can always do a get afterwards and
> find what is missing if you got a return code of "partial success".
> Just a little less efficient..
>
>
>> We return a bitmask of which operations were successful. So if SW fails
>> we have both bits cleared and we abort. When SW is successful we set the
>> SW bit and try to program the HW. If its sucessful we set the HW bit if
>> its not we abort with an err. Converting this to (1) is not much work
>> just skip the abort.
>>
>
> Ok, guess i am gonna have to go stare at the code some more.
> I thought we returned one of the error codes?
> A bitmask would work for a single entry - because you have two
> options add to h/ware and/or s/ware. So response is easy to encode.
> But if i have 1000 and they are sparsely populated (think an indexed
> table and i have indices 1, 23, 45, etc), then a bitmask would be
> hard to use.
I'm confused by this discussion. Do I have this right: You want to
send 1000 RTM_NEWNEIGHs to PF_BRIDGE with both NTF_MASTER and NTF_SELF
set such that 1000 new FBD entries are installed in both (SW) the
bridge's FDB and (HW) the port driver's FDB. My first confusion is
why do you want these FBD entries in bridge's FDB? We're offloading
the switching to HW so HW should be handling fwd plane. If ctrl pkt
make it to SW, it can learn those FDB entries; no need for manual
install of FDB entry in SW. It seems to me you only want to use
NTF_SELF to install the FDB entry in HW using the port driver. And an
error code is returned for that install. Since there is only one
target (NTF_SELF) there is no need for bitmask return.
> cheers,
> jamal
^ permalink raw reply
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Florian Fainelli @ 2014-11-26 2:34 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiri Pirko, 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: <CAE4R7bBQnxKh7y+ViB-s-7b7Ro=gTQLavUTcNLA1u=3UJHa1Rg@mail.gmail.com>
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...
>
>> [snip]
>>
>>> +EXPORT_SYMBOL(br_fdb_external_learn_del);
>>> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
>>> index 4f577c4..02cd63b 100644
>>> --- a/net/bridge/br_private.h
>>> +++ b/net/bridge/br_private.h
>>> @@ -101,6 +101,7 @@ struct net_bridge_fdb_entry
>>> unsigned char is_local;
>>> unsigned char is_static;
>>> unsigned char added_by_user;
>>> + unsigned char added_by_external_learn;
>>
>> Pheww, we could be saving some memory footprint here by using different
>> types here ;)
>> --
>> Florian
^ permalink raw reply
* Re: [PATCH 1/4] GMAC: add driver for Rockchip RK3288 SoCs integrated GMAC
From: Roger @ 2014-11-26 2:29 UTC (permalink / raw)
To: Giuseppe CAVALLARO, heiko
Cc: netdev, linux-kernel, linux-rockchip, kever.yang, mark.yao,
eddie.cai
In-Reply-To: <54745455.9060607@st.com>
Hi! Giuseppe CAVALLARO
在 2014/11/25 18:05, Giuseppe CAVALLARO 写道:
> Hello Roger
>
> thx for these patches, my comments inline below
>
> On 11/25/2014 10:07 AM, Roger Chen wrote:
>> This driver is based on stmmac driver.
>>
>> Signed-off-by: Roger Chen <roger.chen@rock-chips.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
>> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 629
>> ++++++++++++++++++++
>> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +
>> .../net/ethernet/stmicro/stmmac/stmmac_platform.h | 1 +
>> 4 files changed, 634 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
>> b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> index ac4d562..73c2715 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> @@ -6,7 +6,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o
>> stmmac_mdio.o ring_mode.o \
>>
>> obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
>> stmmac-platform-objs:= stmmac_platform.o dwmac-meson.o
>> dwmac-sunxi.o \
>> - dwmac-sti.o dwmac-socfpga.o
>> + dwmac-sti.o dwmac-socfpga.o dwmac-rk.o
>>
>> obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
>> stmmac-pci-objs:= stmmac_pci.o
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> new file mode 100644
>> index 0000000..9e50b37
>> --- /dev/null
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> @@ -0,0 +1,629 @@
>> +/**
>> + * dwmac-rk.c - Rockchip RK3288 DWMAC specific glue layer
>> + *
>> + * Copyright (C) 2014 Chen-Zhi (Roger Chen)
>> + *
>> + * Chen-Zhi (Roger Chen) <roger.chen@rock-chips.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/stmmac.h>
>> +#include <linux/clk.h>
>> +#include <linux/phy.h>
>> +#include <linux/of_net.h>
>> +#include <linux/gpio.h>
>> +#include <linux/of_gpio.h>
>> +#include <linux/of_device.h>
>> +#include <linux/regulator/consumer.h>
>> +#include <linux/delay.h>
>> +#include <linux/regmap.h>
>> +#include <linux/mfd/syscon.h>
>> +
>> +struct rk_priv_data {
>> + struct platform_device *pdev;
>> + int phy_iface;
>> + bool power_ctrl_by_pmu;
>> + char pmu_regulator[32];
>> + int pmu_enable_level;
>> +
>> + int power_io;
>> + int power_io_level;
>> + int reset_io;
>> + int reset_io_level;
>> + int phyirq_io;
>> + int phyirq_io_level;
>> +
>> + bool clk_enabled;
>> + bool clock_input;
>> +
>> + struct clk *clk_mac;
>> + struct clk *clk_mac_pll;
>> + struct clk *gmac_clkin;
>> + struct clk *mac_clk_rx;
>> + struct clk *mac_clk_tx;
>> + struct clk *clk_mac_ref;
>> + struct clk *clk_mac_refout;
>> + struct clk *aclk_mac;
>> + struct clk *pclk_mac;
>> +
>> + int tx_delay;
>> + int rx_delay;
>> +
>> + struct regmap *grf;
>> +};
>> +
>> +#define RK3288_GRF_SOC_CON1 0x0248
>> +#define RK3288_GRF_SOC_CON3 0x0250
>> +#define RK3288_GRF_GPIO3D_E 0x01ec
>> +#define RK3288_GRF_GPIO4A_E 0x01f0
>> +#define RK3288_GRF_GPIO4B_E 0x01f4
>> +
>> +/*RK3288_GRF_SOC_CON1*/
>> +#define GMAC_PHY_INTF_SEL_RGMII ((0x01C0 << 16) | (0x0040))
>> +#define GMAC_PHY_INTF_SEL_RMII ((0x01C0 << 16) | (0x0100))
>> +#define GMAC_FLOW_CTRL ((0x0200 << 16) | (0x0200))
>> +#define GMAC_FLOW_CTRL_CLR ((0x0200 << 16) | (0x0000))
>> +#define GMAC_SPEED_10M ((0x0400 << 16) | (0x0000))
>> +#define GMAC_SPEED_100M ((0x0400 << 16) | (0x0400))
>> +#define GMAC_RMII_CLK_25M ((0x0800 << 16) | (0x0800))
>> +#define GMAC_RMII_CLK_2_5M ((0x0800 << 16) | (0x0000))
>> +#define GMAC_CLK_125M ((0x3000 << 16) | (0x0000))
>> +#define GMAC_CLK_25M ((0x3000 << 16) | (0x3000))
>> +#define GMAC_CLK_2_5M ((0x3000 << 16) | (0x2000))
>> +#define GMAC_RMII_MODE ((0x4000 << 16) | (0x4000))
>> +#define GMAC_RMII_MODE_CLR ((0x4000 << 16) | (0x0000))
>> +
>> +/*RK3288_GRF_SOC_CON3*/
>> +#define GMAC_TXCLK_DLY_ENABLE ((0x4000 << 16) | (0x4000))
>> +#define GMAC_TXCLK_DLY_DISABLE ((0x4000 << 16) | (0x0000))
>> +#define GMAC_RXCLK_DLY_ENABLE ((0x8000 << 16) | (0x8000))
>> +#define GMAC_RXCLK_DLY_DISABLE ((0x8000 << 16) | (0x0000))
>> +#define GMAC_CLK_RX_DL_CFG(val) ((0x3F80 << 16) | (val<<7))
>> +#define GMAC_CLK_TX_DL_CFG(val) ((0x007F << 16) | (val))
>
> why do not use BIT and BIT_MASK where possible?
>
>> +static void set_to_rgmii(struct rk_priv_data *bsp_priv,
>> + int tx_delay, int rx_delay)
>> +{
>> + if (IS_ERR(bsp_priv->grf)) {
>> + pr_err("%s: Missing rockchip,grf property\n", __func__);
>> + return;
>> + }
>> +
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> + GMAC_PHY_INTF_SEL_RGMII);
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> + GMAC_RMII_MODE_CLR);
>
> maybe you could perform just one write unless there is some HW
> constraint.
>
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON3,
>> + GMAC_RXCLK_DLY_ENABLE);
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON3,
>> + GMAC_TXCLK_DLY_ENABLE);
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON3,
>> + GMAC_CLK_RX_DL_CFG(rx_delay));
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON3,
>> + GMAC_CLK_TX_DL_CFG(tx_delay));
>
> ditto
>
>> +
>> + regmap_write(bsp_priv->grf, RK3288_GRF_GPIO3D_E, 0xFFFFFFFF);
>> + regmap_write(bsp_priv->grf, RK3288_GRF_GPIO4B_E,
>> + 0x3<<2<<16 | 0x3<<2);
>
> pls use macros, these shift sequence is really help to decode
>
>> + regmap_write(bsp_priv->grf, RK3288_GRF_GPIO4A_E, 0xFFFFFFFF);
>> +
>> + pr_info("%s: tx delay=0x%x; rx delay=0x%x;\n",
>> + __func__, tx_delay, rx_delay);
>
> may I suggest pr_debug?
>
>> +}
>> +
>> +static void set_to_rmii(struct rk_priv_data *bsp_priv)
>> +{
>> + if (IS_ERR(bsp_priv->grf)) {
>> + pr_err("%s: Missing rockchip,grf property\n", __func__);
>> + return;
>> + }
>> +
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> + GMAC_PHY_INTF_SEL_RMII);
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> + GMAC_RMII_MODE);
>> +}
>> +
>> +static void set_rgmii_speed(struct rk_priv_data *bsp_priv, int speed)
>> +{
>> + if (IS_ERR(bsp_priv->grf)) {
>> + pr_err("%s: Missing rockchip,grf property\n", __func__);
>> + return;
>> + }
>> +
>> + if (speed == 10)
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> GMAC_CLK_2_5M);
>> + else if (speed == 100)
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1, GMAC_CLK_25M);
>> + else if (speed == 1000)
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> GMAC_CLK_125M);
>> + else
>> + pr_err("unknown speed value for RGMII! speed=%d", speed);
>> +}
>> +
>> +static void set_rmii_speed(struct rk_priv_data *bsp_priv, int speed)
>> +{
>> + if (IS_ERR(bsp_priv->grf)) {
>> + pr_err("%s: Missing rockchip,grf property\n", __func__);
>> + return;
>> + }
>> +
>> + if (speed == 10) {
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> + GMAC_RMII_CLK_2_5M);
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> + GMAC_SPEED_10M);
>> + } else if (speed == 100) {
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> + GMAC_RMII_CLK_25M);
>> + regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
>> + GMAC_SPEED_100M);
>> + } else {
>> + pr_err("unknown speed value for RMII! speed=%d", speed);
>> + }
>> +}
>> +
>> +#define MAC_CLK_RX "mac_clk_rx"
>> +#define MAC_CLK_TX "mac_clk_tx"
>> +#define CLK_MAC_REF "clk_mac_ref"
>> +#define CLK_MAC_REF_OUT "clk_mac_refout"
>> +#define CLK_MAC_PLL "clk_mac_pll"
>> +#define ACLK_MAC "aclk_mac"
>> +#define PCLK_MAC "pclk_mac"
>> +#define MAC_CLKIN "ext_gmac"
>> +#define CLK_MAC "stmmaceth"
>
> Concerning the clocks, the "stmmaceth" is actually used for the main
> clock so maybe you should use another name.
>
in stmmac_main.c, clk "stmmaceth"(STMMAC_RESOURCE_NAME) is used to be
the source of priv->clk_csr.
priv->stmmac_clk = devm_clk_get(priv->device, STMMAC_RESOURCE_NAME);
so I have to define a kind of clock named "stmmaceth".
> See: Documentation/devicetree/bindings/net/stmmac.txt
>
> For St platforms, it has been used: sti-ethclk but we could
> used a common and better name: stmmac-phyclk
> And I could also propose this change on STi glue-logic.
>
> Then, I think that all the clock macros above should be documented
> and maybe managed at DT level, what do you think?
>
>> +
>> +int gmac_clk_init(struct rk_priv_data *bsp_priv)
>> +{
>> + struct device *dev = &bsp_priv->pdev->dev;
>> +
>> + bsp_priv->clk_enabled = false;
>> +
>> + bsp_priv->mac_clk_rx = clk_get(dev, MAC_CLK_RX);
>> + if (IS_ERR(bsp_priv->mac_clk_rx))
>> + pr_warn("%s: warning: cannot get clock %s\n",
>> + __func__, MAC_CLK_RX);
>> +
>> + bsp_priv->mac_clk_tx = clk_get(dev, MAC_CLK_TX);
>> + if (IS_ERR(bsp_priv->mac_clk_tx))
>> + pr_warn("%s: warning: cannot get clock %s\n",
>> + __func__, MAC_CLK_TX);
>> +
>> + bsp_priv->clk_mac_ref = clk_get(dev, CLK_MAC_REF);
>> + if (IS_ERR(bsp_priv->clk_mac_ref))
>> + pr_warn("%s: warning: cannot get clock %s\n",
>> + __func__, CLK_MAC_REF);
>> +
>> + bsp_priv->clk_mac_refout = clk_get(dev, CLK_MAC_REF_OUT);
>> + if (IS_ERR(bsp_priv->clk_mac_refout))
>> + pr_warn("%s: warning:cannot get clock %s\n",
>> + __func__, CLK_MAC_REF_OUT);
>> +
>> + bsp_priv->aclk_mac = clk_get(dev, ACLK_MAC);
>> + if (IS_ERR(bsp_priv->aclk_mac))
>> + pr_warn("%s: warning: cannot get clock %s\n",
>> + __func__, ACLK_MAC);
>> +
>> + bsp_priv->pclk_mac = clk_get(dev, PCLK_MAC);
>> + if (IS_ERR(bsp_priv->pclk_mac))
>> + pr_warn("%s: warning: cannot get clock %s\n",
>> + __func__, PCLK_MAC);
>> +
>> + bsp_priv->clk_mac_pll = clk_get(dev, CLK_MAC_PLL);
>> + if (IS_ERR(bsp_priv->clk_mac_pll))
>> + pr_warn("%s: warning: cannot get clock %s\n",
>> + __func__, CLK_MAC_PLL);
>> +
>> + bsp_priv->gmac_clkin = clk_get(dev, MAC_CLKIN);
>> + if (IS_ERR(bsp_priv->gmac_clkin))
>> + pr_warn("%s: warning: cannot get clock %s\n",
>> + __func__, MAC_CLKIN);
>> +
>> + bsp_priv->clk_mac = clk_get(dev, CLK_MAC);
>> + if (IS_ERR(bsp_priv->clk_mac))
>> + pr_warn("%s: warning: cannot get clock %s\n",
>> + __func__, CLK_MAC);
>> +
>> + if (bsp_priv->clock_input) {
>> + pr_info("%s: clock input from PHY\n", __func__);
>> + } else {
>> + if (bsp_priv->phy_iface == PHY_INTERFACE_MODE_RMII)
>> + clk_set_rate(bsp_priv->clk_mac_pll, 50000000);
>> +
>> + clk_set_parent(bsp_priv->clk_mac, bsp_priv->clk_mac_pll);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int gmac_clk_enable(struct rk_priv_data *bsp_priv, bool enable)
>> +{
>> + int phy_iface = phy_iface = bsp_priv->phy_iface;
>> +
>> + if (enable) {
>> + if (!bsp_priv->clk_enabled) {
>> + if (phy_iface == PHY_INTERFACE_MODE_RMII) {
>> + if (!IS_ERR(bsp_priv->mac_clk_rx))
>> + clk_prepare_enable(
>> + bsp_priv->mac_clk_rx);
>> +
>> + if (!IS_ERR(bsp_priv->clk_mac_ref))
>> + clk_prepare_enable(
>> + bsp_priv->clk_mac_ref);
>> +
>> + if (!IS_ERR(bsp_priv->clk_mac_refout))
>> + clk_prepare_enable(
>> + bsp_priv->clk_mac_refout);
>> + }
>> +
>> + if (!IS_ERR(bsp_priv->aclk_mac))
>> + clk_prepare_enable(bsp_priv->aclk_mac);
>> +
>> + if (!IS_ERR(bsp_priv->pclk_mac))
>> + clk_prepare_enable(bsp_priv->pclk_mac);
>> +
>> + if (!IS_ERR(bsp_priv->mac_clk_tx))
>> + clk_prepare_enable(bsp_priv->mac_clk_tx);
>> +
>> + /**
>> + * if (!IS_ERR(bsp_priv->clk_mac))
>> + * clk_prepare_enable(bsp_priv->clk_mac);
>> + */
>
> why do you need to comment this? could it be related to the stmmaceth
> clk that is used by the main?
>
yes. the same explanation as above
>> + mdelay(5);
>
> hmm, do you actually need this mdelay? Is it to stabilize PLL sources?
>
yes.
>> + bsp_priv->clk_enabled = true;
>> + }
>> + } else {
>> + if (bsp_priv->clk_enabled) {
>> + if (phy_iface == PHY_INTERFACE_MODE_RMII) {
>> + if (!IS_ERR(bsp_priv->mac_clk_rx))
>> + clk_disable_unprepare(
>> + bsp_priv->mac_clk_rx);
>> +
>> + if (!IS_ERR(bsp_priv->clk_mac_ref))
>> + clk_disable_unprepare(
>> + bsp_priv->clk_mac_ref);
>> +
>> + if (!IS_ERR(bsp_priv->clk_mac_refout))
>> + clk_disable_unprepare(
>> + bsp_priv->clk_mac_refout);
>> + }
>> +
>> + if (!IS_ERR(bsp_priv->aclk_mac))
>> + clk_disable_unprepare(bsp_priv->aclk_mac);
>> +
>> + if (!IS_ERR(bsp_priv->pclk_mac))
>> + clk_disable_unprepare(bsp_priv->pclk_mac);
>> +
>> + if (!IS_ERR(bsp_priv->mac_clk_tx))
>> + clk_disable_unprepare(bsp_priv->mac_clk_tx);
>> + /**
>> + * if (!IS_ERR(bsp_priv->clk_mac))
>> + * clk_disable_unprepare(bsp_priv->clk_mac);
>> + */
>> + bsp_priv->clk_enabled = false;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int power_on_by_pmu(struct rk_priv_data *bsp_priv, bool enable)
>> +{
>> + struct regulator *ldo;
>> + char *ldostr = bsp_priv->pmu_regulator;
>> + int ret;
>> +
>> + if (!ldostr) {
>> + pr_err("%s: no ldo found\n", __func__);
>> + return -1;
>> + }
>> +
>> + ldo = regulator_get(NULL, ldostr);
>> + if (!ldo) {
>> + pr_err("\n%s get ldo %s failed\n", __func__, ldostr);
>> + } else {
>> + if (enable) {
>> + if (!regulator_is_enabled(ldo)) {
>> + regulator_set_voltage(ldo, 3300000, 3300000);
>> + ret = regulator_enable(ldo);
>> + if (ret != 0)
>> + pr_err("%s: fail to enable %s\n",
>> + __func__, ldostr);
>> + else
>> + pr_info("turn on ldo done.\n");
>> + } else {
>> + pr_warn("%s is enabled before enable", ldostr);
>> + }
>> + } else {
>> + if (regulator_is_enabled(ldo)) {
>> + ret = regulator_disable(ldo);
>> + if (ret != 0)
>> + pr_err("%s: fail to disable %s\n",
>> + __func__, ldostr);
>> + else
>> + pr_info("turn off ldo done.\n");
>> + } else {
>> + pr_warn("%s is disabled before disable",
>> + ldostr);
>> + }
>> + }
>> + regulator_put(ldo);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int power_on_by_gpio(struct rk_priv_data *bsp_priv, bool enable)
>> +{
>> + if (enable) {
>> + /*power on*/
>> + if (gpio_is_valid(bsp_priv->power_io))
>> + gpio_direction_output(bsp_priv->power_io,
>> + bsp_priv->power_io_level);
>> + } else {
>> + /*power off*/
>> + if (gpio_is_valid(bsp_priv->power_io))
>> + gpio_direction_output(bsp_priv->power_io,
>> + !bsp_priv->power_io_level);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
>> +{
>> + int ret = -1;
>> +
>> + pr_info("Ethernet PHY power %s\n", enable == 1 ? "on" : "off");
>> +
>> + if (bsp_priv->power_ctrl_by_pmu)
>> + ret = power_on_by_pmu(bsp_priv, enable);
>> + else
>> + ret = power_on_by_gpio(bsp_priv, enable);
>> +
>> + if (enable) {
>> + /*reset*/
>> + if (gpio_is_valid(bsp_priv->reset_io)) {
>> + gpio_direction_output(bsp_priv->reset_io,
>> + bsp_priv->reset_io_level);
>> + mdelay(5);
>> + gpio_direction_output(bsp_priv->reset_io,
>> + !bsp_priv->reset_io_level);
>> + }
>> + mdelay(30);
>> +
>> + } else {
>> + /*pull down reset*/
>> + if (gpio_is_valid(bsp_priv->reset_io)) {
>> + gpio_direction_output(bsp_priv->reset_io,
>> + bsp_priv->reset_io_level);
>> + }
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +#define GPIO_PHY_POWER "gmac_phy_power"
>> +#define GPIO_PHY_RESET "gmac_phy_reset"
>> +#define GPIO_PHY_IRQ "gmac_phy_irq"
>> +
>> +static void *rk_gmac_setup(struct platform_device *pdev)
>> +{
>> + struct rk_priv_data *bsp_priv;
>> + struct device *dev = &pdev->dev;
>> + enum of_gpio_flags flags;
>> + int ret;
>> + const char *strings = NULL;
>> + int value;
>> + int irq;
>> +
>> + bsp_priv = devm_kzalloc(dev, sizeof(*bsp_priv), GFP_KERNEL);
>> + if (!bsp_priv)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + bsp_priv->phy_iface = of_get_phy_mode(dev->of_node);
>> +
>> + ret = of_property_read_string(dev->of_node, "pmu_regulator",
>> &strings);
>> + if (ret) {
>> + pr_err("%s: Can not read property: pmu_regulator.\n",
>> __func__);
>> + bsp_priv->power_ctrl_by_pmu = false;
>> + } else {
>> + pr_info("%s: ethernet phy power controlled by pmu(%s).\n",
>> + __func__, strings);
>> + bsp_priv->power_ctrl_by_pmu = true;
>> + strcpy(bsp_priv->pmu_regulator, strings);
>> + }
>> +
>> + ret = of_property_read_u32(dev->of_node, "pmu_enable_level",
>> &value);
>> + if (ret) {
>> + pr_err("%s: Can not read property: pmu_enable_level.\n",
>> + __func__);
>> + bsp_priv->power_ctrl_by_pmu = false;
>> + } else {
>> + pr_info("%s: PHY power controlled by pmu(level = %s).\n",
>> + __func__, (value == 1) ? "HIGH" : "LOW");
>> + bsp_priv->power_ctrl_by_pmu = true;
>> + bsp_priv->pmu_enable_level = value;
>> + }
>> +
>> + ret = of_property_read_string(dev->of_node, "clock_in_out",
>> &strings);
>> + if (ret) {
>> + pr_err("%s: Can not read property: clock_in_out.\n", __func__);
>> + bsp_priv->clock_input = true;
>> + } else {
>> + pr_info("%s: clock input or output? (%s).\n",
>> + __func__, strings);
>> + if (!strcmp(strings, "input"))
>> + bsp_priv->clock_input = true;
>> + else
>> + bsp_priv->clock_input = false;
>> + }
>> +
>> + ret = of_property_read_u32(dev->of_node, "tx_delay", &value);
>> + if (ret) {
>> + bsp_priv->tx_delay = 0x30;
>> + pr_err("%s: Can not read property: tx_delay.", __func__);
>> + pr_err("%s: set tx_delay to 0x%x\n",
>> + __func__, bsp_priv->tx_delay);
>> + } else {
>> + pr_info("%s: TX delay(0x%x).\n", __func__, value);
>> + bsp_priv->tx_delay = value;
>> + }
>> +
>> + ret = of_property_read_u32(dev->of_node, "rx_delay", &value);
>> + if (ret) {
>> + bsp_priv->rx_delay = 0x10;
>> + pr_err("%s: Can not read property: rx_delay.", __func__);
>> + pr_err("%s: set rx_delay to 0x%x\n",
>> + __func__, bsp_priv->rx_delay);
>> + } else {
>> + pr_info("%s: RX delay(0x%x).\n", __func__, value);
>> + bsp_priv->rx_delay = value;
>> + }
>> +
>> + bsp_priv->grf = syscon_regmap_lookup_by_phandle(dev->of_node,
>> + "rockchip,grf");
>> + if (IS_ERR(bsp_priv->grf))
>> + dev_err(&pdev->dev, "Missing rockchip,grf property\n");
>
> I wonder if you can fail on here and save all the check in
> set_rgmii_speed etc.
> Maybe this can be considered a mandatory property for the glue-logic.
>
about fail check, you mean "if(IS_ERR(bsp_priv->grf))" ?
or all of the return value of of_property_*
>> +
>> + bsp_priv->phyirq_io =
>> + of_get_named_gpio_flags(dev->of_node,
>> + "phyirq-gpio", 0, &flags);
>> + bsp_priv->phyirq_io_level = (flags & OF_GPIO_ACTIVE_LOW) ? 0 : 1;
>
>
> Sorry, did you document all in Documentation/devicetree/bindings/net/ ?
>
>> +
>> + bsp_priv->reset_io =
>> + of_get_named_gpio_flags(dev->of_node,
>> + "reset-gpio", 0, &flags);
>> + bsp_priv->reset_io_level = (flags & OF_GPIO_ACTIVE_LOW) ? 0 : 1;
>> +
>> + bsp_priv->power_io =
>> + of_get_named_gpio_flags(dev->of_node, "power-gpio", 0, &flags);
>> + bsp_priv->power_io_level = (flags & OF_GPIO_ACTIVE_LOW) ? 0 : 1;
>> +
>> + /*power*/
>> + if (!gpio_is_valid(bsp_priv->power_io)) {
>> + pr_err("%s: Failed to get GPIO %s.\n",
>> + __func__, "power-gpio");
>> + } else {
>> + ret = gpio_request(bsp_priv->power_io, GPIO_PHY_POWER);
>> + if (ret)
>> + pr_err("%s: ERROR: Failed to request GPIO %s.\n",
>> + __func__, GPIO_PHY_POWER);
>> + }
>> +
>> + if (!gpio_is_valid(bsp_priv->reset_io)) {
>> + pr_err("%s: ERROR: Get reset-gpio failed.\n", __func__);
>> + } else {
>> + ret = gpio_request(bsp_priv->reset_io, GPIO_PHY_RESET);
>> + if (ret)
>> + pr_err("%s: ERROR: Failed to request GPIO %s.\n",
>> + __func__, GPIO_PHY_RESET);
>> + }
>> +
>> + if (bsp_priv->phyirq_io > 0) {
>> + struct plat_stmmacenet_data *plat_dat;
>> +
>> + pr_info("PHY irq in use\n");
>> + ret = gpio_request(bsp_priv->phyirq_io, GPIO_PHY_IRQ);
>> + if (ret < 0) {
>> + pr_warn("%s: Failed to request GPIO %s\n",
>> + __func__, GPIO_PHY_IRQ);
>> + goto goon;
>> + }
>> +
>> + ret = gpio_direction_input(bsp_priv->phyirq_io);
>> + if (ret < 0) {
>> + pr_err("%s, Failed to set input for GPIO %s\n",
>> + __func__, GPIO_PHY_IRQ);
>> + gpio_free(bsp_priv->phyirq_io);
>> + goto goon;
>> + }
>> +
>> + irq = gpio_to_irq(bsp_priv->phyirq_io);
>> + if (irq < 0) {
>> + ret = irq;
>> + pr_err("Failed to set irq for %s\n",
>> + GPIO_PHY_IRQ);
>> + gpio_free(bsp_priv->phyirq_io);
>> + goto goon;
>> + }
>> +
>> + plat_dat = dev_get_platdata(&pdev->dev);
>> + if (plat_dat)
>> + plat_dat->mdio_bus_data->probed_phy_irq = irq;
>> + else
>> + pr_err("%s: plat_data is NULL\n", __func__);
>> + }
>> +
>> +goon:
>> + /*rmii or rgmii*/
>> + if (bsp_priv->phy_iface == PHY_INTERFACE_MODE_RGMII) {
>> + pr_info("%s: init for RGMII\n", __func__);
>> + set_to_rgmii(bsp_priv, bsp_priv->tx_delay, bsp_priv->rx_delay);
>> + } else if (bsp_priv->phy_iface == PHY_INTERFACE_MODE_RMII) {
>> + pr_info("%s: init for RMII\n", __func__);
>> + set_to_rmii(bsp_priv);
>> + } else {
>> + pr_err("%s: ERROR: NO interface defined!\n", __func__);
>> + }
>> +
>> + bsp_priv->pdev = pdev;
>> +
>> + gmac_clk_init(bsp_priv);
>> +
>> + return bsp_priv;
>> +}
>> +
>> +static int rk_gmac_init(struct platform_device *pdev, void *priv)
>> +{
>> + struct rk_priv_data *bsp_priv = priv;
>> + int ret;
>> +
>> + ret = phy_power_on(bsp_priv, true);
>> + if (ret)
>> + return ret;
>> +
>> + ret = gmac_clk_enable(bsp_priv, true);
>> + if (ret)
>> + return ret;
>> +
>> + return 0;
>> +}
>> +
>> +static void rk_gmac_exit(struct platform_device *pdev, void *priv)
>> +{
>> + struct rk_priv_data *gmac = priv;
>> +
>> + phy_power_on(gmac, false);
>> + gmac_clk_enable(gmac, false);
>> +}
>> +
>> +static void rk_fix_speed(void *priv, unsigned int speed)
>> +{
>> + struct rk_priv_data *bsp_priv = priv;
>> +
>> + if (bsp_priv->phy_iface == PHY_INTERFACE_MODE_RGMII)
>> + set_rgmii_speed(bsp_priv, speed);
>> + else if (bsp_priv->phy_iface == PHY_INTERFACE_MODE_RMII)
>> + set_rmii_speed(bsp_priv, speed);
>> + else
>> + pr_err("unsupported interface %d", bsp_priv->phy_iface);
>> +}
>> +
>> +const struct stmmac_of_data rk_gmac_data = {
>> + .has_gmac = 1,
>> + .tx_coe = 1,
>
> FYI, on new gmac there is the HW capability register to dinamically
> provide you if coe is supported.
>
> IMO you should add the OF "compatible" string and in case of mac
> newer than the 3.50a you can remove coe.
>
>
> BR
> Peppe
>
>> + .fix_mac_speed = rk_fix_speed,
>> + .setup = rk_gmac_setup,
>> + .init = rk_gmac_init,
>> + .exit = rk_gmac_exit,
>> +};
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> index 15814b7..b4dee96 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> @@ -33,6 +33,7 @@
>>
>> static const struct of_device_id stmmac_dt_ids[] = {
>> /* SoC specific glue layers should come before generic bindings */
>> + { .compatible = "rockchip,rk3288-gmac", .data = &rk_gmac_data},
>> { .compatible = "amlogic,meson6-dwmac", .data =
>> &meson6_dwmac_data},
>> { .compatible = "allwinner,sun7i-a20-gmac", .data =
>> &sun7i_gmac_data},
>> { .compatible = "st,stih415-dwmac", .data = &stih4xx_dwmac_data},
>> @@ -291,6 +292,8 @@ static int stmmac_pltfr_probe(struct
>> platform_device *pdev)
>> return -ENOMEM;
>> }
>>
>> + pdev->dev.platform_data = plat_dat;
>> +
>> ret = stmmac_probe_config_dt(pdev, plat_dat, &mac);
>> if (ret) {
>> pr_err("%s: main dt probe failed", __func__);
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h
>> index 25dd1f7..32a0516 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h
>> @@ -24,5 +24,6 @@ extern const struct stmmac_of_data sun7i_gmac_data;
>> extern const struct stmmac_of_data stih4xx_dwmac_data;
>> extern const struct stmmac_of_data stid127_dwmac_data;
>> extern const struct stmmac_of_data socfpga_gmac_data;
>> +extern const struct stmmac_of_data rk_gmac_data;
>>
>> #endif /* __STMMAC_PLATFORM_H__ */
>>
>
>
>
>
^ permalink raw reply
* [PATCH] xen-netfront: Remove BUGs on paged skb data which crosses a page boundary
From: Seth Forshee @ 2014-11-26 2:28 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Boris Ostrovsky, David Vrabel
Cc: Zoltan Kiss, Eric Dumazet, Stefan Bader, Seth Forshee, xen-devel,
netdev, linux-kernel
These BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.
Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
Cc: <stable@vger.kernel.org> # 3.7+
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
drivers/net/xen-netfront.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index cca871346a0f..ece8d1804d13 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -496,9 +496,6 @@ static void xennet_make_frags(struct sk_buff *skb, struct netfront_queue *queue,
len = skb_frag_size(frag);
offset = frag->page_offset;
- /* Data must not cross a page boundary. */
- BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
-
/* Skip unused frames from start of page */
page += offset >> PAGE_SHIFT;
offset &= ~PAGE_MASK;
@@ -506,8 +503,6 @@ static void xennet_make_frags(struct sk_buff *skb, struct netfront_queue *queue,
while (len > 0) {
unsigned long bytes;
- BUG_ON(offset >= PAGE_SIZE);
-
bytes = PAGE_SIZE - offset;
if (bytes > len)
bytes = len;
--
1.9.1
^ permalink raw reply related
* [PATCH V3 1/1] ipv6: Remove unnecessary test
From: Zhu Yanjun @ 2014-11-26 2:25 UTC (permalink / raw)
To: zyjzyj2000, netdev, davem
Cc: Zhu Yanjun, Hong Zhiguo, Octavian Purdila, Pavel Emelyanov,
Cong Wang
The "init_net" test in function addrconf_exit_net is introduced
in commit 44a6bd29 [Create ipv6 devconf-s for namespaces] to avoid freeing
init_net. In commit c900a800 [ipv6: fix bad free of addrconf_init_net],
function addrconf_init_net will allocate memory for every net regardless of
init_net. In this case, it is unnecessary to make "init_net" test.
CC: Hong Zhiguo <honkiko@gmail.com>
CC: Octavian Purdila <opurdila@ixiacom.com>
CC: Pavel Emelyanov <xemul@openvz.org>
CC: Cong Wang <cwang@twopensource.com>
Suggested-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
net/ipv6/addrconf.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 0169ccf..b8724fc 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -5336,10 +5336,8 @@ static void __net_exit addrconf_exit_net(struct net *net)
__addrconf_sysctl_unregister(net->ipv6.devconf_dflt);
__addrconf_sysctl_unregister(net->ipv6.devconf_all);
#endif
- if (!net_eq(net, &init_net)) {
- kfree(net->ipv6.devconf_dflt);
- kfree(net->ipv6.devconf_all);
- }
+ kfree(net->ipv6.devconf_dflt);
+ kfree(net->ipv6.devconf_all);
}
static struct pernet_operations addrconf_ops = {
--
1.9.1
^ permalink raw reply related
* [PATCH V2 1/1] ipv6: Remove unnecessary test
From: Zhu Yanjun @ 2014-11-26 2:23 UTC (permalink / raw)
To: zyjzyj2000, netdev, davem
Cc: Zhu Yanjun, Hong Zhiguo, Octavian Purdila, Pavel Emelyanov,
Cong Wang
The "init_net" condition judgement in function addrconf_exit_net is introduced
in commit 44a6bd29 [Create ipv6 devconf-s for namespaces] to avoid freeing
init_net. In commit c900a800 [ipv6: fix bad free of addrconf_init_net],
function addrconf_init_net will allocate memory for every net regardless of
init_net. In this case, it is unnecessary to make "init_net" condition judgement.
CC: Hong Zhiguo <honkiko@gmail.com>
CC: Octavian Purdila <opurdila@ixiacom.com>
CC: Pavel Emelyanov <xemul@openvz.org>
CC: Cong Wang <cwang@twopensource.com>
Suggested-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
net/ipv6/addrconf.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 0169ccf..b8724fc 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -5336,10 +5336,8 @@ static void __net_exit addrconf_exit_net(struct net *net)
__addrconf_sysctl_unregister(net->ipv6.devconf_dflt);
__addrconf_sysctl_unregister(net->ipv6.devconf_all);
#endif
- if (!net_eq(net, &init_net)) {
- kfree(net->ipv6.devconf_dflt);
- kfree(net->ipv6.devconf_all);
- }
+ kfree(net->ipv6.devconf_dflt);
+ kfree(net->ipv6.devconf_all);
}
static struct pernet_operations addrconf_ops = {
--
1.9.1
^ permalink raw reply related
* [PATCH net 2/2] net: dsa: bcm_sf2: reset switch prior to initialization
From: Florian Fainelli @ 2014-11-26 2:08 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
In-Reply-To: <1416967729-717-1-git-send-email-f.fainelli@gmail.com>
Our boot agent may have left the switch in an certain configuration
state, make sure we issue a software reset prior to configuring the
switch in order to ensure the HW is in a consistent state, in particular
transmit queues and internal buffers.
Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 52 ++++++++++++++++++++++++++---------------------
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 46632e8b6336..4f4c2a7888e5 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -377,6 +377,29 @@ static irqreturn_t bcm_sf2_switch_1_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static int bcm_sf2_sw_rst(struct bcm_sf2_priv *priv)
+{
+ unsigned int timeout = 1000;
+ u32 reg;
+
+ reg = core_readl(priv, CORE_WATCHDOG_CTRL);
+ reg |= SOFTWARE_RESET | EN_CHIP_RST | EN_SW_RESET;
+ core_writel(priv, reg, CORE_WATCHDOG_CTRL);
+
+ do {
+ reg = core_readl(priv, CORE_WATCHDOG_CTRL);
+ if (!(reg & SOFTWARE_RESET))
+ break;
+
+ usleep_range(1000, 2000);
+ } while (timeout-- > 0);
+
+ if (timeout == 0)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
static int bcm_sf2_sw_setup(struct dsa_switch *ds)
{
const char *reg_names[BCM_SF2_REGS_NUM] = BCM_SF2_REGS_NAME;
@@ -410,6 +433,12 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds)
base++;
}
+ ret = bcm_sf2_sw_rst(priv);
+ if (ret) {
+ pr_err("unable to software reset switch: %d\n", ret);
+ goto out_unmap;
+ }
+
/* Disable all interrupts and request them */
intrl2_0_writel(priv, 0xffffffff, INTRL2_CPU_MASK_SET);
intrl2_0_writel(priv, 0xffffffff, INTRL2_CPU_CLEAR);
@@ -735,29 +764,6 @@ static int bcm_sf2_sw_suspend(struct dsa_switch *ds)
return 0;
}
-static int bcm_sf2_sw_rst(struct bcm_sf2_priv *priv)
-{
- unsigned int timeout = 1000;
- u32 reg;
-
- reg = core_readl(priv, CORE_WATCHDOG_CTRL);
- reg |= SOFTWARE_RESET | EN_CHIP_RST | EN_SW_RESET;
- core_writel(priv, reg, CORE_WATCHDOG_CTRL);
-
- do {
- reg = core_readl(priv, CORE_WATCHDOG_CTRL);
- if (!(reg & SOFTWARE_RESET))
- break;
-
- usleep_range(1000, 2000);
- } while (timeout-- > 0);
-
- if (timeout == 0)
- return -ETIMEDOUT;
-
- return 0;
-}
-
static int bcm_sf2_sw_resume(struct dsa_switch *ds)
{
struct bcm_sf2_priv *priv = ds_to_priv(ds);
--
2.1.0
^ permalink raw reply related
* [PATCH net 1/2] net: dsa: bcm_sf2: fix unmapping registers in case of errors
From: Florian Fainelli @ 2014-11-26 2:08 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
In-Reply-To: <1416967729-717-1-git-send-email-f.fainelli@gmail.com>
In case we fail to ioremap() one of our registers, we would be leaking
existing mappings, unwind those accordingly on errors.
Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index b9625968daac..46632e8b6336 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -404,7 +404,8 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds)
*base = of_iomap(dn, i);
if (*base == NULL) {
pr_err("unable to find register: %s\n", reg_names[i]);
- return -ENODEV;
+ ret = -ENOMEM;
+ goto out_unmap;
}
base++;
}
@@ -484,7 +485,8 @@ out_free_irq0:
out_unmap:
base = &priv->core;
for (i = 0; i < BCM_SF2_REGS_NUM; i++) {
- iounmap(*base);
+ if (*base)
+ iounmap(*base);
base++;
}
return ret;
--
2.1.0
^ permalink raw reply related
* [PATCH net 0/2] net: dsa: bcm_sf2: misc bugfixes
From: Florian Fainelli @ 2014-11-26 2:08 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
Hi David,
This patch series contains two bug fixes:
- first patch fixes an issue on the error path of the driver where we could
have left some of our registers mapped
- second patch enforces the use of a software reset of the switch to guarantee
the HW is in a consistent state prior to software initialization
Thanks!
Florian Fainelli (2):
net: dsa: bcm_sf2: fix unmapping registers in case of errors
net: dsa: bcm_sf2: reset switch prior to initialization
drivers/net/dsa/bcm_sf2.c | 58 +++++++++++++++++++++++++++--------------------
1 file changed, 33 insertions(+), 25 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net 0/2] net: dsa: bcm_sf2: misc bugfixes
From: Florian Fainelli @ 2014-11-26 2:08 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
Hi David,
This patch series contains two bug fixes:
- first patch fixes an issue on the error path of the driver where we could
have left some of our registers mapped
- second patch enforces the use of a software reset of the switch to guarantee
the HW is in a consistent state prior to software initialization
Thanks!
Florian Fainelli (2):
net: dsa: bcm_sf2: fix unmapping registers in case of errors
net: dsa: bcm_sf2: reset switch prior to initialization
drivers/net/dsa/bcm_sf2.c | 58 +++++++++++++++++++++++++++--------------------
1 file changed, 33 insertions(+), 25 deletions(-)
--
2.1.0
^ permalink raw reply
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Scott Feldman @ 2014-11-26 2:03 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jiri Pirko, 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: <54750669.4090406@gmail.com>
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.
> [snip]
>
>> +EXPORT_SYMBOL(br_fdb_external_learn_del);
>> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
>> index 4f577c4..02cd63b 100644
>> --- a/net/bridge/br_private.h
>> +++ b/net/bridge/br_private.h
>> @@ -101,6 +101,7 @@ struct net_bridge_fdb_entry
>> unsigned char is_local;
>> unsigned char is_static;
>> unsigned char added_by_user;
>> + unsigned char added_by_external_learn;
>
> Pheww, we could be saving some memory footprint here by using different
> types here ;)
> --
> Florian
^ permalink raw reply
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Scott Feldman @ 2014-11-26 1:48 UTC (permalink / raw)
To: Thomas Graf
Cc: Andy Gospodarek, 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, Jamal Hadi Salim,
Florian Fainelli, Roopa Prabhu
In-Reply-To: <20141125223643.GH3912@casper.infradead.org>
On Tue, Nov 25, 2014 at 12:36 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 11/25/14 at 11:38am, Andy Gospodarek wrote:
>> On Tue, Nov 25, 2014 at 11:28:40AM +0100, 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>
>
> I like the simplicity of this. That said, given we'll have multiple
> users of swdev including OVS, shouldn't this be a notifier or a
> callback that depends on who is controlling the device?
I like the idea. When the switch port joins Linux bridge or OVS
datapath, a callback is registered with the driver. That way the
driver doesn't really care if the port is a bridge member or an OVS
vport in a datapath. It's just passing up the FDB entry
(port/mac/vlan) details to the container device. Can we hold this
idea until this patchset sticks? I think once OVS support comes back
into the swdev model would be the time to address this.
>
>> > + spin_lock(&br->hash_lock);
>> (Since you asked to check locking...)
>>
>> Most of the other fdb_add/delete/insert/update calls take this with
>> spin_lock_bh. Did you try this with lockdep enabled just to see if that
>> is needed here? I suspect that anytime br->hash_lock is taken it will
>> need to be with softirqs disabled from this point forward.
>
> At least br_fdb_update() seems to be called from BH context so I would
> agree and argue the lock in br_fdb_cleanup() and br_fdb_update() need a
> fix too. I'll send a patch.
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Simon Horman @ 2014-11-26 1:44 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: John Fastabend, Jiri Pirko, netdev, davem, nhorman, andy, tgraf,
dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, edumazet, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, alexander.h.duyck, john.ronciak, mleitner,
shrijeet, gospo, bcrl
In-Reply-To: <5474B353.10802@mojatatu.com>
On Tue, Nov 25, 2014 at 11:50:27AM -0500, Jamal Hadi Salim wrote:
> On 11/25/14 11:30, John Fastabend wrote:
> >On 11/25/2014 08:18 AM, Jamal Hadi Salim wrote:
> >>On 11/25/14 11:01, John Fastabend wrote:
> >>>On 11/25/2014 07:38 AM, Jamal Hadi Salim wrote:
> >>>>On 11/25/14 05:28, Jiri Pirko wrote:
> >>>>>Do the work of parsing NDA_VLAN directly in rtnetlink code, pass simple
> >>>>>u16 vid to drivers from there.
> >>>>>
> >>>>
>
>
> >Actually (after having some coffee) this becomes much more useful
> >if you return which items failed. Then you can slam the hardware
> >with your 100 entries, probably a lot more then that, and come back
> >later and clean it up.
> >
>
> Yes, that is the general use case.
> Unfortunately at the moment we only return codes on a netlink set
> direction - but would be a beauty if we could return what succeeded
> and didnt in some form of vector.
> Note: all is not lost because you can always do a get afterwards and
> find what is missing if you got a return code of "partial success".
> Just a little less efficient..
I agree entirely. But efficiency may be a very real issue in practice.
> >We return a bitmask of which operations were successful. So if SW fails
> >we have both bits cleared and we abort. When SW is successful we set the
> >SW bit and try to program the HW. If its sucessful we set the HW bit if
> >its not we abort with an err. Converting this to (1) is not much work
> >just skip the abort.
> >
>
> Ok, guess i am gonna have to go stare at the code some more.
> I thought we returned one of the error codes?
> A bitmask would work for a single entry - because you have two
> options add to h/ware and/or s/ware. So response is easy to encode.
> But if i have 1000 and they are sparsely populated (think an indexed
> table and i have indices 1, 23, 45, etc), then a bitmask would be
> hard to use.
>
> cheers,
> jamal
^ permalink raw reply
* Re: [net-next PATCH 2/5] ethernet/intel: Use eth_skb_pad helper
From: Eric Dumazet @ 2014-11-26 1:43 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Alexander Duyck, netdev, Jeff Kirsher, davem
In-Reply-To: <54752263.2040204@gmail.com>
On Tue, 2014-11-25 at 16:44 -0800, Alexander Duyck wrote:
>
> I wonder if we couldn't make this some sort of netdevice attribute to
> indicate what the smallest frame we can handle is and then just pad the
> frame to that as a part of __dev_xmit_skb. Then we could do that
> outside of the locks and take care of it before we even hit the qdisc layer.
Well, many NIC do not have such restriction.
Do we have some kind of counters of skb->head reallocations caused by
this padding ?
I believe I finally have an idea why we had various + 15 in skb
allocations in TCP stack !
We probably should reinstate them, as ACK packets can be 54 bytes long.
^ permalink raw reply
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Scott Feldman @ 2014-11-26 1:35 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiri Pirko, 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,
Florian Fainelli, John Linville
In-Reply-To: <5475073E.70503@cumulusnetworks.com>
So offload is a little strong for this particular function. The
bridge driver or external STP process (msptd) is still controlling STP
state for the port and processing the BPDUs. When the state changes
on the port, the bridge driver is letting HW know, that's it. If the
port driver can't do anything with that notification, then it should
not implement ndo_switch_port_stp_update. If it does implement
ndo_switch_port_stp_update, then it can adjust its HW (e.g. disable
port if BR_DISABLED, etc), and return err code if somehow it failed
while adjusting HW.
This is not offloading STP state ctrl plane to HW. The ctrl plane is
kept in bridge driver (or mstpd) in SW. HW stays dumb in this model.
The bridge currently has policy control to turn on/off STP per bridge
and a netlink hook for external processes to change STP state.
On Tue, Nov 25, 2014 at 12:48 PM, Roopa Prabhu
<roopa@cumulusnetworks.com> wrote:
> On 11/25/14, 2:28 AM, Jiri Pirko wrote:
>>
>> From: Scott Feldman <sfeldma@gmail.com>
>>
>> To notify switch driver of change in STP state of bridge port, add new
>> .ndo op and provide switchdev wrapper func to call ndo op. Use it in
>> bridge
>> code then.
>>
>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>> v2->v3:
>> -changed "sw" string to "switch" to avoid confusion
>> v1->v2:
>> -no change
>> ---
>> include/linux/netdevice.h | 5 +++++
>> include/net/switchdev.h | 7 +++++++
>> net/bridge/br_stp.c | 2 ++
>> net/switchdev/switchdev.c | 19 +++++++++++++++++++
>> 4 files changed, 33 insertions(+)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index ce096dc..66cb64e 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -1024,6 +1024,9 @@ typedef u16 (*select_queue_fallback_t)(struct
>> net_device *dev,
>> * Called to get an ID of the switch chip this port is part of.
>> * If driver implements this, it indicates that it represents a port
>> * of a switch chip.
>> + * int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
>> + * Called to notify switch device port of bridge port STP
>> + * state change.
>> */
>> struct net_device_ops {
>> int (*ndo_init)(struct net_device *dev);
>> @@ -1180,6 +1183,8 @@ struct net_device_ops {
>> #ifdef CONFIG_NET_SWITCHDEV
>> int (*ndo_switch_parent_id_get)(struct
>> net_device *dev,
>> struct
>> netdev_phys_item_id *psid);
>> + int (*ndo_switch_port_stp_update)(struct
>> net_device *dev,
>> + u8 state);
>> #endif
>> };
>> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>> index 7a52360..8a6d164 100644
>> --- a/include/net/switchdev.h
>> +++ b/include/net/switchdev.h
>> @@ -16,6 +16,7 @@
>> int netdev_switch_parent_id_get(struct net_device *dev,
>> struct netdev_phys_item_id *psid);
>> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state);
>> #else
>> @@ -25,6 +26,12 @@ static inline int netdev_switch_parent_id_get(struct
>> net_device *dev,
>> return -EOPNOTSUPP;
>> }
>> +static inline int netdev_switch_port_stp_update(struct net_device *dev,
>> + u8 state)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> #endif
>> #endif /* _LINUX_SWITCHDEV_H_ */
>> diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
>> index 2b047bc..35e016c 100644
>> --- a/net/bridge/br_stp.c
>> +++ b/net/bridge/br_stp.c
>> @@ -12,6 +12,7 @@
>> */
>> #include <linux/kernel.h>
>> #include <linux/rculist.h>
>> +#include <net/switchdev.h>
>> #include "br_private.h"
>> #include "br_private_stp.h"
>> @@ -39,6 +40,7 @@ void br_log_state(const struct net_bridge_port *p)
>> void br_set_state(struct net_bridge_port *p, unsigned int state)
>> {
>> p->state = state;
>> + netdev_switch_port_stp_update(p->dev, state);
>> }
>> /* called under bridge lock */
>> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>> index 66973de..d162b21 100644
>> --- a/net/switchdev/switchdev.c
>> +++ b/net/switchdev/switchdev.c
>> @@ -31,3 +31,22 @@ int netdev_switch_parent_id_get(struct net_device *dev,
>> return ops->ndo_switch_parent_id_get(dev, psid);
>> }
>> EXPORT_SYMBOL(netdev_switch_parent_id_get);
>> +
>> +/**
>> + * netdev_switch_port_stp_update - Notify switch device port of STP
>> + * state change
>> + * @dev: port device
>> + * @state: port STP state
>> + *
>> + * Notify switch device port of bridge port STP state change.
>> + */
>> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
>> +{
>> + const struct net_device_ops *ops = dev->netdev_ops;
>> +
>> + if (!ops->ndo_switch_port_stp_update)
>> + return -EOPNOTSUPP;
>> + WARN_ON(!ops->ndo_switch_parent_id_get);
>> + return ops->ndo_switch_port_stp_update(dev, state);
>> +}
>> +EXPORT_SYMBOL(netdev_switch_port_stp_update);
>
>
> This should also check if offload is enabled on the bridge/port ?
>
^ permalink raw reply
* Re: [PATCH] bonding: move ipoib_header_ops to vmlinux
From: Wengang @ 2014-11-26 1:30 UTC (permalink / raw)
To: David Miller, jay.vosburgh-Z7WLFzj8eWMS+FvcfC7Uqw
Cc: ogerlitz-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141125.134450.1265438298771389292.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
于 2014年11月26日 02:44, David Miller 写道:
> From: Jay Vosburgh <jay.vosburgh-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> Date: Tue, 25 Nov 2014 10:41:17 -0800
>
>> Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>>
>>> On 11/25/2014 8:07 AM, David Miller wrote:
>>>> IPOIB should not work over bonding as it requires that the device
>>>> use ARPHRD_ETHER.
>>> Hi Dave,
>>>
>>> IPoIB devices can be enslaved to both bonding and teaming in their HA mode,
>>> the bond device type becomes ARPHRD_INFINIBAND when this happens.
>> The point was that pktgen disallows ARPHRD_INFINIBAND, not that
>> bonding does.
>>
>> Pktgen specifically checks for type != ARPHRD_ETHER, so the
>> IPoIB bond should not be able to be used with pkgten. My suspicion is
>> that pktgen is being configured on the bond first, then an IPoIB slave
>> is added to the bond; this would change its type in a way that pktgen
>> wouldn't notice.
> +1
I think it go this way:
1) bond_master is ready
2) bond_enslave enslave a IPOIB interface calling bond_setup_by_slave
3) then bond_setup_by_slave set change master type to ARPHRD_INFINIBAND.
code is like this:
1 /* enslave device <slave> to bond device <master> */
2 int bond_enslave(struct net_device *bond_dev, struct net_device
*slave_dev)
3 {
4 <snip>...
5 /* set bonding device ether type by slave - bonding netdevices are
6 * created with ether_setup, so when the slave type is not ARPHRD_ETHER
7 * there is a need to override some of the type dependent attribs/funcs.
8 *
9 * bond ether type mutual exclusion - don't allow slaves of dissimilar
10 * ether type (eg ARPHRD_ETHER and ARPHRD_INFINIBAND) share the same bond
11 */
12 if (!bond_has_slaves(bond)) {
13 if (bond_dev->type != slave_dev->type) {
14 <snip>...
15 if (slave_dev->type != ARPHRD_ETHER)
16 bond_setup_by_slave(bond_dev, slave_dev);
17 else {
18 ether_setup(bond_dev);
19 bond_dev->priv_flags &= ~IFF_TX_SKB_SHARING;
20 }
21
22 call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE,
23 bond_dev);
24 }
25 <snip>...
26 }
27
28 static void bond_setup_by_slave(struct net_device *bond_dev,
29 struct net_device *slave_dev)
30 {
31 bond_dev->header_ops = slave_dev->header_ops;
32
33 bond_dev->type = slave_dev->type;
34 bond_dev->hard_header_len = slave_dev->hard_header_len;
35 bond_dev->addr_len = slave_dev->addr_len;
36
37 memcpy(bond_dev->broadcast, slave_dev->broadcast,
38 slave_dev->addr_len);
39 }
40
thanks
wengang
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next PATCH 2/5] ethernet/intel: Use eth_skb_pad helper
From: Florian Fainelli @ 2014-11-26 1:05 UTC (permalink / raw)
To: Alexander Duyck, Eric Dumazet, Alexander Duyck
Cc: netdev, Jeff Kirsher, davem
In-Reply-To: <54752263.2040204@gmail.com>
On 25/11/14 16:44, Alexander Duyck wrote:
> On 11/25/2014 03:14 PM, Eric Dumazet wrote:
>> On Tue, 2014-11-25 at 14:44 -0800, Alexander Duyck wrote:
>>> Update the Intel Ethernet drivers to use eth_skb_pad() instead of doing
>>> their own implementations of the function.
>>>
>>> Also this cleans up two other spots where skb_pad was called but the length
>>> and tail pointers were being manipulated directly instead of just having
>>> the padding length added via __skb_put.
>>>
>>> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
>>> ---
>>> drivers/net/ethernet/intel/e1000/e1000_main.c | 8 ++------
>>> drivers/net/ethernet/intel/fm10k/fm10k_main.c | 11 +++--------
>>> drivers/net/ethernet/intel/igb/igb_main.c | 11 +++--------
>>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++--------
>>> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 +++--------
>>> 5 files changed, 14 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
>>> index 24f3986..862d198 100644
>>> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
>>> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
>>> @@ -3136,12 +3136,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
>>> * packets may get corrupted during padding by HW.
>>> * To WA this issue, pad all small packets manually.
>>> */
>>> - if (skb->len < ETH_ZLEN) {
>>> - if (skb_pad(skb, ETH_ZLEN - skb->len))
>>> - return NETDEV_TX_OK;
>>> - skb->len = ETH_ZLEN;
>>> - skb_set_tail_pointer(skb, ETH_ZLEN);
>>> - }
>>> + if (eth_skb_pad(skb))
>>> + return NETDEV_TX_OK;
>>>
>> Its a bit sad almost no driver increments some drop counter.
>>
>> This probably could be generically done in eth_skb_pad()
>>
>> atomic_long_inc(&skb->dev->tx_dropped)
>
> The only problem is eth_skb_pad is called in the Rx path of some drivers
> as well.
>
> I wonder if we couldn't make this some sort of netdevice attribute to
> indicate what the smallest frame we can handle is and then just pad the
> frame to that as a part of __dev_xmit_skb. Then we could do that
> outside of the locks and take care of it before we even hit the qdisc layer.
One potential problem could be that the padding size varies at runtime
based on e.g: netdev features, connection to an Ethernet switch etc...
we could probably just advertise whatever maximum padding we need once
and for all and just assume that any skb we get called with in a
driver's xmit() has the required padding, that is probably fine too.
--
Florian
^ permalink raw reply
* Re: [net-next PATCH 1/5] etherdevice: Add function for handling padding frame to ETH_ZLEN
From: Florian Fainelli @ 2014-11-26 0:56 UTC (permalink / raw)
To: Alexander Duyck, netdev; +Cc: davem
In-Reply-To: <20141125224400.1867.48907.stgit@ahduyck-vm-fedora20>
On 25/11/14 14:44, Alexander Duyck wrote:
> This patch adds a simple function for padding a frame up to the minimum
> size for for Ethernet. The motivation behind it is that there are a number
> of implementations throughout the network device drivers that are all doing
> the same thing, but each a little bit differently and as a result several
> implementations contain bugs such as updating the length without updating
> the tail offset and other similar issues.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> include/linux/etherdevice.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> index 733980f..7e436f3 100644
> --- a/include/linux/etherdevice.h
> +++ b/include/linux/etherdevice.h
> @@ -392,4 +392,25 @@ static inline unsigned long compare_ether_header(const void *a, const void *b)
> #endif
> }
>
> +/**
> + * eth_skb_pad - Pad buffer to mininum number of octets for Ethernet frame
> + * @skb: Buffer to pad
> + *
> + * An Ethernet frame should have a minimum size of 60 bytes. This function
> + * takes short frames and pads them with zeros up to the 60 byte limit.
minimum size without FCS
> + */
> +static inline int eth_skb_pad(struct sk_buff *skb)
> +{
> + unsigned int size = skb->len;
> +
> + if (unlikely(size < ETH_ZLEN)) {
> + size = ETH_ZLEN - size;
> + if (skb_pad(skb, size))
> + return -ENOMEM;
> + __skb_put(skb, size);
> + }
most drivers call skb_padto(skb, ETH_ZLEN), besides the extra
__skb_put() here, this is not different.
> +
> + return 0;
> +}
> +
> #endif /* _LINUX_ETHERDEVICE_H */
>
> --
> 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
* Re: [net-next PATCH 2/5] ethernet/intel: Use eth_skb_pad helper
From: Alexander Duyck @ 2014-11-26 0:44 UTC (permalink / raw)
To: Eric Dumazet, Alexander Duyck; +Cc: netdev, Jeff Kirsher, davem
In-Reply-To: <1416957251.29427.39.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/25/2014 03:14 PM, Eric Dumazet wrote:
> On Tue, 2014-11-25 at 14:44 -0800, Alexander Duyck wrote:
>> Update the Intel Ethernet drivers to use eth_skb_pad() instead of doing
>> their own implementations of the function.
>>
>> Also this cleans up two other spots where skb_pad was called but the length
>> and tail pointers were being manipulated directly instead of just having
>> the padding length added via __skb_put.
>>
>> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
>> ---
>> drivers/net/ethernet/intel/e1000/e1000_main.c | 8 ++------
>> drivers/net/ethernet/intel/fm10k/fm10k_main.c | 11 +++--------
>> drivers/net/ethernet/intel/igb/igb_main.c | 11 +++--------
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++--------
>> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 +++--------
>> 5 files changed, 14 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> index 24f3986..862d198 100644
>> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
>> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> @@ -3136,12 +3136,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
>> * packets may get corrupted during padding by HW.
>> * To WA this issue, pad all small packets manually.
>> */
>> - if (skb->len < ETH_ZLEN) {
>> - if (skb_pad(skb, ETH_ZLEN - skb->len))
>> - return NETDEV_TX_OK;
>> - skb->len = ETH_ZLEN;
>> - skb_set_tail_pointer(skb, ETH_ZLEN);
>> - }
>> + if (eth_skb_pad(skb))
>> + return NETDEV_TX_OK;
>>
> Its a bit sad almost no driver increments some drop counter.
>
> This probably could be generically done in eth_skb_pad()
>
> atomic_long_inc(&skb->dev->tx_dropped)
The only problem is eth_skb_pad is called in the Rx path of some drivers
as well.
I wonder if we couldn't make this some sort of netdevice attribute to
indicate what the smallest frame we can handle is and then just pad the
frame to that as a part of __dev_xmit_skb. Then we could do that
outside of the locks and take care of it before we even hit the qdisc layer.
- Alex
^ permalink raw reply
* Re: [net-next PATCH 5/5] r8169: Use eth_skb_pad function
From: Alexander Duyck @ 2014-11-26 0:33 UTC (permalink / raw)
To: Francois Romieu, Alexander Duyck
Cc: netdev, Realtek linux nic maintainers, davem
In-Reply-To: <20141126000258.GA5901@electric-eye.fr.zoreil.com>
On 11/25/2014 04:02 PM, Francois Romieu wrote:
> Alexander Duyck <alexander.h.duyck@redhat.com> :
>> Replace rtl_skb_pad with eth_skb_pad since they do the same thing.
> rtl_skb_pad returns true on success.
>
> eth_skb_pad returns 0 on success.
>
Okay, that is an easy enough fix. I will just test for !eth_skb_pad in
the v2 version.
- Alex
^ permalink raw reply
* Re: [net-next PATCH 5/5] r8169: Use eth_skb_pad function
From: Francois Romieu @ 2014-11-26 0:02 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, Realtek linux nic maintainers, davem
In-Reply-To: <20141125224425.1867.70460.stgit@ahduyck-vm-fedora20>
Alexander Duyck <alexander.h.duyck@redhat.com> :
> Replace rtl_skb_pad with eth_skb_pad since they do the same thing.
rtl_skb_pad returns true on success.
eth_skb_pad returns 0 on success.
--
Ueimor
^ permalink raw reply
* Re: [PATCH v5 2/4] arch: Add lightweight memory barriers dma_rmb() and dma_wmb()
From: Benjamin Herrenschmidt @ 2014-11-25 23:15 UTC (permalink / raw)
To: Alexander Duyck
Cc: linux-arch, netdev, linux-kernel, mathieu.desnoyers, peterz,
heiko.carstens, mingo, mikey, linux, donald.c.skidmore,
matthew.vick, geert, jeffrey.t.kirsher, romieu, paulmck, nic_swsd,
will.deacon, michael, tony.luck, torvalds, oleg, schwidefsky,
fweisbec, davem
In-Reply-To: <20141119012400.9563.21117.stgit@ahduyck-server>
On Tue, 2014-11-18 at 17:24 -0800, Alexander Duyck wrote:
> There are a number of situations where the mandatory barriers rmb() and
> wmb() are used to order memory/memory operations in the device drivers
> and those barriers are much heavier than they actually need to be. For
> example in the case of PowerPC wmb() calls the heavy-weight sync
> instruction when for coherent memory operations all that is really needed
> is an lsync or eieio instruction.
> .../...
For powerpc:
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: [net-next PATCH 2/5] ethernet/intel: Use eth_skb_pad helper
From: Eric Dumazet @ 2014-11-25 23:14 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, Jeff Kirsher, davem
In-Reply-To: <20141125224406.1867.97911.stgit@ahduyck-vm-fedora20>
On Tue, 2014-11-25 at 14:44 -0800, Alexander Duyck wrote:
> Update the Intel Ethernet drivers to use eth_skb_pad() instead of doing
> their own implementations of the function.
>
> Also this cleans up two other spots where skb_pad was called but the length
> and tail pointers were being manipulated directly instead of just having
> the padding length added via __skb_put.
>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> drivers/net/ethernet/intel/e1000/e1000_main.c | 8 ++------
> drivers/net/ethernet/intel/fm10k/fm10k_main.c | 11 +++--------
> drivers/net/ethernet/intel/igb/igb_main.c | 11 +++--------
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++--------
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 +++--------
> 5 files changed, 14 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
> index 24f3986..862d198 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> @@ -3136,12 +3136,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
> * packets may get corrupted during padding by HW.
> * To WA this issue, pad all small packets manually.
> */
> - if (skb->len < ETH_ZLEN) {
> - if (skb_pad(skb, ETH_ZLEN - skb->len))
> - return NETDEV_TX_OK;
> - skb->len = ETH_ZLEN;
> - skb_set_tail_pointer(skb, ETH_ZLEN);
> - }
> + if (eth_skb_pad(skb))
> + return NETDEV_TX_OK;
>
Its a bit sad almost no driver increments some drop counter.
This probably could be generically done in eth_skb_pad()
atomic_long_inc(&skb->dev->tx_dropped)
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Thomas Graf @ 2014-11-25 23:11 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jiri Pirko, netdev, davem, nhorman, andy, dborkman, ogerlitz,
jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma, 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: <54750505.3060004@gmail.com>
On 11/25/14 at 02:39pm, Florian Fainelli wrote:
> On 25/11/14 14:14, Thomas Graf 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?
> >
>
> Not sure I follow you here, the commit message says what it says it
> does, are we looking at the same patch?
I'm referring to the discussion that occured on patch 06/10 of v2:
http://www.spinics.net/lists/netdev/msg303637.html
http://www.spinics.net/lists/netdev/msg303669.html
http://www.spinics.net/lists/netdev/msg303689.html
http://www.spinics.net/lists/netdev/msg303706.html
I won't hold up this series though. Glad to do the work afterwards.
^ permalink raw reply
* Re: [patch net-next v3 15/17] bridge: add new hwmode swdev
From: Thomas Graf @ 2014-11-25 23:00 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, netdev, davem, nhorman, andy, dborkman, ogerlitz,
jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, 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: <5474A95B.3080607@mojatatu.com>
On 11/25/14 at 11:07am, Jamal Hadi Salim wrote:
> On 11/25/14 05:28, Jiri Pirko wrote:
> >From: Scott Feldman <sfeldma@gmail.com>
> >
> >Current hwmode settings are "vepa" or "veb". These are for NIC interfaces
> >with basic bridging function offloaded to HW. Add new "swdev" for full
> >switch device offloads.
> >
> >Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> >Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> >---
> >new in v3
> >---
> > include/uapi/linux/if_bridge.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> >diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> >index da17e45..60425ca 100644
> >--- a/include/uapi/linux/if_bridge.h
> >+++ b/include/uapi/linux/if_bridge.h
> >@@ -105,6 +105,7 @@ struct __fdb_entry {
> >
> > #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> > #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> >+#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
> >
> > /* Bridge management nested attributes
> > * [IFLA_AF_SPEC] = {
> >
>
> Again - Why is this not a generic interface the way Roopa had it?
> We need to do offloads for a lot of other things than just bridge..
I agree in general but I'm not sure we should mirror the NETIF_F_*
approach. Even the relatively simple encap offload has turned into
a complex set of feature bitmasks requiring harmonization.
I think we should discuss this in the context of John's work which
neatly abstracts the capabilities.
^ 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