Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH][V2] batman-adv: fix various spelling mistakes
From: Sven Eckelmann @ 2017-07-29  8:03 UTC (permalink / raw)
  To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
  Cc: Marek Lindner, netdev-u79uwXL29TY76Z2rM5mHXA, Antonio Quartulli,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Colin King, David S . Miller
In-Reply-To: <20170626102644.11337-1-colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Montag, 26. Juni 2017 11:26:44 CEST Colin King wrote:
> From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> 
> Trivial fix to spelling mistakes in batadv_dbg debug messages and
> also in a comment and ensure comment line is not wider than 80
> characters
> 
> "ourselve" -> "ourselves"
> "surpressed" -> "suppressed"
> "troughput" -> "throughput"
> 
> Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>


Applied as f25cbb2a6ac1ce702d8c39222bc13c24a69bb5ef [1]

Thanks,
	Sven

[1] https://git.open-mesh.org/linux-merge.git/commit/f25cbb2a6ac1ce702d8c39222bc13c24a69bb5ef

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply

* Re: [PATCH net-next v11 3/4] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jiri Pirko @ 2017-07-29  7:19 UTC (permalink / raw)
  To: Jamal Hadi Salim
  Cc: davem, netdev, xiyou.wangcong, dsahern, eric.dumazet, mrv,
	simon.horman, alex.aring
In-Reply-To: <12475aaa-eba1-1c9a-0eec-17c908a627f1@mojatatu.com>

Sat, Jul 29, 2017 at 12:10:20AM CEST, jhs@mojatatu.com wrote:
>On 17-07-28 11:45 AM, Jiri Pirko wrote:
>> Fri, Jul 28, 2017 at 05:08:10PM CEST, jhs@mojatatu.com wrote:
>> > On 17-07-28 10:52 AM, Jamal Hadi Salim wrote:
>> > > On 17-07-28 10:12 AM, Jiri Pirko wrote:
>
>
>> >         /*disallow invalid selector */
>> >         if ((bf->selector & *valid_flags_allowed) > *valid_flags_allowed)
>> 
>> I don't get the ">"....
>> Just (bf->selector & ~*valid_flags_allowed) should be enought, no?
>> 
>
>It may be enough - I will try it out tommorow.
>I was worried about the selector having more bits than the allowed flags.

That is what the code I wrote above do. And I think that your code does
not (if you don't assume that allowed flags are always starting from the
least significant bit)

>
>cheers,
>jamal

^ permalink raw reply

* Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode
From: Corentin Labbe @ 2017-07-29  6:48 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Andrew Lunn, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	mark.rutland-5wv7dgnIgG8,
	maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
	linux-I+IVW8TIWO2tmTQ+vhA3Yw, peppe.cavallaro-qxv4g6HH51o,
	alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	icenowy-h8G6r0blFSE
In-Reply-To: <f8fe754c-8b46-a9f6-4020-f7db6c985773-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Fri, Jul 28, 2017 at 10:54:30AM -0700, Florian Fainelli wrote:
> On 07/28/2017 07:44 AM, Corentin Labbe wrote:
> > On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
> >>>> I've probably asked this before: Does the internal PHY use a different
> >>>> PHY ID in registers 2 and 3?
> >>>>
> >>>
> >>> yes
> >>>
> >>> reg2: 0x0044
> >>> reg3: 0X1500
> > 
> > Copy/paste error, its 1400
> > 
> >>
> >> So this is not about loading the correct PHY driver. You can already
> >> do this based on the PHY IDs...
> >>
> >> This is about selecting which PHY to use. Internal or External?	
> >>
> >>      Andrew
> > 
> > It is too late when we know the PHY ID.
> 
> > We need to set a syscon for choosing external/internal PHY.
> > So we can rely only on DT.
> 
> Since the Device Tree needs to be correct to identify which PHY to use
> (internal or external), if you use the standard compatible string for
> the PHY that contains its OUI, e.g:
> 
> compatible = "ethernet-phy-id0044.1400", "ethernet-phy-ieee802.3-c22"
> 
> then you can have your Ethernet MAC identify whether this is an internal
> PHY by having a list of compatible strings to match against.

So basicly, I replace sun8i-h3-ephy by ethernet-phy-id0044.1400 and it is good ?

> 
> Corentin, can you make sure you copy netdev, Andrew and myself on the
> next submissions so we don't have to keep track of seemingly identical
> threads (this one + the rockchip dwmac changes) and we can work towards
> one solution?

Ok

Thanks
Corentin Labbe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: STABLE: net: reduce skb_warn_bad_offload() noise
From: Willy Tarreau @ 2017-07-29  6:46 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, salyzyn, stable, netdev
In-Reply-To: <1501305772.1876.0.camel@edumazet-glaptop3.roam.corp.google.com>

On Fri, Jul 28, 2017 at 10:22:52PM -0700, Eric Dumazet wrote:
> On Fri, 2017-07-28 at 12:30 -0700, David Miller wrote:
> > From: Mark Salyzyn <salyzyn@android.com>
> > Date: Fri, 28 Jul 2017 10:29:57 -0700
> > 
> > > Please backport the upstream patch to the stable trees (including
> > > 3.10.y, 3.18.y, 4.4.y and 4.9.y):
> > > 
> > > b2504a5dbef3305ef41988ad270b0e8ec289331c net: reduce
> > > skb_warn_bad_offload() noise
> > > 
> > > Impacting performance or creating unnecessary alarm, and will result
> > > in kernel panic for panic_on_warn configuration.
> > 
> > Yeah this is fine.
> 
> If you do so, also backport 6e7bc478c9a006c701c14476ec9d389a484b4864
> ("net: skb_needs_check() accepts CHECKSUM_NONE for tx")
 
OK, noted for next 3.10 as well.

thanks!
Willy

^ permalink raw reply

* [PATCH 2/2] netfilter: ipt_CLUSTERIP: constify nf_hook_ops structures
From: Julia Lawall @ 2017-07-29  6:40 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: bhumirks, kernel-janitors, Jozsef Kadlecsik, Florian Westphal,
	David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
	netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <1501310455-7896-1-git-send-email-Julia.Lawall@lip6.fr>

The nf_hook_ops structure is only passed as the second argument to
nf_register_net_hook or nf_unregister_net_hook, both of which are
declared as const.  Thus the nf_hook_ops structure itself can be
const.

Done with the help of Coccinelle.

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct nf_hook_ops i@p = { ... };

@ok1@
identifier r.i;
expression e;
position p;
@@
 \(nf_register_net_hook\|nf_unregister_net_hook\)(e,&i@p)

@bad@
position p != {r.p,ok1.p};
identifier r.i;
struct nf_hook_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct nf_hook_ops i = { ... };
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>

---
 net/ipv4/netfilter/ipt_CLUSTERIP.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index efaa04d..17b4ca5 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -625,7 +625,7 @@ static void arp_print(struct arp_payload *payload)
 	return NF_ACCEPT;
 }
 
-static struct nf_hook_ops cip_arp_ops __read_mostly = {
+static const struct nf_hook_ops cip_arp_ops = {
 	.hook = arp_mangle,
 	.pf = NFPROTO_ARP,
 	.hooknum = NF_ARP_OUT,

^ permalink raw reply related

* [PATCH 1/2] decnet: dn_rtmsg: constify nf_hook_ops structures
From: Julia Lawall @ 2017-07-29  6:40 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: bhumirks, kernel-janitors, Jozsef Kadlecsik, Florian Westphal,
	David S. Miller, netfilter-devel, coreteam, linux-decnet-user,
	netdev, linux-kernel
In-Reply-To: <1501310455-7896-1-git-send-email-Julia.Lawall@lip6.fr>

The nf_hook_ops structure is only passed as the second argument to
nf_register_net_hook or nf_unregister_net_hook, both of which are
declared as const.  Thus the nf_hook_ops structure itself can be
const.

Done with the help of Coccinelle.

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct nf_hook_ops i@p = { ... };

@ok1@
identifier r.i;
expression e;
position p;
@@
 \(nf_register_net_hook\|nf_unregister_net_hook\)(e,&i@p)

@bad@
position p != {r.p,ok1.p};
identifier r.i;
struct nf_hook_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct nf_hook_ops i = { ... };
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>

---
 net/decnet/netfilter/dn_rtmsg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/decnet/netfilter/dn_rtmsg.c b/net/decnet/netfilter/dn_rtmsg.c
index aa8ffec..ab395e5 100644
--- a/net/decnet/netfilter/dn_rtmsg.c
+++ b/net/decnet/netfilter/dn_rtmsg.c
@@ -115,7 +115,7 @@ static inline void dnrmg_receive_user_skb(struct sk_buff *skb)
 	RCV_SKB_FAIL(-EINVAL);
 }
 
-static struct nf_hook_ops dnrmg_ops __read_mostly = {
+static const struct nf_hook_ops dnrmg_ops = {
 	.hook		= dnrmg_hook,
 	.pf		= NFPROTO_DECNET,
 	.hooknum	= NF_DN_ROUTE,

^ permalink raw reply related

* [PATCH 0/2] constify nf_hook_ops structures
From: Julia Lawall @ 2017-07-29  6:40 UTC (permalink / raw)
  To: linux-decnet-user
  Cc: bhumirks, kernel-janitors, Pablo Neira Ayuso, Jozsef Kadlecsik,
	Florian Westphal, David S. Miller, netfilter-devel, coreteam,
	netdev, linux-kernel

The nf_hook_ops structure is only passed as the second argument to
nf_register_net_hook or nf_unregister_net_hook, both of which are
declared as const.  Thus the nf_hook_ops structure itself can be
const.

Done with the help of Coccinelle.

---

 net/decnet/netfilter/dn_rtmsg.c    |    2 +-
 net/ipv4/netfilter/ipt_CLUSTERIP.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

^ permalink raw reply

* Re: [PATCH net-next v2 0/3] ethtool: support for forward error correction mode setting on a link
From: Roopa Prabhu @ 2017-07-29  6:29 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Jakub Kicinski, davem@davemloft.net, John W. Linville,
	netdev@vger.kernel.org, Vidya Sagar Ravipati, Dustin Byford,
	Dave Olson, Casey Leedom, Gal Pressman, Manoj Malviya,
	Santosh Rastapur, yuval.mintz, odedw, Ariel Almog, Jeff Kirsher
In-Reply-To: <20170728172957.GK2132@lunn.ch>

On Fri, Jul 28, 2017 at 10:29 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Fri, Jul 28, 2017 at 09:46:20AM -0700, Jakub Kicinski wrote:
>> On Fri, 28 Jul 2017 07:53:01 -0700, Roopa Prabhu wrote:
>> > On Thu, Jul 27, 2017 at 7:33 PM, Jakub Kicinski <kubakici@wp.pl> wrote:
>> > > On Thu, 27 Jul 2017 16:47:25 -0700, Roopa Prabhu wrote:
>> > >> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>> > >>
>> > >> Forward Error Correction (FEC) modes i.e Base-R
>> > >> and Reed-Solomon modes are introduced in 25G/40G/100G standards
>> > >> for providing good BER at high speeds. Various networking devices
>> > >> which support 25G/40G/100G provides ability to manage supported FEC
>> > >> modes and the lack of FEC encoding control and reporting today is a
>> > >> source for interoperability issues for many vendors.
>> > >> FEC capability as well as specific FEC mode i.e. Base-R
>> > >> or RS modes can be requested or advertised through bits D44:47 of base link
>> > >> codeword.
>> > >>
>> > >> This patch set intends to provide option under ethtool to manage and
>> > >> report FEC encoding settings for networking devices as per IEEE 802.3
>> > >> bj, bm and by specs.
>> > >>
>> > >> v2 :
>> > >>         - minor patch format fixes and typos pointed out by Andrew
>> > >>         - there was a pending discussion on the use of 'auto' vs
>> > >>           'automatic' for fec settings. I have left it as 'auto'
>> > >>           because in most cases today auto is used in place of
>> > >>           automatic to represent automatically generated values.
>> > >>           We use it in other networking config too. I would prefer
>> > >>           leaving it as auto.
>> > >
>> > > On the subject of resetting the values when module is replugged I
>> > > assume what was previously described remains:
>> > >  - we always allow users to set the FEC regardless of the module type;
>> > >  - if user set an incorrect FEC for the module type (or module gets
>> > >    swapped) the link will be administratively taken down by either
>> > >    the driver or FW.
>> > >
>> > > Is that correct?  Am I misremembering?
>> >
>> > yes, correct. And possible future sfp hotplug events can give user-space
>> > more info to react to module type changes etc.
>>
>> OK, if nobody else objects and we go with that - lets make sure we
>> document clearly those are expected :)  My concern is that if there is
>> ever 10G + RS FEC standard we don't want to end up in a situation where
>> some drivers silently ignore FEC settings in 10G and other apply it.
>> So let's make it clear what the intended Linux behaviour is.  It could
>> be in the ethtool man page, or the kernel somewhere.
>
> You might also find this interesting:
>
> https://py3.patchwork.dja.id.au/patch/42846/
>
> Most of the rest of the series has been reviewed, so i don't think it
> will be too long before it is in the kernel.
>

yes, we are excited about this work as well..

^ permalink raw reply

* Re: [PATCH net-next v2 0/3] ethtool: support for forward error correction mode setting on a link
From: Roopa Prabhu @ 2017-07-29  6:28 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: davem@davemloft.net, John W. Linville, netdev@vger.kernel.org,
	Vidya Sagar Ravipati, Dustin Byford, Dave Olson, Casey Leedom,
	Gal Pressman, Andrew Lunn, Manoj Malviya, Santosh Rastapur,
	yuval.mintz, odedw, Ariel Almog, Jeff Kirsher
In-Reply-To: <20170728094620.525ba156@cakuba.netronome.com>

On Fri, Jul 28, 2017 at 9:46 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> On Fri, 28 Jul 2017 07:53:01 -0700, Roopa Prabhu wrote:
>> On Thu, Jul 27, 2017 at 7:33 PM, Jakub Kicinski <kubakici@wp.pl> wrote:
>> > On Thu, 27 Jul 2017 16:47:25 -0700, Roopa Prabhu wrote:
>> >> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>> >>
>> >> Forward Error Correction (FEC) modes i.e Base-R
>> >> and Reed-Solomon modes are introduced in 25G/40G/100G standards
>> >> for providing good BER at high speeds. Various networking devices
>> >> which support 25G/40G/100G provides ability to manage supported FEC
>> >> modes and the lack of FEC encoding control and reporting today is a
>> >> source for interoperability issues for many vendors.
>> >> FEC capability as well as specific FEC mode i.e. Base-R
>> >> or RS modes can be requested or advertised through bits D44:47 of base link
>> >> codeword.
>> >>
>> >> This patch set intends to provide option under ethtool to manage and
>> >> report FEC encoding settings for networking devices as per IEEE 802.3
>> >> bj, bm and by specs.
>> >>
>> >> v2 :
>> >>         - minor patch format fixes and typos pointed out by Andrew
>> >>         - there was a pending discussion on the use of 'auto' vs
>> >>           'automatic' for fec settings. I have left it as 'auto'
>> >>           because in most cases today auto is used in place of
>> >>           automatic to represent automatically generated values.
>> >>           We use it in other networking config too. I would prefer
>> >>           leaving it as auto.
>> >
>> > On the subject of resetting the values when module is replugged I
>> > assume what was previously described remains:
>> >  - we always allow users to set the FEC regardless of the module type;
>> >  - if user set an incorrect FEC for the module type (or module gets
>> >    swapped) the link will be administratively taken down by either
>> >    the driver or FW.
>> >
>> > Is that correct?  Am I misremembering?
>>
>> yes, correct. And possible future sfp hotplug events can give user-space
>> more info to react to module type changes etc.
>
> OK, if nobody else objects and we go with that - lets make sure we
> document clearly those are expected :)  My concern is that if there is
> ever 10G + RS FEC standard we don't want to end up in a situation where
> some drivers silently ignore FEC settings in 10G and other apply it.
> So let's make it clear what the intended Linux behaviour is.  It could
> be in the ethtool man page, or the kernel somewhere.

sure :), ack. We will document it in the ethtool manpage.

^ permalink raw reply

* [PATCH V2 net-next 2/2] liquidio: Add support to create management interface
From: Felix Manlunas @ 2017-07-29  6:18 UTC (permalink / raw)
  To: davem
  Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
	veerasenareddy.burru
In-Reply-To: <20170729061707.GA1134@felix-thinkpad.cavium.com>

From: Veerasenareddy Burru <veerasenareddy.burru@cavium.com>

This patch adds support to create a virtual ethernet interface to
communicate with Linux on LiquidIO adapter for management.

Signed-off-by: Veerasenareddy Burru <veerasenareddy.burru@cavium.com>
Signed-off-by: Srinivasa Jampala <srinivasa.jampala@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
---
 drivers/net/ethernet/cavium/liquidio/Makefile      |   1 +
 drivers/net/ethernet/cavium/liquidio/lio_main.c    |   6 +
 .../net/ethernet/cavium/liquidio/liquidio_common.h |   4 +
 .../net/ethernet/cavium/liquidio/liquidio_mgmt.c   | 351 +++++++++++++++++++++
 .../net/ethernet/cavium/liquidio/octeon_device.h   |   2 +
 drivers/net/ethernet/cavium/liquidio/octeon_main.h |   8 +
 6 files changed, 372 insertions(+)
 create mode 100644 drivers/net/ethernet/cavium/liquidio/liquidio_mgmt.c

diff --git a/drivers/net/ethernet/cavium/liquidio/Makefile b/drivers/net/ethernet/cavium/liquidio/Makefile
index c4d411d..2064157 100644
--- a/drivers/net/ethernet/cavium/liquidio/Makefile
+++ b/drivers/net/ethernet/cavium/liquidio/Makefile
@@ -15,6 +15,7 @@ liquidio-$(CONFIG_LIQUIDIO) += lio_ethtool.o \
 			octeon_mailbox.o   \
 			octeon_mem_ops.o   \
 			octeon_droq.o      \
+			liquidio_mgmt.o      \
 			octeon_nic.o
 
 liquidio-objs := lio_main.o octeon_console.o $(liquidio-y)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 6f49513..44c65ca 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -1776,6 +1776,9 @@ static void liquidio_remove(struct pci_dev *pdev)
 
 	dev_dbg(&oct_dev->pci_dev->dev, "Stopping device\n");
 
+	if (oct_dev->fw_info.app_cap_flags & LIQUIDIO_MGMT_INTF_CAP)
+		lio_mgmt_exit(oct_dev);
+
 	if (oct_dev->watchdog_task)
 		kthread_stop(oct_dev->watchdog_task);
 
@@ -4408,6 +4411,9 @@ static int liquidio_init_nic_module(struct octeon_device *oct)
 		goto octnet_init_failure;
 	}
 
+	if (oct->fw_info.app_cap_flags & LIQUIDIO_MGMT_INTF_CAP)
+		lio_mgmt_init(oct);
+
 	liquidio_ptp_init(oct);
 
 	dev_dbg(&oct->pci_dev->dev, "Network interfaces ready\n");
diff --git a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
index 2ce2ebb..7162fb8 100644
--- a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
+++ b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
@@ -63,6 +63,8 @@ enum octeon_tag_type {
  */
 #define OPCODE_CORE 0           /* used for generic core operations */
 #define OPCODE_NIC  1           /* used for NIC operations */
+#define OPCODE_MGMT 2           /* used for MGMT operations */
+
 /* Subcodes are used by host driver/apps to identify the sub-operation
  * for the core. They only need to by unique for a given subsystem.
  */
@@ -106,6 +108,8 @@ enum octeon_tag_type {
 #define MAX_IOQ_INTERRUPTS_PER_PF   (64 * 2)
 #define MAX_IOQ_INTERRUPTS_PER_VF   (8 * 2)
 
+/* App specific capabilities from firmware to pf driver */
+#define LIQUIDIO_MGMT_INTF_CAP 0x1
 
 static inline u32 incr_index(u32 index, u32 count, u32 max)
 {
diff --git a/drivers/net/ethernet/cavium/liquidio/liquidio_mgmt.c b/drivers/net/ethernet/cavium/liquidio/liquidio_mgmt.c
new file mode 100644
index 0000000..8680d8b
--- /dev/null
+++ b/drivers/net/ethernet/cavium/liquidio/liquidio_mgmt.c
@@ -0,0 +1,351 @@
+/**********************************************************************
+ * Author: Cavium, Inc.
+ *
+ * Contact: support@cavium.com
+ *          Please include "LiquidIO" in the subject.
+ *
+ * Copyright (c) 2003-2017 Cavium, Inc.
+ *
+ * This file is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, Version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful, but
+ * AS-IS and WITHOUT ANY WARRANTY; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, TITLE, or
+ * NONINFRINGEMENT.  See the GNU General Public License for more details.
+ ***********************************************************************/
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/crc32.h>
+#include <linux/dma-mapping.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+#include <linux/ip.h>
+#include <net/ip.h>
+#include <linux/ipv6.h>
+#include <linux/net_tstamp.h>
+#include <linux/if_vlan.h>
+#include <linux/firmware.h>
+#include <linux/ethtool.h>
+#include <linux/types.h>
+#include <linux/list.h>
+#include <linux/workqueue.h>
+#include <linux/interrupt.h>
+#include "octeon_config.h"
+#include "liquidio_common.h"
+#include "octeon_droq.h"
+#include "octeon_iq.h"
+#include "response_manager.h"
+#include "octeon_device.h"
+#include "octeon_nic.h"
+#include "octeon_main.h"
+#include "octeon_network.h"
+
+#define OPCODE_MGMT_PKT_DATA   0x10
+
+struct lio_mgmt {
+	atomic_t ifstate;
+	struct net_device *parent_netdev;
+	struct octeon_device *oct_dev;
+	struct net_device *netdev;
+	u64 dev_capability;
+	struct oct_link_info linfo;
+	u32 intf_open;
+};
+
+struct lio_mgmt_rx_pkt {
+	struct list_head list;
+	struct sk_buff *skb;
+};
+
+#define LIO_MGMT_SIZE (sizeof(struct lio_mgmt))
+#define GET_LIO_MGMT(netdev)  ((struct lio_mgmt *)netdev_priv(netdev))
+
+static int lio_mgmt_open(struct net_device *netdev)
+{
+	struct lio_mgmt *lio_mgmt = GET_LIO_MGMT(netdev);
+
+	ifstate_set((struct lio *)lio_mgmt, LIO_IFSTATE_RUNNING);
+	netif_carrier_on(netdev);
+
+	netif_start_queue(netdev);
+
+	/* Ready for link status updates */
+	lio_mgmt->intf_open = 1;
+
+	return 0;
+}
+
+/**
+ * \brief Net device stop for LiquidIO
+ * @param netdev network device
+ */
+static int lio_mgmt_stop(struct net_device *netdev)
+{
+	struct lio_mgmt *lio_mgmt = GET_LIO_MGMT(netdev);
+
+	ifstate_reset((struct lio *)lio_mgmt, LIO_IFSTATE_RUNNING);
+
+	netif_tx_disable(netdev);
+
+	/* Inform that netif carrier is down */
+	netif_carrier_off(netdev);
+	lio_mgmt->intf_open = 0;
+
+	return 0;
+}
+
+/**
+ * \brief callback for octeon soft command completions
+ * @oct     octeon device on which the command was executed
+ * @status  command completion status
+ * @buf     soft command buffer
+ */
+static void packet_sent_callback(struct octeon_device *oct,
+				 u32 status __attribute__((unused)), void *buf)
+{
+	struct octeon_soft_command *sc = (struct octeon_soft_command *)buf;
+	struct sk_buff *skb = sc->ctxptr;
+
+	dma_unmap_single(&oct->pci_dev->dev, sc->dmadptr,
+			 sc->datasize, DMA_TO_DEVICE);
+	dev_kfree_skb_any(skb);
+	kfree(sc);
+}
+
+/** \brief Transmit networks packets to the Octeon interface
+ * @param skbuff   skbuff struct to be passed to network layer.
+ * @param netdev    pointer to network device
+ * @returns whether the packet was transmitted to the device okay or not
+ *             (NETDEV_TX_OK or NETDEV_TX_BUSY)
+ */
+static int lio_mgmt_xmit(struct sk_buff *skb, struct net_device *netdev)
+{
+	struct octeon_soft_command *sc = NULL;
+	struct octeon_instr_pki_ih3 *pki_ih3;
+	struct lio_mgmt *lio_mgmt;
+	struct lio *parent_lio;
+	int status;
+
+	lio_mgmt = GET_LIO_MGMT(netdev);
+	parent_lio = GET_LIO(lio_mgmt->parent_netdev);
+
+	if (eth_skb_pad(skb))
+		return NETDEV_TX_OK;
+
+	/* Check for all conditions in which the current packet cannot be
+	 * transmitted.
+	 */
+	if (!(atomic_read(&lio_mgmt->ifstate) & LIO_IFSTATE_RUNNING) ||
+	    (skb->len > OCTNET_DEFAULT_FRM_SIZE)) {
+		goto lio_xmit_failed;
+	}
+
+	if (octnet_iq_is_full(lio_mgmt->oct_dev, parent_lio->txq)) {
+		/* defer sending if queue is full */
+		return NETDEV_TX_BUSY;
+	}
+
+	if (!skb_shinfo(skb)->nr_frags) {
+		sc = kzalloc(sizeof(*sc), GFP_ATOMIC);
+		if (!sc)
+			goto lio_xmit_failed;
+
+		sc->dmadptr = dma_map_single(&lio_mgmt->oct_dev->pci_dev->dev,
+					     skb->data,
+					     skb->len, DMA_TO_DEVICE);
+		if (dma_mapping_error
+		    (&lio_mgmt->oct_dev->pci_dev->dev, sc->dmadptr)) {
+			kfree(sc);
+			return NETDEV_TX_BUSY;
+		}
+		sc->virtdptr = skb->data;
+		sc->datasize = skb->len;
+		sc->ctxptr = skb;	/* to be freed in sent callback */
+		sc->dmarptr = 0;
+		sc->rdatasize = 0;
+		sc->iq_no = parent_lio->txq;	/* default input queue */
+		octeon_prepare_soft_command(lio_mgmt->oct_dev, sc, OPCODE_MGMT,
+					    OPCODE_MGMT_PKT_DATA, 0, 0,
+					    0);
+
+		/*prepare softcommand uses ATOMIC TAG, change it to ORDERED */
+		pki_ih3 = (struct octeon_instr_pki_ih3 *)&sc->cmd.cmd3.pki_ih3;
+		pki_ih3->tag = LIO_DATA((lio_mgmt->oct_dev->instr_queue
+					[sc->iq_no]->txpciq.s.port));
+		pki_ih3->tagtype = ORDERED_TAG;
+
+		sc->callback = packet_sent_callback;
+		sc->callback_arg = sc;
+		status = octeon_send_soft_command(lio_mgmt->oct_dev, sc);
+		if (status == IQ_SEND_FAILED) {
+			dma_unmap_single(&lio_mgmt->oct_dev->pci_dev->dev,
+					 sc->dmadptr, sc->datasize,
+					 DMA_TO_DEVICE);
+			kfree(sc);
+			goto lio_xmit_failed;
+		}
+
+		if (status == IQ_SEND_STOP)
+			netif_stop_queue(netdev);
+	} else {
+		goto lio_xmit_failed;
+	}
+
+	netdev->stats.tx_packets++;
+	netdev->stats.tx_bytes += skb->len;
+
+	return NETDEV_TX_OK;
+
+lio_xmit_failed:
+	netdev->stats.tx_dropped++;
+	dev_kfree_skb_any(skb);
+	return NETDEV_TX_OK;
+}
+
+static int lio_mgmt_rx(struct octeon_recv_info *recv_info, void *arg)
+{
+	struct octeon_device *octdev = (struct octeon_device *)arg;
+	struct octeon_recv_pkt *recv_pkt = recv_info->recv_pkt;
+	struct lio_mgmt *lio_mgmt;
+	struct net_device *netdev;
+	unsigned int pkt_size = 0;
+	unsigned char *pkt_ptr;
+	struct sk_buff *skb;
+	int i;
+
+	netdev = (struct net_device *)octdev->mgmt_ctx;
+	lio_mgmt = GET_LIO_MGMT(netdev);
+	/* Do not proceed if the interface is not in RUNNING state. */
+	if (!ifstate_check((struct lio *)lio_mgmt, LIO_IFSTATE_RUNNING))
+		goto fail;
+
+	/* Not handling more than one buffer */
+	if (recv_pkt->buffer_count > 1)
+		goto fail;
+
+	pkt_size = recv_pkt->buffer_size[0] - OCT_DROQ_INFO_SIZE;
+	pkt_ptr = get_rbd(recv_pkt->buffer_ptr[0]) + OCT_DROQ_INFO_SIZE;
+
+	skb = netdev_alloc_skb_ip_align(netdev, pkt_size);
+	if (!skb)
+		goto fail;
+
+	skb_copy_to_linear_data(skb, pkt_ptr, pkt_size);
+
+	skb_put(skb, pkt_size);
+	netdev->stats.rx_packets++;
+	netdev->stats.rx_bytes += skb->len;
+
+	skb->dev = netdev;
+	skb->protocol = eth_type_trans(skb, skb->dev);
+	netif_receive_skb(skb);
+
+fail:
+	for (i = 0; i < recv_pkt->buffer_count; i++)
+		recv_buffer_free(recv_pkt->buffer_ptr[i]);
+
+	octeon_free_recv_info(recv_info);
+
+	return 0;
+}
+
+const struct net_device_ops liocomdevops = {
+	.ndo_open = lio_mgmt_open,
+	.ndo_stop = lio_mgmt_stop,
+	.ndo_start_xmit = lio_mgmt_xmit,
+};
+
+/* Initializes the LiquidIO management interface module
+ * @param octdev - octeon device pointer
+ * @returns 0 if init is success, -1 otherwise
+ */
+int lio_mgmt_init(struct octeon_device *octdev)
+{
+	struct lio_mgmt *lio_mgmt = NULL;
+	struct net_device *netdev;
+	struct lio *parent_lio;
+
+	/* Register netdev only for pf 0 */
+	if (octdev->pf_num == 0) {
+		netdev = alloc_etherdev(LIO_MGMT_SIZE);
+		if (!netdev) {
+			dev_err(&octdev->pci_dev->dev, "Mgmt: Device allocation failed\n");
+			goto nic_dev_fail;
+		}
+
+		/* SET_NETDEV_DEV(netdev, &octdev->pci_dev->dev); */
+		netdev->netdev_ops = &liocomdevops;
+
+		lio_mgmt = GET_LIO_MGMT(netdev);
+		memset(lio_mgmt, 0, LIO_MGMT_SIZE);
+		lio_mgmt->oct_dev = octdev;
+
+		/*use ifidx zero of pf */
+		lio_mgmt->parent_netdev = octdev->props[0].netdev;
+		parent_lio = GET_LIO(lio_mgmt->parent_netdev);
+
+		lio_mgmt->dev_capability = NETIF_F_HIGHDMA;
+
+		netdev->vlan_features = lio_mgmt->dev_capability;
+		netdev->features = lio_mgmt->dev_capability;
+		netdev->hw_features = lio_mgmt->dev_capability;
+
+		lio_mgmt->linfo = parent_lio->linfo;
+		eth_hw_addr_random(netdev);
+
+		/* Register the network device with the OS */
+		if (register_netdev(netdev)) {
+			dev_err(&octdev->pci_dev->dev, "Mgmt: Device registration failed\n");
+			goto nic_dev_fail;
+		}
+
+		netif_carrier_on(netdev);
+		ifstate_set((struct lio *)lio_mgmt, LIO_IFSTATE_REGISTERED);
+		/*  Register RX dispatch function */
+		if (octeon_register_dispatch_fn(octdev, OPCODE_MGMT,
+						OPCODE_MGMT_PKT_DATA,
+						lio_mgmt_rx, octdev)) {
+			goto nic_dev_fail;
+		}
+		octdev->mgmt_ctx = (void *)netdev;
+	}
+
+	return 0;
+
+nic_dev_fail:
+	if (netdev) {
+		struct lio_mgmt *lio_mgmt = GET_LIO_MGMT(netdev);
+
+		if (atomic_read(&lio_mgmt->ifstate) &
+		    LIO_IFSTATE_REGISTERED)
+			unregister_netdev(netdev);
+
+		free_netdev(netdev);
+	}
+
+	return -ENOMEM;
+}
+
+/* De-initializes the LiquidIO management interface module */
+void lio_mgmt_exit(struct octeon_device *octdev)
+{
+	struct net_device *netdev = (struct net_device *)octdev->mgmt_ctx;
+	struct lio_mgmt *lio_mgmt;
+
+	if (netdev) {
+		lio_mgmt = GET_LIO_MGMT(netdev);
+
+		if (atomic_read(&lio_mgmt->ifstate) & LIO_IFSTATE_RUNNING)
+			netif_stop_queue(netdev);
+
+		if (atomic_read(&lio_mgmt->ifstate) &
+		    LIO_IFSTATE_REGISTERED)
+			unregister_netdev(netdev);
+
+		free_netdev(netdev);
+		octdev->mgmt_ctx = NULL;
+	}
+	pr_info("LiquidIO management module is now unloaded\n");
+}
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.h b/drivers/net/ethernet/cavium/liquidio/octeon_device.h
index ad46478..2429ea1 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.h
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.h
@@ -554,6 +554,8 @@ struct octeon_device {
 	} loc;
 
 	atomic_t *adapter_refcount; /* reference count of adapter */
+
+	void *mgmt_ctx; /* pointer to management context */
 };
 
 #define  OCT_DRV_ONLINE 1
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_main.h b/drivers/net/ethernet/cavium/liquidio/octeon_main.h
index 7ccffbb..3d47595 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_main.h
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_main.h
@@ -198,4 +198,12 @@ static inline int octeon_map_pci_barx(struct octeon_device *oct,
 #define ROUNDUP128(val) (((val) + 127) & 0xffffff80)
 #endif
 
+/* Initializes the LiquidIO management interface module
+ * @param octdev - octeon device pointer
+ * @returns 0 if init is success, -1 otherwise
+ */
+int lio_mgmt_init(struct octeon_device *octdev);
+
+/* De-initializes the LiquidIO management interface module */
+void lio_mgmt_exit(struct octeon_device *octdev);
 #endif /* _OCTEON_MAIN_H_ */
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH V2 net-next 1/2] liquidio: Add support to pass meta information to firmware
From: Felix Manlunas @ 2017-07-29  6:18 UTC (permalink / raw)
  To: davem
  Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
	veerasenareddy.burru
In-Reply-To: <20170729061707.GA1134@felix-thinkpad.cavium.com>

From: Veerasenareddy Burru <veerasenareddy.burru@cavium.com>

The LiquidIO adapter has processor cores that can run Linux. This patch
adds the support for passing meta information to LiquidIO linux cores.

Signed-off-by: Veerasenareddy Burru <veerasenareddy.burru@cavium.com>
Signed-off-by: Srinivasa Jampala <srinivasa.jampala@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
---
 drivers/net/ethernet/cavium/liquidio/lio_main.c    | 11 ++++++++-
 .../net/ethernet/cavium/liquidio/liquidio_common.h | 17 +++++++++++++
 .../net/ethernet/cavium/liquidio/octeon_console.c  | 28 ++++++++++++++++++----
 3 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 1d8fefa..6f49513 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -3949,6 +3949,8 @@ static int setup_nic_devices(struct octeon_device *octeon_dev)
 	u32 resp_size, ctx_size, data_size;
 	u32 ifidx_or_pfnum;
 	struct lio_version *vdata;
+	union oct_nic_vf_info vf_info;
+
 
 	/* This is to handle link status changes */
 	octeon_register_dispatch_fn(octeon_dev, OPCODE_NIC,
@@ -4017,9 +4019,16 @@ static int setup_nic_devices(struct octeon_device *octeon_dev)
 
 		sc->iq_no = 0;
 
+		/* Populate VF info for firmware */
+		vf_info.info = 0;
+
+		vf_info.s.bus_num = octeon_dev->pci_dev->bus->number;
+		vf_info.s.dev_fn = octeon_dev->pci_dev->devfn;
+		vf_info.s.max_vfs = octeon_dev->sriov_info.max_vfs;
+
 		octeon_prepare_soft_command(octeon_dev, sc, OPCODE_NIC,
 					    OPCODE_NIC_IF_CFG, 0,
-					    if_cfg.u64, 0);
+					    if_cfg.u64, vf_info.info);
 
 		sc->callback = if_cfg_callback;
 		sc->callback_arg = sc;
diff --git a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
index 53aaf41..2ce2ebb 100644
--- a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
+++ b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
@@ -895,4 +895,21 @@ struct oct_intrmod_cfg {
 	} s;
 };
 
+union oct_nic_vf_info {
+	u64 info;
+	struct {
+#ifdef __BIG_ENDIAN_BITFIELD
+		u64 max_vfs:32;
+		u64 bus_num:8;
+		u64 dev_fn:8;
+		u64 reserved:16;
+#else
+		u64 reserved:16;
+		u64 dev_fn:8;
+		u64 bus_num:8;
+		u64 max_vfs:32;
+#endif
+	} s;
+};
+
 #endif
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_console.c b/drivers/net/ethernet/cavium/liquidio/octeon_console.c
index e08f760..a6b9551 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_console.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_console.c
@@ -724,15 +724,19 @@ static int octeon_console_read(struct octeon_device *oct, u32 console_num,
 }
 
 #define FBUF_SIZE	(4 * 1024 * 1024)
+#define MAX_DATE_SIZE    30
 
 int octeon_download_firmware(struct octeon_device *oct, const u8 *data,
 			     size_t size)
 {
-	int ret = 0;
+	struct octeon_firmware_file_header *h;
+	char date[MAX_DATE_SIZE];
+	struct timeval time;
 	u32 crc32_result;
+	struct tm tm_val;
 	u64 load_addr;
 	u32 image_len;
-	struct octeon_firmware_file_header *h;
+	int ret = 0;
 	u32 i, rem;
 
 	if (size < sizeof(struct octeon_firmware_file_header)) {
@@ -814,8 +818,24 @@ int octeon_download_firmware(struct octeon_device *oct, const u8 *data,
 	dev_info(&oct->pci_dev->dev, "Writing boot command: %s\n",
 		 h->bootcmd);
 
-	/* Invoke the bootcmd */
+	/*Get time of the day*/
+	do_gettimeofday(&time);
+	time_to_tm(time.tv_sec, (-sys_tz.tz_minuteswest) * 60,  &tm_val);
+	ret = snprintf(date, MAX_DATE_SIZE,
+		       " date=%04ld.%02d.%02d-%02d:%02d:%02d",
+		       tm_val.tm_year + 1900, tm_val.tm_mon + 1, tm_val.tm_mday,
+		       tm_val.tm_hour, tm_val.tm_min, tm_val.tm_sec);
+	if ((sizeof(h->bootcmd) - strnlen(h->bootcmd, sizeof(h->bootcmd))) <
+		ret) {
+		dev_err(&oct->pci_dev->dev, "Boot command buffer too small\n");
+		return -EINVAL;
+	}
+	strncat(h->bootcmd, date,
+		sizeof(h->bootcmd) - strnlen(h->bootcmd, sizeof(h->bootcmd)));
+
 	ret = octeon_console_send_cmd(oct, h->bootcmd, 50);
+	if (ret)
+		dev_info(&oct->pci_dev->dev, "Boot command send failed\n");
 
-	return 0;
+	return ret;
 }
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH V2 net-next 0/2] liquidio: Add support for managing liquidio adapter
From: Felix Manlunas @ 2017-07-29  6:17 UTC (permalink / raw)
  To: davem
  Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
	veerasenareddy.burru

From: Veerasenareddy Burru <veerasenareddy.burru@cavium.com>

The LiquidIO adapter has processor cores that can run Linux. This patch
set adds support to create a virtual Ethernet interface on host to
communicate with applications running on Linux in the LiquidIO adapter.
The virtual Ethernet interface also provides login access to Linux on
LiquidIO through ssh for management and debugging.

Change Log:
V1 -> V2
 Only patch #2 was changed:
   * Removed inline functions in .c files
   * Removed useless, almost-empty functions
   * Revised if-statement under "/* Check for all conditions ..."
   * Replaced "if (skb_shinfo(skb)->nr_frags == 0)" with
       "if (!skb_shinfo(skb)->nr_frags)"

Veerasenareddy Burru (2):
  liquidio: Add support to pass meta information to firmware
  liquidio: Add support to create management interface

 drivers/net/ethernet/cavium/liquidio/Makefile      |   1 +
 drivers/net/ethernet/cavium/liquidio/lio_main.c    |  17 +-
 .../net/ethernet/cavium/liquidio/liquidio_common.h |  21 ++
 .../net/ethernet/cavium/liquidio/liquidio_mgmt.c   | 351 +++++++++++++++++++++
 .../net/ethernet/cavium/liquidio/octeon_console.c  |  28 +-
 .../net/ethernet/cavium/liquidio/octeon_device.h   |   2 +
 drivers/net/ethernet/cavium/liquidio/octeon_main.h |   8 +
 7 files changed, 423 insertions(+), 5 deletions(-)
 create mode 100644 drivers/net/ethernet/cavium/liquidio/liquidio_mgmt.c

-- 
1.8.3.1

^ permalink raw reply

* [PATCH 2/2] l2tp: constify net_protocol structures
From: Julia Lawall @ 2017-07-29  6:16 UTC (permalink / raw)
  To: David S. Miller; +Cc: bhumirks, kernel-janitors, netdev, linux-kernel
In-Reply-To: <1501309016-16059-1-git-send-email-Julia.Lawall@lip6.fr>

The net_protocol structure is only passed as the first argument to
inet_add_protocol or inet_del_protocol, both of which are declared
as const.  Thus the net_protocol structure itself can be const.

Done with the help of Coccinelle.

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct net_protocol i@p = { ... };

@ok1@
identifier r.i;
expression e1;
position p;
@@
 \(inet_add_protocol\|inet_del_protocol\)(&i@p,...)

@bad@
position p != {r.p,ok1.p};
identifier r.i;
struct net_protocol e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct net_protocol i = { ... };
// </smpl>

Also drop __read_mostly.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>

---
 net/l2tp/l2tp_ip.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index 4d322c1..c8e4d85 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -649,7 +649,7 @@ int l2tp_ioctl(struct sock *sk, int cmd, unsigned long arg)
 	.ops		= &l2tp_ip_ops,
 };
 
-static struct net_protocol l2tp_ip_protocol __read_mostly = {
+static const struct net_protocol l2tp_ip_protocol = {
 	.handler	= l2tp_ip_recv,
 	.netns_ok	= 1,
 };

^ permalink raw reply related

* [PATCH 1/2] ipv4: constify net_protocol structures
From: Julia Lawall @ 2017-07-29  6:16 UTC (permalink / raw)
  To: David S. Miller
  Cc: bhumirks, kernel-janitors, Alexey Kuznetsov, Hideaki YOSHIFUJI,
	netdev, linux-kernel
In-Reply-To: <1501309016-16059-1-git-send-email-Julia.Lawall@lip6.fr>

The net_protocol structures are only passed as the first argument to
inet_add_protocol, which is declared as const.  Thus the net_protocol
structures themselves can be const.

Done with the help of Coccinelle.

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct net_protocol i@p = { ... };

@ok1@
identifier r.i;
expression e1;
position p;
@@
 inet_add_protocol(&i@p,...)

@bad@
position p != {r.p,ok1.p};
identifier r.i;
struct net_protocol e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct net_protocol i = { ... };
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>

---
 net/ipv4/af_inet.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 5ce44fb..2e38624 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1594,7 +1594,7 @@ u64 snmp_fold_field64(void __percpu *mib, int offt, size_t syncp_offset)
 };
 #endif
 
-static struct net_protocol tcp_protocol = {
+static const struct net_protocol tcp_protocol = {
 	.early_demux	=	tcp_v4_early_demux,
 	.early_demux_handler =  tcp_v4_early_demux,
 	.handler	=	tcp_v4_rcv,
@@ -1604,7 +1604,7 @@ u64 snmp_fold_field64(void __percpu *mib, int offt, size_t syncp_offset)
 	.icmp_strict_tag_validation = 1,
 };
 
-static struct net_protocol udp_protocol = {
+static const struct net_protocol udp_protocol = {
 	.early_demux =	udp_v4_early_demux,
 	.early_demux_handler =	udp_v4_early_demux,
 	.handler =	udp_rcv,

^ permalink raw reply related

* [PATCH 0/2] constify net_protocol structures
From: Julia Lawall @ 2017-07-29  6:16 UTC (permalink / raw)
  To: David S. Miller; +Cc: bhumirks, kernel-janitors, netdev, linux-kernel

The net_protocol structure is only passed as the first argument to
inet_add_protocol or inet_del_protocol, both of which are declared
as const.  Thus the net_protocol structure itself can be const.

Done with the help of Coccinelle.

---

 net/ipv4/af_inet.c |    4 ++--
 net/l2tp/l2tp_ip.c |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

^ permalink raw reply

* Re: [RFC PATCH v1 0/5] TCP Wave
From: Eric Dumazet @ 2017-07-29  5:33 UTC (permalink / raw)
  To: Natale Patriciello
  Cc: David S . Miller, netdev, Ahmed Said, Francesco Zampognaro,
	Cesare Roseti
In-Reply-To: <20170728195919.10099-1-natale.patriciello@gmail.com>

On Fri, 2017-07-28 at 21:59 +0200, Natale Patriciello wrote:
> Hi,
> We are working on a new TCP congestion control algorithm, aiming at satisfying
> new requirements coming from current networks. For instance, adaptation to
> bandwidth/delay changes (due to mobility, dynamic switching, handover), and
> optimal exploitation of very high link capacity and efficient transmission of
> small objects, irrespective of the underlying link characteristics.
> 
> TCP Wave (TCPW) replaces the window-based transmission paradigm of the standard
> TCP with a burst-based transmission, the ACK-clock scheduling with a
> self-managed timer and the RTT-based congestion control loop with an Ack-based
> Capacity and Congestion Estimation (ACCE) module. In non-technical words, it
> sends data down the stack when its internal timer expires, and the timing of
> the received ACKs contribute to updating this timer regularly.
> 
> We tried to add this new sender paradigm without deeply touching existing code.
> In fact, we added four (optional) new congestion control functions:
> 
> +       /* get the expiration time for the send timer (optional) */
> +       unsigned long (*get_send_timer_exp_time)(struct sock *sk);
> +       /* no data to transmit at the timer expiration (optional) */
> +       void (*no_data_to_transmit)(struct sock *sk);
> +       /* the send timer is expired (optional) */
> +       void (*send_timer_expired)(struct sock *sk);
> +       /* the TCP has sent some segments (optional) */
> +       void (*segment_sent)(struct sock *sk, u32 sent);
> 
> And a timer (tp->send_timer) which uses a send callback to push data down the
> stack. If the first of these function, get_send_timer_exp_time,  is not
> implemented by the current congestion control, then the timer sending timer is
> never set, therefore falling back to the old, ACK-clocked, behavior.

trimmed CC

This patch series seems to have missed recent efforts in TCP stack,
namely TCP pacing.

commit 218af599fa635b107cfe10acf3249c4dfe5e4123 ("tcp: internal
implementation for pacing") added a timer already to get fine grained
packet xmits.

I suggest you rebase your work and try to reuse existing mechanisms.

Thanks.

^ permalink raw reply

* Re: STABLE: net: reduce skb_warn_bad_offload() noise
From: Eric Dumazet @ 2017-07-29  5:22 UTC (permalink / raw)
  To: David Miller; +Cc: salyzyn, stable, netdev
In-Reply-To: <20170728.123010.242124876818464581.davem@davemloft.net>

On Fri, 2017-07-28 at 12:30 -0700, David Miller wrote:
> From: Mark Salyzyn <salyzyn@android.com>
> Date: Fri, 28 Jul 2017 10:29:57 -0700
> 
> > Please backport the upstream patch to the stable trees (including
> > 3.10.y, 3.18.y, 4.4.y and 4.9.y):
> > 
> > b2504a5dbef3305ef41988ad270b0e8ec289331c net: reduce
> > skb_warn_bad_offload() noise
> > 
> > Impacting performance or creating unnecessary alarm, and will result
> > in kernel panic for panic_on_warn configuration.
> 
> Yeah this is fine.

If you do so, also backport 6e7bc478c9a006c701c14476ec9d389a484b4864
("net: skb_needs_check() accepts CHECKSUM_NONE for tx")

^ permalink raw reply

* Re: [PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer
From: David Miller @ 2017-07-29  2:01 UTC (permalink / raw)
  To: alex.g-JVBBi1ABkv5Wk0Htik3J/w
  Cc: linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
	netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170728220707.13960-4-alex.g-JVBBi1ABkv5Wk0Htik3J/w@public.gmane.org>

From: Alexandru Gagniuc <alex.g-JVBBi1ABkv5Wk0Htik3J/w@public.gmane.org>
Date: Fri, 28 Jul 2017 15:07:03 -0700

> Before the GMAC on the Anarion chip can be used, the PHY interface
> selection must be configured with the DWMAC block in reset.
> 
> This layer covers a block containing only two registers. Although it
> is possible to model this as a reset controller and use the "resets"
> property of stmmac, it's much more intuitive to include this in the
> glue layer instead.
> 
> At this time only RGMII is supported, because it is the only mode
> which has been validated hardware-wise.
> 
> Signed-off-by: Alexandru Gagniuc <alex.g-JVBBi1ABkv5Wk0Htik3J/w@public.gmane.org>

I don't see how this fits into any patch series at all.  If this is
part of a series you posted elsewhere, you should keep netdev@ on
all such postings so people there can review the change in-context.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 0/2] constify inet6_protocol structures
From: David Miller @ 2017-07-29  1:53 UTC (permalink / raw)
  To: Julia.Lawall; +Cc: kernel-janitors, bhumirks, netdev, linux-kernel
In-Reply-To: <1501273138-22771-1-git-send-email-Julia.Lawall@lip6.fr>

From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Fri, 28 Jul 2017 22:18:56 +0200

> The inet6_protocol structure is only passed as the first argument to
> inet6_add_protocol or inet6_del_protocol, both of which are declared as
> const.  Thus the inet6_protocol structure itself can be const.
> 
> Done with the help of Coccinelle.
 ...

Series applied, thanks Julia.

^ permalink raw reply

* Re: [RFC PATCH v1 5/5] wave: Added basic version of TCP Wave
From: David Miller @ 2017-07-29  1:52 UTC (permalink / raw)
  To: natale.patriciello
  Cc: kuznet, jmorris, yoshfuji, kaber, netdev, ahmed.said, zampognaro,
	roseti
In-Reply-To: <20170728195919.10099-6-natale.patriciello@gmail.com>

From: Natale Patriciello <natale.patriciello@gmail.com>
Date: Fri, 28 Jul 2017 21:59:19 +0200

> +static __always_inline bool test_flag(u8 value, const u8 *flags)

Never, ever, declare functions as inline in foo.c files.

Always let the compiler decide.  No matter how brilliant you think
you are, it always knows better.

And when it doesn't, that's a bug that should be fixed instead of
worked around in our code.

Thanks.

^ permalink raw reply

* Re: [RFC PATCH v1 5/5] wave: Added basic version of TCP Wave
From: David Miller @ 2017-07-29  1:51 UTC (permalink / raw)
  To: natale.patriciello
  Cc: kuznet, jmorris, yoshfuji, kaber, netdev, ahmed.said, zampognaro,
	roseti
In-Reply-To: <20170728195919.10099-6-natale.patriciello@gmail.com>

From: Natale Patriciello <natale.patriciello@gmail.com>
Date: Fri, 28 Jul 2017 21:59:19 +0200

> +/* TCP Wave private struct */
> +struct wavetcp {
> +	/* The module flags */
> +	u8 flags;
> +	/* The current transmission timer (us) */
> +	u32 tx_timer;
> +	/* The current burst size (segments) */
> +	u16 burst;

This style of declaring a data structure wastes a lot of vertical
screen space.  Instead use:

	type	name;	/* comment */

> +static void wavetcp_init(struct sock *sk)
> +{
> +	struct tcp_sock *tp = tcp_sk(sk);
> +	struct wavetcp *ca = inet_csk_ca(sk);

Always declare local variables in longest to shortest line order.

> +	DBG("%u sport: %u [%s]\n", tcp_time_stamp, ca->sport,
> +	    __func__);

DO NOT define your own custom debug logging facilities.

The kernel has millions of mechanism by which you can log information
either in the kernel log buffer or in the kernel trace log.  THere is
everything from dynamic fine-grained run time enable/disable, to
compile time controls.

There is absolutely therefore never a reason to define custom
mechanisms like you are here.

Thanks.

^ permalink raw reply

* Re: [RFC PATCH v1 2/5] tcp: Implemented the timing-based operations
From: David Miller @ 2017-07-29  1:46 UTC (permalink / raw)
  To: natale.patriciello
  Cc: kuznet, jmorris, yoshfuji, kaber, netdev, ahmed.said, zampognaro,
	roseti
In-Reply-To: <20170728195919.10099-3-natale.patriciello@gmail.com>

From: Natale Patriciello <natale.patriciello@gmail.com>
Date: Fri, 28 Jul 2017 21:59:16 +0200

> @@ -369,6 +369,9 @@ struct tcp_sock {
>  	 */
>  	struct request_sock *fastopen_rsk;
>  	u32	*saved_syn;
> +
> +/* TCP send timer */
> +	struct timer_list send_timer;
>  };
>  
>  enum tsq_enum {

If this is congestion control specific it should go into the congestion
control algorithm metadata.  If not, then it's OK to be here I guess :)

> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 4858e190f6ac..357b9cd5019e 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2187,6 +2187,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
>  			   int push_one, gfp_t gfp)
>  {
>  	struct tcp_sock *tp = tcp_sk(sk);
> +	const struct tcp_congestion_ops *ca_ops;
>  	struct sk_buff *skb;
>  	unsigned int tso_segs, sent_pkts;
>  	int cwnd_quota;

Please maintain the reverse christmas tree (longest to shortest) line ordering
of all local variable declarations.

> +	if (timer_pending(&tp->send_timer) == 0) {
> +		/* Timer is not running, push data out */
> +		int ret;
> +		const struct tcp_congestion_ops *ca_ops;

Likewise.

^ permalink raw reply

* RE: [PATCH V3 net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission
From: maowenan @ 2017-07-29  1:39 UTC (permalink / raw)
  To: Neal Cardwell
  Cc: Netdev, David Miller, Yuchung Cheng, Nandita Dukkipati,
	weiyongjun (A), Chenweilong, Wangkefeng (Kevin)
In-Reply-To: <CADVnQy=Dw__BrTHwoUrn0Wxu8=Xb7NqZ9bAuEeM8SrNhzd_2SA@mail.gmail.com>



> -----Original Message-----
> From: Neal Cardwell [mailto:ncardwell@google.com]
> Sent: Saturday, July 29, 2017 6:48 AM
> To: maowenan
> Cc: Netdev; David Miller; Yuchung Cheng; Nandita Dukkipati; weiyongjun (A);
> Chenweilong; Wangkefeng (Kevin)
> Subject: Re: [PATCH V3 net-next] TLP: Don't reschedule PTO when there's one
> outstanding TLP retransmission
> 
> On Thu, Jul 27, 2017 at 8:08 AM, Mao Wenan <maowenan@huawei.com>
> wrote:
> > If there is one TLP probe went out(TLP use the write_queue_tail packet
> > as TLP probe, we assume this first TLP probe named A), and this TLP
> > probe was not acked by receive side.
> >
> > Then the transmit side sent the next two packetes out(named B,C), but
> > unfortunately these two packets are also not acked by receive side.
> >
> > And then there is one data packet with ack_seq A arrive at transmit
> > side, in tcp_ack() will call tcp_schedule_loss_probe() to rearm PTO,
> > the handler tcp_send_loss_probe() is to check
> > if(tp->tlp_high_seq) then go to rearm_timer(because there is one
> > outstanding TLP named A), so the new TLP probe can't be sent out and
> > it needs to rearm the RTO timer(timeout is relative to the transmit
> > time of the write queue head).
> >
> > After that, there is another data packet with ack_seq A is received,
> > if the tlp_time_stamp is greater than rto_time_stamp, it will reset
> > the TLP timeout, which is before previous RTO timeout, so PTO is rearm
> > and previous RTO is cleared. Because there is no retransmission packet
> > was sent or no TLP sack receive,
> > tp->tlp_high_seq can't be reset to zero and the next TLP probe also
> > can't be sent out, so there is no way(or very long time) to retransmit
> > the lost packet.
> >
> > This fix is to check(tp->tlp_high_seq) in tcp_schedule_loss_probe()
> > when TLP PTO is after RTO, It is not needed to reschedule PTO when
> > there is one outstanding TLP retransmission, so if the TLP A is lost
> > RTO can retransmit lost packet, then tp->tlp_high_seq will be set to
> > 0, and TLP will go to the normal work process.
> >
> > v1->v2
> >         refine some words of code and patch comments.
> > v2->v3
> >         delete senseless "{" and "}" in if clause.
> >
> > Signed-off-by: Mao Wenan <maowenan@huawei.com>
> 
> Thanks for posting this patch with a detailed problem description, as well as a
> trace in the thread for v1 of the patch. This was very helpful!
> 
> Thinking about the problem you describe, and looking at the trace, AFAICT I
> don't think this is the patch we want.
> 
> We can still have this problem of improperly/repeatedly rescheduling a PTO
> even when the TLPs are new data. When the TLPs are new data
> tp->tlp_high_seq is not set, and so the patch above will not help.
[Mao Wenan]ok, We have reproduced this issue with packetdrill yesterday, 
there is no the same issue when TLP send new data packet, RTO will be fired and 
retransmit packet.
> 
> I think the broader problem is hinted at in this part of your commit
> description:
> 
> > After that, there is another data packet with ack_seq A is received,
> > if the tlp_time_stamp is greater than rto_time_stamp, it will reset
> > the TLP timeout
> 
> The broader problem here is that an incoming data packet (with no new
> ACK/SACK info) affected the TLP for our outbound data. That is a problem
> because such incoming data can cause us to delay the TLP when there is no
> reason to.
> 
> I think this is basically the same as the TLP issue from the "TCP fast retransmit
> issues" thread on netdev from July 26. Our TCP team at Google has a proposed
> fix for this more general issue that we have tested and reviewed. I will post a
> quick summary of the proposed patch in the "TCP fast retransmit issues"
> thread. Once the patch has undergone a little more testing we will send it to
> the list, hopefully next week.
[Mao Wenan]OK.
> 
> Thanks!
> neal

^ permalink raw reply

* Re: [PATCH net v2] MAINTAINERS: Add more files to the PHY LIBRARY section
From: Andrew Lunn @ 2017-07-29  1:28 UTC (permalink / raw)
  To: Florian Fainelli; +Cc: netdev, davem
In-Reply-To: <20170729004317.31525-1-f.fainelli@gmail.com>

On Fri, Jul 28, 2017 at 05:43:17PM -0700, Florian Fainelli wrote:
> Include missing files that are provided by, used, or directly maintained
> within the PHY LIBRARY, this include uapi header, header files used by
> Device Tree code etc.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply

* [PATCH net v2] MAINTAINERS: Add more files to the PHY LIBRARY section
From: Florian Fainelli @ 2017-07-29  0:43 UTC (permalink / raw)
  To: netdev; +Cc: davem, andrew, Florian Fainelli

Include missing files that are provided by, used, or directly maintained
within the PHY LIBRARY, this include uapi header, header files used by
Device Tree code etc.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:

- added the files Andrew identified and a few more
- sort by alphabetical order

 MAINTAINERS | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 297e610c9163..8e44a637c490 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5138,12 +5138,26 @@ M:	Andrew Lunn <andrew@lunn.ch>
 M:	Florian Fainelli <f.fainelli@gmail.com>
 L:	netdev@vger.kernel.org
 S:	Maintained
-F:	include/linux/phy.h
-F:	include/linux/phy_fixed.h
-F:	drivers/net/phy/
+F:	Documentation/ABI/testing/sysfs-bus-mdio
+F:	Documentation/devicetree/bindings/net/mdio-mux-gpio.txt
+F:	Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
+F:	Documentation/devicetree/bindings/net/mdio-mux.txt
+F:	Documentation/devicetree/bindings/net/mdio.txt
 F:	Documentation/networking/phy.txt
+F:	drivers/net/phy/
 F:	drivers/of/of_mdio.c
 F:	drivers/of/of_net.c
+F:	include/linux/mdio-bitbang.h
+F:	include/linux/mdio-mux.h
+F:	include/linux/mdio.h
+F:	include/linux/of_mdio.h
+F:	include/linux/of_net.h
+F:	include/linux/phy.h
+F:	include/linux/phy_fixed.h
+F:	include/linux/platform_data/mdio-gpio.h
+F:	include/trace/events/mdio.h
+F:	include/uapi/linux/mdio.h
+F:	include/uapi/linux/mii.h
 
 EXT2 FILE SYSTEM
 M:	Jan Kara <jack@suse.com>
-- 
2.9.3

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox