* 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
* Re: [PATCH net-next v3 1/5] netdev: introduce new NETIF_F_HW_NETFUNC_OFFLOAD feature flag for switch device offloads
From: Jiri Pirko @ 2015-01-23 9:44 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, vyasevic,
ronen.arad, netdev, davem, shm, gospo
In-Reply-To: <1421987606-10884-2-git-send-email-roopa@cumulusnetworks.com>
Fri, Jan 23, 2015 at 05:33:22AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This is a high level feature flag for all switch asic offloads
>
>switch drivers set this flag on switch ports. Logical devices like
>bridge, bonds, vxlans can inherit this flag from their slaves/ports.
>
>The patch also adds the flag to NETIF_F_ONE_FOR_ALL, so that it gets
>propagated to the upperdevices (bridges and bonds).
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>---
> include/linux/netdev_features.h | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>index 8e30685..784a461 100644
>--- a/include/linux/netdev_features.h
>+++ b/include/linux/netdev_features.h
>@@ -66,6 +66,7 @@ enum {
> NETIF_F_HW_VLAN_STAG_FILTER_BIT,/* Receive filtering on VLAN STAGs */
> NETIF_F_HW_L2FW_DOFFLOAD_BIT, /* Allow L2 Forwarding in Hardware */
> NETIF_F_BUSY_POLL_BIT, /* Busy poll */
>+ NETIF_F_HW_NETFUNC_OFFLOAD_BIT, /* HW switch offload */
How about rather "HW_DATAPATH_OFFLOAD"? Feels more accurate. By the
name, I still cannot understand what NETFUNC should mean.
>
> /*
> * Add your fresh new feature above and remember to update
>@@ -124,6 +125,7 @@ enum {
> #define NETIF_F_HW_VLAN_STAG_TX __NETIF_F(HW_VLAN_STAG_TX)
> #define NETIF_F_HW_L2FW_DOFFLOAD __NETIF_F(HW_L2FW_DOFFLOAD)
> #define NETIF_F_BUSY_POLL __NETIF_F(BUSY_POLL)
>+#define NETIF_F_HW_NETFUNC_OFFLOAD __NETIF_F(HW_NETFUNC_OFFLOAD)
>
> /* Features valid for ethtool to change */
> /* = all defined minus driver/device-class-related */
>@@ -159,7 +161,9 @@ enum {
> */
> #define NETIF_F_ONE_FOR_ALL (NETIF_F_GSO_SOFTWARE | NETIF_F_GSO_ROBUST | \
> NETIF_F_SG | NETIF_F_HIGHDMA | \
>- NETIF_F_FRAGLIST | NETIF_F_VLAN_CHALLENGED)
>+ NETIF_F_FRAGLIST | NETIF_F_VLAN_CHALLENGED | \
>+ NETIF_F_HW_NETFUNC_OFFLOAD)
>+
> /*
> * If one device doesn't support one of these features, then disable it
> * for all in netdev_increment_features.
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH] net: ieee802154: cc2520: fix coding style issue
From: Varka Bhadram @ 2015-01-23 9:46 UTC (permalink / raw)
To: Mohammad Jamal
Cc: Alexander Aring, linux-wpan - ML, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1422005800-13442-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hi Mohammad Jamal,
On Fri, Jan 23, 2015 at 3:06 PM, Mohammad Jamal
<md.jamalmohiuddin@gmail.com> wrote:
> 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
>
Please work on bluetooth-next[1] tree and also include
'bluetooth-next' tag for the patch.
[1]: http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/
--
Thanks and Regards,
Varka Bhadram.
^ permalink raw reply
* Re: [PATCH] net: ieee802154: cc2520: fix coding style issue
From: Jamal Mohammad @ 2015-01-23 9:48 UTC (permalink / raw)
To: Varka Bhadram
Cc: Alexander Aring, linux-wpan - ML, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAEUmHybQkyR7_TqOstDFcU=7iohL8E8ZaQYSNPiZC+MCi=hLmA@mail.gmail.com>
On Fri, Jan 23, 2015 at 3:16 PM, Varka Bhadram <varkabhadram@gmail.com> wrote:
> Hi Mohammad Jamal,
>
> On Fri, Jan 23, 2015 at 3:06 PM, Mohammad Jamal
> <md.jamalmohiuddin@gmail.com> wrote:
>> 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
>>
>
> Please work on bluetooth-next[1] tree and also include
> 'bluetooth-next' tag for the patch.
>
> [1]: http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/
>
> --
> Thanks and Regards,
> Varka Bhadram.
OK , i will send u the patch once i clone the bluetooth-next tree.
^ 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