netdev - Re: [PATCH net-next v2] net: dsa: mv88e6xxx: check for mode change in port_setup

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190814144821.GQ15047@lunn.ch>
Date:   Wed, 14 Aug 2019 16:48:21 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Marek Behún <marek.behun@....cz>
Cc:     netdev@...r.kernel.org, Vivien Didelot <vivien.didelot@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH net-next v2] net: dsa: mv88e6xxx: check for mode change
 in port_setup_mac

On Wed, Aug 14, 2019 at 04:40:24PM +0200, Marek Behún wrote:
> The mv88e6xxx_port_setup_mac checks if the requested MAC settings are
> different from the current ones, and if not, does nothing (since chaning
> them requires putting the link down).
> 
> In this check it only looks if the triplet [link, speed, duplex] is
> being changed.
> 
> This patch adds support to also check if the mode parameter (of type
> phy_interface_t) is requested to be changed. The current mode is
> computed by the ->port_link_state() method, and if it is different from
> PHY_INTERFACE_MODE_NA, we check for equality with the requested mode.
> 
> In the implementations of the mv88e6250_port_link_state() method we set
> the current mode to PHY_INTERFACE_MODE_NA - so the code does not check
> for mode change on 6250.
> 
> In the mv88e6352_port_link_state() method, we use the cached cmode of
> the port to determine the mode as phy_interface_t (and if it is not
> enough, eg. for RGMII, we also look at the port control register for
> RX/TX timings).
> 
> Signed-off-by: Marek Behún <marek.behun@....cz>

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew