* [PATCH net-next v3 3/5] bridge: offload bridge port attributes to switch asic if feature flag set
From: roopa @ 2015-01-23 4:33 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds support to set/del bridge port attributes in hardware from
the bridge driver.
When the user sends a bridge setlink message, it will come in with 'master',
- go to the bridge driver ndo_bridge_setlink handler,
- set settings in the kernel
- if offload mode is set on the port, also call the swicthdev api to
propagate the attrs to the switchdev hardware
If you want to act on the hw alone, you can still use the self flag to
go to the switch hw or switch port driver directly.
With this, it also makes sure a notification goes out only after the
attributes are set both in the kernel and hw.
The patch calls switchdev api only if BRIDGE_FLAGS_SELF is not set.
This is because the offload cases with BRIDGE_FLAGS_SELF are handled in
the caller (in rtnetlink.c). This needed flags (IFLA_BRIDGE_FLAGS) to be
passed to bridge setlink and dellink functions, to avoid
another call to parse of IFLA_AF_SPEC in br_setlink/br_getlink respectively.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
drivers/net/ethernet/rocker/rocker.c | 2 +-
include/linux/netdevice.h | 6 +++--
net/bridge/br_netlink.c | 30 ++++++++++++++++++++-----
net/bridge/br_private.h | 4 ++--
net/core/rtnetlink.c | 10 +++++----
6 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2ed2c7d..13425e5 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7786,7 +7786,7 @@ static int ixgbe_ndo_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
}
static int ixgbe_ndo_bridge_setlink(struct net_device *dev,
- struct nlmsghdr *nlh)
+ struct nlmsghdr *nlh, u16 flags)
{
struct ixgbe_adapter *adapter = netdev_priv(dev);
struct nlattr *attr, *br_spec;
diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
index 2f398fa..109aa1b 100644
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@ -3713,7 +3713,7 @@ skip:
}
static int rocker_port_bridge_setlink(struct net_device *dev,
- struct nlmsghdr *nlh)
+ struct nlmsghdr *nlh, u16 flags)
{
struct rocker_port *rocker_port = netdev_priv(dev);
struct nlattr *protinfo;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c31f74d..1c8641f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1151,13 +1151,15 @@ struct net_device_ops {
int idx);
int (*ndo_bridge_setlink)(struct net_device *dev,
- struct nlmsghdr *nlh);
+ struct nlmsghdr *nlh,
+ u16 flags);
int (*ndo_bridge_getlink)(struct sk_buff *skb,
u32 pid, u32 seq,
struct net_device *dev,
u32 filter_mask);
int (*ndo_bridge_dellink)(struct net_device *dev,
- struct nlmsghdr *nlh);
+ struct nlmsghdr *nlh,
+ u16 flags);
int (*ndo_change_carrier)(struct net_device *dev,
bool new_carrier);
int (*ndo_get_phys_port_id)(struct net_device *dev,
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 9f5eb55..f73b094 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -16,6 +16,7 @@
#include <net/rtnetlink.h>
#include <net/net_namespace.h>
#include <net/sock.h>
+#include <net/switchdev.h>
#include <uapi/linux/if_bridge.h>
#include "br_private.h"
@@ -359,13 +360,13 @@ static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
}
/* Change state and parameters on port. */
-int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
+int br_setlink(struct net_device *dev, struct nlmsghdr *nlh, u16 flags)
{
struct nlattr *protinfo;
struct nlattr *afspec;
struct net_bridge_port *p;
struct nlattr *tb[IFLA_BRPORT_MAX + 1];
- int err = 0;
+ int err = 0, ret_offload = 0;
protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_PROTINFO);
afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
@@ -407,19 +408,28 @@ int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
afspec, RTM_SETLINK);
}
+ if (!(flags & BRIDGE_FLAGS_SELF)) {
+ /* set bridge attributes in hardware if supported
+ */
+ ret_offload = netdev_switch_port_bridge_setlink(dev, nlh,
+ flags);
+ if (ret_offload && ret_offload != -EOPNOTSUPP)
+ br_warn(p->br, "error setting attrs on port %u(%s)\n",
+ (unsigned int)p->port_no, p->dev->name);
+ }
+
if (err == 0)
br_ifinfo_notify(RTM_NEWLINK, p);
-
out:
return err;
}
/* Delete port information */
-int br_dellink(struct net_device *dev, struct nlmsghdr *nlh)
+int br_dellink(struct net_device *dev, struct nlmsghdr *nlh, u16 flags)
{
struct nlattr *afspec;
struct net_bridge_port *p;
- int err;
+ int err = 0, ret_offload = 0;
afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
if (!afspec)
@@ -433,6 +443,16 @@ int br_dellink(struct net_device *dev, struct nlmsghdr *nlh)
err = br_afspec((struct net_bridge *)netdev_priv(dev), p,
afspec, RTM_DELLINK);
+ if (!(flags & BRIDGE_FLAGS_SELF)) {
+ /* del bridge attributes in hardware
+ */
+ ret_offload = netdev_switch_port_bridge_dellink(dev, nlh,
+ flags);
+ if (ret_offload && ret_offload != -EOPNOTSUPP)
+ br_warn(p->br, "error deleting attrs on port %u (%s)\n",
+ (unsigned int)p->port_no, p->dev->name);
+ }
+
return err;
}
static int br_validate(struct nlattr *tb[], struct nlattr *data[])
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index aea3d13..0ebad7c 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -815,8 +815,8 @@ extern struct rtnl_link_ops br_link_ops;
int br_netlink_init(void);
void br_netlink_fini(void);
void br_ifinfo_notify(int event, struct net_bridge_port *port);
-int br_setlink(struct net_device *dev, struct nlmsghdr *nlmsg);
-int br_dellink(struct net_device *dev, struct nlmsghdr *nlmsg);
+int br_setlink(struct net_device *dev, struct nlmsghdr *nlmsg, u16 flags);
+int br_dellink(struct net_device *dev, struct nlmsghdr *nlmsg, u16 flags);
int br_getlink(struct sk_buff *skb, u32 pid, u32 seq, struct net_device *dev,
u32 filter_mask);
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index d06107d..70e5c93 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2946,7 +2946,7 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh)
goto out;
}
- err = br_dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
+ err = br_dev->netdev_ops->ndo_bridge_setlink(dev, nlh, flags);
if (err)
goto out;
@@ -2957,7 +2957,8 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh)
if (!dev->netdev_ops->ndo_bridge_setlink)
err = -EOPNOTSUPP;
else
- err = dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
+ err = dev->netdev_ops->ndo_bridge_setlink(dev, nlh,
+ flags);
if (!err)
flags &= ~BRIDGE_FLAGS_SELF;
@@ -3019,7 +3020,7 @@ static int rtnl_bridge_dellink(struct sk_buff *skb, struct nlmsghdr *nlh)
goto out;
}
- err = br_dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
+ err = br_dev->netdev_ops->ndo_bridge_dellink(dev, nlh, flags);
if (err)
goto out;
@@ -3030,7 +3031,8 @@ static int rtnl_bridge_dellink(struct sk_buff *skb, struct nlmsghdr *nlh)
if (!dev->netdev_ops->ndo_bridge_dellink)
err = -EOPNOTSUPP;
else
- err = dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
+ err = dev->netdev_ops->ndo_bridge_dellink(dev, nlh,
+ flags);
if (!err)
flags &= ~BRIDGE_FLAGS_SELF;
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v3 4/5] rocker: set feature NETIF_F_HW_NETFUNC_OFFLOAD
From: roopa @ 2015-01-23 4:33 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch sets the NETIF_F_HW_NETFUNC_OFFLOAD feature flag on rocker ports
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/ethernet/rocker/rocker.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
index 109aa1b..3aa0e85 100644
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@ -4004,7 +4004,8 @@ static int rocker_probe_port(struct rocker *rocker, unsigned int port_number)
NAPI_POLL_WEIGHT);
rocker_carrier_init(rocker_port);
- dev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
+ dev->features |= NETIF_F_HW_VLAN_CTAG_FILTER |
+ NETIF_F_HW_NETFUNC_OFFLOAD;
err = register_netdev(dev);
if (err) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v3 5/5] bonding: handle NETIF_F_HW_NETFUNC_OFFLOAD flag to bonding feature mask
From: roopa @ 2015-01-23 4:33 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
We want bond to pick up the offload flag if any of its slaves have it.
NETIF_F_HW_NETFUNC_OFFLOAD flag is added to the mask, so that
netdev_increment_features does not ignore it.
If this needs to be under CONFIG_NET_SWITCHDEV, I can do so.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/bonding/bond_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 184c434..4304194 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -979,7 +979,11 @@ static netdev_features_t bond_fix_features(struct net_device *dev,
netdev_features_t mask;
struct slave *slave;
- mask = features;
+ /* If any slave has the offload feature flag set,
+ * set the offload flag on the bond.
+ */
+ mask = features | NETIF_F_HW_NETFUNC_OFFLOAD;
+
features &= ~NETIF_F_ONE_FOR_ALL;
features |= NETIF_F_ALL_FOR_ALL;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/2] net: stmmac: add fixed_phy and phy_addr support using DT file
From: Ming Lei @ 2015-01-23 4:57 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-arm-kernel, David S. Miller, Network Development,
linux-samsung-soc, Byungho An, Kukjin Kim
In-Reply-To: <54C1CADD.4060103@gmail.com>
On Fri, Jan 23, 2015 at 12:15 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Le 22/01/2015 18:41, Ming Lei a écrit :
>> From: Byungho An <bh74.an@samsung.com>
>>
>> This patch adds codes for DT file support, fixed_phy and phy_addr
>> can be set in DT file.
>>
>> Signed-off-by: Byungho An <bh74.an@samsung.com> (bypass check for
>> fixed phy) Signed-off-by: Ming Lei<ming.lei@canonical.com> ---
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++++-
>> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++++++ 2
>> files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index
>> 8c6b7c16..ddb4351 100644 ---
>> a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -847,8
>> +847,11 @@ static int stmmac_init_phy(struct net_device *dev) * 0
>> rather than 0xffff. Catch this here and treat 0 as a non-existent *
>> device as well. * Note: phydev->phy_id is the result of reading the
>> UID PHY registers. + * But phy_id returned from fixed phy is
>> always zero, so bypass the + * check for fixed phy. */ - if
>> (phydev->phy_id == 0) { + if (phydev->phy_id == 0 &&
>> (!priv->plat->phy_bus_name || +
>> strcmp(priv->plat->phy_bus_name,"fixed"))) {
>> phy_disconnect(phydev); return -ENODEV; } diff --git
>> a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index
>> 879e29f..4f11491 100644 ---
>> a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -128,6
>> +128,7 @@ static int stmmac_probe_config_dt(struct platform_device
>> *pdev, struct device_node *np = pdev->dev.of_node; struct
>> stmmac_dma_cfg *dma_cfg; const struct of_device_id *device; + u32
>> phy_addr;
>>
>> if (!np) return -ENODEV; @@ -217,6 +218,12 @@ static int
>> stmmac_probe_config_dt(struct platform_device *pdev, plat->pmt =
>> 1; }
>>
>> + if (of_find_property(np, "fixed_phy", NULL)) { +
>> plat->phy_bus_name = "fixed"; + of_property_read_u32(np,
>> "phy_addr", &phy_addr); + plat->phy_addr = phy_addr; + }
>
> Humm, same here, it would look like you could use the existing Device
> Tree helpers for parsing and registering a fixed PHY here, provided
> that you use the proper binding though.
OK, I will try to use the existing DT helpers in v1.
>
> BTW, Ming Lei's email is bouncing, do we have an updated email he
> could be contacted with?
Sorry, my signed-off-by email in the 1st patch is wrong(typo), and
the address in this email and patch is correct.
Thanks,
Ming Lei
^ permalink raw reply
* rxhash for virtio_net
From: Nick H @ 2015-01-23 5:43 UTC (permalink / raw)
To: netdev; +Cc: mst, jasonwang
While trying to enable rxhash for virtio_net over net-next, I found
that we still do not support it. Quick Google search yields several
patches (including flow-director for virtio_net), but looks like none
of them made it in. If my observation is correct, what are the
prominent reasons why rxhash support for virtio has not made its way
in ? (I see some concerns over Out-of-order delivery etc, any other ?
). Without rxhash for virtio, is there a way to tie a flow to a
particular cpu on host and guest side ?
Thanks,
N
^ permalink raw reply
* Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling
From: Ahmed S. Darwish @ 2015-01-23 6:07 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Andri Yngvason, Olivier Sobrie, Oliver Hartkopp,
Marc Kleine-Budde, Linux-CAN, netdev, LKML
In-Reply-To: <49707d45a389a1acb9ccec4295d05762@grandegger.com>
On Wed, Jan 21, 2015 at 05:13:45PM +0100, Wolfgang Grandegger wrote:
> On Wed, 21 Jan 2015 10:36:47 -0500, "Ahmed S. Darwish"
> <darwish.07@gmail.com> wrote:
> > On Wed, Jan 21, 2015 at 03:00:15PM +0000, Andri Yngvason wrote:
> >> Quoting Ahmed S. Darwish (2015-01-21 14:43:23)
> >> > Hi!
> >
> > ...
> >
> >> > <-- Unplug the cable -->
> >> >
> >> > (000.009106) can0 20000080 [8] 00 00 00 00 00 00 08 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{8}{0}}
> >> > (000.001872) can0 20000080 [8] 00 00 00 00 00 00 10 00
>
> For a bus-errors I would also expcect some more information in the
> data[2..3] fields. But these are always zero.
>
M16C error factors made it possible to report things like
CAN_ERR_PROT_FORM/STUFF/BIT0/BIT1/TX in data[2], and
CAN_ERR_PROT_LOC_ACK/CRC_DEL in data[3].
Unfortunately such error factors are only reported in Leaf, but
not in USBCan-II due to the wire format change in the error event:
struct leaf_msg_error_event {
u8 tid;
u8 flags;
__le16 time[3];
u8 channel;
u8 padding;
u8 tx_errors_count;
u8 rx_errors_count;
u8 status;
u8 error_factor;
} __packed;
struct usbcan_msg_error_event {
u8 tid;
u8 padding;
u8 tx_errors_count_ch0;
u8 rx_errors_count_ch0;
u8 tx_errors_count_ch1;
u8 rx_errors_count_ch1;
u8 status_ch0;
u8 status_ch1;
__le16 time;
} __packed;
I speculate that the wire format was changed due to controller
bugs in the USBCan-II, which was slightly mentioned in their
data sheets here:
http://www.kvaser.com/canlib-webhelp/page_hardware_specific_can_controllers.html
So it seems there's really no way for filling such bus error
info given the very limited amount of data exported :-(
The issue of incomplete data does not even stop here, kindly
check below notes regarding reverse state transitions:
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{16}{0}}
> >> [...]
> >> > error-counter-tx-rx{{80}{0}}
> >> > (000.001910) can0 20000080 [8] 00 00 00 00 00 00 58 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{88}{0}}
> >> > (000.001753) can0 20000084 [8] 00 08 00 00 00 00 60 00
> >> > ERRORFRAME
> >> > controller-problem{tx-error-warning}
> >> Good.
> >> > bus-error
> >> > error-counter-tx-rx{{96}{0}}
> >
> > Nice.
> >
> >> > (000.001720) can0 20000080 [8] 00 00 00 00 00 00 68 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{104}{0}}
> >> > (000.001876) can0 20000080 [8] 00 00 00 00 00 00 70 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{112}{0}}
> >> > (000.001749) can0 20000080 [8] 00 00 00 00 00 00 78 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{120}{0}}
> >> > (000.001771) can0 20000084 [8] 00 20 00 00 00 00 80 00
> >> > ERRORFRAME
> >> > controller-problem{tx-error-passive}
> >> Also good.
> >> > bus-error
> >> > error-counter-tx-rx{{128}{0}}
> >
> > Also nice :-)
> >
> >> > (000.001868) can0 20000080 [8] 00 00 00 00 00 00 80 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{128}{0}}
> >> > (000.001982) can0 20000080 [8] 00 00 00 00 00 00 80 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{128}{0}}
> >> >
> >> > (( Then a continous flood, exactly similar to the above packet,
> >> > appears.
> >> > Unfortunately this flooding is a firmware problem. ))
> >> >
> >> > <-- Replug the cable, after a good amount of time -->
> >> >
> >> Where are the reverse state transitions?
> >> >
> >
> > Hmmm...
> >
> > [ ... ]
> >>
> >> Reverse state transitions are missing from the logs. See comments
> above.
> >>
> >
> > When the device is on the _receiving_ end, and I unplug the CAN cable
> after
> > introducing some noise to the level of reaching WARNING or PASSIVE, I
> > receive a BUS_ERROR event with the rxerr count reset back to 0 or 1. In
> > that case, the driver correctly transitions back the state to
> ERROR_ACTIVE
> > and candump produces something similar to:
> >
> > (000.000362) can0 2000008C [8] 00 40 40 00 00 00 00 01
> > ERRORFRAME
> > controller-problem{}
> > protocol-violation{{back-to-error-active}{}}
> > bus-error
> > error-counter-tx-rx{{0}{1}}
> >
> > which is, AFAIK, the correct behaviour from the driver side.
> >
> > Meanwhile, when the device is on the _sending_ end and I re-plug the CAN
> > cable again. Sometimes I receive events with txerr reset to 0 or 1, and
> > the driver correctly reverts back to ERROR_ACTIVE in that case. But on
> > another times like the quoted case above, I don't receive any events
> > resetting txerr back -- only data packets on the bus.
>
> Well, the firmware seems to report *only* bus-errors via
> CMD_CAN_ERROR_EVENT messages, also carrying the new state, but no
> CMD_CHIP_STATE_EVENT just for the state changes.
>
I've dumped _every_ message I receive from the firmware while
disconnecting the CAN bus, waiting a while, and connecting it again.
I really received _nothing_ from the firmware when the CAN bus was
reconnected and the data packets were flowing again. Not even a
single CHIP_STATE_EVENT, even after waiting for a long time.
So it's basically:
...
ERR EVENT, txerr=128, rxerr=0
ERR EVENT, txerr=128, rxerr=0
ERR EVENT, txerr=128, rxerr=0
...
then complete silence, except the data frames. I've even tried with
different versions of the firmware, but the same behaviour persisted.
> > So, What can the driver do given the above?
>
> Little if the notification does not come.
>
We can poll the state by sending CMD_GET_CHIP_STATE to the firmware,
and it will hopefully reply with a CHIP_STATE_EVENT response
containing the new txerr and rxerr values that we can use for
reverse state transitions.
But do we _really_ want to go through the path? I feel that it will
open some cans of worms w.r.t. concurrent access to both the netdev
and USB stacks from a single driver.
A possible solution can be setting up a kernel thread that queries
for a CHIP_STATE_EVENT every second?
Your inputs on this is appreciated.
> Wolfgang.
>
Regards,
Darwish
^ permalink raw reply
* [PATCH net-next v2] iproute2: bridge: support vlan range
From: roopa @ 2015-01-23 6:25 UTC (permalink / raw)
To: davem, stephen, netdev, vyasevic; +Cc: wkok, sfeldma
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds vlan range support to bridge command
using the newly added vinfo flags BRIDGE_VLAN_INFO_RANGE_BEGIN and
BRIDGE_VLAN_INFO_RANGE_END.
$bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
$bridge vlan add vid 10-15 dev dummy0
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
10
11
12
13
14
15
$bridge vlan del vid 14 dev dummy0
$bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
10
11
12
13
15
$bridge vlan del vid 10-15 dev dummy0
$bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
v2: fix vid check
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
---
bridge/vlan.c | 44 ++++++++++++++++++++++++++++++++++++++++----
include/linux/if_bridge.h | 2 ++
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/bridge/vlan.c b/bridge/vlan.c
index 3bd7b0d..88992e6 100644
--- a/bridge/vlan.c
+++ b/bridge/vlan.c
@@ -32,6 +32,7 @@ static int vlan_modify(int cmd, int argc, char **argv)
} req;
char *d = NULL;
short vid = -1;
+ short vid_end = -1;
struct rtattr *afspec;
struct bridge_vlan_info vinfo;
unsigned short flags = 0;
@@ -49,8 +50,18 @@ static int vlan_modify(int cmd, int argc, char **argv)
NEXT_ARG();
d = *argv;
} else if (strcmp(*argv, "vid") == 0) {
+ char *p;
NEXT_ARG();
- vid = atoi(*argv);
+ p = strchr(*argv, '-');
+ if (p) {
+ *p = '\0';
+ p++;
+ vid = atoi(*argv);
+ vid_end = atoi(p);
+ vinfo.flags |= BRIDGE_VLAN_INFO_RANGE_BEGIN;
+ } else {
+ vid = atoi(*argv);
+ }
} else if (strcmp(*argv, "self") == 0) {
flags |= BRIDGE_FLAGS_SELF;
} else if (strcmp(*argv, "master") == 0) {
@@ -83,15 +94,40 @@ static int vlan_modify(int cmd, int argc, char **argv)
return -1;
}
- vinfo.vid = vid;
+ if (vinfo.flags & BRIDGE_VLAN_INFO_RANGE_BEGIN) {
+ if (vid_end == -1 || vid_end >= 4096 || vid >= vid_end) {
+ fprintf(stderr, "Invalid VLAN range \"%hu-%hu\"\n",
+ vid, vid_end);
+ return -1;
+ }
+ if (vinfo.flags & BRIDGE_VLAN_INFO_PVID) {
+ fprintf(stderr,
+ "pvid cannot be configured for a vlan range\n");
+ return -1;
+ }
+ }
afspec = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
if (flags)
addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
- addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
- sizeof(vinfo));
+ vinfo.vid = vid;
+ if (vid_end != -1) {
+ /* send vlan range start */
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+ vinfo.flags &= ~BRIDGE_VLAN_INFO_RANGE_BEGIN;
+
+ /* Now send the vlan range end */
+ vinfo.flags |= BRIDGE_VLAN_INFO_RANGE_END;
+ vinfo.vid = vid_end;
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+ } else {
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+ }
addattr_nest_end(&req.n, afspec);
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 19ff22a..efa10b8 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -125,6 +125,8 @@ enum {
#define BRIDGE_VLAN_INFO_MASTER (1<<0) /* Operate on Bridge device as well */
#define BRIDGE_VLAN_INFO_PVID (1<<1) /* VLAN is PVID, ingress untagged */
#define BRIDGE_VLAN_INFO_UNTAGGED (1<<2) /* VLAN egresses untagged */
+#define BRIDGE_VLAN_INFO_RANGE_BEGIN (1<<3) /* VLAN is start of vlan range */
+#define BRIDGE_VLAN_INFO_RANGE_END (1<<4) /* VLAN is end of vlan range */
struct bridge_vlan_info {
__u16 flags;
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Stephen Hemminger @ 2015-01-23 6:40 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, hannes
In-Reply-To: <1421263039-96198-1-git-send-email-dsahern@gmail.com>
On Wed, 14 Jan 2015 12:17:19 -0700
David Ahern <dsahern@gmail.com> wrote:
> Currently, ipv6 addresses are flushed when the interface is configured down:
>
> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> [root@f20 ~]# ip link set dev eth1 up
> [root@f20 ~]# ip link set dev eth1 down
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>
> Add a new sysctl to make this behavior optional. Setting defaults to flush
> addresses to maintain backwards compatibility. When reset flushing is bypassed:
>
> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> [root@f20 ~]# ip link set dev eth1 up
> [root@f20 ~]# ip link set dev eth1 down
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::4:11ff:fe22:3301/64 scope link
> valid_lft forever preferred_lft forever
>
> Suggested-by: Hannes Frederic Sowa <hannes@redhat.com>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> Cc: Hannes Frederic Sowa <hannes@redhat.com>
Would this break existing application expecting a particular semantic
by listening to netlink? What happens to packets received with the static
address when interface is down? With IPv4 Linux is mostly a weak host
model, and IPv6 somewhere in between.
For vendors that control the application stack or have limited number
of services this would work fine, but what about RHEL?
^ permalink raw reply
* Re: [PATCH net-next 1/2] tipc: fix excessive network event logging
From: Erik Hugne @ 2015-01-23 6:44 UTC (permalink / raw)
To: Joe Perches; +Cc: richard.alpe, netdev, jon.maloy, ying.xue, tipc-discussion
In-Reply-To: <1421947487.2702.1.camel@perches.com>
On Thu, Jan 22, 2015 at 09:24:47AM -0800, Joe Perches wrote:
> On Thu, 2015-01-22 at 17:10 +0100, erik.hugne@ericsson.com wrote:
> > From: Erik Hugne <erik.hugne@ericsson.com>
> >
> > If a large number of namespaces is spawned on a node and TIPC is
> > enabled in each of these, the excessive printk tracing of network
> > events will cause the system to grind down to a near halt.
> > The traces are still of debug value, so instead of removing them
> > completely we fix it by changing the link state and node availability
> > logging debug traces.
>
> Maybe some of these should be net_<level>_ratelimited(fmt, ...)
We proposed that initially, but changed all to pr_debug after David's comment:
http://www.spinics.net/lists/netdev/msg312902.html
The topology information (links going up/down) can be accessed
both via netlink ('tipc link list' command) and the topology server
via a subscription API.
//E
^ permalink raw reply
* Re: [PATCH net-next v2] iproute2: bridge: support vlan range
From: Stephen Hemminger @ 2015-01-23 6:51 UTC (permalink / raw)
To: roopa; +Cc: davem, netdev, vyasevic, wkok, sfeldma
In-Reply-To: <1421994310-48811-1-git-send-email-roopa@cumulusnetworks.com>
On Thu, 22 Jan 2015 22:25:10 -0800
roopa@cumulusnetworks.com wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch adds vlan range support to bridge command
> using the newly added vinfo flags BRIDGE_VLAN_INFO_RANGE_BEGIN and
> BRIDGE_VLAN_INFO_RANGE_END.
>
> $bridge vlan show
> port vlan ids
> br0 1 PVID Egress Untagged
>
> dummy0 1 PVID Egress Untagged
>
> $bridge vlan add vid 10-15 dev dummy0
> port vlan ids
> br0 1 PVID Egress Untagged
>
> dummy0 1 PVID Egress Untagged
> 10
> 11
> 12
> 13
> 14
> 15
Doing on vlan id per line gets ridiculous with 1000 vlan's
how about something more compact?
^ permalink raw reply
* Re: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
From: Alexander Duyck @ 2015-01-23 7:18 UTC (permalink / raw)
To: Hiroshi Shimamoto, Skidmore, Donald C, Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Choi, Sy Jong, linux-kernel@vger.kernel.org, David Laight,
Hayato Momma
In-Reply-To: <7F861DC0615E0C47A872E6F3C5FCDDBD05E0B6B1@BPXM14GP.gisp.nec.co.jp>
On 01/22/2015 04:32 PM, Hiroshi Shimamoto wrote:
>> Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
>>> "Skidmore, Donald C" <donald.c.skidmore@intel.com> writes:
>>>
>>>> My hang up is more related to: without the nob to enable it (off by
>>>> default) we are letting one VF dictate policy for all the other VFs
>>>> and the PF. If one VF needs to be in promiscuous multicast so is
>>>> everyone else. Their stacks now needs to deal with all the extra
>>>> multicast packets. As you point out this might not be a direct
>>>> concern for isolation in that the VM could have 'chosen' to join any
>>>> Multicast group and seen this traffic. My concern over isolation is
>>>> one VF has chosen that all the other VM now have to see this multicast
>>>> traffic.
>>> Apologies if this question is stupid, but I just have to ask about stuff I don't
>>> understand...
>>>
>>> Looking at the proposed implementation, the promiscous multicast flag
>>> seems to be a per-VF flag:
>>>
>>> +int ixgbe_ndo_set_vf_mc_promisc(struct net_device *netdev, int vf, bool
>>> +setting) {
>>> + struct ixgbe_adapter *adapter = netdev_priv(netdev);
>>> + struct ixgbe_hw *hw = &adapter->hw;
>>> + u32 vmolr;
>>> +
>>> + if (vf >= adapter->num_vfs)
>>> + return -EINVAL;
>>> +
>>> + adapter->vfinfo[vf].mc_promisc_enabled = setting;
>>> +
>>> + vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
>>> + if (setting) {
>>> + e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
>>> + vmolr |= IXGBE_VMOLR_MPE;
>>> + } else {
>>> + e_info(drv, "VF %u: disabling multicast promiscuous\n", vf);
>>> + vmolr &= ~IXGBE_VMOLR_MPE;
>>> + }
>>> +
>>> + IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
>>> +
>>> + return 0;
>>> +}
>>> +
>>>
>>> I haven't read the data sheet, but I took a quick look at the excellent high
>>> level driver docs:
>>> http://www.intel.com/content/dam/doc/design-guide/82599-sr-iov-driver-
>>> companion-guide.pdf
>>>
>>> It mentions "Multicast Promiscuous Enable" in its "Thoughts for
>>> Customization" section:
>>>
>>> 7.1 Multicast Promiscuous Enable
>>>
>>> The controller has provisions to allow each VF to be put into Multicast
>>> Promiscuous mode. The Intel reference driver does not configure this
>>> option .
>>>
>>> The capability can be enabled/disabled by manipulating the MPE field (bit
>>> 28) of the PF VF L2 Control Register (PFVML2FLT – 0x0F000)
>>>
>>> and showing a section from the data sheet describing the "PF VM L2 Control
>>> Register - PFVML2FLT[n] (0x0F000 + 4 * n, n=0...63; RW)"
>>>
>>> To me it looks like enabling Promiscuos Multicast for a VF won't affect any
>>> other VF at all. Is this really not the case?
>>>
>>>
>>>
>>> Bjørn
>> Clearly not a dumb question at all and I'm glad you mentioned that. :) I was going off the assumption, been awhile since
>> I read the patch, that the patch was using FCTRL.MPE or MANC.MCST_PASS_L2 which would turn multicast promiscuous on for
>> everyone. Since the patch is using PFVML2FLT.MPE this lessens my concern over effect on the entire system.
> I believe the patches for this VF multicast promiscuous mode is per VF.
>
>> That said I still would prefer having a way to override this behavior on the PF, although I admit my argument is weaker.
>> I'm still concerned about a VF changing the behavior of the PF without any way to prevent it. This might be one part
>> philosophical (PF sets policy not the VF) but this still could have a noticeable effect on the overall system. If any
>> other VFs (or the PF) are receiving MC packets these will have to be replicated which will be a performance hit. When
>> we use the MC hash this is limited vs. when anyone is in MC promiscuous every MC packet used by another pool would be
>> replicated. I could imagine in some environments (i.e. public clouds) where you don't trust what is running in your VM
>> you might what to block this from happening.
> I understand your request and I'm thinking to submit the patches
> 1) Add new mbox API between ixgbe/ixgbevf to turn MC promiscuous on,
> and enables it when ixgbevf needs over 30 MC addresses.
> 2) Add a policy knob to prevent enabling it from the PF.
>
> Does it seem okay?
I would advise that if such a knob is added it should be set to disabled
by default. The main problem with supporting that many multicast
addresses per VF is that you run the risk for flooding the PCIe
interface on the network adapter if too many adapters were to go into
such a mode.
> BTW, I'm bit worried about to use ndo interface for 2) because adding a
> new hook makes core code complicated.
> Is it really reasonable to do it with ndo?
> I haven't find any other suitable method to do it, right now. And using
> ndo VF hook looks standard way to control VF functionality.
> Then, I think it's the best way to implement this policy in ndo hook.
The ndo is probably the only way to go on this. It is how past controls
for the VF network functionality have been implemented.
>> In some ways it is almost the mirror image of the issue you brought up:
>>
>> Adding a new hook for this seems over-complicated to me. And it still
>> doesn't solve the real problems that
>> a) the user has to know about this limit, and
>> b) manually configure the feature
>>
>> My reverse argument might be that if this happens automatically. It might take the VM provider a long time to realize
>> performance has taken a hit because some VM asked to join 31 multicast groups and entered MC promiscuous. Then only to
>> find that they have no way to block such behavior.
>>
>> Maybe I wouldn't as concerned if the patch author could provide some performance results to show this won't have as a
>> negative effect as I'm afraid it might?
> Hm, what kind of test case would you like to have?
> The user A who has 30 MC addresses vs the user B who has 31 MC addresses, which
> means that MC promiscuous mode, and coming MC packets the user doesn't expect?
>
> thanks,
> Hiroshi
The question I would have is how many of these interfaces do you expect
to have supporting the expanded multicast mode? As it currently stands
multicast traffic has the potential to flood the adapter, greatly reduce
the overall throughput, and add extra workload to the PF and all VFs.
For example if several VFs enable this feature, and then someone on the
network sends a stream of multicast traffic what happens to the CPU load
for the host system?
Also how many addresses beyond 30 is it you require? An alternative to
adding multicast promiscuous might be to consider extending the mailbox
API to support sending more than 30 addresses via something such as a
multi-part multicast configuration message. The fm10k driver already
has logic similar to this as it adds addresses 1 at a time though a
separate Switch interface API between the PF and the Switch. You might
be able to reuse some of that code to reach beyond the 30 address limit.
- Alex
^ permalink raw reply
* Re: subtle change in behavior with tun driver
From: Michael S. Tsirkin @ 2015-01-23 7:38 UTC (permalink / raw)
To: Ani Sinha; +Cc: fruggeri, netdev@vger.kernel.org
In-Reply-To: <CAOxq_8PCJXw+yoXj0MtLO7nTvWWdR3N4XvKUZ00SX6y-A9EziQ@mail.gmail.com>
On Thu, Jan 22, 2015 at 04:28:09PM -0800, Ani Sinha wrote:
> On Thu, Jan 22, 2015 at 1:53 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Jan 21, 2015 at 02:36:17PM -0800, Ani Sinha wrote:
> >> Hi guys :
> >>
> >> Commit 5d097109257c03 ("tun: only queue packets on device") seems to
> >> have introduced a subtle change in behavior in the tun driver in the
> >> default (non IFF_ONE_QUEUE) case. Previously when the queues got full
> >> and eventually sk_wmem_alloc of the socket exceeded sk_sndbuf value,
> >> the user would be given a feedback by returning EAGAIN from sendto()
> >> etc. That way, the user could retry sending the packet again.
> >
> > This behaviour is common, but by no means guaranteed.
> > For example, if socket buffer size is large enough,
> > packets are small enough, or there are multiple sockets
> > transmitting through tun, packets would previously
> > accumulate in qdisc, followed by packet drops
> > without EAGAIN.
>
> Ah I see. pfifo_fast_enqueue() also starts dropping packets when it's
> length exceeds a threshold. So I supposed we do not have a strong
> argument for bringing back the old semantics because it wasn't
> guranteed in every scenario in the first place.
>
> >
> >> Unfortunately, with this new default single queue mode, the driver
> >> silently drops the packet when the device queue is full without giving
> >> userland any feedback. This makes it appear to userland as though the
> >> packet was transmitted successfully. It seems there is a semantic
> >> change in the driver with this commit.
> >>
> >> If the receiving process gets stuck for a short interval and is unable
> >> to drain packets and then restarts again, one might see strange packet
> >> drops in the kernel without getting any error back on the sender's
> >> side. It kind of feels wrong.
> >>
> >> Any thoughts?
> >>
> >> Ani
> >
> > Unfortunately - since it's pretty common for unpriveledged userspace to
> > drive the tun device - blocking the queue indefinitely as was done
> > previously leads to deadlocks for some apps, this was deemed worse than
> > some performance degradation.
>
> agreed. However applications which needs protection from deadlock can
> exclusively set IFF_ONE_QUEUE mode and live with the fact that they
> might see dropped packets.
This doesn't work because applications are just using the
linux networking stack. Packets end up in tun.
It's up to tun not to break the stack, we can't
change all applications out there.
> >
> > As a simple work-around, if you want packets to accumulate in the qdisc,
> > it's easy to implement by using a non work conserving qdisc.
> > Set the limits to match the speed at which your application
> > is able to consume the packets.
> >
> > I've been thinking about using some kind of watchdog to
> > make it safe to put the old non IFF_ONE_QUEUE semantics back,
> > unfortunately due to application being able to consume packets at the
> > same time it's not trivial to do in a non-racy way.
>
> I do not have an answer to this issue either. I agree that this is a
> hard issue to solve.
^ permalink raw reply
* [PATCH 0/2] ARM EXYNOS5 & net: add fixed phy support
From: Ming Lei @ 2015-01-23 7:48 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller
Cc: linux-samsung-soc, Kukjin Kim, netdev, Byungho An,
Florian Fainelli
Hi,
These two patches adds fixed phy support using the fixed-link DT binding
for stmmac.
Thanks,
Ming Lei
^ permalink raw reply
* [PATCH 2/2] net: stmmac: add fixed_phy support via fixed-link DT binding
From: Ming Lei @ 2015-01-23 7:48 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller
Cc: linux-samsung-soc, Kukjin Kim, netdev, Byungho An,
Florian Fainelli, Ming Lei
In-Reply-To: <1421999305-19267-1-git-send-email-ming.lei@canonical.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 3039de2..73a3ced 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -27,6 +27,7 @@
#include <linux/of.h>
#include <linux/of_net.h>
#include <linux/of_device.h>
+#include <linux/of_mdio.h>
#include "stmmac.h"
#include "stmmac_platform.h"
@@ -216,6 +217,15 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
plat->pmt = 1;
}
+ if (of_phy_is_fixed_link(np)) {
+ int ret = of_phy_register_fixed_link(np);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register fixed PHY\n");
+ return ret;
+ }
+ plat->phy_bus_name = "fixed";
+ }
+
if (of_device_is_compatible(np, "snps,dwmac-3.610") ||
of_device_is_compatible(np, "snps,dwmac-3.710")) {
plat->enh_desc = 1;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] ARM: exynos5440-sd5v1: switch to fixed-link DT binding
From: Ming Lei @ 2015-01-23 7:48 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller
Cc: linux-samsung-soc, Kukjin Kim, netdev, Byungho An,
Florian Fainelli, Ming Lei
In-Reply-To: <1421999305-19267-1-git-send-email-ming.lei@canonical.com>
The previous dts property isn't standard way for fixed phy
support, and switch to the fixed-link DT binding.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/boot/dts/exynos5440-sd5v1.dts | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5440-sd5v1.dts b/arch/arm/boot/dts/exynos5440-sd5v1.dts
index 268609a..ee65a5c 100644
--- a/arch/arm/boot/dts/exynos5440-sd5v1.dts
+++ b/arch/arm/boot/dts/exynos5440-sd5v1.dts
@@ -28,8 +28,10 @@
};
gmac: ethernet@00230000 {
- fixed_phy;
- phy_addr = <1>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
spi {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v1] usbnet: re-use native hex2bin()
From: Oliver Neukum @ 2015-01-23 8:12 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: netdev
In-Reply-To: <1421962032-25497-1-git-send-email-andy.shevchenko@gmail.com>
On Thu, 2015-01-22 at 23:27 +0200, Andy Shevchenko wrote:
> Call hex2bin() library function, instead of doing conversion here.
>
> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.de>
^ permalink raw reply
* Re: [PATCH 2/2] net: stmmac: add fixed_phy support via fixed-link DT binding
From: Ming Lei @ 2015-01-23 8:28 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller
Cc: linux-samsung-soc, Kukjin Kim, netdev, Byungho An,
Florian Fainelli, Ming Lei
In-Reply-To: <1421999305-19267-3-git-send-email-ming.lei@canonical.com>
On 1/23/15, Ming Lei <ming.lei@canonical.com> wrote:
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
> ---
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 3039de2..73a3ced 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -27,6 +27,7 @@
> #include <linux/of.h>
> #include <linux/of_net.h>
> #include <linux/of_device.h>
> +#include <linux/of_mdio.h>
>
> #include "stmmac.h"
> #include "stmmac_platform.h"
> @@ -216,6 +217,15 @@ static int stmmac_probe_config_dt(struct
> platform_device *pdev,
> plat->pmt = 1;
> }
>
> + if (of_phy_is_fixed_link(np)) {
> + int ret = of_phy_register_fixed_link(np);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register fixed PHY\n");
> + return ret;
> + }
> + plat->phy_bus_name = "fixed";
> + }
> +
> if (of_device_is_compatible(np, "snps,dwmac-3.610") ||
> of_device_is_compatible(np, "snps,dwmac-3.710")) {
> plat->enh_desc = 1;
Sorry, bypassing check on phy id is missed in this patch, and will
submit v1 later.
Thanks,
Ming Lei
^ permalink raw reply
* [PATCH] net: macb: Remove CONFIG_PM ifdef because of compilation warning
From: Michal Simek @ 2015-01-23 8:36 UTC (permalink / raw)
To: linux-kernel, monstr; +Cc: Nicolas Ferre, netdev
[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]
Fix compilation warning:
drivers/net/ethernet/cadence/macb.c:2415:12: warning: 'macb_suspend'
defined but not used [-Wunused-function]
static int macb_suspend(struct device *dev)
drivers/net/ethernet/cadence/macb.c:2432:12: warning: 'macb_resume'
defined but not used [-Wunused-function]
static int macb_resume(struct device *dev)
when CONFIG_PM=y, CONFIG_PM_SLEEP=n are used.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/cadence/macb.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 3767271c7667..23ae32f118c2 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2411,8 +2411,7 @@ static int __exit macb_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-static int macb_suspend(struct device *dev)
+static int __maybe_unused macb_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct net_device *netdev = platform_get_drvdata(pdev);
@@ -2429,7 +2428,7 @@ static int macb_suspend(struct device *dev)
return 0;
}
-static int macb_resume(struct device *dev)
+static int __maybe_unused macb_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct net_device *netdev = platform_get_drvdata(pdev);
@@ -2444,7 +2443,6 @@ static int macb_resume(struct device *dev)
return 0;
}
-#endif
static SIMPLE_DEV_PM_OPS(macb_pm_ops, macb_suspend, macb_resume);
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: David Miller @ 2015-01-23 8:54 UTC (permalink / raw)
To: arnd
Cc: wstephen, jcliburn, grant.likely, robh+dt, linux-kernel, netdev,
devicetree
In-Reply-To: <1753817.oBE21Kj2o0@wuerfel>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 22 Jan 2015 11:18:50 +0100
> I see. In this case, I think merging your new driver is not a good idea:
+1
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: David Miller @ 2015-01-23 9:00 UTC (permalink / raw)
To: therbert; +Cc: vincent.jardin, jesse, pshelar, netdev
In-Reply-To: <CA+mtBx9pnkJBVftqFTK6fcd-toAxsJrvB=drTxWQs_=5s9C0+A@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Thu, 22 Jan 2015 08:24:15 -0800
> STT is undoubtedly a creative and unique solution I'll give you that,
> but the potential repercussions of allowing this to be widely deployed
> are profound. IMO this needs to be fully explored before it can ever
> be allowed in the kernel. If there has already been discussion on this
> please forward a pointer (I didn't find anything in the IETF mailing
> list archives other than the draft posting announcements), but at the
> minimum these patches warrant a lot of scrutiny.
+1
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: David Miller @ 2015-01-23 9:00 UTC (permalink / raw)
To: pablo
Cc: tgraf, jhs, john.fastabend, simon.horman, sfeldma, netdev,
gerlitz.or, andy, ast, jiri
In-Reply-To: <20150122164951.GA3417@salvia>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 22 Jan 2015 17:49:51 +0100
> I think those vendors do not want to push those driver changes
> mainstream. They will likely use these new ndo's to fully expose their
> vendor-specific capabilities distributed in proprietary blobs.
+1
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: David Miller @ 2015-01-23 9:04 UTC (permalink / raw)
To: vincent.jardin; +Cc: therbert, jesse, pshelar, netdev
In-Reply-To: <54C138BB.7000407@6wind.com>
From: Vincent JARDIN <vincent.jardin@6wind.com>
Date: Thu, 22 Jan 2015 18:51:55 +0100
> Same: LRO/GRO is is bad features: it breaks many times networking
> (most IP forwarders must disable it), but it helps for servers. Same
> for STT in fact, it has its narrow set of use-cases which are valid.
False, GRO helps for forwarders too, because it decreases the number
of IP route lookups, one of the most expensive operations during
formwarding.
Please do not spread misinformation, and especially do not try to show
that GRO is in _ANY_ way something like STT. That's completely wrong.
^ permalink raw reply
* [PATCH] net: ieee802154: cc2520: Fix coding style issues
From: Mohammad Jamal @ 2015-01-23 9:26 UTC (permalink / raw)
To: varkabhadram, alex.aring, linux-wpan, netdev, linux-kernel; +Cc: Mohammad Jamal
This patch solves the coding style issues such as space after ,
and removes the blank lines
Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
---
drivers/net/ieee802154/cc2520.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
index f9df9fa..dd129be 100644
--- a/drivers/net/ieee802154/cc2520.c
+++ b/drivers/net/ieee802154/cc2520.c
@@ -513,7 +513,6 @@ err_tx:
return rc;
}
-
static int cc2520_rx(struct cc2520_private *priv)
{
u8 len = 0, lqi = 0, bytes = 1;
@@ -551,14 +550,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
u8 rssi;
int ret;
- ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
+ ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
if (ret)
return ret;
if (status != RSSI_VALID)
return -EINVAL;
- ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
+ ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
if (ret)
return ret;
@@ -947,7 +946,6 @@ static int cc2520_probe(struct spi_device *spi)
if (ret)
goto err_hw_init;
-
gpio_set_value(pdata->vreg, HIGH);
usleep_range(100, 150);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] net: ieee802154: cc2520: fix coding style issue
From: Mohammad Jamal @ 2015-01-23 9:36 UTC (permalink / raw)
To: varkabhadram, alex.aring, linux-wpan, netdev, linux-kernel; +Cc: Mohammad Jamal
This patch solves the coding style issue warning
by replacing the shifting operations by BIT macro
Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
---
drivers/net/ieee802154/cc2520.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
index dd129be..b9b2a49 100644
--- a/drivers/net/ieee802154/cc2520.c
+++ b/drivers/net/ieee802154/cc2520.c
@@ -45,9 +45,9 @@
#define CC2520_FREG_MASK 0x3F
/* status byte values */
-#define CC2520_STATUS_XOSC32M_STABLE (1 << 7)
-#define CC2520_STATUS_RSSI_VALID (1 << 6)
-#define CC2520_STATUS_TX_UNDERFLOW (1 << 3)
+#define CC2520_STATUS_XOSC32M_STABLE BIT(7)
+#define CC2520_STATUS_RSSI_VALID BIT(6)
+#define CC2520_STATUS_TX_UNDERFLOW BIT(3)
/* IEEE-802.15.4 defined constants (2.4 GHz logical channels) */
#define CC2520_MINCHANNEL 11
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] net: ieee802154: cc2520: Fix coding style issues
From: Varka Bhadram @ 2015-01-23 9:39 UTC (permalink / raw)
To: Mohammad Jamal
Cc: Alexander Aring, linux-wpan - ML, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1422005180-13230-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hi Mohammad Jamal,
These changes already there in the current bluetooth-next tree.
On Fri, Jan 23, 2015 at 2:56 PM, Mohammad Jamal
<md.jamalmohiuddin@gmail.com> wrote:
> This patch solves the coding style issues such as space after ,
> and removes the blank lines
>
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
> index f9df9fa..dd129be 100644
> --- a/drivers/net/ieee802154/cc2520.c
> +++ b/drivers/net/ieee802154/cc2520.c
> @@ -513,7 +513,6 @@ err_tx:
> return rc;
> }
>
> -
> static int cc2520_rx(struct cc2520_private *priv)
> {
> u8 len = 0, lqi = 0, bytes = 1;
> @@ -551,14 +550,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
> u8 rssi;
> int ret;
>
> - ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
> + ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
> if (ret)
> return ret;
>
> if (status != RSSI_VALID)
> return -EINVAL;
>
> - ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
> + ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
> if (ret)
> return ret;
>
> @@ -947,7 +946,6 @@ static int cc2520_probe(struct spi_device *spi)
> if (ret)
> goto err_hw_init;
>
> -
> gpio_set_value(pdata->vreg, HIGH);
> usleep_range(100, 150);
>
> --
> 1.7.9.5
>
--
Thanks and Regards,
Varka Bhadram.
^ 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