Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH bpf-next 1/3] bpftool: Add missing prog types and attach types
From: Andrey Ignatov @ 2018-04-16 23:57 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180416165250.0c907e90@cakuba.netronome.com>

Jakub Kicinski <kubakici@wp.pl> [Mon, 2018-04-16 16:53 -0700]:
> On Mon, 16 Apr 2018 14:41:57 -0700, Andrey Ignatov wrote:
> > diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
> > index cae32a6..8689916 100644
> > --- a/tools/bpf/bpftool/cgroup.c
> > +++ b/tools/bpf/bpftool/cgroup.c
> > @@ -16,15 +16,28 @@
> >  #define HELP_SPEC_ATTACH_FLAGS						\
> >  	"ATTACH_FLAGS := { multi | override }"
> >  
> > -#define HELP_SPEC_ATTACH_TYPES						\
> > -	"ATTACH_TYPE := { ingress | egress | sock_create | sock_ops | device }"
> > +#define HELP_SPEC_ATTACH_TYPES						       \
> > +	"       ATTACH_TYPE := { ingress | egress | sock_create |\n"	       \
> > +	"                        sock_ops | stream_parser |\n"		       \
> > +	"                        stream_verdict | device | msg_verdict |\n"    \
> > +	"                        bind4 | bind6 | connect4 | connect6 |\n"      \
> > +	"                        post_bind4 | post_bind6 }"
> >  
> 
> Would you mind updating the man page in Documentation/ as well?

Sure. Will update and send v2.

-- 
Andrey Ignatov

^ permalink raw reply

* Re: [iproute PATCH] iproute: Abort if nexthop cannot be parsed
From: Stephen Hemminger @ 2018-04-17  0:00 UTC (permalink / raw)
  To: Jakub Sitnicki; +Cc: netdev
In-Reply-To: <20180411094311.21097-1-jkbs@redhat.com>

On Wed, 11 Apr 2018 11:43:11 +0200
Jakub Sitnicki <jkbs@redhat.com> wrote:

> Attempt to add a multipath route where a nexthop definition refers to a
> non-existent device causes 'ip' to crash and burn due to stack buffer
> overflow:
> 
>   # ip -6 route add fd00::1/64 nexthop dev fake1
>   Cannot find device "fake1"
>   Cannot find device "fake1"
>   Cannot find device "fake1"
>   ...
>   Segmentation fault (core dumped)
> 
> Don't ignore errors from the helper routine that parses the nexthop
> definition, and abort immediately if parsing fails.
> 
> Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>

Makes sense. Applied

^ permalink raw reply

* Re: [PATCH net-next 2/2] openvswitch: Support conntrack zone limit
From: Gregory Rose @ 2018-04-17  0:00 UTC (permalink / raw)
  To: Yi-Hung Wei, netdev
In-Reply-To: <1523902550-10767-3-git-send-email-yihung.wei@gmail.com>

On 4/16/2018 11:15 AM, Yi-Hung Wei wrote:
> Currently, nf_conntrack_max is used to limit the maximum number of
> conntrack entries in the conntrack table for every network namespace.
> For the VMs and containers that reside in the same namespace,
> they share the same conntrack table, and the total # of conntrack entries
> for all the VMs and containers are limited by nf_conntrack_max.  In this
> case, if one of the VM/container abuses the usage the conntrack entries,
> it blocks the others to commit valid conntrack entry into the conntrack

s/to commit/from committing/
s/entry/entries/

> table.  Even if we can possibly put the VM in different network namespace,
> the current nf_conntrack_max configuration is kind of rigid that we cannot
> limit different VM/container to have different # conntrack entries.
>
> To address the aforementioned issue, this patch proposes to have a
> fine-grained mechanism that could further limit the # of conntrack entries
> per-zone.  For example, we can designate different zone to different VM,
> and set conntrack limit to each zone.  By providing this isolation, a
> mis-behaved VM only consumes the conntrack entries in its own zone, and
> it will not influence other well-behaved VMs.  Moreover, the users can
> set various conntrack limit to different zone based on their preference.
>
> The proposed implementation utilizes Netfilter's nf_conncount backend
> to count the number of connections in a particular zone.  If the number of
> connection is above a configured limitation, ovs will return ENOMEM to the
> userspace.  If userspace does not configure the zone limit, the limit
> defaults to zero that is no limitation, which is backward compatible to
> the behavior without this patch.
>
> The following high leve APIs are provided to the userspace:
>    - OVS_CT_LIMIT_CMD_SET:
>      * set default connection limit for all zones
>      * set the connection limit for a particular zone
>    - OVS_CT_LIMIT_CMD_DEL:
>      * remove the connection limit for a particular zone
>    - OVS_CT_LIMIT_CMD_GET:
>      * get the default connection limit for all zones
>      * get the connection limit for a particular zone
>
> Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>

I think this is a great idea but I suggest porting to the iproute2 package
so everyone can use it.  Then git rid of the OVS specific prefixes.
Presuming of course that the conntrack connection
limit backend works there as well I guess.  If it doesn't, then I'd 
suggest extending
it.  This is a nice feature for all users in my opinion and then OVS
can take advantage of it as well.

Thanks!

- Greg

> ---
>   net/openvswitch/Kconfig     |   3 +-
>   net/openvswitch/conntrack.c | 497 +++++++++++++++++++++++++++++++++++++++++++-
>   net/openvswitch/conntrack.h |   9 +-
>   net/openvswitch/datapath.c  |   7 +-
>   net/openvswitch/datapath.h  |   1 +
>   5 files changed, 511 insertions(+), 6 deletions(-)
>
> diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig
> index 2650205cdaf9..89da9512ec1e 100644
> --- a/net/openvswitch/Kconfig
> +++ b/net/openvswitch/Kconfig
> @@ -9,7 +9,8 @@ config OPENVSWITCH
>   		   (NF_CONNTRACK && ((!NF_DEFRAG_IPV6 || NF_DEFRAG_IPV6) && \
>   				     (!NF_NAT || NF_NAT) && \
>   				     (!NF_NAT_IPV4 || NF_NAT_IPV4) && \
> -				     (!NF_NAT_IPV6 || NF_NAT_IPV6)))
> +				     (!NF_NAT_IPV6 || NF_NAT_IPV6) && \
> +				     (!NETFILTER_CONNCOUNT || NETFILTER_CONNCOUNT)))
>   	select LIBCRC32C
>   	select MPLS
>   	select NET_MPLS_GSO
> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> index c5904f629091..2f51da91d056 100644
> --- a/net/openvswitch/conntrack.c
> +++ b/net/openvswitch/conntrack.c
> @@ -17,7 +17,9 @@
>   #include <linux/udp.h>
>   #include <linux/sctp.h>
>   #include <net/ip.h>
> +#include <net/genetlink.h>
>   #include <net/netfilter/nf_conntrack_core.h>
> +#include <net/netfilter/nf_conntrack_count.h>
>   #include <net/netfilter/nf_conntrack_helper.h>
>   #include <net/netfilter/nf_conntrack_labels.h>
>   #include <net/netfilter/nf_conntrack_seqadj.h>
> @@ -76,6 +78,38 @@ struct ovs_conntrack_info {
>   #endif
>   };
>   
> +#if	IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +#define OVS_CT_LIMIT_UNLIMITED	0
> +#define OVS_CT_LIMIT_DEFAULT OVS_CT_LIMIT_UNLIMITED
> +#define CT_LIMIT_HASH_BUCKETS 512
> +
> +struct ovs_ct_limit {
> +	/* Elements in ovs_ct_limit_info->limits hash table */
> +	struct hlist_node hlist_node;
> +	struct rcu_head rcu;
> +	u16 zone;
> +	u32 limit;
> +};
> +
> +struct ovs_ct_limit_info {
> +	u32 default_limit;
> +	struct hlist_head *limits;
> +	struct nf_conncount_data *data __aligned(8);
> +};
> +
> +static const struct nla_policy ct_limit_policy[OVS_CT_LIMIT_ATTR_MAX + 1] = {
> +	[OVS_CT_LIMIT_ATTR_OPTION] = { .type = NLA_NESTED, },
> +};
> +
> +static const struct nla_policy
> +	ct_zone_limit_policy[OVS_CT_ZONE_LIMIT_ATTR_MAX + 1] = {
> +		[OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT] = { .type = NLA_U32, },
> +		[OVS_CT_ZONE_LIMIT_ATTR_ZONE] = { .type = NLA_U16, },
> +		[OVS_CT_ZONE_LIMIT_ATTR_LIMIT] = { .type = NLA_U32, },
> +		[OVS_CT_ZONE_LIMIT_ATTR_COUNT] = { .type = NLA_U32, },
> +};
> +#endif
> +
>   static bool labels_nonzero(const struct ovs_key_ct_labels *labels);
>   
>   static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info);
> @@ -1036,6 +1070,94 @@ static bool labels_nonzero(const struct ovs_key_ct_labels *labels)
>   	return false;
>   }
>   
> +#if	IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +static struct hlist_head *ct_limit_hash_bucket(
> +	const struct ovs_ct_limit_info *info, u16 zone)
> +{
> +	return &info->limits[zone & (CT_LIMIT_HASH_BUCKETS - 1)];
> +}
> +
> +/* Call with ovs_mutex */
> +static void ct_limit_set(const struct ovs_ct_limit_info *info,
> +			 struct ovs_ct_limit *new_ct_limit)
> +{
> +	struct ovs_ct_limit *ct_limit;
> +	struct hlist_head *head;
> +
> +	head = ct_limit_hash_bucket(info, new_ct_limit->zone);
> +	hlist_for_each_entry_rcu(ct_limit, head, hlist_node) {
> +		if (ct_limit->zone == new_ct_limit->zone) {
> +			hlist_replace_rcu(&ct_limit->hlist_node,
> +					  &new_ct_limit->hlist_node);
> +			kfree_rcu(ct_limit, rcu);
> +			return;
> +		}
> +	}
> +
> +	hlist_add_head_rcu(&new_ct_limit->hlist_node, head);
> +}
> +
> +/* Call with ovs_mutex */
> +static void ct_limit_del(const struct ovs_ct_limit_info *info, u16 zone)
> +{
> +	struct ovs_ct_limit *ct_limit;
> +	struct hlist_head *head;
> +
> +	head = ct_limit_hash_bucket(info, zone);
> +	hlist_for_each_entry_rcu(ct_limit, head, hlist_node) {
> +		if (ct_limit->zone == zone) {
> +			hlist_del_rcu(&ct_limit->hlist_node);
> +			kfree_rcu(ct_limit, rcu);
> +			return;
> +		}
> +	}
> +}
> +
> +/* Call with RCU read lock */
> +static u32 ct_limit_get(const struct ovs_ct_limit_info *info, u16 zone)
> +{
> +	struct ovs_ct_limit *ct_limit;
> +	struct hlist_head *head;
> +
> +	head = ct_limit_hash_bucket(info, zone);
> +	hlist_for_each_entry_rcu(ct_limit, head, hlist_node) {
> +		if (ct_limit->zone == zone)
> +			return ct_limit->limit;
> +	}
> +
> +	return info->default_limit;
> +}
> +
> +static int ovs_ct_check_limit(struct net *net,
> +			      const struct ovs_conntrack_info *info,
> +			      const struct nf_conntrack_tuple *tuple)
> +{
> +	struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
> +	const struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
> +	u32 per_zone_limit, connections;
> +	u32 conncount_key[5];
> +
> +	conncount_key[0] = info->zone.id;
> +
> +	rcu_read_lock();
> +	per_zone_limit = ct_limit_get(ct_limit_info, info->zone.id);
> +	if (per_zone_limit == OVS_CT_LIMIT_UNLIMITED) {
> +		rcu_read_unlock();
> +		return 0;
> +	}
> +
> +	connections = nf_conncount_count(net, ct_limit_info->data,
> +					 conncount_key, tuple, &info->zone);
> +	if (connections > per_zone_limit) {
> +		rcu_read_unlock();
> +		return -ENOMEM;
> +	}
> +
> +	rcu_read_unlock();
> +	return 0;
> +}
> +#endif
> +
>   /* Lookup connection and confirm if unconfirmed. */
>   static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,
>   			 const struct ovs_conntrack_info *info,
> @@ -1054,6 +1176,13 @@ static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,
>   	if (!ct)
>   		return 0;
>   
> +#if	IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +	err = ovs_ct_check_limit(net, info,
> +				 &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
> +	if (err)
> +		return err;
> +#endif
> +
>   	/* Set the conntrack event mask if given.  NEW and DELETE events have
>   	 * their own groups, but the NFNLGRP_CONNTRACK_UPDATE group listener
>   	 * typically would receive many kinds of updates.  Setting the event
> @@ -1655,7 +1784,363 @@ static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info)
>   		nf_ct_tmpl_free(ct_info->ct);
>   }
>   
> -void ovs_ct_init(struct net *net)
> +#if	IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +static int ovs_ct_limit_init(struct net *net, struct ovs_net *ovs_net)
> +{
> +	int i;
> +
> +	ovs_net->ct_limit_info = kmalloc(sizeof *ovs_net->ct_limit_info,
> +					 GFP_KERNEL);
> +	if (!ovs_net->ct_limit_info)
> +		return -ENOMEM;
> +
> +	ovs_net->ct_limit_info->default_limit = OVS_CT_LIMIT_DEFAULT;
> +	ovs_net->ct_limit_info->limits =
> +		kmalloc_array(CT_LIMIT_HASH_BUCKETS, sizeof(struct hlist_head),
> +			      GFP_KERNEL);
> +	if (!ovs_net->ct_limit_info->limits) {
> +		kfree(ovs_net->ct_limit_info);
> +		return -ENOMEM;
> +	}
> +
> +	for (i = 0; i < CT_LIMIT_HASH_BUCKETS; i++)
> +		INIT_HLIST_HEAD(&ovs_net->ct_limit_info->limits[i]);
> +
> +	ovs_net->ct_limit_info->data =
> +		nf_conncount_init(net, NFPROTO_INET, sizeof(u32));
> +
> +	if (IS_ERR(ovs_net->ct_limit_info->data)) {
> +		kfree(ovs_net->ct_limit_info->limits);
> +		kfree(ovs_net->ct_limit_info);
> +		return PTR_ERR(ovs_net->ct_limit_info->data);
> +	}
> +	return 0;
> +}
> +
> +static void ovs_ct_limit_exit(struct net *net, struct ovs_net *ovs_net)
> +{
> +	const struct ovs_ct_limit_info *info = ovs_net->ct_limit_info;
> +	int i;
> +
> +	nf_conncount_destroy(net, NFPROTO_INET, info->data);
> +	for (i = 0; i < CT_LIMIT_HASH_BUCKETS; ++i) {
> +		struct hlist_head *head = &info->limits[i];
> +		struct ovs_ct_limit *ct_limit;
> +
> +		hlist_for_each_entry_rcu(ct_limit, head, hlist_node)
> +			kfree_rcu(ct_limit, rcu);
> +	}
> +	kfree(ovs_net->ct_limit_info->limits);
> +	kfree(ovs_net->ct_limit_info);
> +}
> +
> +static struct sk_buff *
> +ovs_ct_limit_cmd_reply_start(struct genl_info *info, u8 cmd,
> +			     struct ovs_header **ovs_reply_header)
> +{
> +	struct sk_buff *skb;
> +	struct ovs_header *ovs_header = info->userhdr;
> +
> +	skb = genlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> +	if (!skb)
> +		return ERR_PTR(-ENOMEM);
> +
> +	*ovs_reply_header = genlmsg_put(skb, info->snd_portid,
> +					info->snd_seq,
> +					&dp_ct_limit_genl_family, 0, cmd);
> +
> +	if (!*ovs_reply_header) {
> +		nlmsg_free(skb);
> +		return ERR_PTR(-EMSGSIZE);
> +	}
> +	(*ovs_reply_header)->dp_ifindex = ovs_header->dp_ifindex;
> +
> +	return skb;
> +}
> +
> +static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
> +				       struct ovs_ct_limit_info *info)
> +{
> +	struct nlattr *nla;
> +	int rem, err;
> +
> +	nla_for_each_nested(nla, nla_zone_limit, rem) {
> +		struct nlattr *attr[OVS_CT_ZONE_LIMIT_ATTR_MAX + 1];
> +		struct ovs_ct_limit *ct_limit;
> +
> +		if (nla_type(nla) != OVS_CT_ZONE_LIMIT_ATTR_SET_REQ)
> +			return  -EINVAL;
> +
> +		err = nla_parse((struct nlattr **)&attr,
> +				OVS_CT_ZONE_LIMIT_ATTR_MAX, nla_data(nla),
> +				nla_len(nla), ct_zone_limit_policy, NULL);
> +		if (err)
> +			return err;
> +
> +		if (attr[OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT]) {
> +			u32 default_limit = nla_get_u32(
> +				attr[OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT]);
> +			ovs_lock();
> +			info->default_limit = default_limit;
> +			ovs_unlock();
> +		} else {
> +			if (!attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE] ||
> +			    !attr[OVS_CT_ZONE_LIMIT_ATTR_LIMIT]) {
> +				return -EINVAL;
> +			}
> +
> +			ct_limit = kmalloc(sizeof(*ct_limit), GFP_KERNEL);
> +			if (!ct_limit)
> +				return -ENOMEM;
> +
> +			ct_limit->zone = nla_get_u16(
> +				attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE]);
> +			ct_limit->limit = nla_get_u32(
> +				attr[OVS_CT_ZONE_LIMIT_ATTR_LIMIT]);
> +
> +			ovs_lock();
> +			ct_limit_set(info, ct_limit);
> +			ovs_unlock();
> +		}
> +	}
> +	return 0;
> +}
> +
> +static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,
> +				       struct ovs_ct_limit_info *info)
> +{
> +	struct nlattr *nla;
> +	int rem, err;
> +
> +	nla_for_each_nested(nla, nla_zone_limit, rem) {
> +		struct nlattr *attr[OVS_CT_ZONE_LIMIT_ATTR_MAX + 1];
> +		u16 zone;
> +
> +		if (nla_type(nla) != OVS_CT_ZONE_LIMIT_ATTR_DEL_REQ)
> +			return  -EINVAL;
> +
> +		err = nla_parse((struct nlattr **)&attr,
> +				OVS_CT_ZONE_LIMIT_ATTR_MAX, nla_data(nla),
> +				nla_len(nla), ct_zone_limit_policy, NULL);
> +		if (err)
> +			return err;
> +
> +		if (!attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE])
> +			return -EINVAL;
> +
> +		zone = nla_get_u16(attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE]);
> +
> +		ovs_lock();
> +		ct_limit_del(info, zone);
> +		ovs_unlock();
> +	}
> +	return 0;
> +}
> +
> +static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
> +					  struct sk_buff *reply)
> +{
> +	int err;
> +	struct nlattr *nla_nested;
> +
> +	nla_nested = nla_nest_start(reply, OVS_CT_ZONE_LIMIT_ATTR_GET_RLY);
> +
> +	err = nla_put_u32(reply, OVS_CT_ZONE_LIMIT_ATTR_DEFAULT_LIMIT,
> +			  info->default_limit);
> +	if (err)
> +		return err;
> +
> +	nla_nest_end(reply, nla_nested);
> +	return 0;
> +}
> +
> +static int ovs_ct_limit_get_zone_limit(struct net *net,
> +				       struct nlattr *nla_zone_limit,
> +				       struct ovs_ct_limit_info *info,
> +				       struct sk_buff *reply)
> +{
> +	struct nlattr *nla, *nla_nested;
> +	int rem, err;
> +	u16 zone;
> +	u32 limit, count, conncount_key[5];
> +	struct nf_conntrack_zone ct_zone;
> +
> +	nla_for_each_nested(nla, nla_zone_limit, rem) {
> +		struct nlattr *attr[OVS_CT_ZONE_LIMIT_ATTR_MAX + 1];
> +
> +		if (nla_type(nla) != OVS_CT_ZONE_LIMIT_ATTR_GET_REQ)
> +			return -EINVAL;
> +
> +		err = nla_parse((struct nlattr **)&attr,
> +				OVS_CT_ZONE_LIMIT_ATTR_MAX, nla_data(nla),
> +				nla_len(nla), ct_zone_limit_policy, NULL);
> +		if (err)
> +			return err;
> +
> +		if (!attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE])
> +			return -EINVAL;
> +
> +		zone = nla_get_u16(attr[OVS_CT_ZONE_LIMIT_ATTR_ZONE]);
> +		nf_ct_zone_init(&ct_zone, zone, NF_CT_DEFAULT_ZONE_DIR, 0);
> +		rcu_read_lock();
> +		limit = ct_limit_get(info, zone);
> +		rcu_read_unlock();
> +
> +		conncount_key[0] = zone;
> +		count = nf_conncount_count(net, info->data, conncount_key,
> +					   NULL, &ct_zone);
> +
> +		nla_nested = nla_nest_start(reply,
> +					    OVS_CT_ZONE_LIMIT_ATTR_GET_RLY);
> +		if (nla_put_u16(reply, OVS_CT_ZONE_LIMIT_ATTR_ZONE, zone) ||
> +		    nla_put_u32(reply, OVS_CT_ZONE_LIMIT_ATTR_LIMIT, limit) ||
> +		    nla_put_u32(reply, OVS_CT_ZONE_LIMIT_ATTR_COUNT, count))
> +			return -EMSGSIZE;
> +		nla_nest_end(reply, nla_nested);
> +	}
> +
> +	return 0;
> +}
> +
> +static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)
> +{
> +	struct nlattr **a = info->attrs;
> +	struct sk_buff *reply;
> +	struct ovs_header *ovs_reply_header;
> +	struct ovs_net *ovs_net = net_generic(sock_net(skb->sk), ovs_net_id);
> +	struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
> +	int err;
> +
> +	reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_SET,
> +					     &ovs_reply_header);
> +	if (IS_ERR(reply))
> +		return PTR_ERR(reply);
> +
> +	if (!a[OVS_CT_LIMIT_ATTR_OPTION])
> +		return -EINVAL;
> +
> +	err = ovs_ct_limit_set_zone_limit(a[OVS_CT_LIMIT_ATTR_OPTION],
> +					  ct_limit_info);
> +	if (err)
> +		goto exit_err;
> +
> +	genlmsg_end(reply, ovs_reply_header);
> +	return genlmsg_reply(reply, info);
> +
> +exit_err:
> +	nlmsg_free(reply);
> +	return err;
> +}
> +
> +static int ovs_ct_limit_cmd_del(struct sk_buff *skb, struct genl_info *info)
> +{
> +	struct nlattr **a = info->attrs;
> +	struct sk_buff *reply;
> +	struct ovs_header *ovs_reply_header;
> +	struct ovs_net *ovs_net = net_generic(sock_net(skb->sk), ovs_net_id);
> +	struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
> +	int err;
> +
> +	reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_DEL,
> +					     &ovs_reply_header);
> +	if (IS_ERR(reply))
> +		return PTR_ERR(reply);
> +
> +	if (!a[OVS_CT_LIMIT_ATTR_OPTION])
> +		return -EINVAL;
> +
> +	err = ovs_ct_limit_del_zone_limit(a[OVS_CT_LIMIT_ATTR_OPTION],
> +					  ct_limit_info);
> +	if (err)
> +		goto exit_err;
> +
> +	genlmsg_end(reply, ovs_reply_header);
> +	return genlmsg_reply(reply, info);
> +
> +exit_err:
> +	nlmsg_free(reply);
> +	return err;
> +}
> +
> +static int ovs_ct_limit_cmd_get(struct sk_buff *skb, struct genl_info *info)
> +{
> +	struct nlattr **a = info->attrs;
> +	struct nlattr *nla_reply;
> +	struct sk_buff *reply;
> +	struct ovs_header *ovs_reply_header;
> +	struct net *net = sock_net(skb->sk);
> +	struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
> +	struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
> +	int err;
> +
> +	reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_GET,
> +					     &ovs_reply_header);
> +	if (IS_ERR(reply))
> +		return PTR_ERR(reply);
> +
> +	nla_reply = nla_nest_start(reply, OVS_CT_LIMIT_ATTR_OPTION);
> +
> +	err = ovs_ct_limit_get_default_limit(ct_limit_info, reply);
> +	if (err)
> +		goto exit_err;
> +
> +	if (a[OVS_CT_LIMIT_ATTR_OPTION]) {
> +		err = ovs_ct_limit_get_zone_limit(
> +			net, a[OVS_CT_LIMIT_ATTR_OPTION], ct_limit_info,
> +			reply);
> +		if (err)
> +			goto exit_err;
> +	}
> +
> +	nla_nest_end(reply, nla_reply);
> +	genlmsg_end(reply, ovs_reply_header);
> +	return genlmsg_reply(reply, info);
> +
> +exit_err:
> +	nlmsg_free(reply);
> +	return err;
> +}
> +
> +static struct genl_ops ct_limit_genl_ops[] = {
> +	{ .cmd = OVS_CT_LIMIT_CMD_SET,
> +		.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN
> +					   * privilege. */
> +		.policy = ct_limit_policy,
> +		.doit = ovs_ct_limit_cmd_set,
> +	},
> +	{ .cmd = OVS_CT_LIMIT_CMD_DEL,
> +		.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN
> +					   * privilege. */
> +		.policy = ct_limit_policy,
> +		.doit = ovs_ct_limit_cmd_del,
> +	},
> +	{ .cmd = OVS_CT_LIMIT_CMD_GET,
> +		.flags = 0,		  /* OK for unprivileged users. */
> +		.policy = ct_limit_policy,
> +		.doit = ovs_ct_limit_cmd_get,
> +	},
> +};
> +
> +static const struct genl_multicast_group ovs_ct_limit_multicast_group = {
> +	.name = OVS_CT_LIMIT_MCGROUP,
> +};
> +
> +struct genl_family dp_ct_limit_genl_family __ro_after_init = {
> +	.hdrsize = sizeof(struct ovs_header),
> +	.name = OVS_CT_LIMIT_FAMILY,
> +	.version = OVS_CT_LIMIT_VERSION,
> +	.maxattr = OVS_CT_LIMIT_ATTR_MAX,
> +	.netnsok = true,
> +	.parallel_ops = true,
> +	.ops = ct_limit_genl_ops,
> +	.n_ops = ARRAY_SIZE(ct_limit_genl_ops),
> +	.mcgrps = &ovs_ct_limit_multicast_group,
> +	.n_mcgrps = 1,
> +	.module = THIS_MODULE,
> +};
> +#endif
> +
> +int ovs_ct_init(struct net *net)
>   {
>   	unsigned int n_bits = sizeof(struct ovs_key_ct_labels) * BITS_PER_BYTE;
>   	struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
> @@ -1666,12 +2151,22 @@ void ovs_ct_init(struct net *net)
>   	} else {
>   		ovs_net->xt_label = true;
>   	}
> +
> +#if	IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +	return ovs_ct_limit_init(net, ovs_net);
> +#else
> +	return 0;
> +#endif
>   }
>   
>   void ovs_ct_exit(struct net *net)
>   {
>   	struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
>   
> +#if	IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +	ovs_ct_limit_exit(net, ovs_net);
> +#endif
> +
>   	if (ovs_net->xt_label)
>   		nf_connlabels_put(net);
>   }
> diff --git a/net/openvswitch/conntrack.h b/net/openvswitch/conntrack.h
> index 399dfdd2c4f9..900dadd70974 100644
> --- a/net/openvswitch/conntrack.h
> +++ b/net/openvswitch/conntrack.h
> @@ -17,10 +17,11 @@
>   #include "flow.h"
>   
>   struct ovs_conntrack_info;
> +struct ovs_ct_limit_info;
>   enum ovs_key_attr;
>   
>   #if IS_ENABLED(CONFIG_NF_CONNTRACK)
> -void ovs_ct_init(struct net *);
> +int ovs_ct_init(struct net *);
>   void ovs_ct_exit(struct net *);
>   bool ovs_ct_verify(struct net *, enum ovs_key_attr attr);
>   int ovs_ct_copy_action(struct net *, const struct nlattr *,
> @@ -44,7 +45,7 @@ void ovs_ct_free_action(const struct nlattr *a);
>   #else
>   #include <linux/errno.h>
>   
> -static inline void ovs_ct_init(struct net *net) { }
> +static inline int ovs_ct_init(struct net *net) { return 0; }
>   
>   static inline void ovs_ct_exit(struct net *net) { }
>   
> @@ -104,4 +105,8 @@ static inline void ovs_ct_free_action(const struct nlattr *a) { }
>   
>   #define CT_SUPPORTED_MASK 0
>   #endif /* CONFIG_NF_CONNTRACK */
> +
> +#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +extern struct genl_family dp_ct_limit_genl_family;
> +#endif
>   #endif /* ovs_conntrack.h */
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 015e24e08909..a61818e94396 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -2288,6 +2288,9 @@ static struct genl_family * const dp_genl_families[] = {
>   	&dp_flow_genl_family,
>   	&dp_packet_genl_family,
>   	&dp_meter_genl_family,
> +#if	IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
> +	&dp_ct_limit_genl_family,
> +#endif
>   };
>   
>   static void dp_unregister_genl(int n_families)
> @@ -2323,8 +2326,7 @@ static int __net_init ovs_init_net(struct net *net)
>   
>   	INIT_LIST_HEAD(&ovs_net->dps);
>   	INIT_WORK(&ovs_net->dp_notify_work, ovs_dp_notify_wq);
> -	ovs_ct_init(net);
> -	return 0;
> +	return ovs_ct_init(net);
>   }
>   
>   static void __net_exit list_vports_from_net(struct net *net, struct net *dnet,
> @@ -2469,3 +2471,4 @@ MODULE_ALIAS_GENL_FAMILY(OVS_VPORT_FAMILY);
>   MODULE_ALIAS_GENL_FAMILY(OVS_FLOW_FAMILY);
>   MODULE_ALIAS_GENL_FAMILY(OVS_PACKET_FAMILY);
>   MODULE_ALIAS_GENL_FAMILY(OVS_METER_FAMILY);
> +MODULE_ALIAS_GENL_FAMILY(OVS_CT_LIMIT_FAMILY);
> diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
> index 523d65526766..51bd4dcb6c8b 100644
> --- a/net/openvswitch/datapath.h
> +++ b/net/openvswitch/datapath.h
> @@ -144,6 +144,7 @@ struct dp_upcall_info {
>   struct ovs_net {
>   	struct list_head dps;
>   	struct work_struct dp_notify_work;
> +	struct ovs_ct_limit_info *ct_limit_info;
>   
>   	/* Module reference for configuring conntrack. */
>   	bool xt_label;

^ permalink raw reply

* Re: [PATCH iproute2] utils: Do not reset family for default, any, all addresses
From: Stephen Hemminger @ 2018-04-17  0:01 UTC (permalink / raw)
  To: David Ahern; +Cc: netdev, whissi, Serhey Popovych
In-Reply-To: <20180413163633.1844-1-dsahern@gmail.com>

On Fri, 13 Apr 2018 09:36:33 -0700
David Ahern <dsahern@gmail.com> wrote:

> Thomas reported a change in behavior with respect to autodectecting
> address families. Specifically, 'ip ro add default via fe80::1'
> syntax was failing to treat fe80::1 as an IPv6 address as it did in
> prior releases. The root causes appears to be a change in family when
> the default keyword is parsed.
> 
> 'default', 'any' and 'all' are relevant outside of AF_INET. Leave the
> family arg as is for these when setting addr.
> 
> Fixes: 93fa12418dc6 ("utils: Always specify family and ->bytelen in get_prefix_1()")
> Reported-by: Thomas Deutschmann <whissi@gentoo.org>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> Cc: Serhey Popovych <serhe.popovych@gmail.com>

Looks good, thanks for fixing.
Applied

^ permalink raw reply

* Re: [PATCH 08/10] net: ax88796: Make reset more robust on AX88796B
From: Michael Schmitz @ 2018-04-17  0:14 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: netdev, Linux/m68k, Michael Karcher, John Paul Adrian Glaubitz,
	Michael Karcher
In-Reply-To: <20180416231223.GB23474@lunn.ch>

Hi Andrew,

On Tue, Apr 17, 2018 at 11:12 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Apr 17, 2018 at 10:04:43AM +1200, Michael Schmitz wrote:
>> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>>
>> The AX88796B as installed on the X-Surf-100 does not recognize a MII reset
>> request if the previous write to the MII control register also was a reset
>> request. So a dummy write to the control register makes the soft reset in
>> the PHY initialization code work.
>>
>> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
>> ---
>>  drivers/net/ethernet/8390/ax88796.c |    4 ++++
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
>> index 6af9aca..a2f9a09 100644
>> --- a/drivers/net/ethernet/8390/ax88796.c
>> +++ b/drivers/net/ethernet/8390/ax88796.c
>> @@ -374,6 +374,10 @@ static int ax_mii_probe(struct net_device *dev)
>>               return -ENODEV;
>>       }
>>
>> +     /* write a non-reset pattern to the control register to
>> +      * re-arm the reset request detection logic (needed on AX88796B)
>> +      */
>> +     phy_write(phy_dev, MII_BMCR, 0);
>
> This should really be fixed in the PHY driver, not the MAC.

OK - do you want this separate, or as part of this series? Might have
a few side effects on more commonly used hardware, perhaps?

Cheers,

  Michael

>
>      Andrew

^ permalink raw reply

* RE: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements to the list
From: Brown, Aaron F @ 2018-04-17  0:52 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
	Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-2-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:17 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements
> to the list
> 
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements to
> > the list
> >
> > Because the order of the parameters passes to 'hlist_add_behind()' was
> > inverted, the 'parent' node was added "behind" the 'input', as input
> > is not in the list, this causes the 'input' node to be lost.
> >
> > Fixes: 0e71def25281 ("igb: add support of RX network flow classification")
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Resending with "Tested-by..." rather then "Tested by..." so that patchwork actually picks it up.  What I get for signing off on the mails late Friday.
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue selection on MAC filters on i210
From: Brown, Aaron F @ 2018-04-17  0:52 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-3-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:18 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue
> selection on MAC filters on i210
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue
> > selection on MAC filters on i210
> >
> > On the RAH registers there are semantic differences on the meaning of
> > the "queue" parameter for traffic steering depending on the controller
> > model: there is the 82575 meaning, which "queue" means a RX Hardware
> > Queue, and the i350 meaning, where it is a reception pool.
> >
> > The previous behaviour was having no effect for i210 based controllers
> > because the QSEL bit of the RAH register wasn't being set.
> >
> > This patch separates the condition in discrete cases, so the different
> > handling is clearer.
> >
> > Fixes: 83c21335c876 ("igb: improve MAC filter handling")
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 13 +++++++++----
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> >
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the hardware traffic class feature bit for igb models
From: Brown, Aaron F @ 2018-04-17  0:52 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-4-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:18 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the
> hardware traffic class feature bit for igb models
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the
> > hardware traffic class feature bit for igb models
> >
> > This will allow functionality depending on the hardware being traffic
> > class aware to work. In particular the tc-flower offloading checks
> > verifies that this bit is set.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 3 +++
> >  1 file changed, 3 insertions(+)
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [next-queue PATCH v7 04/10] igb: Add support for MAC address filters specifying source addresses
From: Brown, Aaron F @ 2018-04-17  0:53 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
	Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-5-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:19 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 04/10] igb: Add support for MAC address
> filters specifying source addresses
> 
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 04/10] igb: Add support for MAC address
> > filters specifying source addresses
> >
> > Makes it possible to direct packets to queues based on their source
> > address. Documents the expected usage of the 'flags' parameter.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  .../net/ethernet/intel/igb/e1000_defines.h    |  1 +
> >  drivers/net/ethernet/intel/igb/igb.h          |  1 +
> >  drivers/net/ethernet/intel/igb/igb_main.c     | 40 ++++++++++++++++---
> >  3 files changed, 37 insertions(+), 5 deletions(-)
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support for enabling queue steering in filters
From: Brown, Aaron F @ 2018-04-17  0:53 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-6-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:20 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support
> for enabling queue steering in filters
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support
> for
> > enabling queue steering in filters
> >
> > On some igb models (82575 and i210) the MAC address filters can
> > control to which queue the packet will be assigned.
> >
> > This extends the 'state' with one more state to signify that queue
> > selection should be enabled for that filter.
> >
> > As 82575 parts are no longer easily obtained (and this was developed
> > against i210), only support for the i210 model is enabled.
> >
> > These functions are exported and will be used in the next patch.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  .../net/ethernet/intel/igb/e1000_defines.h    |  1 +
> >  drivers/net/ethernet/intel/igb/igb.h          |  6 +++++
> >  drivers/net/ethernet/intel/igb/igb_main.c     | 26 +++++++++++++++++++
> >  3 files changed, 33 insertions(+)
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters to be added for the local MAC address
From: Brown, Aaron F @ 2018-04-17  0:53 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-7-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:20 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters
> to be added for the local MAC address
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters to
> > be added for the local MAC address
> >
> > Users expect that when adding a steering filter for the local MAC
> > address, that all the traffic directed to that address will go to some
> > queue.
> >
> > Currently, it's not possible to configure entries in the "in use"
> > state, which is the normal state of the local MAC address entry (it is
> > the default), this patch allows to override the steering configuration
> > of "in use" entries, if the filter to be added match the address and
> > address type (source or destination) of an existing entry.
> >
> > There is a bit of a special handling for entries referring to the
> > local MAC address, when they are removed, only the steering
> > configuration is reset.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 40 ++++++++++++++++++++-
> --
> >  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify MAC addresses
From: Brown, Aaron F @ 2018-04-17  0:54 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
	Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-8-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:22 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify
> MAC addresses
> 
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify MAC
> > addresses
> >
> > This allows igb_add_filter()/igb_erase_filter() to work on filters
> > that include MAC addresses (both source and destination).
> >
> > For now, this only exposes the functionality, the next commit glues
> > ethtool into this. Later in this series, these APIs are used to allow
> > offloading of cls_flower filters.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb.h         |  4 +++
> >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 28
> ++++++++++++++++++++
> >  2 files changed, 32 insertions(+)
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [next-queue PATCH v7 08/10] igb: Add MAC address support for ethtool nftuple filters
From: Brown, Aaron F @ 2018-04-17  0:54 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
	Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-9-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:23 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 08/10] igb: Add MAC address support for
> ethtool nftuple filters
> 
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 08/10] igb: Add MAC address support for
> > ethtool nftuple filters
> >
> > This adds the capability of configuring the queue steering of arriving
> > packets based on their source and destination MAC addresses.
> >
> > Source address steering (i.e. driving traffic to a specific queue),
> > for the i210, does not work, but filtering does (i.e. accepting
> > traffic based on the source address). So, trying to add a filter
> > specifying only a source address will be an error.
> >
> > In practical terms this adds support for the following use cases,
> > characterized by these examples:
> >
> > $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> > (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> > to the RX queue 0)
> >
> > $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 \
> >   	     	  	    	  proto 0x22f0 action 3
> > (this will direct packets with source address "44:44:44:44:44:44" and
> > ethertype 0x22f0 to the RX queue 3)
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 43 ++++++++++++++++++-
> -
> >  1 file changed, 39 insertions(+), 4 deletions(-)
> >
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the skeletons for tc-flower offloading
From: Brown, Aaron F @ 2018-04-17  0:54 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-10-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:23 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the
> skeletons for tc-flower offloading
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> > palencia@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the
> > skeletons for tc-flower offloading
> >
> > This adds basic functions needed to implement offloading for filters
> > created by tc-flower.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 66
> > +++++++++++++++++++++++
> >  1 file changed, 66 insertions(+)
> >
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [next-queue PATCH v7 10/10] igb: Add support for adding offloaded clsflower filters
From: Brown, Aaron F @ 2018-04-17  0:55 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
	Sanchez-Palencia, Jesus
In-Reply-To: <20180410174959.18757-11-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:25 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>
> Subject: RE: [next-queue PATCH v7 10/10] igb: Add support for adding
> offloaded clsflower filters
> 
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>
> > Subject: [next-queue PATCH v7 10/10] igb: Add support for adding
> offloaded
> > clsflower filters
> >
> > This allows filters added by tc-flower and specifying MAC addresses,
> > Ethernet types, and the VLAN priority field, to be offloaded to the
> > controller.
> >
> > This reuses most of the infrastructure used by ethtool, but clsflower
> > filters are kept in a separated list, so they are invisible to
> > ethtool.
> >
> > To setup clsflower offloading:
> >
> > $ tc qdisc replace dev eth0 handle 100: parent root mqprio \
> >      	   	   num_tc 3 map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
> > 		   queues 1@0 1@1 2@2 hw 0
> > (clsflower offloading depends on the netword driver to be configured
> > with multiple traffic classes, we use mqprio's 'num_tc' parameter to
> > set it to 3)
> >
> > $ tc qdisc add dev eth0 ingress
> >
> > Examples of filters:
> >
> > $ tc filter add dev eth0 parent ffff: flower \
> >      	    dst_mac aa:aa:aa:aa:aa:aa \
> > 	    hw_tc 2 skip_sw
> > (just a simple filter filtering for the destination MAC address and
> > steering that traffic to queue 2)
> >
> > $ tc filter add dev enp2s0 parent ffff: proto 0x22f0 flower \
> >      	    src_mac cc:cc:cc:cc:cc:cc \
> > 	    hw_tc 1 skip_sw
> > (as the i210 doesn't support steering traffic based on the source
> > address alone, we need to use another steering traffic, in this case
> > we are using the ethernet type (0x22f0) to steer traffic to queue 1)
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb.h      |   2 +
> >  drivers/net/ethernet/intel/igb/igb_main.c | 188
> > +++++++++++++++++++++-
> >  2 files changed, 188 insertions(+), 2 deletions(-)
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* RE: [next-queue PATCH] igb: Fix the transmission mode of queue 0 for Qav mode
From: Brown, Aaron F @ 2018-04-17  0:55 UTC (permalink / raw)
  To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
  Cc: Gomes, Vinicius, Kirsher, Jeffrey T, netdev@vger.kernel.org,
	Sanchez-Palencia, Jesus, Guedes, Andre
In-Reply-To: <20180331000652.2855-1-vinicius.gomes@intel.com>

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:28 PM
> To: 'Vinicius Costa Gomes' <vinicius.gomes@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palencia@intel.com>; Guedes, Andre
> <andre.guedes@intel.com>
> Subject: RE: [next-queue PATCH] igb: Fix the transmission mode of queue 0
> for Qav mode
> 
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Friday, March 30, 2018 5:07 PM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.gomes@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palencia@intel.com>; Guedes, Andre
> > <andre.guedes@intel.com>
> > Subject: [next-queue PATCH] igb: Fix the transmission mode of queue 0 for
> > Qav mode
> >
> > When Qav mode is enabled, queue 0 should be kept on Stream
> Reservation
> > mode. From the i210 datasheet, section 8.12.19:
> >
> > "Note: Queue0 QueueMode must be set to 1b when TransmitMode is set
> to
> > Qav." ("QueueMode 1b" represents the Stream Reservation mode)
> >
> > The solution is to give queue 0 the all the credits it might need, so
> > it has priority over queue 1.
> >
> > A situation where this can happen is when cbs is "installed" only on
> > queue 1, leaving queue 0 alone. For example:
> >
> > $ tc qdisc replace dev enp2s0 handle 100: parent root mqprio num_tc 3 \
> >      	   map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 0
> >
> > $ tc qdisc replace dev enp2s0 parent 100:2 cbs locredit -1470 \
> >      	   hicredit 30 sendslope -980000 idleslope 20000 offload 1
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 17 ++++++++++++++++-
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> >
> 
> Tested by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>

^ permalink raw reply

* Re: [PATCH 08/10] net: ax88796: Make reset more robust on AX88796B
From: Andrew Lunn @ 2018-04-17  1:32 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: netdev, Linux/m68k, Michael Karcher, John Paul Adrian Glaubitz,
	Michael Karcher
In-Reply-To: <CAOmrzkKoPwNRf5Nq=GN8ktP-9B5dNyGggFsrJ-Tr3D-z=Jj2rQ@mail.gmail.com>

> > This should really be fixed in the PHY driver, not the MAC.
> 
> OK - do you want this separate, or as part of this series? Might have
> a few side effects on more commonly used hardware, perhaps?

Hi Michael

What PHY driver is used? In the driver you can implement a .soft_reset
function which first does the dummy write, and then uses
genphy_soft_reset() to do the actual reset.

     Andrew

^ permalink raw reply

* [PATCH v2 3/8] net: ax88796: Do not free IRQ in ax_remove() (already freed in ax_close()).
From: Michael Schmitz @ 2018-04-17  2:08 UTC (permalink / raw)
  To: netdev
  Cc: andrew, linux-m68k, Michael.Karcher, John Paul Adrian Glaubitz,
	Michael Karcher
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

This complements the fix in 82533ad9a1c that removed the free_irq
call in the error path of probe, to also not call free_irq when
remove is called to revert the effects of probe.

Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
---
 drivers/net/ethernet/8390/ax88796.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index 83e59ae..ecf104c 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -793,7 +793,6 @@ static int ax_remove(struct platform_device *pdev)
 	struct resource *mem;
 
 	unregister_netdev(dev);
-	free_irq(dev->irq, dev);
 
 	iounmap(ei_local->mem);
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 0/8] New network driver for Amiga X-Surf 100 (m68k)
From: Michael Schmitz @ 2018-04-17  2:08 UTC (permalink / raw)
  To: netdev; +Cc: andrew, linux-m68k, Michael.Karcher
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>

This patch series adds support for the Individual Computers X-Surf 100
network card for m68k Amiga, a network adapter based on the AX88796 chip set.

The driver was originally written for kernel version 3.19 by Michael Karcher
(see CC:), and adapted to 4.16 for submission to netdev by me. Questions 
regarding motivation for some of the changes are probably best directed at
Michael Karcher.

The driver has been tested by Adrian <glaubitz@physik.fu-berlin.de> who will
send his Tested-by tag separately.

A few changes to the ax88796 driver were required:
- to read the MAC address, some setup of the ax99796 chip must be done,
- attach to the MII bus only on device open to allow module unloading,
- allow to supersede ax_block_input/ax_block_output by card-specific
  optimized code,
- use an optional interrupt status callback to allow easier sharing of the
  card interrupt,
- set IRQF_SHARED if platform IRQ resource is marked shareable,

Some additional cleanup:
- do not attempt to free IRQ in ax_remove (complements 82533ad9a1c),
- clear platform drvdata on probe fail and module remove.

Changes since v1:

Raised in review by Andrew Lunn:
- move MII code around to avoid need for forward declaration
- combine patches 2 and 7 to add cleanup in error path

The patch series, in order:

1/8 net: ax88796: Fix MAC address reading
2/8 net: ax88796: Attach MII bus only when open
3/8 net: ax88796: Do not free IRQ in ax_remove() (already freed in ax_close()).
4/8 net: ax88796: Add block_input/output hooks to ax_plat_data
5/8 net: ax88796: add interrupt status callback to platform data
6/8 net: ax88796: set IRQF_SHARED flag when IRQ resource is marked as shareable
7/8 net: ax88796: release platform device drvdata on probe error and module remove
8/8 net: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)

 drivers/net/ethernet/8390/Kconfig    |   14 +-
 drivers/net/ethernet/8390/Makefile   |    1 +
 drivers/net/ethernet/8390/ax88796.c  |  228 +++++++++++--------
 drivers/net/ethernet/8390/xsurf100.c |  411 ++++++++++++++++++++++++++++++++++
 include/net/ax88796.h                |   14 +-
 5 files changed, 573 insertions(+), 95 deletions(-)

Cheers,

  Michael

^ permalink raw reply

* [PATCH v2 2/8] net: ax88796: Attach MII bus only when open
From: Michael Schmitz @ 2018-04-17  2:08 UTC (permalink / raw)
  To: netdev
  Cc: andrew, linux-m68k, Michael.Karcher, Michael Karcher,
	Michael Karcher, Michael Schmitz
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>

From: Michael Karcher <debian@mkarcher.dialup.fu-berlin.de>

Call ax_mii_init in ax_open(), and unregister/remove mdiobus resources
in ax_close().

This is needed to be able to unload the module, as the module is busy
while the MII bus is attached.

Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
 drivers/net/ethernet/8390/ax88796.c |  183 ++++++++++++++++++-----------------
 1 files changed, 95 insertions(+), 88 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index 2a256aa..83e59ae 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -389,6 +389,90 @@ static void ax_phy_switch(struct net_device *dev, int on)
 	ei_outb(reg_gpoc, ei_local->mem + EI_SHIFT(0x17));
 }
 
+static void ax_bb_mdc(struct mdiobb_ctrl *ctrl, int level)
+{
+	struct ax_device *ax = container_of(ctrl, struct ax_device, bb_ctrl);
+
+	if (level)
+		ax->reg_memr |= AX_MEMR_MDC;
+	else
+		ax->reg_memr &= ~AX_MEMR_MDC;
+
+	ei_outb(ax->reg_memr, ax->addr_memr);
+}
+
+static void ax_bb_dir(struct mdiobb_ctrl *ctrl, int output)
+{
+	struct ax_device *ax = container_of(ctrl, struct ax_device, bb_ctrl);
+
+	if (output)
+		ax->reg_memr &= ~AX_MEMR_MDIR;
+	else
+		ax->reg_memr |= AX_MEMR_MDIR;
+
+	ei_outb(ax->reg_memr, ax->addr_memr);
+}
+
+static void ax_bb_set_data(struct mdiobb_ctrl *ctrl, int value)
+{
+	struct ax_device *ax = container_of(ctrl, struct ax_device, bb_ctrl);
+
+	if (value)
+		ax->reg_memr |= AX_MEMR_MDO;
+	else
+		ax->reg_memr &= ~AX_MEMR_MDO;
+
+	ei_outb(ax->reg_memr, ax->addr_memr);
+}
+
+static int ax_bb_get_data(struct mdiobb_ctrl *ctrl)
+{
+	struct ax_device *ax = container_of(ctrl, struct ax_device, bb_ctrl);
+	int reg_memr = ei_inb(ax->addr_memr);
+
+	return reg_memr & AX_MEMR_MDI ? 1 : 0;
+}
+
+static const struct mdiobb_ops bb_ops = {
+	.owner = THIS_MODULE,
+	.set_mdc = ax_bb_mdc,
+	.set_mdio_dir = ax_bb_dir,
+	.set_mdio_data = ax_bb_set_data,
+	.get_mdio_data = ax_bb_get_data,
+};
+
+static int ax_mii_init(struct net_device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev->dev.parent);
+	struct ei_device *ei_local = netdev_priv(dev);
+	struct ax_device *ax = to_ax_dev(dev);
+	int err;
+
+	ax->bb_ctrl.ops = &bb_ops;
+	ax->addr_memr = ei_local->mem + AX_MEMR;
+	ax->mii_bus = alloc_mdio_bitbang(&ax->bb_ctrl);
+	if (!ax->mii_bus) {
+		err = -ENOMEM;
+		goto out;
+	}
+
+	ax->mii_bus->name = "ax88796_mii_bus";
+	ax->mii_bus->parent = dev->dev.parent;
+	snprintf(ax->mii_bus->id, MII_BUS_ID_SIZE, "%s-%x",
+		pdev->name, pdev->id);
+
+	err = mdiobus_register(ax->mii_bus);
+	if (err)
+		goto out_free_mdio_bitbang;
+
+	return 0;
+
+ out_free_mdio_bitbang:
+	free_mdio_bitbang(ax->mii_bus);
+ out:
+	return err;
+}
+
 static int ax_open(struct net_device *dev)
 {
 	struct ax_device *ax = to_ax_dev(dev);
@@ -396,6 +480,10 @@ static int ax_open(struct net_device *dev)
 
 	netdev_dbg(dev, "open\n");
 
+	ret = ax_mii_init(dev);
+	if (ret)
+		goto failed_mii;
+
 	ret = request_irq(dev->irq, ax_ei_interrupt, ax->irqflags,
 			  dev->name, dev);
 	if (ret)
@@ -423,6 +511,10 @@ static int ax_open(struct net_device *dev)
 	ax_phy_switch(dev, 0);
 	free_irq(dev->irq, dev);
  failed_request_irq:
+	/* unregister mdiobus */
+	mdiobus_unregister(ax->mii_bus);
+	free_mdio_bitbang(ax->mii_bus);
+ failed_mii:
 	return ret;
 }
 
@@ -442,6 +534,9 @@ static int ax_close(struct net_device *dev)
 	phy_disconnect(dev->phydev);
 
 	free_irq(dev->irq, dev);
+
+	mdiobus_unregister(ax->mii_bus);
+	free_mdio_bitbang(ax->mii_bus);
 	return 0;
 }
 
@@ -541,92 +636,8 @@ static void ax_eeprom_register_write(struct eeprom_93cx6 *eeprom)
 #endif
 };
 
-static void ax_bb_mdc(struct mdiobb_ctrl *ctrl, int level)
-{
-	struct ax_device *ax = container_of(ctrl, struct ax_device, bb_ctrl);
-
-	if (level)
-		ax->reg_memr |= AX_MEMR_MDC;
-	else
-		ax->reg_memr &= ~AX_MEMR_MDC;
-
-	ei_outb(ax->reg_memr, ax->addr_memr);
-}
-
-static void ax_bb_dir(struct mdiobb_ctrl *ctrl, int output)
-{
-	struct ax_device *ax = container_of(ctrl, struct ax_device, bb_ctrl);
-
-	if (output)
-		ax->reg_memr &= ~AX_MEMR_MDIR;
-	else
-		ax->reg_memr |= AX_MEMR_MDIR;
-
-	ei_outb(ax->reg_memr, ax->addr_memr);
-}
-
-static void ax_bb_set_data(struct mdiobb_ctrl *ctrl, int value)
-{
-	struct ax_device *ax = container_of(ctrl, struct ax_device, bb_ctrl);
-
-	if (value)
-		ax->reg_memr |= AX_MEMR_MDO;
-	else
-		ax->reg_memr &= ~AX_MEMR_MDO;
-
-	ei_outb(ax->reg_memr, ax->addr_memr);
-}
-
-static int ax_bb_get_data(struct mdiobb_ctrl *ctrl)
-{
-	struct ax_device *ax = container_of(ctrl, struct ax_device, bb_ctrl);
-	int reg_memr = ei_inb(ax->addr_memr);
-
-	return reg_memr & AX_MEMR_MDI ? 1 : 0;
-}
-
-static const struct mdiobb_ops bb_ops = {
-	.owner = THIS_MODULE,
-	.set_mdc = ax_bb_mdc,
-	.set_mdio_dir = ax_bb_dir,
-	.set_mdio_data = ax_bb_set_data,
-	.get_mdio_data = ax_bb_get_data,
-};
-
 /* setup code */
 
-static int ax_mii_init(struct net_device *dev)
-{
-	struct platform_device *pdev = to_platform_device(dev->dev.parent);
-	struct ei_device *ei_local = netdev_priv(dev);
-	struct ax_device *ax = to_ax_dev(dev);
-	int err;
-
-	ax->bb_ctrl.ops = &bb_ops;
-	ax->addr_memr = ei_local->mem + AX_MEMR;
-	ax->mii_bus = alloc_mdio_bitbang(&ax->bb_ctrl);
-	if (!ax->mii_bus) {
-		err = -ENOMEM;
-		goto out;
-	}
-
-	ax->mii_bus->name = "ax88796_mii_bus";
-	ax->mii_bus->parent = dev->dev.parent;
-	snprintf(ax->mii_bus->id, MII_BUS_ID_SIZE, "%s-%x",
-		pdev->name, pdev->id);
-
-	err = mdiobus_register(ax->mii_bus);
-	if (err)
-		goto out_free_mdio_bitbang;
-
-	return 0;
-
- out_free_mdio_bitbang:
-	free_mdio_bitbang(ax->mii_bus);
- out:
-	return err;
-}
-
 static void ax_initial_setup(struct net_device *dev, struct ei_device *ei_local)
 {
 	void __iomem *ioaddr = ei_local->mem;
@@ -758,10 +769,6 @@ static int ax_init_dev(struct net_device *dev)
 	dev->netdev_ops = &ax_netdev_ops;
 	dev->ethtool_ops = &ax_ethtool_ops;
 
-	ret = ax_mii_init(dev);
-	if (ret)
-		goto err_out;
-
 	ax_NS8390_init(dev, 0);
 
 	ret = register_netdev(dev);
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 4/8] net: ax88796: Add block_input/output hooks to ax_plat_data
From: Michael Schmitz @ 2018-04-17  2:08 UTC (permalink / raw)
  To: netdev
  Cc: andrew, linux-m68k, Michael.Karcher, Michael Schmitz,
	Michael Karcher
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>

Add platform specific hooks for block transfer reads/writes of packet
buffer data, superseding the default provided ax_block_input/output.
Currently used for m68k Amiga XSurf100.

Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
 drivers/net/ethernet/8390/ax88796.c |   10 ++++++++--
 include/net/ax88796.h               |    9 ++++++++-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index ecf104c..29cde38 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -760,8 +760,14 @@ static int ax_init_dev(struct net_device *dev)
 #endif
 
 	ei_local->reset_8390 = &ax_reset_8390;
-	ei_local->block_input = &ax_block_input;
-	ei_local->block_output = &ax_block_output;
+	if (ax->plat->block_input)
+		ei_local->block_input = ax->plat->block_input;
+	else
+		ei_local->block_input = &ax_block_input;
+	if (ax->plat->block_output)
+		ei_local->block_output = ax->plat->block_output;
+	else
+		ei_local->block_output = &ax_block_output;
 	ei_local->get_8390_hdr = &ax_get_8390_hdr;
 	ei_local->priv = 0;
 	ei_local->msg_enable = ax_msg_enable;
diff --git a/include/net/ax88796.h b/include/net/ax88796.h
index b9a3bec..26cc459 100644
--- a/include/net/ax88796.h
+++ b/include/net/ax88796.h
@@ -8,10 +8,11 @@
  * published by the Free Software Foundation.
  *
 */
-
 #ifndef __NET_AX88796_PLAT_H
 #define __NET_AX88796_PLAT_H
 
+struct net_device;
+
 #define AXFLG_HAS_EEPROM		(1<<0)
 #define AXFLG_MAC_FROMDEV		(1<<1)	/* device already has MAC */
 #define AXFLG_HAS_93CX6			(1<<2)	/* use eeprom_93cx6 driver */
@@ -26,6 +27,12 @@ struct ax_plat_data {
 	u32		*reg_offsets;	/* register offsets */
 	u8		*mac_addr;	/* MAC addr (only used when
 					   AXFLG_MAC_FROMPLATFORM is used */
+
+	/* uses default ax88796 buffer if set to NULL */
+	void (*block_output)(struct net_device *dev, int count,
+			const unsigned char *buf, int star_page);
+	void (*block_input)(struct net_device *dev, int count,
+			struct sk_buff *skb, int ring_offset);
 };
 
 #endif /* __NET_AX88796_PLAT_H */
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 1/8] net: ax88796: Fix MAC address reading
From: Michael Schmitz @ 2018-04-17  2:08 UTC (permalink / raw)
  To: netdev
  Cc: andrew, linux-m68k, Michael.Karcher, Michael Karcher,
	Michael Karcher, Michael Schmitz
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>

From: Michael Karcher <debian@mkarcher.dialup.fu-berlin.de>

To read the MAC address from the (virtual) SAprom, the remote DMA
unit needs to be set up like for every other process access to card-local
memory.

Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
 drivers/net/ethernet/8390/ax88796.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index 2455547..2a256aa 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -671,10 +671,16 @@ static int ax_init_dev(struct net_device *dev)
 	if (ax->plat->flags & AXFLG_HAS_EEPROM) {
 		unsigned char SA_prom[32];
 
+		ei_outb(6, ioaddr + EN0_RCNTLO);
+		ei_outb(0, ioaddr + EN0_RCNTHI);
+		ei_outb(0, ioaddr + EN0_RSARLO);
+		ei_outb(0, ioaddr + EN0_RSARHI);
+		ei_outb(E8390_RREAD + E8390_START, ioaddr + NE_CMD);
 		for (i = 0; i < sizeof(SA_prom); i += 2) {
 			SA_prom[i] = ei_inb(ioaddr + NE_DATAPORT);
 			SA_prom[i + 1] = ei_inb(ioaddr + NE_DATAPORT);
 		}
+		ei_outb(ENISR_RDC, ioaddr + EN0_ISR);	/* Ack intr. */
 
 		if (ax->plat->wordlength == 2)
 			for (i = 0; i < 16; i++)
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 5/8] net: ax88796: add interrupt status callback to platform data
From: Michael Schmitz @ 2018-04-17  2:08 UTC (permalink / raw)
  To: netdev
  Cc: andrew, linux-m68k, Michael.Karcher, Michael Schmitz,
	Michael Karcher
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>

To be able to tell the ax88796 driver whether it is sensible to enter
the 8390 interrupt handler, an "is this interrupt caused by the 88796"
callback has been added to the ax_plat_data structure (with NULL being
compatible to the previous behaviour).

Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
 drivers/net/ethernet/8390/ax88796.c |   23 +++++++++++++++++++++--
 include/net/ax88796.h               |    5 +++++
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index 29cde38..c799441 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -165,6 +165,21 @@ static void ax_reset_8390(struct net_device *dev)
 	ei_outb(ENISR_RESET, addr + EN0_ISR);	/* Ack intr. */
 }
 
+/* Wrapper for __ei_interrupt for platforms that have a platform-specific
+ * way to find out whether the interrupt request might be caused by
+ * the ax88796 chip.
+ */
+static irqreturn_t ax_ei_interrupt_filtered(int irq, void *dev_id)
+{
+	struct net_device *dev = dev_id;
+	struct ax_device *ax = to_ax_dev(dev);
+	struct platform_device *pdev = to_platform_device(dev->dev.parent);
+
+	if (!ax->plat->check_irq(pdev))
+		return IRQ_NONE;
+
+	return ax_ei_interrupt(irq, dev_id);
+}
 
 static void ax_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr,
 			    int ring_page)
@@ -484,8 +499,12 @@ static int ax_open(struct net_device *dev)
 	if (ret)
 		goto failed_mii;
 
-	ret = request_irq(dev->irq, ax_ei_interrupt, ax->irqflags,
-			  dev->name, dev);
+	if (ax->plat->check_irq)
+		ret = request_irq(dev->irq, ax_ei_interrupt_filtered,
+				  ax->irqflags, dev->name, dev);
+	else
+		ret = request_irq(dev->irq, ax_ei_interrupt, ax->irqflags,
+				  dev->name, dev);
 	if (ret)
 		goto failed_request_irq;
 
diff --git a/include/net/ax88796.h b/include/net/ax88796.h
index 26cc459..26412cd 100644
--- a/include/net/ax88796.h
+++ b/include/net/ax88796.h
@@ -12,6 +12,7 @@
 #define __NET_AX88796_PLAT_H
 
 struct net_device;
+struct platform_device;
 
 #define AXFLG_HAS_EEPROM		(1<<0)
 #define AXFLG_MAC_FROMDEV		(1<<1)	/* device already has MAC */
@@ -33,6 +34,10 @@ struct ax_plat_data {
 			const unsigned char *buf, int star_page);
 	void (*block_input)(struct net_device *dev, int count,
 			struct sk_buff *skb, int ring_offset);
+	/* returns nonzero if a pending interrupt request might by caused by
+	 * the ax88786. Handles all interrupts if set to NULL
+	 */
+	int (*check_irq)(struct platform_device *pdev);
 };
 
 #endif /* __NET_AX88796_PLAT_H */
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 7/8] net: ax88796: release platform device drvdata on probe error and module remove
From: Michael Schmitz @ 2018-04-17  2:08 UTC (permalink / raw)
  To: netdev; +Cc: andrew, linux-m68k, Michael.Karcher, Michael Schmitz
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>

The net device struct pointer is stored as platform device drvdata on
module probe - clear the drvdata entry on probe fail there, as well as
when unloading the module.

Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
 drivers/net/ethernet/8390/ax88796.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index a72dfbc..eb72282 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -829,6 +829,7 @@ static int ax_remove(struct platform_device *pdev)
 		release_mem_region(mem->start, resource_size(mem));
 	}
 
+	platform_set_drvdata(pdev, NULL);
 	free_netdev(dev);
 
 	return 0;
@@ -962,6 +963,7 @@ static int ax_probe(struct platform_device *pdev)
 	release_mem_region(mem->start, mem_size);
 
  exit_mem:
+	platform_set_drvdata(pdev, NULL);
 	free_netdev(dev);
 
 	return ret;
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 6/8] net: ax88796: set IRQF_SHARED flag when IRQ resource is marked as shareable
From: Michael Schmitz @ 2018-04-17  2:08 UTC (permalink / raw)
  To: netdev
  Cc: andrew, linux-m68k, Michael.Karcher, John Paul Adrian Glaubitz,
	Michael Karcher, Michael Schmitz
In-Reply-To: <1523916285-6057-1-git-send-email-schmitzmic@gmail.com>

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

On the Amiga X-Surf100, the network card interrupt is shared with many
other interrupt sources, so requires the IRQF_SHARED flag to register.

Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
 drivers/net/ethernet/8390/ax88796.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index c799441..a72dfbc 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -875,6 +875,9 @@ static int ax_probe(struct platform_device *pdev)
 	dev->irq = irq->start;
 	ax->irqflags = irq->flags & IRQF_TRIGGER_MASK;
 
+	if (irq->flags &  IORESOURCE_IRQ_SHAREABLE)
+		ax->irqflags |= IRQF_SHARED;
+
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!mem) {
 		dev_err(&pdev->dev, "no MEM specified\n");
-- 
1.7.0.4

^ 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