All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Vivien Didelot <vivien.didelot@gmail.com>,
	Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: "Andrew Lunn" <andrew@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Marek Behún" <marek.behun@nic.cz>,
	"Russell King" <rmk+kernel@armlinux.org.uk>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Chris Healy" <cphealy@gmail.com>
Subject: Re: [PATCH] net: dsa: mv88e6xxx: avoid error message on remove from VLAN 0
Date: Fri, 31 May 2019 09:44:04 -0700	[thread overview]
Message-ID: <8d5070ac-1f31-cff0-5a5b-2134c7894b3f@gmail.com> (raw)
In-Reply-To: <20190531103105.GE23464@t480s.localdomain>

On 5/31/19 7:31 AM, Vivien Didelot wrote:
> Hi Nikita,
> 
> On Fri, 31 May 2019 10:35:14 +0300, Nikita Yushchenko <nikita.yoush@cogentembedded.com> wrote:
>> When non-bridged, non-vlan'ed mv88e6xxx port is moving down, error
>> message is logged:
>>
>> failed to kill vid 0081/0 for device eth_cu_1000_4
>>
>> This is caused by call from __vlan_vid_del() with vin set to zero, over
>> call chain this results into _mv88e6xxx_port_vlan_del() called with
>> vid=0, and mv88e6xxx_vtu_get() called from there returns -EINVAL.
>>
>> On symmetric path moving port up, call goes through
>> mv88e6xxx_port_vlan_prepare() that calls mv88e6xxx_port_check_hw_vlan()
>> that returns -EOPNOTSUPP for zero vid.
>>
>> This patch changes mv88e6xxx_vtu_get() to also return -EOPNOTSUPP for
>> zero vid, then this error code is explicitly cleared in
>> dsa_slave_vlan_rx_kill_vid() and error message is no longer logged.
>>
>> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
>> ---
>>  drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>> index 28414db979b0..6b77fde5f0e4 100644
>> --- a/drivers/net/dsa/mv88e6xxx/chip.c
>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
>> @@ -1392,7 +1392,7 @@ static int mv88e6xxx_vtu_get(struct mv88e6xxx_chip *chip, u16 vid,
>>  	int err;
>>  
>>  	if (!vid)
>> -		return -EINVAL;
>> +		return -EOPNOTSUPP;
>>  
>>  	entry->vid = vid - 1;
>>  	entry->valid = false;
> 
> I'm not sure that I like the semantic of it, because the driver can actually
> support VID 0 per-se, only the kernel does not use VLAN 0. Thus I would avoid
> calling the port_vlan_del() ops for VID 0, directly into the upper DSA layer.
> 
> Florian, Andrew, wouldn't the following patch be more adequate?

See my comment about the usage of VLAN ID == 0 with non mv88e6xxx
switches this would break VLAN filtering/isolation for non bridged port.

> 
>     diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>     index 1e2ae9d59b88..80f228258a92 100644
>     --- a/net/dsa/slave.c
>     +++ b/net/dsa/slave.c
>     @@ -1063,6 +1063,10 @@ static int dsa_slave_vlan_rx_kill_vid(struct net_device *dev, __be16 proto,
>             struct bridge_vlan_info info;
>             int ret;
>      
>     +       /* VID 0 has a special meaning and is never programmed in hardware */
>     +       if (!vid)
>     +               return 0;
>     +
>             /* Check for a possible bridge VLAN entry now since there is no
>              * need to emulate the switchdev prepare + commit phase.
>              */
> 
> 
> Thanks,
> Vivien
> 


-- 
Florian

  parent reply	other threads:[~2019-05-31 16:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31  7:35 [PATCH] net: dsa: mv88e6xxx: avoid error message on remove from VLAN 0 Nikita Yushchenko
2019-05-31 14:31 ` Vivien Didelot
2019-05-31 14:37   ` Andrew Lunn
2019-05-31 14:46     ` Nikita Yushchenko
2019-05-31 15:00       ` Vivien Didelot
2019-05-31 15:02         ` Nikita Yushchenko
2019-05-31 16:36         ` Florian Fainelli
2019-05-31 18:19           ` Vivien Didelot
2019-05-31 19:33             ` Florian Fainelli
2019-05-31 16:34     ` Florian Fainelli
2019-05-31 20:14       ` Vivien Didelot
2019-05-31 16:44   ` Florian Fainelli [this message]
2019-05-31 20:15 ` Vivien Didelot
2019-06-02 20:54 ` David Miller
  -- strict thread matches above, loose matches on Subject: below --
2019-05-31  7:27 Nikita Yushchenko

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=8d5070ac-1f31-cff0-5a5b-2134c7894b3f@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=cphealy@gmail.com \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marek.behun@nic.cz \
    --cc=netdev@vger.kernel.org \
    --cc=nikita.yoush@cogentembedded.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.