* Re: [PATCH] sky2: avoid pci write posting after disabling irqs
From: David Miller @ 2014-12-06 5:34 UTC (permalink / raw)
To: LinoSanfilippo; +Cc: stephen, mlindner, netdev, linux-kernel
In-Reply-To: <1417348611-1752-1-git-send-email-LinoSanfilippo@gmx.de>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Sun, 30 Nov 2014 12:56:51 +0100
> In sky2_change_mtu setting B0_IMSK to 0 may be delayed due to PCI write posting
> which could result in irqs being still active when synchronize_irq is called.
> Since we are not prepared to handle any further irqs after synchronize_irq
> (our resources are freed after that) force the write by a consecutive read from
> the same register.
> Similar situation in sky2_all_down: Here we disabled irqs by a write to B0_IMSK
> but did not ensure that this write took place before synchronize_irq. Fix that
> too.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH] uapi: fix to export linux/vm_sockets.h
From: David Miller @ 2014-12-06 5:36 UTC (permalink / raw)
To: yamada.m-NAum8xwdG0+S7A1Ibl2khg
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
ast-uqk4Ao+rVK5Wk0Htik3J/w, piotr.krol-zILERgsGILsAvxtiuMwx3w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417396577-32499-1-git-send-email-yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
From: Masahiro Yamada <yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
Date: Mon, 1 Dec 2014 10:16:17 +0900
> A typo "header=y" was introduced by commit 7071cf7fc435
> (uapi: add missing network related headers to kbuild).
>
> Signed-off-by: Masahiro Yamada <yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
> Cc: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH v2 iproute] bridge link: add option 'self'
From: Scott Feldman @ 2014-12-06 5:36 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller, shm,
Andy Gospodarek
In-Reply-To: <1417827563-811-1-git-send-email-roopa@cumulusnetworks.com>
On Fri, Dec 5, 2014 at 4:59 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Currently self is set internally only if hwmode is set.
> This makes it necessary for the hw to have a mode.
> There is no hwmode really required to go to hardware. So, introduce
> self for anybody who wants to target hardware.
>
> v1 -> v2
> - fix a few bugs. Initialize flags to zero: this was required to
> keep the current behaviour unchanged.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> bridge/link.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/bridge/link.c b/bridge/link.c
> index 90d9e7f..b8b8675 100644
> --- a/bridge/link.c
> +++ b/bridge/link.c
> @@ -261,7 +261,7 @@ static int brlink_modify(int argc, char **argv)
> __s16 priority = -1;
> __s8 state = -1;
> __s16 mode = -1;
> - __u16 flags = BRIDGE_FLAGS_MASTER;
> + __u16 flags = 0;
I don't follow why this change is necessary. Seems defaulting to
MASTER unless SELF is set due to "self" or "hwmode" would be more
correct (and expected).
> struct rtattr *nest;
>
> memset(&req, 0, sizeof(req));
> @@ -321,6 +321,8 @@ static int brlink_modify(int argc, char **argv)
> "\"veb\".\n");
> exit(-1);
> }
> + } else if (strcmp(*argv, "self") == 0) {
> + flags = BRIDGE_FLAGS_SELF;
> } else {
> usage();
> }
> @@ -375,10 +377,11 @@ static int brlink_modify(int argc, char **argv)
> * devices so far. Thus we only need to include the flags attribute
> * if we are setting the hw mode.
> */
The comment above needs to be updated to reflect the new logic.
> - if (mode >= 0) {
> + if (mode >= 0 || flags > 0) {
> nest = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
>
> - addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
> + if (flags > 0)
> + addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
>
> if (mode >= 0)
> addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net] openvswitch: Fix flow mask validation.
From: David Miller @ 2014-12-06 5:42 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1417417457-1492-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Sun, 30 Nov 2014 23:04:17 -0800
> Following patch fixes typo in the flow validation. This prevented
> installation of ARP and IPv6 flows.
>
> Fixes: 19e7a3df72 ("openvswitch: Fix NDP flow mask validation")
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] rocker: remove swdev mode
From: Scott Feldman @ 2014-12-06 5:44 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller, shm,
Andy Gospodarek
In-Reply-To: <1417828604-42722-3-git-send-email-roopa@cumulusnetworks.com>
On Fri, Dec 5, 2014 at 5:16 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This resets rocker mode to zero (vepa) during gets.
> This is because the default getlink handler that rocker
> uses today always takes a mode.
>
> Will fix that in a subsequent patch.
One patch set with that fix would be better, otherwise your patch here
will show rocker port running in VEB mode, which is wrong. Maybe
return mode=-1 for unspecified, or something like that?
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
> index fded127..391077c 100644
> --- a/drivers/net/ethernet/rocker/rocker.c
> +++ b/drivers/net/ethernet/rocker/rocker.c
> @@ -3700,27 +3700,11 @@ static int rocker_port_bridge_setlink(struct net_device *dev,
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> struct nlattr *protinfo;
> - struct nlattr *afspec;
> struct nlattr *attr;
> - u16 mode;
> int err;
>
> protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
> IFLA_PROTINFO);
> - afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
> -
> - if (afspec) {
> - attr = nla_find_nested(afspec, IFLA_BRIDGE_MODE);
> - if (attr) {
> - if (nla_len(attr) < sizeof(mode))
> - return -EINVAL;
> -
> - mode = nla_get_u16(attr);
> - if (mode != BRIDGE_MODE_SWDEV)
> - return -EINVAL;
> - }
> - }
> -
> if (protinfo) {
> attr = nla_find_nested(protinfo, IFLA_BRPORT_LEARNING);
> if (attr) {
> @@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> u32 filter_mask)
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> - u16 mode = BRIDGE_MODE_SWDEV;
> + u16 mode = 0;
> u32 mask = BR_LEARNING | BR_LEARNING_SYNC;
>
> return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode,
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH V4 net-next] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
From: David Miller @ 2014-12-06 5:45 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst, eric.dumazet
In-Reply-To: <1417423995-4765-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Mon, 1 Dec 2014 16:53:15 +0800
> To be more friendly with drop monitor, we should only call kfree_skb() when
> the packets were dropped and use consume_skb() in other cases.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Eric Dumazet @ 2014-12-06 5:46 UTC (permalink / raw)
To: David Miller; +Cc: weiyang, netdev, gideonn, edumazet, amirv
In-Reply-To: <20141205.213112.1199355931404701216.davem@davemloft.net>
On Fri, 2014-12-05 at 21:31 -0800, David Miller wrote:
> Guys, let's figure out what we are doing with this patch.
> --
Oh well, patch is fine, please apply it, thanks !
^ permalink raw reply
* Re: [PATCH v2 net-next 0/6] allow eBPF programs to be attached to sockets
From: David Miller @ 2014-12-06 5:48 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A, luto-kltTT9wpgjJwATOyAt5JVQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417475199-15950-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Mon, 1 Dec 2014 15:06:33 -0800
> V1->V2:
>
> fixed comments in sample code to state clearly that packet data is accessed
> with LD_ABS instructions and not internal skb fields.
> Also replaced constants in:
> BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
> with:
> BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol) /* R0 = ip->proto */),
>
> V1 cover:
>
> Introduce BPF_PROG_TYPE_SOCKET_FILTER type of eBPF programs that can be
> attached to sockets with setsockopt().
> Allow such programs to access maps via lookup/update/delete helpers.
>
> This feature was previewed by bpf manpage in commit b4fc1a460f30("Merge branch 'bpf-next'")
> Now it can actually run.
>
> 1st patch adds LD_ABS/LD_IND instruction verification and
> 2nd patch adds new setsockopt() flag.
> Patches 3-6 are examples in assembler and in C.
>
> Though native eBPF programs are way more powerful than classic filters
> (attachable through similar setsockopt() call), they don't have skb field
> accessors yet. Like skb->pkt_type, skb->dev->ifindex are not accessible.
> There are sevaral ways to achieve that. That will be in the next set of patches.
> So in this set native eBPF programs can only read data from packet and
> access maps.
>
> The most powerful example is sockex2_kern.c from patch 6 where ~200 lines of C
> are compiled into ~300 of eBPF instructions.
> It shows how quite complex packet parsing can be done.
>
> LLVM used to build examples is at https://github.com/iovisor/llvm
> which is fork of llvm trunk that I'm cleaning up for upstreaming.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Scott Feldman @ 2014-12-06 6:29 UTC (permalink / raw)
To: Arad, Ronen
Cc: Roopa Prabhu, Netdev, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505D8436D@ORSMSX101.amr.corp.intel.com>
On Fri, Dec 5, 2014 at 5:04 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
> I have another case of propagation which is not covered by the proposed patch.
> A recent patch introduced default_pvid attribute for a bridge (so far supported only via sysfs and not via netlink).
> When a port joins a bridge, it inherits a PVID from the default_pvid of the bridge.
> The bridge driver propagates that to the newly created net_bridge_port. This is done in br_vlan.c:
>
> int nbp_vlan_init(struct net_bridge_port *p)
> {
> int rc = 0;
>
> if (p->br->default_pvid) {
> rc = nbp_vlan_add(p, p->br->default_pvid,
> BRIDGE_VLAN_INFO_PVID |
> BRIDGE_VLAN_INFO_UNTAGGED);
> }
>
> return rc;
> }
>
> When L2 switching is offloaded to the HW, this PVID setting need to be propagated.
Agreed, it would be nice to have it propagated down, but there is a
non-ideal work-around. If you set default_pvid=0 to turn off PVID,
then the switch port driver can pick some internal VLAN ID just for HW
purposes in matching untagged pkts. It's non-ideal because the switch
port driver needs to reserve a block of VLAN IDs for internal usage or
use some other matching mechanism to keep untagged pkts within this
bridge.
Better to have default_pvid value propagated down. But, default_pvid
is a per-bridge property, not a per-bridge-port property.
RTM_SETLINK/RTM_GETLINK for PF_BRIDGE does have AFSPEC for per-bridge
and PROTINFO for per-bridge-port, so it seems PVID needs to be part of
AFSPEC.
>However, it does not come via ndo_bridge_setlink. The proposed propagation at br_setlink or an up level one at rtnetlink are not capable of handling this case.
> One possible way for handling that is to replace the call to nbp_vlan_add with a call to a new function let's say
> int br_propagate_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
> This function will compose a netlink message with VLAN filtering information (i.e. AF_SPEC with VLAN_INFO) and call br_setlink - leveraging the offload support proposed by Roopa.
>
> If this is an acceptable course of action, I could work on such patch.
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Arad, Ronen
>> Sent: Friday, December 05, 2014 3:21 PM
>> To: Roopa Prabhu; Scott Feldman; Netdev
>> Cc: Jirí Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>> fastabend; stephen@networkplumber.org; John Linville;
>> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>> Fainelli; buytenh@wantstofly.org; Aviad Raveh; David S. Miller;
>> shm@cumulusnetworks.com; Andy Gospodarek
>> Subject: RE: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
>> if feature flag set
>>
>>
>>
>> > -----Original Message-----
>> > From: netdev-owner@vger.kernel.org [mailto:netdev-
>> > owner@vger.kernel.org] On Behalf Of Roopa Prabhu
>> > Sent: Thursday, December 04, 2014 11:02 PM
>> > To: Scott Feldman
>> > Cc: Jiří Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>> > fastabend; stephen@networkplumber.org; John Linville;
>> > nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>> > Fainelli; buytenh@wantstofly.org; Aviad Raveh; Netdev; David S.
>> > Miller; shm@cumulusnetworks.com; Andy Gospodarek
>> > Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to
>> > switch asic if feature flag set
>> >
>> > On 12/4/14, 10:41 PM, Scott Feldman wrote:
>> > > On Thu, Dec 4, 2014 at 6:26 PM, <roopa@cumulusnetworks.com> wrote:
>> > >> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>> > >>
>> > >> This allows offloading to switch asic without having the user to
>> > >> set any flag. And this is done in the bridge driver to rollback
>> > >> kernel settings on hw offload failure if required in the future.
>> > >>
>> > >> With this, it also makes sure a notification goes out only after
>> > >> the attributes are set both in the kernel and hw.
>> > > I like this approach as it streamlines the steps for the user in
>> > > setting port flags. There is one case for FLOODING where you'll
>> > > have to turn off flooding for both, and then turn on flooding in hw.
>> > > You don't want flooding turned on on kernel and hw.
>> > ok, maybe using the higher bits as in
>> > https://patchwork.ozlabs.org/patch/413211/
>> >
>> > might help with that. Let me think some more.
>> > >
>> > >> ---
>> > >> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
>> > >> 1 file changed, 26 insertions(+), 1 deletion(-)
>> > >>
>> > >> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
>> > >> index
>> > >> 9f5eb55..ce173f0 100644
>> > >> --- a/net/bridge/br_netlink.c
>> > >> +++ b/net/bridge/br_netlink.c
>> > >> @@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct
>> > nlmsghdr *nlh)
>> > >> afspec, RTM_SETLINK);
>> > >> }
>> > >>
>> > >> + if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
>> > >> + dev->netdev_ops->ndo_bridge_setlink) {
>> > >> + int ret = dev->netdev_ops->ndo_bridge_setlink(dev,
>> > >> + nlh);
>> > > I think you want to up-level this to net/core/rtnetlink.c because
>> > > you're only enabling the feature for one instance of a driver that
>> > > implements ndo_bridge_setlink: the bridge driver. If another driver
>> > > was MASTER and implemented ndo_bridge_setlink, you'd want same
>> check
>> > > to push setting down to SELF port driver.
>> >
>> > yeah, i thought about that. But i moved it here so that rollback would
>> > be easier.
>>
>> There is a need for propagating setlink/dellink requests down multiple levels.
>> The use-case I have in mind is a bridge at the top, team/bond in the middle,
>> and port devices at the bottom.
>> A setlink for VLAN filtering attributes would come with MASTER flag set, and
>> either port or bond/team netdev.
>> How would this be handled?
>>
>> The propagation rules between bridge and enslaved port device could be
>> different from those between bond/team and enslaved devices.
>> The current bridge driver does not propagate VLAN filtering from bridge to its
>> ports as each port could have different configuration. In a case of a
>> bond/team all members need to have the same configuration such that the a
>> bond/team would be indistinguishable from a simple port.
>>
>> Therefore rtnetlink.c might not have the knowledge for propagation across
>> multiple levels.
>> It seems that each device which implements
>> ndo_bridge_setlink/ndo_bridge_dellink and could have master role, need to
>> take care of propagation to its slaves.
>>
>> > >
>> > >> + if (ret && ret != -EOPNOTSUPP) {
>> > >> + /* XXX Fix this in the future to rollback
>> > >> + * kernel settings and return error
>> > >> + */
>> > > The future is now. Let's fix this now for the rollback case (again
>> > > up in rtnetlink.c). So then a general question comes to mind: for
>> > > these dual target sets, is it best to try HW first and then SW, or
>> > > the other way around? Either way, on failure on second you need to
>> > > rollback first. And, on failure, you need to know rollback value
>> > > for first, so you have to do a getlink on first before attempting set.
>> > yep, exactly, I went through the same thought process yesterday when i
>> > was trying to implement rollback.
>> > >
>> > >> + br_warn(p->br, "error offloading bridge attributes "
>> > >> + "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;
>> > >> }
>> > >> @@ -433,6 +445,19 @@ int br_dellink(struct net_device *dev, struct
>> > nlmsghdr *nlh)
>> > >> err = br_afspec((struct net_bridge *)netdev_priv(dev), p,
>> > >> afspec, RTM_DELLINK);
>> > >>
>> > >> + if (dev->features & NETIF_F_HW_SWITCH_OFFLOAD
>> > >> + && dev->netdev_ops->ndo_bridge_setlink) {
>> > >> + int ret = dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
>> > >> + if (ret && ret != -EOPNOTSUPP) {
>> > >> + /* XXX Fix this in the future to rollback
>> > >> + * kernel settings and return error
>> > >> + */
>> > >> + br_warn(p->br, "error offloading bridge attributes "
>> > >> + "on port %u(%s)\n", (unsigned int) p->port_no,
>> > >> + p->dev->name);
>> > >> + }
>> > >> + }
>> > >> +
>> > > Same comments as setlink above.
>> > >
>> > >> return err;
>> > >> }
>> > >> static int br_validate(struct nlattr *tb[], struct nlattr
>> > >> *data[])
>> > >> --
>> > >> 1.7.10.4
>> > >>
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe netdev" in
>> > the body of a message to majordomo@vger.kernel.org More majordomo
>> info
>> > at http://vger.kernel.org/majordomo-info.html
>> {.n + +% lzwm b 맲 r zw u ^n r z h & G h ( 階 ݢj" m z ޖ
>> f h ~ m
^ permalink raw reply
* Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Scott Feldman @ 2014-12-06 6:54 UTC (permalink / raw)
To: Arad, Ronen
Cc: Roopa Prabhu, Netdev, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505D842BA@ORSMSX101.amr.corp.intel.com>
On Fri, Dec 5, 2014 at 3:21 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Roopa Prabhu
>> Sent: Thursday, December 04, 2014 11:02 PM
>> To: Scott Feldman
>> Cc: Jiří Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>> fastabend; stephen@networkplumber.org; John Linville;
>> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>> Fainelli; buytenh@wantstofly.org; Aviad Raveh; Netdev; David S. Miller;
>> shm@cumulusnetworks.com; Andy Gospodarek
>> Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
>> if feature flag set
>>
>> On 12/4/14, 10:41 PM, Scott Feldman wrote:
>> > On Thu, Dec 4, 2014 at 6:26 PM, <roopa@cumulusnetworks.com> wrote:
>> >> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>> >>
>> >> This allows offloading to switch asic without having the user to set
>> >> any flag. And this is done in the bridge driver to rollback kernel
>> >> settings on hw offload failure if required in the future.
>> >>
>> >> With this, it also makes sure a notification goes out only after the
>> >> attributes are set both in the kernel and hw.
>> > I like this approach as it streamlines the steps for the user in
>> > setting port flags. There is one case for FLOODING where you'll have
>> > to turn off flooding for both, and then turn on flooding in hw. You
>> > don't want flooding turned on on kernel and hw.
>> ok, maybe using the higher bits as in
>> https://patchwork.ozlabs.org/patch/413211/
>>
>> might help with that. Let me think some more.
>> >
>> >> ---
>> >> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
>> >> 1 file changed, 26 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c index
>> >> 9f5eb55..ce173f0 100644
>> >> --- a/net/bridge/br_netlink.c
>> >> +++ b/net/bridge/br_netlink.c
>> >> @@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct
>> nlmsghdr *nlh)
>> >> afspec, RTM_SETLINK);
>> >> }
>> >>
>> >> + if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
>> >> + dev->netdev_ops->ndo_bridge_setlink) {
>> >> + int ret = dev->netdev_ops->ndo_bridge_setlink(dev,
>> >> + nlh);
>> > I think you want to up-level this to net/core/rtnetlink.c because
>> > you're only enabling the feature for one instance of a driver that
>> > implements ndo_bridge_setlink: the bridge driver. If another driver
>> > was MASTER and implemented ndo_bridge_setlink, you'd want same check
>> > to push setting down to SELF port driver.
>>
>> yeah, i thought about that. But i moved it here so that rollback would be
>> easier.
>
> There is a need for propagating setlink/dellink requests down multiple levels.
> The use-case I have in mind is a bridge at the top, team/bond in the middle, and port devices at the bottom.
> A setlink for VLAN filtering attributes would come with MASTER flag set, and either port or bond/team netdev.
> How would this be handled?
>
> The propagation rules between bridge and enslaved port device could be different from those between bond/team and enslaved devices.
> The current bridge driver does not propagate VLAN filtering from bridge to its ports as each port could have different configuration. In a case of a bond/team all members need to have the same configuration such that the a bond/team would be indistinguishable from a simple port.
>
> Therefore rtnetlink.c might not have the knowledge for propagation across multiple levels.
> It seems that each device which implements ndo_bridge_setlink/ndo_bridge_dellink and could have master role, need to take care of propagation to its slaves.
Thanks Ronen for bringing up this use-case of stacked masters. I
think for VLAN filtering, the stacked master case is handled, not by
ndo_setlink/dellink at each level, but with ndo_vlan_rx_kill_vid and
ndo_vlan_rx_add_vid. So the switch port driver can know VLAN
membership for port even if port is under bond which is under bridge,
by using ndo_vlan_rx_xxx and setting NETIF_F_HW_VLAN_CTAG_FILTER. The
bonding driver's ndo_vlan_rx_xxx handlers seem to keep ports in bond
VLAN membership consistent across bond.
But in general, ndo_setlink/dellink don't work for the stack use-case
for other non-VLAN attributes. Maybe the answer is to use the VLAN
propogation model for other attributes. ndo_setlink/dellink/getlink
have enough weird-isms it might be time to define cleaner ndo ops to
propagate the other attrs down.
^ permalink raw reply
* Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature flag for switch device offloads
From: Roopa Prabhu @ 2014-12-06 7:46 UTC (permalink / raw)
To: Thomas Graf
Cc: jiri, sfeldma, jhs, bcrl, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <20141205224320.GA22992@casper.infradead.org>
On 12/5/14, 2:43 PM, Thomas Graf wrote:
> On 12/04/14 at 06:26pm, roopa@cumulusnetworks.com wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> This is a generic high level feature flag for all switch asic features today.
>>
>> switch drivers set this flag on switch ports. Logical devices like
>> bridge, bonds, vxlans can inherit this flag from their slaves/ports.
>>
>> I had to use SWITCH in the name to avoid ambiguity with other feature
>> flags. But, since i have been harping about not calling it 'switch',
>> I am welcome to any suggestions :)
>>
>> An alternative to using a feature flag is to use a IFF_HW_OFFLOAD
>> in net_device_flags.
> What does this flag indicate specifically? What driver would
> implement ndo_bridge_setlink() but not set this flag?
>
> I think it should be clearly documented when this flag is to bet set.
I mentioned it as an alternative because it was there in my RFC patch.
There is no code for it yet.
And I will get rid of the comment in v2.
^ permalink raw reply
* Re: [PATCH v2 iproute] bridge link: add option 'self'
From: Roopa Prabhu @ 2014-12-06 8:03 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller, shm,
Andy Gospodarek
In-Reply-To: <CAE4R7bBYOW60bL07hD-wPWZZZxQ+jKx95cG0wnEMdU8KMZB5rw@mail.gmail.com>
On 12/5/14, 9:36 PM, Scott Feldman wrote:
> On Fri, Dec 5, 2014 at 4:59 PM, <roopa@cumulusnetworks.com> wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> Currently self is set internally only if hwmode is set.
>> This makes it necessary for the hw to have a mode.
>> There is no hwmode really required to go to hardware. So, introduce
>> self for anybody who wants to target hardware.
>>
>> v1 -> v2
>> - fix a few bugs. Initialize flags to zero: this was required to
>> keep the current behaviour unchanged.
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>> ---
>> bridge/link.c | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/bridge/link.c b/bridge/link.c
>> index 90d9e7f..b8b8675 100644
>> --- a/bridge/link.c
>> +++ b/bridge/link.c
>> @@ -261,7 +261,7 @@ static int brlink_modify(int argc, char **argv)
>> __s16 priority = -1;
>> __s8 state = -1;
>> __s16 mode = -1;
>> - __u16 flags = BRIDGE_FLAGS_MASTER;
>> + __u16 flags = 0;
> I don't follow why this change is necessary. Seems defaulting to
> MASTER unless SELF is set due to "self" or "hwmode" would be more
> correct (and expected).
That flags initialization was always a no-op. IFLA_BRIDGE_FLAGS was
always set only with the 'self' flag on.
And i don't want to change that unnecessarily with my patch.
Setting it to master now means we will always include IFLA_AF_SPEC with
IFLA_BRIDGE_FLAGS in every 'bridge setlink' msg.
Which will be a change from the current behavior. And i dont intend to
introduce it with this patch.
Kernel has always treated no flags as 'master', so we are good from
kernel perspective.
>
>> struct rtattr *nest;
>>
>> memset(&req, 0, sizeof(req));
>> @@ -321,6 +321,8 @@ static int brlink_modify(int argc, char **argv)
>> "\"veb\".\n");
>> exit(-1);
>> }
>> + } else if (strcmp(*argv, "self") == 0) {
>> + flags = BRIDGE_FLAGS_SELF;
>> } else {
>> usage();
>> }
>> @@ -375,10 +377,11 @@ static int brlink_modify(int argc, char **argv)
>> * devices so far. Thus we only need to include the flags attribute
>> * if we are setting the hw mode.
>> */
> The comment above needs to be updated to reflect the new logic.
ok, will do, Thanks
>
>> - if (mode >= 0) {
>> + if (mode >= 0 || flags > 0) {
>> nest = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
>>
>> - addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
>> + if (flags > 0)
>> + addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
>>
>> if (mode >= 0)
>> addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
>> --
>> 1.7.10.4
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Arad, Ronen @ 2014-12-06 8:05 UTC (permalink / raw)
To: Scott Feldman, Netdev
Cc: Roopa Prabhu, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <CAE4R7bChFLfCX5z4FTWHfnpNuYKnkTtD64xg5BE0yAwA381w3g@mail.gmail.com>
> -----Original Message-----
> From: Scott Feldman [mailto:sfeldma@gmail.com]
> Sent: Friday, December 05, 2014 10:29 PM
> To: Arad, Ronen
> Cc: Roopa Prabhu; Netdev; Jirí Pírko; Jamal Hadi Salim; Benjamin LaHaise;
> Thomas Graf; john fastabend; stephen@networkplumber.org; John Linville;
> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
> Fainelli; buytenh@wantstofly.org; Aviad Raveh; David S. Miller;
> shm@cumulusnetworks.com; Andy Gospodarek
> Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
> if feature flag set
>
> On Fri, Dec 5, 2014 at 5:04 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
> > I have another case of propagation which is not covered by the proposed
> patch.
> > A recent patch introduced default_pvid attribute for a bridge (so far
> supported only via sysfs and not via netlink).
> > When a port joins a bridge, it inherits a PVID from the default_pvid of the
> bridge.
> > The bridge driver propagates that to the newly created net_bridge_port.
> This is done in br_vlan.c:
> >
> > int nbp_vlan_init(struct net_bridge_port *p) {
> > int rc = 0;
> >
> > if (p->br->default_pvid) {
> > rc = nbp_vlan_add(p, p->br->default_pvid,
> > BRIDGE_VLAN_INFO_PVID |
> > BRIDGE_VLAN_INFO_UNTAGGED);
> > }
> >
> > return rc;
> > }
> >
> > When L2 switching is offloaded to the HW, this PVID setting need to be
> propagated.
>
> Agreed, it would be nice to have it propagated down, but there is a non-ideal
> work-around. If you set default_pvid=0 to turn off PVID, then the switch port
> driver can pick some internal VLAN ID just for HW purposes in matching
> untagged pkts. It's non-ideal because the switch port driver needs to reserve
> a block of VLAN IDs for internal usage or use some other matching
> mechanism to keep untagged pkts within this bridge.
This work-around let the administrator avoid using VID=1 as the default VLAN for untagged frames. However, it does not let the administrator pick a VID of her choice.
>
> Better to have default_pvid value propagated down. But, default_pvid is a
> per-bridge property, not a per-bridge-port property.
> RTM_SETLINK/RTM_GETLINK for PF_BRIDGE does have AFSPEC for per-bridge
> and PROTINFO for per-bridge-port, so it seems PVID needs to be part of
> AFSPEC.
I believe AFSPEC is not limited to per-bridge properties. It is per-bridge when the netlink msg's ifindex is that of a bridge and SELF flag is set.
AFSPEC is for a port when the netlink msg's ifindex is that of an enslaved port device and MASTER flag is set (or neither MASTER nor SELF flag is set)
PVID is one of the flags associated with a VID in bridge_vlan_info.
default_pvid is not currently supported by netlink. A new IFLA_BRIDGE_DEFAULT_PVID could be introduced to carry this property when a nlmsg is directed at a bridge.
>
> >However, it does not come via ndo_bridge_setlink. The proposed
> propagation at br_setlink or an up level one at rtnetlink are not capable of
> handling this case.
> > One possible way for handling that is to replace the call to
> >nbp_vlan_add with a call to a new function let's say int
> >br_propagate_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
> This function will compose a netlink message with VLAN filtering information
> (i.e. AF_SPEC with VLAN_INFO) and call br_setlink - leveraging the offload
> support proposed by Roopa.
> >
> > If this is an acceptable course of action, I could work on such patch.
> >
> >
> >> -----Original Message-----
> >> From: netdev-owner@vger.kernel.org [mailto:netdev-
> >> owner@vger.kernel.org] On Behalf Of Arad, Ronen
> >> Sent: Friday, December 05, 2014 3:21 PM
> >> To: Roopa Prabhu; Scott Feldman; Netdev
> >> Cc: Jirí Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
> >> fastabend; stephen@networkplumber.org; John Linville;
> >> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
> >> Fainelli; buytenh@wantstofly.org; Aviad Raveh; David S. Miller;
> >> shm@cumulusnetworks.com; Andy Gospodarek
> >> Subject: RE: [PATCH 2/3] bridge: offload bridge port attributes to
> >> switch asic if feature flag set
> >>
> >>
> >>
<snip>
^ permalink raw reply
* [PATCH v3 iproute2] bridge link: add option 'self'
From: roopa @ 2014-12-06 8:21 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
linville, vyasevic
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Currently self is set internally only if hwmode is set.
This makes it necessary for the hw to have a mode.
There is no hwmode really required to go to hardware. So, introduce
self for anybody who wants to target hardware.
v1 -> v2
- fix a few bugs. Initialize flags to zero: this was required to
keep the current behaviour unchanged.
v2 -> v3
- fix comment
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
bridge/link.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/bridge/link.c b/bridge/link.c
index 90d9e7f..3f77aab 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -261,7 +261,7 @@ static int brlink_modify(int argc, char **argv)
__s16 priority = -1;
__s8 state = -1;
__s16 mode = -1;
- __u16 flags = BRIDGE_FLAGS_MASTER;
+ __u16 flags = 0;
struct rtattr *nest;
memset(&req, 0, sizeof(req));
@@ -321,6 +321,8 @@ static int brlink_modify(int argc, char **argv)
"\"veb\".\n");
exit(-1);
}
+ } else if (strcmp(*argv, "self") == 0) {
+ flags = BRIDGE_FLAGS_SELF;
} else {
usage();
}
@@ -369,16 +371,16 @@ static int brlink_modify(int argc, char **argv)
addattr_nest_end(&req.n, nest);
- /* IFLA_AF_SPEC nested attribute. Contains IFLA_BRIDGE_FLAGS that
- * designates master or self operation as well as 'vepa' or 'veb'
- * operation modes. These are only valid in 'self' mode on some
- * devices so far. Thus we only need to include the flags attribute
- * if we are setting the hw mode.
+ /* IFLA_AF_SPEC nested attribute. Contains IFLA_BRIDGE_FLAGS that
+ * designates master or self operation and IFLA_BRIDGE_MODE
+ * for hw 'vepa' or 'veb' operation modes. The hwmodes are
+ * only valid in 'self' mode on some devices so far.
*/
- if (mode >= 0) {
+ if (mode >= 0 || flags > 0) {
nest = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
- addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
+ if (flags > 0)
+ addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
if (mode >= 0)
addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
--
1.7.10.4
^ permalink raw reply related
* [PATCH] netfilter: Fix build for NETFILTER_XT_TARGET_REDIRECT
From: Guenter Roeck @ 2014-12-06 9:41 UTC (permalink / raw)
To: netfilter-devel
Cc: coreteam, netdev, Guenter Roeck, Pablo Neira Ayuso,
Arturo Borrero Gonzalez
Fix:
ERROR: "nf_nat_redirect_ipv6" [net/netfilter/xt_REDIRECT.ko] undefined!
Seen if NETFILTER_XT_TARGET_REDIRECT is configured but NF_NAT_IPV6
is not, since code compiled with NF_NAT_REDIRECT_IPV6 is used
unconditionally by code enabled with NETFILTER_XT_TARGET_REDIRECT.
This means that NETFILTER_XT_TARGET_REDIRECT depends on NF_NAT_IPV6
and must always select NF_NAT_REDIRECT_IPV6.
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
Seen in and applies to -next. See various qemu test failures
reported at http://server.roeck-us.net:8010/builders,
net/netfilter/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 57f15a9..2134ef0 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -843,9 +843,9 @@ config NETFILTER_XT_TARGET_RATEEST
config NETFILTER_XT_TARGET_REDIRECT
tristate "REDIRECT target support"
- depends on NF_NAT
+ depends on NF_NAT && NF_NAT_IPV6
select NF_NAT_REDIRECT_IPV4 if NF_NAT_IPV4
- select NF_NAT_REDIRECT_IPV6 if NF_NAT_IPV6
+ select NF_NAT_REDIRECT_IPV6
---help---
REDIRECT is a special case of NAT: all incoming connections are
mapped onto the incoming interface's address, causing the packets to
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature flag for switch device offloads
From: Thomas Graf @ 2014-12-06 10:14 UTC (permalink / raw)
To: Roopa Prabhu
Cc: jiri, sfeldma, jhs, bcrl, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <5482B44F.2050509@cumulusnetworks.com>
On 12/05/14 at 11:46pm, Roopa Prabhu wrote:
> On 12/5/14, 2:43 PM, Thomas Graf wrote:
> >On 12/04/14 at 06:26pm, roopa@cumulusnetworks.com wrote:
> >>From: Roopa Prabhu <roopa@cumulusnetworks.com>
> >>
> >>This is a generic high level feature flag for all switch asic features today.
> >>
> >>switch drivers set this flag on switch ports. Logical devices like
> >>bridge, bonds, vxlans can inherit this flag from their slaves/ports.
> >>
> >>I had to use SWITCH in the name to avoid ambiguity with other feature
> >>flags. But, since i have been harping about not calling it 'switch',
> >>I am welcome to any suggestions :)
> >>
> >>An alternative to using a feature flag is to use a IFF_HW_OFFLOAD
> >>in net_device_flags.
> >What does this flag indicate specifically? What driver would
> >implement ndo_bridge_setlink() but not set this flag?
> >
> >I think it should be clearly documented when this flag is to bet set.
> I mentioned it as an alternative because it was there in my RFC patch. There
> is no code for it yet.
> And I will get rid of the comment in v2.
Sorry, I was referring to NETIF_F_HW_SWITCH_OFFLOAD. I do not
understand the scope of this bit/flag yet. Can you give examples
when to set this bit? At what point would the existing ixgbe FDB
offload set this bit? Is there a case when ndo_bridge_setlink()
is implemented but this bit is not set?
^ permalink raw reply
* Re: [PATCH] iproute2: Add support for CAN presume-ack feature
From: Oliver Hartkopp @ 2014-12-06 10:33 UTC (permalink / raw)
To: Nikita Edward Baruzdin, linux-can, netdev
In-Reply-To: <1417768902-5404-2-git-send-email-nebaruzdin@gmail.com>
On 05.12.2014 09:41, Nikita Edward Baruzdin wrote:
> This patch makes CAN_CTRLMODE_PRESUME_ACK netlink feature configurable.
> When enabled, the feature sets CAN controller in mode in which
> acknowledgement absence is ignored.
>
> Signed-off-by: Nikita Edward Baruzdin <nebaruzdin@gmail.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Hi Nikita,
I just noticed that you only posted to linux-can ML last time - so it didn't
reach the iproute and netdev guys like Stephen Hemminger ...
Thanks for posting it again to the appropriate MLs.
Best regards,
Oliver
> ---
> ip/iplink_can.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/ip/iplink_can.c b/ip/iplink_can.c
> index 5b92426..fb50332 100644
> --- a/ip/iplink_can.c
> +++ b/ip/iplink_can.c
> @@ -37,6 +37,7 @@ static void print_usage(FILE *f)
> "\t[ one-shot { on | off } ]\n"
> "\t[ berr-reporting { on | off } ]\n"
> "\t[ fd { on | off } ]\n"
> + "\t[ presume-ack { on | off } ]\n"
> "\n"
> "\t[ restart-ms TIME-MS ]\n"
> "\t[ restart ]\n"
> @@ -99,6 +100,7 @@ static void print_ctrlmode(FILE *f, __u32 cm)
> _PF(CAN_CTRLMODE_ONE_SHOT, "ONE-SHOT");
> _PF(CAN_CTRLMODE_BERR_REPORTING, "BERR-REPORTING");
> _PF(CAN_CTRLMODE_FD, "FD");
> + _PF(CAN_CTRLMODE_PRESUME_ACK, "PRESUME-ACK");
> #undef _PF
> if (cm)
> fprintf(f, "%x", cm);
> @@ -201,6 +203,10 @@ static int can_parse_opt(struct link_util *lu, int argc, char **argv,
> NEXT_ARG();
> set_ctrlmode("fd", *argv, &cm,
> CAN_CTRLMODE_FD);
> + } else if (matches(*argv, "presume-ack") == 0) {
> + NEXT_ARG();
> + set_ctrlmode("presume-ack", *argv, &cm,
> + CAN_CTRLMODE_PRESUME_ACK);
> } else if (matches(*argv, "restart") == 0) {
> __u32 val = 1;
>
>
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pavel Machek @ 2014-12-06 12:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pali Rohár, Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141127155840.GC24149@kroah.com>
On Thu 2014-11-27 07:58:40, Greg Kroah-Hartman wrote:
> On Thu, Nov 27, 2014 at 04:22:58PM +0100, Pali Rohár wrote:
> > On Thursday 27 November 2014 16:16:55 Greg Kroah-Hartman wrote:
> > > On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> > > > On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> > > > > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> > > >
> > > > <pali.rohar@gmail.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > wifi driver wl1251 needs NVS calibration data for
> > > > > > working. These data are loaded by driver via
> > > > > > request_firmware from userspace file:
> > > > > > ti-connectivity/wl1251-nvs.bin. In linux-fimrware git
> > > > > > tree there is generic wl1251-nvs.bin file which is used
> > > > > > by default.
> > > > > >
> > > > > > Driver wl1251 is used on Nokia N900 cellphone for its
> > > > > > wifi chip. This cellphone has one special MTD partition
> > > > > > (called CAL) where are stored some configuration data
> > > > > > in special binary (key-value) format. And there is also
> > > > > > stored correct calibration data for specific device
> > > > > > (each device has different data). It is preferred to
> > > > > > use those data instead generic one (provided by
> > > > > > linux-firmware git tree).
> > > > > >
> > > > > > Now my question is: How to correctly load calibration
> > > > > > data from special Nokia N900 CAL partition into wl1251
> > > > > > kernel driver?
> > > > >
> > > > > It is better to let user space script handle the request.
> > > >
> > > > Yes, this makes sense. Implementing CAL parser in kernel
> > > > wl1251 driver would be hard...
> > > >
> > > > > > By default kernel reads ti-connectivity/wl1251-nvs.bin
> > > > > > file from VFS if exists without any userspace support.
> > > > > > If it fails then it fallback to loading via udev.
> > > > >
> > > > > You can remove or rename this file so that loading from
> > > > > user space can be triggered.
> > > >
> > > > It is no so easy... In case when CAL does not contains NVS
> > > > data then we want to use this generic NVS file. And telling
> > > > everybody to rename this is file is not good solution...
> > >
> > > But that's up to your system configuration, not the kernel.
> > > Make a userspace package for the firmware that creates it in
> > > the format you need it to be in, for the hardware you have,
> > > and then there would not be any need for a kernel change,
> > > right?
> > >
> > > greg k-h
> >
> > Not so simple as you think. Some parts of NVS data are configured
> > based on location and cellular station. Data are not static.
>
> Then you need a dynamic program that you control, in userspace, to dump
> the needed data into the kernel. Don't try to do it with "static"
> firmware files. Use the binary sysfs file interface for this if you
> want.
Actually, this seems to be similar situation to fpga programming.
There, it is static firmware for 90% users, but some special use cases
want it more dynamic.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-06 13:00 UTC (permalink / raw)
To: Ming Lei
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Greg Kroah-Hartman, Pavel Machek,
Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo, Sebastian Reichel,
David Gnedt
In-Reply-To: <CACVXFVMCJxQRUo94C8peT7G-VFkVeNYCWGKPYE5jq=twCULrpA@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1089 bytes --]
On Thursday 27 November 2014 16:13:51 Ming Lei wrote:
> > Which userspace helper programs for (automatic) firmware
> > loading are used? Can be udev configured to use own program
> > for loading
>
> At default, udev had its builtin firmware helper, but some new
> udev stops to handle firmware request.
>
> If the udev you are using still supports to handle firmware
> request, you can write your load helper and add your rule for
> handling the special case. Otherwise, you need to write code
> to monitor the netlink uevents from the kernel and handle
> your firmware loading request.
>
> Thanks,
> Ming Lei
For Nokia N900 (and Maemo system) we are using older udev version
(0.125), so here should be support for firmware helper.
And if some new udev version will not work, we can just revert
back to older working... No need to use super-uber-fantastic
systemd-udevd software which removing old useful code.
So looks like adding new rule file to udev for handling firmware
requests from kernel could work...
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-06 13:02 UTC (permalink / raw)
To: Pavel Machek, Greg Kroah-Hartman, Ming Lei
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141206124954.GB17289@amd>
[-- Attachment #1: Type: Text/Plain, Size: 6283 bytes --]
On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
> On Thu 2014-11-27 07:58:40, Greg Kroah-Hartman wrote:
> > On Thu, Nov 27, 2014 at 04:22:58PM +0100, Pali Rohár wrote:
> > > On Thursday 27 November 2014 16:16:55 Greg Kroah-Hartman wrote:
> > > > On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> > > > > On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> > > > > > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> > > > >
> > > > > <pali.rohar@gmail.com> wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > wifi driver wl1251 needs NVS calibration data for
> > > > > > > working. These data are loaded by driver via
> > > > > > > request_firmware from userspace file:
> > > > > > > ti-connectivity/wl1251-nvs.bin. In linux-fimrware
> > > > > > > git tree there is generic wl1251-nvs.bin file
> > > > > > > which is used by default.
> > > > > > >
> > > > > > > Driver wl1251 is used on Nokia N900 cellphone for
> > > > > > > its wifi chip. This cellphone has one special MTD
> > > > > > > partition (called CAL) where are stored some
> > > > > > > configuration data in special binary (key-value)
> > > > > > > format. And there is also stored correct
> > > > > > > calibration data for specific device (each device
> > > > > > > has different data). It is preferred to use those
> > > > > > > data instead generic one (provided by
> > > > > > > linux-firmware git tree).
> > > > > > >
> > > > > > > Now my question is: How to correctly load
> > > > > > > calibration data from special Nokia N900 CAL
> > > > > > > partition into wl1251 kernel driver?
> > > > > >
> > > > > > It is better to let user space script handle the
> > > > > > request.
> > > > >
> > > > > Yes, this makes sense. Implementing CAL parser in
> > > > > kernel wl1251 driver would be hard...
> > > > >
> > > > > > > By default kernel reads
> > > > > > > ti-connectivity/wl1251-nvs.bin file from VFS if
> > > > > > > exists without any userspace support. If it fails
> > > > > > > then it fallback to loading via udev.
> > > > > >
> > > > > > You can remove or rename this file so that loading
> > > > > > from user space can be triggered.
> > > > >
> > > > > It is no so easy... In case when CAL does not contains
> > > > > NVS data then we want to use this generic NVS file.
> > > > > And telling everybody to rename this is file is not
> > > > > good solution...
> > > >
> > > > But that's up to your system configuration, not the
> > > > kernel. Make a userspace package for the firmware that
> > > > creates it in the format you need it to be in, for the
> > > > hardware you have, and then there would not be any need
> > > > for a kernel change, right?
> > > >
> > > > greg k-h
> > >
> > > Not so simple as you think. Some parts of NVS data are
> > > configured based on location and cellular station. Data
> > > are not static.
> >
> > Then you need a dynamic program that you control, in
> > userspace, to dump the needed data into the kernel. Don't
> > try to do it with "static" firmware files. Use the binary
> > sysfs file interface for this if you want.
>
> Actually, this seems to be similar situation to fpga
> programming.
>
> There, it is static firmware for 90% users, but some special
> use cases want it more dynamic.
> Pavel
Greg, Ming, what do you think about this approach?
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 3d785eb..810c4b9 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -111,6 +111,11 @@ static inline long firmware_loading_timeout(void)
#define FW_OPT_FALLBACK 0
#endif
#define FW_OPT_NO_WARN (1U << 3)
+#ifdef CONFIG_FW_LOADER_USER_HELPER
+#define FW_OPT_PREFER_USER (1U << 4)
+#else
+#define FW_OPT_PREFER_USER 0
+#endif
struct firmware_cache {
/* firmware_buf instance will be added into the below list */
@@ -1131,7 +1136,20 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
}
}
- ret = fw_get_filesystem_firmware(device, fw->priv);
+ if (opt_flags & FW_OPT_PREFER_USER) {
+ ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout);
+ if (ret) {
+ dev_warn(device,
+ "User helper firmware load for %s failed with error %d\n",
+ name, ret);
+ dev_warn(device, "Falling back to direct firmware load\n");
+ }
+ } else {
+ ret = -EINVAL;
+ }
+
+ if (ret)
+ ret = fw_get_filesystem_firmware(device, fw->priv);
if (ret) {
if (!(opt_flags & FW_OPT_NO_WARN))
dev_warn(device,
@@ -1218,6 +1236,28 @@ int request_firmware_direct(const struct firmware **firmware_p,
EXPORT_SYMBOL_GPL(request_firmware_direct);
/**
+ * request_firmware_prefer_user: - prefer usermode helper for loading firmware
+ * @firmware_p: pointer to firmware image
+ * @name: name of firmware file
+ * @device: device for which firmware is being loaded
+ *
+ * This function works pretty much like request_firmware(), but it prefer
+ * usermode helper. If usermode helper fails then it fallback to direct access.
+ * Usefull for dynamic or model specific firmware data.
+ **/
+int request_firmware_prefer_user(const struct firmware **firmware_p,
+ const char *name, struct device *device)
+{
+ int ret;
+ __module_get(THIS_MODULE);
+ ret = _request_firmware(firmware_p, name, device,
+ FW_OPT_UEVENT | FW_OPT_PREFER_USER);
+ module_put(THIS_MODULE);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
+
+/**
* release_firmware: - release the resource associated with a firmware image
* @fw: firmware resource to release
**/
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index 5c41c5e..d35c511 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -47,6 +47,8 @@ int request_firmware_nowait(
void (*cont)(const struct firmware *fw, void *context));
int request_firmware_direct(const struct firmware **fw, const char *name,
struct device *device);
+int request_firmware_prefer_user(const struct firmware **fw, const char *name,
+ struct device *device);
void release_firmware(const struct firmware *fw);
#else
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* [net-next v2 00/16][pull request] Intel Wired LAN Driver Updates 2014-12-06
From: Jeff Kirsher @ 2014-12-06 13:01 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to i40e and i40evf.
Shannon provides several patches to cleanup and fix i40e. First removes
an unneeded break statement in i40e_vsi_link_event(). Then removes
some debug messages that really do not give any useful information and
ends up getting printed every service_task loop, which fills the logfile
with noise when AQ tracing is enabled. Updates the aq_cmd arguments to
use %i which is much more forgiving and user friendly than the more
restrictive %x, or %d. Fixes the netdev_stat macro, where the old
xxx_NETDEV_STAT() macro was defined long before the newer
rtnl_link_stats64 came into being, and just never got updated.
Getting the pf_id from the function number had an issue when
when the PF was setup in passthru mode, the PCI bus/device/function
was virtualized and the number in the VM is different from the number in
the bare metal. This caused HW configuration issues when the wrong pf_id
was used to set up the HMC and other structures. The PF_FUNC_RID register
has the real bus/device/function information as configured by the BIOS,
so use that for a better number.
Carolyn adds additional text description for the base pf0 and flow
director generated interrupts, since these interrupts are difficult
to distinguish per port on a multi-function device.
Jacob resolves an issue related to images with multiple PFs per
physical port. We cannot fully support 1588 PTP features, since only
one port should control (i.e. write) the registers at a time. Doing
so can cause interference of functionality.
Anjali provides several updates to i40e, first adds the Virtual Channel
OP event opcode for CONFIG_RSS, so that the Virtual Channel state
machine can properly decipher status change events. Then updates the
driver to add (and use) i40e_is_vf macro for future expansion when new
VF MAC types get added. Adds new update VSI flow to accommodate a
firmware dix with VSI loopback mode. All VSIs on a VEB should either
have loopback enabled or disabled, a mixed mode is not supported for a
VEB. Since our driver supports multiple VSIs per PF that need to talk to
each other make sure to enable Loopback for the PF and FDIR VSI as well.
Mitch provides a couple of i40e and i40evf patches. First updates
i40evf init code more adept at handling when multiple VFs attempt
to initialize simultaneously.
Joe Perches provides a i40e patch which resolves a compile warning
about about frame size being larger than 2048 bytes by reducing the
stack use by using kmemdup and not using a very large struct on the
stack.
v2:
- Dropped patch 13 & 14 while Mitch reworks the patches based on
feedback from Ben Hutchings, probably the tryptophan in the turkey
is to blame for the delay...
- Added Joe Perches patch which resolves a compile warning about frame
size
The following are changes since commit 8d0c4697534a739725e429ff062dea393d8860d1:
Merge branch 'ebpf-next'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Anjali Singhai Jain (4):
i40e: Add a virtual channel op to config RSS
i40e: Define and use i40e_is_vf macro
i40e: Add new update VSI flow to accommodate FW fix with VSI Loopback
mode
i40e: Re enable Main VSI loopback setting in the reset path
Carolyn Wyborny (1):
i40e: Add description to misc and fd interrupts
Catherine Sullivan (1):
i40e: Bump i40e version to 1.2.2 and i40evf version to 1.0.6
Jacob Keller (1):
i40e: don't enable PTP support on more than one PF per port
Joe Perches (1):
i40e: Reduce stack in i40e_dbg_dump_desc
Kevin Scott (1):
i40e: Increase reset delay
Mitch Williams (2):
i40evf: make early init sequence even more robust
i40e: increase ARQ size
Shannon Nelson (5):
i40e: Remove unneeded break statement
i40e: remove useless debug noise
i40e: allow various base numbers in debugfs aq commands
i40e: fix netdev_stat macro definition
i40e: get pf_id from HW rather than PCI function
drivers/net/ethernet/intel/i40e/i40e.h | 2 +-
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 5 +---
drivers/net/ethernet/intel/i40e/i40e_common.c | 25 ++++++++--------
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 34 ++++++++++++----------
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 7 ++++-
drivers/net/ethernet/intel/i40e/i40e_main.c | 34 ++++++++++++++++------
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 32 +++++++++++++-------
drivers/net/ethernet/intel/i40e/i40e_type.h | 2 ++
drivers/net/ethernet/intel/i40e/i40e_virtchnl.h | 1 +
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 4 +--
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 1 +
drivers/net/ethernet/intel/i40evf/i40e_adminq.c | 5 +---
drivers/net/ethernet/intel/i40evf/i40e_type.h | 2 ++
drivers/net/ethernet/intel/i40evf/i40e_virtchnl.h | 1 +
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++++--
.../net/ethernet/intel/i40evf/i40evf_virtchnl.c | 16 ++++------
16 files changed, 107 insertions(+), 75 deletions(-)
--
1.9.3
^ permalink raw reply
* [net-next v2 02/16] i40e: remove useless debug noise
From: Jeff Kirsher @ 2014-12-06 13:01 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1417870933-17248-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
This message really doesn't give any useful information and ends up
getting printed every service_task loop in the Linux driver, filling the
logfile with noise when AQ tracing is enabled. This patch simply removes
the noise.
Change-ID: I30ad51e6b03c7ad12a7d9c102def0087db622df3
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Acked-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 3 ---
drivers/net/ethernet/intel/i40evf/i40e_adminq.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.c b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
index 5bb4914..5dc12c4 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
@@ -956,9 +956,6 @@ i40e_status i40e_clean_arq_element(struct i40e_hw *hw,
ntu = (rd32(hw, hw->aq.arq.head) & I40E_PF_ARQH_ARQH_MASK);
if (ntu == ntc) {
/* nothing to do - shouldn't need to update ring's values */
- i40e_debug(hw,
- I40E_DEBUG_AQ_MESSAGE,
- "AQRX: Queue is empty.\n");
ret_code = I40E_ERR_ADMIN_QUEUE_NO_WORK;
goto clean_arq_element_out;
}
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_adminq.c b/drivers/net/ethernet/intel/i40evf/i40e_adminq.c
index d7e446f..ff6305a 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_adminq.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_adminq.c
@@ -905,9 +905,6 @@ i40e_status i40evf_clean_arq_element(struct i40e_hw *hw,
ntu = (rd32(hw, hw->aq.arq.head) & I40E_PF_ARQH_ARQH_MASK);
if (ntu == ntc) {
/* nothing to do - shouldn't need to update ring's values */
- i40e_debug(hw,
- I40E_DEBUG_AQ_MESSAGE,
- "AQRX: Queue is empty.\n");
ret_code = I40E_ERR_ADMIN_QUEUE_NO_WORK;
goto clean_arq_element_out;
}
--
1.9.3
^ permalink raw reply related
* [net-next v2 01/16] i40e: Remove unneeded break statement
From: Jeff Kirsher @ 2014-12-06 13:01 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1417870933-17248-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
This case statement is empty and the fall through just breaks out
so remove the break and let it fall through to break out.
Change-ID: I1b5ba9870d5245ca80bfca6e7f5f089e2eb8ccb0
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 9ae4270..74f378d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -5450,8 +5450,6 @@ static void i40e_vsi_link_event(struct i40e_vsi *vsi, bool link_up)
break;
case I40E_VSI_SRIOV:
- break;
-
case I40E_VSI_VMDQ2:
case I40E_VSI_CTRL:
case I40E_VSI_MIRROR:
--
1.9.3
^ permalink raw reply related
* [net-next v2 03/16] i40e: allow various base numbers in debugfs aq commands
From: Jeff Kirsher @ 2014-12-06 13:02 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1417870933-17248-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
Use the 'i' rather than the more restrictive 'x' or 'd' in the aq_cmd
arguments. This makes the user interface much more forgiving and user
friendly.
Change-ID: I5dcd57b9befc047e06b74cf1152a25a3fa9e1309
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index 3a3c237..16ac3f8 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -1493,7 +1493,7 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
if (!desc)
goto command_write_done;
cnt = sscanf(&cmd_buf[11],
- "%hx %hx %hx %hx %x %x %x %x %x %x",
+ "%hi %hi %hi %hi %i %i %i %i %i %i",
&desc->flags,
&desc->opcode, &desc->datalen, &desc->retval,
&desc->cookie_high, &desc->cookie_low,
@@ -1541,7 +1541,7 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
if (!desc)
goto command_write_done;
cnt = sscanf(&cmd_buf[20],
- "%hx %hx %hx %hx %x %x %x %x %x %x %hd",
+ "%hi %hi %hi %hi %i %i %i %i %i %i %hi",
&desc->flags,
&desc->opcode, &desc->datalen, &desc->retval,
&desc->cookie_high, &desc->cookie_low,
--
1.9.3
^ permalink raw reply related
* [net-next v2 04/16] i40e: Add description to misc and fd interrupts
From: Jeff Kirsher @ 2014-12-06 13:02 UTC (permalink / raw)
To: davem; +Cc: Carolyn Wyborny, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1417870933-17248-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Carolyn Wyborny <carolyn.wyborny@intel.com>
This patch adds additional text description for base pf0 and flow director
generated interrupts. Without this patch, these interrupts are difficult
to distinguish per port on a multi-function device.
Change-ID: I4662e1b38840757765a3fe63d90219d28e76bfab
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 74f378d..2f4be25 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -4870,9 +4870,11 @@ int i40e_vsi_open(struct i40e_vsi *vsi)
goto err_set_queues;
} else if (vsi->type == I40E_VSI_FDIR) {
- snprintf(int_name, sizeof(int_name) - 1, "%s-fdir",
- dev_driver_string(&pf->pdev->dev));
+ snprintf(int_name, sizeof(int_name) - 1, "%s-%s-fdir",
+ dev_driver_string(&pf->pdev->dev),
+ dev_name(&pf->pdev->dev));
err = i40e_vsi_request_irq(vsi, int_name);
+
} else {
err = -EINVAL;
goto err_setup_rx;
@@ -9141,9 +9143,10 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
hw->aq.arq_buf_size = I40E_MAX_AQ_BUF_SIZE;
hw->aq.asq_buf_size = I40E_MAX_AQ_BUF_SIZE;
pf->adminq_work_limit = I40E_AQ_WORK_LIMIT;
+
snprintf(pf->misc_int_name, sizeof(pf->misc_int_name) - 1,
- "%s-pf%d:misc",
- dev_driver_string(&pf->pdev->dev), pf->hw.pf_id);
+ "%s-%s:misc",
+ dev_driver_string(&pf->pdev->dev), dev_name(&pdev->dev));
err = i40e_init_shared_code(hw);
if (err) {
--
1.9.3
^ permalink raw reply related
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