* Re: [PATCH iproute2 net 0/8] tc/act_pedit: Support offset relative to conventional header
From: Stephen Hemminger @ 2017-05-01 16:26 UTC (permalink / raw)
To: Amir Vadai; +Cc: netdev, Or Gerlitz, Jamal Hadi Salim
In-Reply-To: <20170423125356.1298-1-amir@vadai.me>
On Sun, 23 Apr 2017 15:53:48 +0300
Amir Vadai <amir@vadai.me> wrote:
> Hi Stephen,
>
> This patchset extends pedit to support modifying a field in an offset relative
> to the conventional network headers (kenrel support was added [1] in 4.11 rc1).
> Without the extended pedit, user could specify fields in TCP and ICMP headers,
> but the kernel code was using an offset relative to the begining of the IP
> header. This will break if IP header length is greater than the minimal value
> of 20, or if L3 is not IPv4.
>
> It also introduces support in manipulating ETH, TCP, UDP and IP.ttl fields and
> a new command to increase/decrease the value of a field (current use case is IP.ttl).
>
> Since there might be deployments already using pedit, special consideration was
> taken, not to break those scripts - only by specifying the special keyword
> 'ex', the extended capabilities are available, thus there should be no impact
> on existing scripts.
> Also, the new code can live together with rules added by the old code. It
> supports both the old netlink and the new one.
>
> This patchset is against the master and not net-next as the functionality was
> added in 4.11
>
> Thanks,
> Amir
>
> [1] - 71d0ed7079df ("net/act_pedit: Support using offset relative to the
> conventional network headers")
>
> Amir Vadai (7):
> tc/pedit: Fix a typo in pedit usage message
> tc/pedit: Extend pedit to specify offset relative to mac/transport
> headers
> tc/pedit: Introduce 'add' operation
> tc/pedit: p_ip: introduce editing ttl header
> tc/pedit: Support fields bigger than 32 bits
> tc/pedit: p_eth: ETH header editor
> tc/pedit: p_tcp: introduce pedit tcp support
>
> Or Gerlitz (1):
> tc/pedit: p_udp: introduce pedit udp support
>
> man/man8/tc-pedit.8 | 126 +++++++++++++++++++++--
> tc/Makefile | 1 +
> tc/m_pedit.c | 290 ++++++++++++++++++++++++++++++++++++++++++++++------
> tc/m_pedit.h | 44 ++++++--
> tc/p_eth.c | 72 +++++++++++++
> tc/p_icmp.c | 3 +-
> tc/p_ip.c | 21 +++-
> tc/p_tcp.c | 40 +++++++-
> tc/p_udp.c | 30 +++++-
> 9 files changed, 572 insertions(+), 55 deletions(-)
> create mode 100644 tc/p_eth.c
>
Applied. Then I cleaned up long lines
^ permalink raw reply
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: David Miller @ 2017-05-01 16:26 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <87shko7dkk.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 01 May 2017 12:21:31 -0400
> Hi David,
>
> David Miller <davem@davemloft.net> writes:
>
>> From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
>> Date: Mon, 01 May 2017 11:51:05 -0400
>>
>>> Hi David,
>>>
>>> Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
>>>
>>>> Vivien Didelot (18):
>>>> net: dsa: mv88e6xxx: add max VID to info
>>>> net: dsa: mv88e6xxx: split VTU entry data member
>>>> net: dsa: mv88e6xxx: move VTU Operation accessors
>>>> net: dsa: mv88e6xxx: move VTU flush
>>>> net: dsa: mv88e6xxx: move VTU FID accessors
>>>> net: dsa: mv88e6xxx: move VTU SID accessors
>>>> net: dsa: mv88e6xxx: move VTU VID accessors
>>>> net: dsa: mv88e6xxx: move generic VTU GetNext
>>>> net: dsa: mv88e6xxx: move VTU Data accessors
>>>> net: dsa: mv88e6xxx: move STU GetNext operation
>>>> net: dsa: mv88e6xxx: get STU entry on VTU GetNext
>>>> net: dsa: mv88e6xxx: load STU entry with VTU entry
>>>> net: dsa: mv88e6xxx: add VTU GetNext operation
>>>> net: dsa: mv88e6xxx: add VTU Load/Purge operation
>>>> net: dsa: mv88e6xxx: make VTU helpers static
>>>> net: dsa: mv88e6xxx: simplify VTU entry getter
>>>> net: dsa: mv88e6xxx: support the VTU Page bit
>>>> net: dsa: mv88e6xxx: add VTU support for 88E6390
>>>>
>>>> drivers/net/dsa/mv88e6xxx/Makefile | 1 +
>>>> drivers/net/dsa/mv88e6xxx/chip.c | 568 +++++++++-----------------------
>>>> drivers/net/dsa/mv88e6xxx/global1.h | 14 +
>>>> drivers/net/dsa/mv88e6xxx/global1_vtu.c | 505 ++++++++++++++++++++++++++++
>>>> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 31 +-
>>>> 5 files changed, 684 insertions(+), 435 deletions(-)
>>>> create mode 100644 drivers/net/dsa/mv88e6xxx/global1_vtu.c
>>>
>>> I don't see the patchset in net-next. Can you pick it?
>>
>> This had feedback which you must address, therefore the state in
>> patchwork is "changes requested" which you could have checked before
>> asking me this.
>>
>> If the patch set is fine and you got ACKs for all of your patches
>> then please resubmit.
>>
>> Otherwise, make the changes you were asked to make or explain to
>> the person who asked for them why they are not appropriate.
>
> We did discuss the patchset and everything is good as is. Can someone
> change the state in patchwork afterwards? It feels weird to resend the
> patch with no changes.
Once I set the state to "changes requested", that's basically permanent.
Please simply resubmit your patch series, ACKs added if necessary.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: Andrew Lunn @ 2017-05-01 16:25 UTC (permalink / raw)
To: Vivien Didelot; +Cc: David Miller, netdev, linux-kernel, kernel, f.fainelli
In-Reply-To: <87shko7dkk.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
> We did discuss the patchset and everything is good as is. Can someone
> change the state in patchwork afterwards? It feels weird to resend the
> patch with no changes.
Hi Vivien
I actually pointed out a typo in one of the change log message. And i
requested some additional comments.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: Vivien Didelot @ 2017-05-01 16:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170501.120800.1973590139715167836.davem@davemloft.net>
Hi David,
David Miller <davem@davemloft.net> writes:
> From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Date: Mon, 01 May 2017 11:51:05 -0400
>
>> Hi David,
>>
>> Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
>>
>>> Vivien Didelot (18):
>>> net: dsa: mv88e6xxx: add max VID to info
>>> net: dsa: mv88e6xxx: split VTU entry data member
>>> net: dsa: mv88e6xxx: move VTU Operation accessors
>>> net: dsa: mv88e6xxx: move VTU flush
>>> net: dsa: mv88e6xxx: move VTU FID accessors
>>> net: dsa: mv88e6xxx: move VTU SID accessors
>>> net: dsa: mv88e6xxx: move VTU VID accessors
>>> net: dsa: mv88e6xxx: move generic VTU GetNext
>>> net: dsa: mv88e6xxx: move VTU Data accessors
>>> net: dsa: mv88e6xxx: move STU GetNext operation
>>> net: dsa: mv88e6xxx: get STU entry on VTU GetNext
>>> net: dsa: mv88e6xxx: load STU entry with VTU entry
>>> net: dsa: mv88e6xxx: add VTU GetNext operation
>>> net: dsa: mv88e6xxx: add VTU Load/Purge operation
>>> net: dsa: mv88e6xxx: make VTU helpers static
>>> net: dsa: mv88e6xxx: simplify VTU entry getter
>>> net: dsa: mv88e6xxx: support the VTU Page bit
>>> net: dsa: mv88e6xxx: add VTU support for 88E6390
>>>
>>> drivers/net/dsa/mv88e6xxx/Makefile | 1 +
>>> drivers/net/dsa/mv88e6xxx/chip.c | 568 +++++++++-----------------------
>>> drivers/net/dsa/mv88e6xxx/global1.h | 14 +
>>> drivers/net/dsa/mv88e6xxx/global1_vtu.c | 505 ++++++++++++++++++++++++++++
>>> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 31 +-
>>> 5 files changed, 684 insertions(+), 435 deletions(-)
>>> create mode 100644 drivers/net/dsa/mv88e6xxx/global1_vtu.c
>>
>> I don't see the patchset in net-next. Can you pick it?
>
> This had feedback which you must address, therefore the state in
> patchwork is "changes requested" which you could have checked before
> asking me this.
>
> If the patch set is fine and you got ACKs for all of your patches
> then please resubmit.
>
> Otherwise, make the changes you were asked to make or explain to
> the person who asked for them why they are not appropriate.
We did discuss the patchset and everything is good as is. Can someone
change the state in patchwork afterwards? It feels weird to resend the
patch with no changes.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH iproute2 net 2/8] tc/pedit: Extend pedit to specify offset relative to mac/transport headers
From: Stephen Hemminger @ 2017-05-01 16:21 UTC (permalink / raw)
To: Amir Vadai; +Cc: netdev, Or Gerlitz, Jamal Hadi Salim
In-Reply-To: <20170423125356.1298-3-amir@vadai.me>
On Sun, 23 Apr 2017 15:53:50 +0300
Amir Vadai <amir@vadai.me> wrote:
> -extern int parse_cmd(int *argc_p, char ***argv_p, __u32 len, int type,__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int pack_key(struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int pack_key32(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int pack_key16(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int pack_key8(__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> +extern int pack_key(struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> +extern int pack_key32(__u32 retain, struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> +extern int pack_key16(__u32 retain, struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> +extern int pack_key8(__u32 retain, struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> extern int parse_val(int *argc_p, char ***argv_p, __u32 * val, int type);
> -extern int parse_cmd(int *argc_p, char ***argv_p, __u32 len, int type,__u32 retain,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> -extern int parse_offset(int *argc_p, char ***argv_p,struct tc_pedit_sel *sel,struct tc_pedit_key *tkey);
> +extern int parse_cmd(int *argc_p, char ***argv_p, __u32 len, int type, __u32 retain,
> + struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> +extern int parse_offset(int *argc_p, char ***argv_p,
> + struct m_pedit_sel *sel, struct m_pedit_key *tkey);
> int parse_pedit(struct action_util *a, int *argc_p, char ***argv_p, int tc
Please add newline to break the overly long lines here.
Try and keep with in the 80 column convention.
^ permalink raw reply
* RE: [PATCH v5 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
From: David.Cai @ 2017-05-01 16:21 UTC (permalink / raw)
To: andrew; +Cc: netdev, davem, UNGLinuxDriver, steve.glendinning
In-Reply-To: <20170501161545.GG1285@lunn.ch>
Hi Andrew:
Thanks for your help!
David Cai
-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Monday, May 01, 2017 9:16 AM
To: David Cai - C24226
Cc: netdev@vger.kernel.org; davem@davemloft.net; UNGLinuxDriver; steve.glendinning@shawell.net
Subject: Re: [PATCH v5 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
On Mon, May 01, 2017 at 03:46:56PM +0000, David.Cai@microchip.com wrote:
> From: David Cai <david.cai@microchip.com>
>
> Adding support for Microchip LAN9250 Ethernet controller.
>
> Signed-off-by: David Cai <david.cai@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [iproute2] iplink: add support for IFLA_CARRIER attribute
From: Stephen Hemminger @ 2017-05-01 16:16 UTC (permalink / raw)
To: 张胜举; +Cc: netdev
In-Reply-To: <002301d2bf20$6647b5c0$32d72140$@cmss.chinamobile.com>
On Thu, 27 Apr 2017 14:35:01 +0800
张胜举 <zhangshengju@cmss.chinamobile.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Wednesday, April 26, 2017 11:08 PM
> > To: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> > Cc: netdev@vger.kernel.org
> > Subject: Re: [iproute2] iplink: add support for IFLA_CARRIER attribute
> >
> > On Wed, 26 Apr 2017 15:08:39 +0800
> > Zhang Shengju <zhangshengju@cmss.chinamobile.com> wrote:
> >
> > > Add support to set IFLA_CARRIER attribute.
> > >
> > > Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> > > ---
> > > ip/iplink.c | 12 ++++++++++++
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/ip/iplink.c b/ip/iplink.c index 866ad72..263bfdd 100644
> > > --- a/ip/iplink.c
> > > +++ b/ip/iplink.c
> > > @@ -72,6 +72,7 @@ void iplink_usage(void)
> > > " [ allmulticast { on | off } ]\n"
> > > " [ promisc { on | off } ]\n"
> > > " [ trailers { on | off } ]\n"
> > > + " [ carrier { on | off } ]\n"
> > > " [ txqueuelen PACKETS ]\n"
> > > " [ name NEWNAME ]\n"
> > > " [ address LLADDR ]\n"
> > > @@ -673,6 +674,17 @@ int iplink_parse(int argc, char **argv, struct
> > iplink_req *req,
> > > req->i.ifi_flags |= IFF_NOARP;
> > > else
> > > return on_off("arp", *argv);
> > > + } else if (strcmp(*argv, "carrier") == 0) {
> > > + int carrier;
> > > + NEXT_ARG();
> > > + if (strcmp(*argv, "on") == 0)
> > > + carrier = 1;
> > > + else if (strcmp(*argv, "off") == 0)
> > > + carrier = 0;
> > > + else
> > > + return on_off("carrier", *argv);
> > > +
> > > + addattr8(&req->n, sizeof(*req), IFLA_CARRIER,
> > carrier);
> > > } else if (strcmp(*argv, "vf") == 0) {
> > > struct rtattr *vflist;
> > >
> >
> > The general policy of ip link command is all options should be invertable.
> Yes, so I add 'on' and 'off' subcommand to make sure that it can be
> invertable.
>
> > There are some VPN's that use this to save and restore state. So if you
> add
> > an option to set something there should be similar output under the
> detailed
> > show command.
> Currently, "show command" already can display 'carrier' status. Such as:
> dummy0: <NO-CARRIER...>
>
Applied.
^ permalink raw reply
* Re: iproute2: tc action jump
From: Stephen Hemminger @ 2017-05-01 16:16 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: Jiri Pirko, netdev@vger.kernel.org
In-Reply-To: <3a59ecb3-3bdd-60d1-ffa0-5df284f4ccb5@mojatatu.com>
On Thu, 27 Apr 2017 21:54:13 -0400
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> Attached.
> Needs some cleanup and more testing (I only tested a few of these
> actions - should work, just need to vet before official submission).
>
> cheers,
> jamal
Marked as RFC. When ready please resubmit
^ permalink raw reply
* Re: [PATCH v5 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
From: Andrew Lunn @ 2017-05-01 16:15 UTC (permalink / raw)
To: David.Cai; +Cc: netdev, davem, UNGLinuxDriver, steve.glendinning
In-Reply-To: <C3C28FB10418274EB7FD7C2B85C796A4412480F1@CHN-SV-EXMX02.mchp-main.com>
On Mon, May 01, 2017 at 03:46:56PM +0000, David.Cai@microchip.com wrote:
> From: David Cai <david.cai@microchip.com>
>
> Adding support for Microchip LAN9250 Ethernet controller.
>
> Signed-off-by: David Cai <david.cai@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next iproute2] ip: increase number of MPLS labels
From: Stephen Hemminger @ 2017-05-01 16:15 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, Eric W. Biederman, roopa
In-Reply-To: <ddb54ca8-d7df-3446-3929-5f0116286c80@cumulusnetworks.com>
On Sun, 30 Apr 2017 17:42:15 -0600
David Ahern <dsa@cumulusnetworks.com> wrote:
> On 4/30/17 12:04 AM, Stephen Hemminger wrote:
> > On Sat, 29 Apr 2017 20:48:50 -0700
> > David Ahern <dsa@cumulusnetworks.com> wrote:
> >
> >> Kernel now supports more than 2 labels. Increase ip to
> >> handle up to 16 labels.
> >>
> >> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> >> ---
> >> include/utils.h | 8 ++++----
> >> lib/utils.c | 2 +-
> >> 2 files changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/include/utils.h b/include/utils.h
> >> index 8c12e1e2a60c..a69e176c260d 100644
> >> --- a/include/utils.h
> >> +++ b/include/utils.h
> >> @@ -54,6 +54,9 @@ void incomplete_command(void) __attribute__((noreturn));
> >> #define NEXT_ARG_FWD() do { argv++; argc--; } while(0)
> >> #define PREV_ARG() do { argv--; argc++; } while(0)
> >>
> >> +/* Maximum number of labels the mpls helpers support */
> >> +#define MPLS_MAX_LABELS 16
> >> +
> >
> > Why is the kernel limit not in include/uapi/ header file?
> >
>
> I believe Eric had reasons, but not sure why.
I just don't want iproute2 utilities chasing kernel values.
Would prefer either make utilities take any size, or inherit maximum from kernel headers.
^ permalink raw reply
* Re: [PATCH net v3] driver: veth: Fix one possbile memleak when fail to register_netdevice
From: David Ahern @ 2017-05-01 15:08 UTC (permalink / raw)
To: gfree.wind, davem, jarod, lucien.xin, stephen, netdev
In-Reply-To: <1493437911-27167-1-git-send-email-gfree.wind@foxmail.com>
On 4/28/17 9:51 PM, gfree.wind@foxmail.com wrote:
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 8c39d6d..418376a 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -224,9 +224,21 @@ static int veth_dev_init(struct net_device *dev)
> return 0;
> }
>
> -static void veth_dev_free(struct net_device *dev)
> +static void veth_destructor_free(struct net_device *dev)
_destructor in the name is confusing since veth_dev_free is the
dev->destructor. Perhaps that should be veth_free_stats.
> {
> free_percpu(dev->vstats);
> +}
> +
> +static void veth_dev_uninit(struct net_device *dev)
> +{
> + /* dev is not registered, perform the free instead of destructor */
> + if (dev->reg_state == NETREG_UNINITIALIZED)
> + veth_destructor_free(dev);
> +}
> +
> +static void veth_dev_free(struct net_device *dev)
> +{
> + veth_destructor_free(dev);
> free_netdev(dev);
> }
>
> @@ -284,6 +296,7 @@ static void veth_set_rx_headroom(struct net_device *dev, int new_hr)
>
> static const struct net_device_ops veth_netdev_ops = {
> .ndo_init = veth_dev_init,
> + .ndo_uninit = veth_dev_uninit,
> .ndo_open = veth_open,
> .ndo_stop = veth_close,
> .ndo_start_xmit = veth_xmit,
>
Functionally, it looks good to me.
Acked-by: David Ahern <dsa@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 16:10 UTC (permalink / raw)
To: Corentin Labbe
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue-qxv4g6HH51o, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <20170501155856.GA1957@Red>
> > > > Does the internal PHY have a phy driver? It seems like
> > > > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > > > should be in the phy driver, if it has one.
> > >
> > > Nope. These affect the delay lines for the external PHY interface.
>
> I will add some sentences in the documentation to be more clear about that.
Thanks
>
> >
> > Oh, yes. I understood the patch wrong.
> >
> > None of the patches actually use these properties. Are they actually
> > needed? We should avoid adding vendor specific properties, if they are
> > not used.
> >
>
> The board that use it is the BananaPi M3, but the SoC A83T still lack clocks support.
> So theses properties is already used out of tree, and will be used in tree soon.
Fair enough.
Thanks
Andrew
--
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 net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: David Miller @ 2017-05-01 16:08 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <871ss8bmom.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 01 May 2017 11:51:05 -0400
> Hi David,
>
> Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
>
>> Vivien Didelot (18):
>> net: dsa: mv88e6xxx: add max VID to info
>> net: dsa: mv88e6xxx: split VTU entry data member
>> net: dsa: mv88e6xxx: move VTU Operation accessors
>> net: dsa: mv88e6xxx: move VTU flush
>> net: dsa: mv88e6xxx: move VTU FID accessors
>> net: dsa: mv88e6xxx: move VTU SID accessors
>> net: dsa: mv88e6xxx: move VTU VID accessors
>> net: dsa: mv88e6xxx: move generic VTU GetNext
>> net: dsa: mv88e6xxx: move VTU Data accessors
>> net: dsa: mv88e6xxx: move STU GetNext operation
>> net: dsa: mv88e6xxx: get STU entry on VTU GetNext
>> net: dsa: mv88e6xxx: load STU entry with VTU entry
>> net: dsa: mv88e6xxx: add VTU GetNext operation
>> net: dsa: mv88e6xxx: add VTU Load/Purge operation
>> net: dsa: mv88e6xxx: make VTU helpers static
>> net: dsa: mv88e6xxx: simplify VTU entry getter
>> net: dsa: mv88e6xxx: support the VTU Page bit
>> net: dsa: mv88e6xxx: add VTU support for 88E6390
>>
>> drivers/net/dsa/mv88e6xxx/Makefile | 1 +
>> drivers/net/dsa/mv88e6xxx/chip.c | 568 +++++++++-----------------------
>> drivers/net/dsa/mv88e6xxx/global1.h | 14 +
>> drivers/net/dsa/mv88e6xxx/global1_vtu.c | 505 ++++++++++++++++++++++++++++
>> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 31 +-
>> 5 files changed, 684 insertions(+), 435 deletions(-)
>> create mode 100644 drivers/net/dsa/mv88e6xxx/global1_vtu.c
>
> I don't see the patchset in net-next. Can you pick it?
This had feedback which you must address, therefore the state in
patchwork is "changes requested" which you could have checked before
asking me this.
If the patch set is fine and you got ACKs for all of your patches
then please resubmit.
Otherwise, make the changes you were asked to make or explain to
the person who asked for them why they are not appropriate.
^ permalink raw reply
* Re: [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Corentin Labbe @ 2017-05-01 15:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <20170501144541.GB1285@lunn.ch>
On Mon, May 01, 2017 at 04:45:41PM +0200, Andrew Lunn wrote:
> On Mon, May 01, 2017 at 10:28:46PM +0800, Chen-Yu Tsai wrote:
> > On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > > On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> > >> Hello
> > >>
> > >> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > >> present on Allwinner H3/H5/A83T/A64 SoCs.
> > >>
> > >> This driver is the continuation of the sun8i-emac driver.
> > >> During the development, it appeared that in fact the hardware was a modified
> > >> version of some dwmac.
> > >> So the driver is now written as a glue driver for stmmac.
> > >>
> > >> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> > >> It can use an internal PHY (MII 10/100) or an external PHY
> > >> via RGMII/RMII.
> > >
> > > Hi Corentin
> > >
> > > Sorry if this has been asked before....
> > >
> > > Does the internal PHY have a phy driver? It seems like
> > > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > > should be in the phy driver, if it has one.
> >
> > Nope. These affect the delay lines for the external PHY interface.
I will add some sentences in the documentation to be more clear about that.
>
> Oh, yes. I understood the patch wrong.
>
> None of the patches actually use these properties. Are they actually
> needed? We should avoid adding vendor specific properties, if they are
> not used.
>
The board that use it is the BananaPi M3, but the SoC A83T still lack clocks support.
So theses properties is already used out of tree, and will be used in tree soon.
Regards
^ permalink raw reply
* [PATCH] switchdev: documentation: fix whitespace issues
From: Sylvain Lemieux @ 2017-05-01 15:02 UTC (permalink / raw)
To: jiri, ivecera; +Cc: netdev
From: Liam Beguin <lbeguin@tycoint.com>
Figure 1 is full of whitespaces; fix it
Signed-off-by: Liam Beguin <lbeguin@tycoint.com>
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Documentation/networking/switchdev.txt | 70 +++++++++++++++++-----------------
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
index 2bbac05ab9e2..3e7b946dea27 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -13,43 +13,43 @@ an example setup using a data-center-class switch ASIC chip. Other setups
with SR-IOV or soft switches, such as OVS, are possible.
- User-space tools
-
- user space |
- +-------------------------------------------------------------------+
- kernel | Netlink
- |
- +--------------+-------------------------------+
- | Network stack |
- | (Linux) |
- | |
- +----------------------------------------------+
-
+ User-space tools
+
+ user space |
+ +-------------------------------------------------------------------+
+ kernel | Netlink
+ |
+ +--------------+-------------------------------+
+ | Network stack |
+ | (Linux) |
+ | |
+ +----------------------------------------------+
+
sw1p2 sw1p4 sw1p6
- sw1p1 + sw1p3 + sw1p5 + eth1
- + | + | + | +
- | | | | | | |
- +--+----+----+----+-+--+----+---+ +-----+-----+
- | Switch driver | | mgmt |
- | (this document) | | driver |
- | | | |
- +--------------+----------------+ +-----------+
- |
- kernel | HW bus (eg PCI)
- +-------------------------------------------------------------------+
- hardware |
- +--------------+---+------------+
- | Switch device (sw1) |
- | +----+ +--------+
- | | v offloaded data path | mgmt port
- | | | |
- +--|----|----+----+----+----+---+
- | | | | | |
- + + + + + +
+ sw1p1 + sw1p3 + sw1p5 + eth1
+ + | + | + | +
+ | | | | | | |
+ +--+----+----+----+-+--+----+---+ +-----+-----+
+ | Switch driver | | mgmt |
+ | (this document) | | driver |
+ | | | |
+ +--------------+----------------+ +-----------+
+ |
+ kernel | HW bus (eg PCI)
+ +-------------------------------------------------------------------+
+ hardware |
+ +--------------+---+------------+
+ | Switch device (sw1) |
+ | +----+ +--------+
+ | | v offloaded data path | mgmt port
+ | | | |
+ +--|----|----+----+----+----+---+
+ | | | | | |
+ + + + + + +
p1 p2 p3 p4 p5 p6
-
- front-panel ports
-
+
+ front-panel ports
+
Fig 1.
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: Vivien Didelot @ 2017-05-01 15:51 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn
In-Reply-To: <20170426155336.5937-1-vivien.didelot@savoirfairelinux.com>
Hi David,
Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
> Vivien Didelot (18):
> net: dsa: mv88e6xxx: add max VID to info
> net: dsa: mv88e6xxx: split VTU entry data member
> net: dsa: mv88e6xxx: move VTU Operation accessors
> net: dsa: mv88e6xxx: move VTU flush
> net: dsa: mv88e6xxx: move VTU FID accessors
> net: dsa: mv88e6xxx: move VTU SID accessors
> net: dsa: mv88e6xxx: move VTU VID accessors
> net: dsa: mv88e6xxx: move generic VTU GetNext
> net: dsa: mv88e6xxx: move VTU Data accessors
> net: dsa: mv88e6xxx: move STU GetNext operation
> net: dsa: mv88e6xxx: get STU entry on VTU GetNext
> net: dsa: mv88e6xxx: load STU entry with VTU entry
> net: dsa: mv88e6xxx: add VTU GetNext operation
> net: dsa: mv88e6xxx: add VTU Load/Purge operation
> net: dsa: mv88e6xxx: make VTU helpers static
> net: dsa: mv88e6xxx: simplify VTU entry getter
> net: dsa: mv88e6xxx: support the VTU Page bit
> net: dsa: mv88e6xxx: add VTU support for 88E6390
>
> drivers/net/dsa/mv88e6xxx/Makefile | 1 +
> drivers/net/dsa/mv88e6xxx/chip.c | 568 +++++++++-----------------------
> drivers/net/dsa/mv88e6xxx/global1.h | 14 +
> drivers/net/dsa/mv88e6xxx/global1_vtu.c | 505 ++++++++++++++++++++++++++++
> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 31 +-
> 5 files changed, 684 insertions(+), 435 deletions(-)
> create mode 100644 drivers/net/dsa/mv88e6xxx/global1_vtu.c
I don't see the patchset in net-next. Can you pick it?
Thanks,
Vivien
^ permalink raw reply
* [PATCH v5 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
From: David.Cai @ 2017-05-01 15:46 UTC (permalink / raw)
To: netdev, davem; +Cc: UNGLinuxDriver, steve.glendinning
From: David Cai <david.cai@microchip.com>
Adding support for Microchip LAN9250 Ethernet controller.
Signed-off-by: David Cai <david.cai@microchip.com>
---
Changes
V2
- email format changed
- remove unnecessary text in commit log Changes
V3
- defined all supported Ethernet controller chip ID.
V4
- changed 'if (pdata->generation == 4 && pdata->sub_generation)' to
'if ((pdata->idrev & 0xFFFF0000) == LAN9250)' for more readable
V5
- removed the variable 'sub_generation'.
drivers/net/ethernet/smsc/smsc911x.c | 49 ++++++++++++++++++++++--------------
drivers/net/ethernet/smsc/smsc911x.h | 19 ++++++++++++++
2 files changed, 49 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index fa5ca09..ea1bbc3 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -25,7 +25,7 @@
* LAN9215, LAN9216, LAN9217, LAN9218
* LAN9210, LAN9211
* LAN9220, LAN9221
- * LAN89218
+ * LAN89218,LAN9250
*
*/
@@ -1450,6 +1450,8 @@ static int smsc911x_soft_reset(struct smsc911x_data *pdata)
unsigned int timeout;
unsigned int temp;
int ret;
+ unsigned int reset_offset = HW_CFG;
+ unsigned int reset_mask = HW_CFG_SRST_;
/*
* Make sure to power-up the PHY chip before doing a reset, otherwise @@ -1476,15 +1478,23 @@ static int smsc911x_soft_reset(struct smsc911x_data *pdata)
}
}
+ if ((pdata->idrev & 0xFFFF0000) == LAN9250) {
+ /* special reset for LAN9250 */
+ reset_offset = RESET_CTL;
+ reset_mask = RESET_CTL_DIGITAL_RST_;
+ }
+
/* Reset the LAN911x */
- smsc911x_reg_write(pdata, HW_CFG, HW_CFG_SRST_);
+ smsc911x_reg_write(pdata, reset_offset, reset_mask);
+
+ /* verify reset bit is cleared */
timeout = 10;
do {
udelay(10);
- temp = smsc911x_reg_read(pdata, HW_CFG);
- } while ((--timeout) && (temp & HW_CFG_SRST_));
+ temp = smsc911x_reg_read(pdata, reset_offset);
+ } while ((--timeout) && (temp & reset_mask));
- if (unlikely(temp & HW_CFG_SRST_)) {
+ if (unlikely(temp & reset_mask)) {
SMSC_WARN(pdata, drv, "Failed to complete reset");
return -EIO;
}
@@ -2253,28 +2263,29 @@ static int smsc911x_init(struct net_device *dev)
pdata->idrev = smsc911x_reg_read(pdata, ID_REV);
switch (pdata->idrev & 0xFFFF0000) {
- case 0x01180000:
- case 0x01170000:
- case 0x01160000:
- case 0x01150000:
- case 0x218A0000:
+ case LAN9118:
+ case LAN9117:
+ case LAN9116:
+ case LAN9115:
+ case LAN89218:
/* LAN911[5678] family */
pdata->generation = pdata->idrev & 0x0000FFFF;
break;
- case 0x118A0000:
- case 0x117A0000:
- case 0x116A0000:
- case 0x115A0000:
+ case LAN9218:
+ case LAN9217:
+ case LAN9216:
+ case LAN9215:
/* LAN921[5678] family */
pdata->generation = 3;
break;
- case 0x92100000:
- case 0x92110000:
- case 0x92200000:
- case 0x92210000:
- /* LAN9210/LAN9211/LAN9220/LAN9221 */
+ case LAN9210:
+ case LAN9211:
+ case LAN9220:
+ case LAN9221:
+ case LAN9250:
+ /* LAN9210/LAN9211/LAN9220/LAN9221/LAN9250 */
pdata->generation = 4;
break;
diff --git a/drivers/net/ethernet/smsc/smsc911x.h b/drivers/net/ethernet/smsc/smsc911x.h
index 54d6489..8d75508 100644
--- a/drivers/net/ethernet/smsc/smsc911x.h
+++ b/drivers/net/ethernet/smsc/smsc911x.h
@@ -20,6 +20,22 @@
#ifndef __SMSC911X_H__
#define __SMSC911X_H__
+/*Chip ID*/
+#define LAN9115 0x01150000
+#define LAN9116 0x01160000
+#define LAN9117 0x01170000
+#define LAN9118 0x01180000
+#define LAN9215 0x115A0000
+#define LAN9216 0x116A0000
+#define LAN9217 0x117A0000
+#define LAN9218 0x118A0000
+#define LAN9210 0x92100000
+#define LAN9211 0x92110000
+#define LAN9220 0x92200000
+#define LAN9221 0x92210000
+#define LAN9250 0x92500000
+#define LAN89218 0x218A0000
+
#define TX_FIFO_LOW_THRESHOLD ((u32)1600)
#define SMSC911X_EEPROM_SIZE ((u32)128)
#define USE_DEBUG 0
@@ -303,6 +319,9 @@
#define E2P_DATA_EEPROM_DATA_ 0x000000FF
#define LAN_REGISTER_EXTENT 0x00000100
+#define RESET_CTL 0x1F8
+#define RESET_CTL_DIGITAL_RST_ 0x00000001
+
/*
* MAC Control and Status Register (Indirect Address)
* Offset (through the MAC_CSR CMD and DATA port)
^ permalink raw reply related
* Re: [PATCH] net: dsa: mv88e6xxx: fix mdio bus name when using devicetree
From: Andrew Lunn @ 2017-05-01 15:20 UTC (permalink / raw)
To: Sylvain Lemieux; +Cc: vivien.didelot, netdev
In-Reply-To: <20170501145404.18581-1-slemieux.tyco@gmail.com>
On Mon, May 01, 2017 at 10:54:04AM -0400, Sylvain Lemieux wrote:
> From: Liam Beguin <lbeguin@tycoint.com>
>
> mv88e6xxx_mdio_register automatically generates mdio buses for each switch
> discovered in the devicetree. When switch nodes are embedded in other nodes,
> this can cause sysfs naming collisions since full_name may be truncated.
>
> Only use devicetree node name instead of the full devicetree path
> as the mdio bus name.
Hi Sylvain
I'm not sure this is a good idea. It probably breaks my boards:
:/sys/class/mdio_bus# ls
!mdio-mux!mdio@1!switch@0!mdio 0.1 0.4 400d0000.ethernet-1 fixed-0
!mdio-mux!mdio@2!switch@0!mdio 0.2 0.8 400d1000.ethernet-2 mv88e6xxx-0
np->name is not unique, where as np->full_name is unique.
However, i can understand your problem with truncation. Maybe a better
solution is to detect if truncation is going to happen. If so, use a
concatenation of a hash of np->full_name, and the right hand part of
np->full_name?
Andrew
^ permalink raw reply
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: Andrew Lunn @ 2017-05-01 15:02 UTC (permalink / raw)
To: carl h; +Cc: netdev
In-Reply-To: <CABM+yxmdJD2k1kA+fY9Yva24oB8BuDDhS-FQdY2EJM1ghf6xWw@mail.gmail.com>
On Mon, May 01, 2017 at 10:52:17AM -0400, carl h wrote:
> The Ethernet hardware *is* a 2 port switch in a phone which does support
> vlan tag insertion in the switch and driver. The driver is third party which
> I'm trying to get working with vlans.
> But i can't see how the vlan info propagates down to the switch driver.
How are you adding the vlan?
bridge vlan add dev port0 vid 42 self
That should call __vlan_add(), which calls __vlan_vid_add() which uses
switchdev to push the VLAN down into the hardware.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum_router: Simplify VRF enslavement
From: Ido Schimmel @ 2017-05-01 15:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jiri, mlxsw
In-Reply-To: <20170430.230448.383130211524258207.davem@davemloft.net>
On Sun, Apr 30, 2017 at 11:04:48PM -0400, David Miller wrote:
> Applied, thanks.
I see net-next was updated ~25 minutes ago, yet I don't see the patch
there. Can you please check it's actually applied?
Thanks
^ permalink raw reply
* Re: [PATCH v3 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt @ 2017-05-01 15:15 UTC (permalink / raw)
To: David Miller
Cc: mark.rutland, andrew, f.fainelli, sbranden, vivien.didelot,
jonmason, netdev, linux-kernel, devicetree, robh+dt,
bcm-kernel-feedback-list, rjui, linux-arm-kernel
In-Reply-To: <20170430.224852.172293736555378453.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 850 bytes --]
David Miller <davem@davemloft.net> writes:
> From: Eric Anholt <eric@anholt.net>
> Date: Fri, 28 Apr 2017 15:22:03 -0700
>
>> Cygnus is a small family of SoCs, of which we currently have
>> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
>> same as 58xx, just requiring a tiny bit of setup that was previously
>> missing.
>>
>> v2: Reorder the entry in the docs (suggestion by Scott Branden), add
>> missing '"'
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> The second patch with the DTS file update doesn't apply cleanly
> at all to net-next.
>
> So I'm dropping this series.
DTS updates go through arm-soc branches through Florian. The first
patch is the one I would like you to apply.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: David Miller @ 2017-05-01 14:57 UTC (permalink / raw)
To: heyen2000; +Cc: andrew, netdev
In-Reply-To: <CABM+yxmdJD2k1kA+fY9Yva24oB8BuDDhS-FQdY2EJM1ghf6xWw@mail.gmail.com>
From: carl h <heyen2000@gmail.com>
Date: Mon, 1 May 2017 10:52:17 -0400
> But i can't see how the vlan info propagates down to the switch driver.
Which "VLAN info" are you talking about?
The VLANs configured onto the device itself or the per-packet VLAN
info.
Per-device VLAN configuration is communicated to the netdev driver
via netdev_ops->ndo_vlan_{add,kill}_vid().
Per-packet VLAN information is stored in skb->vlan_{proto,tci}.
^ permalink raw reply
* [PATCH] net: dsa: mv88e6xxx: fix mdio bus name when using devicetree
From: Sylvain Lemieux @ 2017-05-01 14:54 UTC (permalink / raw)
To: andrew, vivien.didelot; +Cc: netdev
From: Liam Beguin <lbeguin@tycoint.com>
mv88e6xxx_mdio_register automatically generates mdio buses for each switch
discovered in the devicetree. When switch nodes are embedded in other nodes,
this can cause sysfs naming collisions since full_name may be truncated.
Only use devicetree node name instead of the full devicetree path
as the mdio bus name.
Signed-off-by: Liam Beguin <lbeguin@tycoint.com>
Signed-off-by: Alexandre Messier <amessier@tycoint.com>
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 3354f99df378..80b4387d573e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2688,8 +2688,8 @@ static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip *chip,
mdio_bus->external = external;
if (np) {
- bus->name = np->full_name;
- snprintf(bus->id, MII_BUS_ID_SIZE, "%s", np->full_name);
+ bus->name = np->name;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s", np->name);
} else {
bus->name = "mv88e6xxx SMI";
snprintf(bus->id, MII_BUS_ID_SIZE, "mv88e6xxx-%d", index++);
--
2.11.0
^ permalink raw reply related
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: carl h @ 2017-05-01 14:52 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20170501143703.GA1285@lunn.ch>
The Ethernet hardware *is* a 2 port switch in a phone which does support
vlan tag insertion in the switch and driver. The driver is third party which
I'm trying to get working with vlans.
But i can't see how the vlan info propagates down to the switch driver.
On Mon, May 1, 2017 at 10:37 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > By what mechanism does the vlan driver (8021q.ko) tell the Ethernet
>> > hardware about a vlan?
>
> Why would the Ethernet hardware need to know?
>
> An Ethernet Switch might need to know. If so, then switchdev would be
> used, include/net/switchdev.h
>
> Andrew
^ permalink raw reply
* Re: [PATCH 00/53] Netfilter/IPVS updates for net-next
From: David Miller @ 2017-05-01 14:48 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20170501105353.GA24620@salvia>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 1 May 2017 12:53:53 +0200
> On Mon, May 01, 2017 at 12:46:27PM +0200, Pablo Neira Ayuso wrote:
>> Hi David,
>>
>> The following patchset contains Netfilter updates for your net-next
>> tree. A large bunch of code cleanups, XXX they are:
>
> Oh well, it case you can amend XXX thing there, David. This should be
> instead...
Fixed.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox