netdev - Re: [PATCH v2 net-next 2/4] net: dsa: mv88e6xxx: read FID when handling ATU violations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5e2c5dd0-4785-fa9f-205a-8dcf543e27ae@gmail.com>
Date:   Fri, 9 Dec 2022 16:05:54 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org
Cc:     Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "Hans J. Schultz" <netdev@...io-technology.com>,
        Saeed Mahameed <saeed@...nel.org>
Subject: Re: [PATCH v2 net-next 2/4] net: dsa: mv88e6xxx: read FID when
 handling ATU violations

On 12/9/22 09:28, Vladimir Oltean wrote:
> From: "Hans J. Schultz" <netdev@...io-technology.com>
> 
> When an ATU violation occurs, the switch uses the ATU FID register to
> report the FID of the MAC address that incurred the violation. It would
> be good for the driver to know the FID value for purposes such as
> logging and CPU-based authentication.
> 
> Up until now, the driver has been calling the mv88e6xxx_g1_atu_op()
> function to read ATU violations, but that doesn't do exactly what we
> want, namely it calls mv88e6xxx_g1_atu_fid_write() with FID 0.
> (side note, the documentation for the ATU Get/Clear Violation command
> says that writes to the ATU FID register have no effect before the
> operation starts, it's only that we disregard the value that this
> register provides once the operation completes)
> 
> So mv88e6xxx_g1_atu_fid_write() is not what we want, but rather
> mv88e6xxx_g1_atu_fid_read(). However, the latter doesn't exist, we need
> to write it.
> 
> The remainder of mv88e6xxx_g1_atu_op() except for
> mv88e6xxx_g1_atu_fid_write() is still needed, namely to send a
> GET_CLR_VIOLATION command to the ATU. In principle we could have still
> kept calling mv88e6xxx_g1_atu_op(), but the MDIO writes to the ATU FID
> register are pointless, but in the interest of doing less CPU work per
> interrupt, write a new function called mv88e6xxx_g1_read_atu_violation()
> and call it.
> 
> The FID will be the port default FID as set by mv88e6xxx_port_set_fid()
> if the VID from the packet cannot be found in the VTU. Otherwise it is
> the FID derived from the VTU entry associated with that VID.
> 
> Signed-off-by: Hans J. Schultz <netdev@...io-technology.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
-- 
Florian