All of lore.kernel.org
 help / color / mirror / Atom feed
From: netdev@kapio-technology.com
To: Vladimir Oltean <olteanv@gmail.com>
Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
	Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 net-next 2/2] net: dsa: mv88e6xxx: mac-auth/MAB implementation
Date: Fri, 02 Dec 2022 12:06:17 +0100	[thread overview]
Message-ID: <343cbf3d367e2a2d4e3ce09487f43615@kapio-technology.com> (raw)
In-Reply-To: <20221120150018.qupfa3flq6hoapgj@skbuf>

On 2022-11-20 16:00, Vladimir Oltean wrote:
> On Sun, Nov 20, 2022 at 11:21:08AM +0100, netdev@kapio-technology.com 
> wrote:
>> I have something like this, using 'mvls vtu' from
>> https://github.com/wkz/mdio-tools:
>>  VID   FID  SID  P  Q  F  0  1  2  3  4  5  6  7  8  9  a
>>    0     0    0  y  -  -  =  =  =  =  =  =  =  =  =  =  =
>>    1     2    0  -  -  -  u  u  u  u  u  u  u  u  u  u  =
>> 4095     1    0  -  -  -  =  =  =  =  =  =  =  =  =  =  =
>> 
>> as a vtu table. I don't remember exactly the consequences, but I am 
>> quite
>> sure that fid=0 gave
>> incorrect handling, but there might be something that I have missed as 
>> to
>> other setups.
> 
> Can you please find out? There needs to be an answer as to why 
> something
> which shouldn't happen happens.

Hi Vladimir,
I haven't been able to reproduce the situation with fid=0, and it may be 
superfluous to check if fid has a non-zero value as the case of fid=0 in 
the miss violation handling is not valid on a bridged port, where I 
understand from consultation that the case fid=0 corresponds to a 
non-bridged port.

What I experienced then might have been from some previous bug at a 
time, but I don't know.

Should I remove the check or not?

  reply	other threads:[~2022-12-02 11:06 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-12 20:37 [PATCH v8 net-next 0/2] mv88e6xxx: Add MAB offload support Hans J. Schultz
2022-11-12 20:37 ` [PATCH v8 net-next 1/2] net: dsa: mv88e6xxx: allow reading FID when handling ATU violations Hans J. Schultz
2022-11-12 20:37 ` [PATCH v8 net-next 2/2] net: dsa: mv88e6xxx: mac-auth/MAB implementation Hans J. Schultz
2022-11-15  9:58   ` Ido Schimmel
2022-11-15 10:36     ` netdev
2022-11-15 15:12       ` Ido Schimmel
2022-11-15 15:24         ` netdev
2022-11-15 22:23   ` Vladimir Oltean
2022-11-20  9:33     ` netdev
2022-11-20  9:54     ` netdev
2022-11-20 10:21     ` netdev
2022-11-20 15:00       ` Vladimir Oltean
2022-12-02 11:06         ` netdev [this message]
2022-12-04 15:08         ` netdev
2022-12-04 13:26     ` netdev
2022-11-15  2:57 ` [PATCH v8 net-next 0/2] mv88e6xxx: Add MAB offload support Jakub Kicinski
2022-11-15  5:18   ` Jakub Kicinski
2022-11-15  9:30 ` Ido Schimmel
2022-11-15 10:26   ` netdev
2022-11-15 10:28     ` Vladimir Oltean
2022-11-15 10:52       ` netdev
2022-11-15 11:10         ` Vladimir Oltean
2022-11-15 11:31           ` netdev
2022-11-15 12:22             ` Vladimir Oltean
2022-11-15 12:40               ` netdev
2022-11-15 13:25               ` netdev
2022-11-15 14:56                 ` Vladimir Oltean
2022-11-15 15:14                   ` netdev
2022-11-15 16:15                     ` Vladimir Oltean
2022-11-15 17:11                       ` netdev
2022-11-15 17:15                         ` Vladimir Oltean
2022-11-15 16:03                   ` netdev
2022-11-15 16:18                     ` Vladimir Oltean
2022-11-15 18:40                       ` netdev
2022-11-16 10:24                         ` Vladimir Oltean
2022-11-16 13:37                           ` Andrew Lunn
2022-11-18 13:37                           ` netdev
2022-11-18 13:51                             ` Andrew Lunn
2022-11-15 13:21             ` Andrew Lunn
2022-11-15 14:18               ` netdev

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=343cbf3d367e2a2d4e3ce09487f43615@kapio-technology.com \
    --to=netdev@kapio-technology.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.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.