netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
	davem@davemloft.net, netdev@vger.kernel.org
Cc: andrew@lunn.ch, vivien.didelot@gmail.com, linus.walleij@linaro.org
Subject: Re: [RFC PATCH net-next 03/13] net: dsa: Create a more convenient function for installing port VLANs
Date: Wed, 27 Mar 2019 02:31:48 +0200	[thread overview]
Message-ID: <32bbb7cd-bc0e-0669-312d-99cdc845604b@gmail.com> (raw)
In-Reply-To: <49500e18-f2d5-4c9f-2ce0-b6fa12cbc8d6@gmail.com>

On 3/25/19 7:06 PM, Florian Fainelli wrote:
> On 3/23/19 8:23 PM, Vladimir Oltean wrote:
>> This refactors the two-phase transaction from dsa_slave_vlan_rx_add_vid
>> and also makes that code available for other functions from within DSA.
>> The newly exposed function either adds or deletes the specified VLAN
>> entry based on a boolean argument.
>>
>> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> 
> The name of the function does not make it particularly clear that
> passing false results in deleting the VLAN. Can you just wrap this under
> a different function name that is only doing the two-step adding of
> VLANs and keep using dsa_port_vlan_del() explicitly when you want to
> remove a VLAN?
> 

The reason why I made it this way was mainly to make the 
switchdev_obj_port_vlan struct an implementation detail. That being so I 
wouldn't need to keep and continuously modify this struct during the 3 
times I'm calling the function from within the 05/13 patch ("net: dsa: 
Optional VLAN-based port separation for switches without tagging"). I 
did try to make use of the .vid_begin/.vid_end feature and batch some of 
the function calls, but doing so would restrict possible values that the 
rx_vid and tx_vid functions may return - dsa_port_setup_8021q_tagging() 
would need to ensure that they are contiguous prior to batching them 
into a single vlan object. By the way, I don't think anybody is making 
any good use of this feature, it's just creating useless boilerplate as 
of now.
The other thing is that if I were to wrap around dsa_port_vlan_add() and 
get rid of the switchdev_obj_port_vlan and just pass the vid as u16, I'd 
have to do the same wrapping for the dsa_port_vlan_del() function too. 
Plus I'd have to keep 3 'if' conditions just to decide whether to call 
*_add or *_del.

> diff --git a/net/dsa/tag_8021q.c b/net/dsa/tag_8021q.c
> index 221299b264f5..1b11b245e2d6 100644
> --- a/net/dsa/tag_8021q.c
> +++ b/net/dsa/tag_8021q.c
> @@ -120,8 +120,10 @@ int dsa_port_setup_8021q_tagging(struct dsa_switch *ds, int port, bool enabled)
>  			/* The Rx VID is a regular VLAN on all others */
>  			flags = BRIDGE_VLAN_INFO_UNTAGGED;
>  
> -		err = dsa_port_trans_vlan_apply(other_dp, rx_vid, flags,
> -						enabled);
> +		if (enabled)
> +			err = __dsa_port_vlan_add(other_dp, rx_vid, flags);
> +		else
> +			err = __dsa_port_vlan_del(other_dp, rx_vid);
>  		if (err) {
>  			dev_err(ds->dev, "Failed to apply Rx VID %d to port %d: %d\n",
>  				rx_vid, port, err);
> @@ -129,14 +131,20 @@ int dsa_port_setup_8021q_tagging(struct dsa_switch *ds, int port, bool enabled)
>  		}
>  	}
>  	/* Finally apply the Tx VID on this port and on the CPU port */
> -	err = dsa_port_trans_vlan_apply(dp, tx_vid, BRIDGE_VLAN_INFO_UNTAGGED,
> -					enabled);
> +	if (enabled)
> +		err = __dsa_port_vlan_add(dp, tx_vid,
> +					  BRIDGE_VLAN_INFO_UNTAGGED);
> +	else
> +		err = __dsa_port_vlan_del(dp, tx_vid);
>  	if (err) {
>  		dev_err(ds->dev, "Failed to apply Tx VID %d on port %d: %d\n",
>  			tx_vid, port, err);
>  		return err;
>  	}
> -	err = dsa_port_trans_vlan_apply(upstream_dp, tx_vid, 0, enabled);
> +	if (enabled)
> +		err = __dsa_port_vlan_add(upstream_dp, tx_vid, 0);
> +	else
> +		err = __dsa_port_vlan_del(upstream_dp, tx_vid);
>  	if (err) {
>  		dev_err(ds->dev, "Failed to apply Tx VID %d on port %d: %d\n",
>  			tx_vid, upstream, err);

How does something like the above look like?

Thanks,
-Vladimir

>> ---
>>   net/dsa/dsa_priv.h |  2 ++
>>   net/dsa/port.c     | 24 ++++++++++++++++++++++++
>>   net/dsa/slave.c    | 16 ++--------------
>>   3 files changed, 28 insertions(+), 14 deletions(-)
>>
>> diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
>> index 093b7d145eb1..8048ced3708f 100644
>> --- a/net/dsa/dsa_priv.h
>> +++ b/net/dsa/dsa_priv.h
>> @@ -164,6 +164,8 @@ int dsa_port_pre_bridge_flags(const struct dsa_port *dp, unsigned long flags,
>>   			      struct switchdev_trans *trans);
>>   int dsa_port_bridge_flags(const struct dsa_port *dp, unsigned long flags,
>>   			  struct switchdev_trans *trans);
>> +int dsa_port_trans_vlan_apply(struct dsa_port *dp, u16 vid, u16 flags,
>> +			      bool enabled);
>>   int dsa_port_vlan_add(struct dsa_port *dp,
>>   		      const struct switchdev_obj_port_vlan *vlan,
>>   		      struct switchdev_trans *trans);
>> diff --git a/net/dsa/port.c b/net/dsa/port.c
>> index a86fe3be1261..9c7358f98004 100644
>> --- a/net/dsa/port.c
>> +++ b/net/dsa/port.c
>> @@ -326,6 +326,30 @@ int dsa_port_vlan_del(struct dsa_port *dp,
>>   	return 0;
>>   }
>>   
>> +int dsa_port_trans_vlan_apply(struct dsa_port *dp, u16 vid, u16 flags,
>> +			      bool enabled)
>> +{
>> +	struct switchdev_obj_port_vlan vlan = {
>> +		.obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
>> +		.flags = flags,
>> +		.vid_begin = vid,
>> +		.vid_end = vid,
>> +	};
>> +	struct switchdev_trans trans;
>> +	int err;
>> +
>> +	if (!enabled)
>> +		return dsa_port_vlan_del(dp, &vlan);
>> +
>> +	trans.ph_prepare = true;
>> +	err = dsa_port_vlan_add(dp, &vlan, &trans);
>> +	if (err == -EOPNOTSUPP)
>> +		return 0;
>> +
>> +	trans.ph_prepare = false;
>> +	return dsa_port_vlan_add(dp, &vlan, &trans);
>> +}
>> +
>>   static struct phy_device *dsa_port_get_phy_device(struct dsa_port *dp)
>>   {
>>   	struct device_node *phy_dn;
>> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>> index 093eef6f2599..3191ef74f6a1 100644
>> --- a/net/dsa/slave.c
>> +++ b/net/dsa/slave.c
>> @@ -987,13 +987,6 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
>>   				     u16 vid)
>>   {
>>   	struct dsa_port *dp = dsa_slave_to_port(dev);
>> -	struct switchdev_obj_port_vlan vlan = {
>> -		.vid_begin = vid,
>> -		.vid_end = vid,
>> -		/* This API only allows programming tagged, non-PVID VIDs */
>> -		.flags = 0,
>> -	};
>> -	struct switchdev_trans trans;
>>   	struct bridge_vlan_info info;
>>   	int ret;
>>   
>> @@ -1010,13 +1003,8 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
>>   			return -EBUSY;
>>   	}
>>   
>> -	trans.ph_prepare = true;
>> -	ret = dsa_port_vlan_add(dp, &vlan, &trans);
>> -	if (ret == -EOPNOTSUPP)
>> -		return 0;
>> -
>> -	trans.ph_prepare = false;
>> -	return dsa_port_vlan_add(dp, &vlan, &trans);
>> +	/* This API only allows programming tagged, non-PVID VIDs */
>> +	return dsa_port_trans_vlan_apply(dp, vid, 0, true);
>>   }
>>   
>>   static int dsa_slave_vlan_rx_kill_vid(struct net_device *dev, __be16 proto,
>>
> 
> 


  reply	other threads:[~2019-03-27  0:31 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-24  3:23 [RFC PATCH net-next 00/13] NXP SJA1105 DSA driver Vladimir Oltean
2019-03-24  3:23 ` [RFC PATCH net-next 01/13] lib: Add support for generic packing operations Vladimir Oltean
2019-03-24 19:02   ` Richard Cochran
2019-03-24 20:32     ` Vladimir Oltean
2019-03-26  4:13       ` Richard Cochran
2019-03-24  3:23 ` [RFC PATCH net-next 02/13] net: dsa: Store vlan_filtering as a property of dsa_port Vladimir Oltean
2019-03-24 20:34   ` Andrew Lunn
2019-03-25 16:46   ` Florian Fainelli
2019-03-24  3:23 ` [RFC PATCH net-next 03/13] net: dsa: Create a more convenient function for installing port VLANs Vladimir Oltean
2019-03-25 17:06   ` Florian Fainelli
2019-03-27  0:31     ` Vladimir Oltean [this message]
2019-03-24  3:23 ` [RFC PATCH net-next 04/13] net: dsa: Call driver's setup callback after setting up its switchdev notifier Vladimir Oltean
2019-03-25 16:47   ` Florian Fainelli
2019-03-24  3:23 ` [RFC PATCH net-next 05/13] net: dsa: Optional VLAN-based port separation for switches without tagging Vladimir Oltean
2019-03-26  2:21   ` Florian Fainelli
2019-03-24  3:23 ` [RFC PATCH net-next 06/13] net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch Vladimir Oltean
2019-03-26 13:02   ` Florian Fainelli
2019-03-26 17:52     ` Vladimir Oltean
2019-03-24  3:23 ` [RFC PATCH net-next 07/13] net: dsa: sja1105: Add support for FDB and MDB management Vladimir Oltean
2019-03-26  2:37   ` Florian Fainelli
2019-03-24  3:23 ` [RFC PATCH net-next 08/13] net: dsa: sja1105: Add support for VLAN operations Vladimir Oltean
2019-03-26  2:41   ` Florian Fainelli
2019-03-24  3:23 ` [RFC PATCH net-next 09/13] net: dsa: sja1105: Add support for ethtool port counters Vladimir Oltean
2019-03-26  2:44   ` Florian Fainelli
2019-03-24  3:23 ` [RFC PATCH net-next 10/13] net: dsa: sja1105: Add support for traffic through standalone ports Vladimir Oltean
2019-03-26  2:31   ` Florian Fainelli
2019-03-26 22:03     ` Vladimir Oltean
2019-03-26 22:13       ` Florian Fainelli
2019-03-26 22:38         ` Vladimir Oltean
2019-03-26 22:45           ` Florian Fainelli
2019-03-24  3:23 ` [RFC PATCH net-next 11/13] net: dsa: sja1105: Add support for Spanning Tree Protocol Vladimir Oltean
2019-03-24  3:23 ` [RFC PATCH net-next 12/13] Documentation: networking: dsa: Add details about NXP SJA1105 driver Vladimir Oltean
2019-03-26  2:34   ` Florian Fainelli
2019-03-24  3:23 ` [RFC PATCH net-next 13/13] dt-bindings: net: dsa: Add documentation for " Vladimir Oltean
2019-03-26  2:24   ` Florian Fainelli
2019-03-26 23:44     ` Vladimir Oltean
2019-03-25 16:31 ` [RFC PATCH net-next 00/13] NXP SJA1105 DSA driver Florian Fainelli
2019-03-26 17:30 ` Vinicius Costa Gomes
2019-03-26 18:07   ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32bbb7cd-bc0e-0669-312d-99cdc845604b@gmail.com \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).