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]
Date:   Fri, 15 Jul 2022 20:24:44 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Alvin __ipraga <alsi@...g-olufsen.dk>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Daniel Scally <djrscally@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        DENG Qingfang <dqfext@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        George McCollister <george.mccollister@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Matthias Brugger <matthias.bgg@...il.com>,
        netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Sean Wang <sean.wang@...iatek.com>,
        UNGLinuxDriver@...rochip.com,
        Vivien Didelot <vivien.didelot@...il.com>,
        Woojung Huh <woojung.huh@...rochip.com>,
        Marek BehĂșn <kabel@...nel.org>
Subject: Re: [PATCH net-next 3/6] net: dsa: add support for retrieving the
 interface mode

On Fri, Jul 15, 2022 at 05:01:37PM +0100, Russell King (Oracle) wrote:
> DSA port bindings allow for an optional phy interface mode. When an
> interface mode is not specified, DSA uses the NA interface mode type.
> 
> However, phylink needs to know the parameters of the link, and this
> will become especially important when using phylink for ports that
> are devoid of all properties except the required "reg" property, so
> that phylink can select the maximum supported link settings. Without
> knowing the interface mode, phylink can't truely know the maximum
> link speed.
> 
> Update the prototype for the phylink_get_caps method to allow drivers
> to report this information back to DSA, and update all DSA
> implementations function declarations to cater for this change. No
> code is added to the implementations.
> 
> Reviewed-by: Marek BehĂșn <kabel@...nel.org>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> ---
(...)
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index b902b31bebce..7c6870d2c607 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -852,7 +852,8 @@ struct dsa_switch_ops {
>  	 * PHYLINK integration
>  	 */
>  	void	(*phylink_get_caps)(struct dsa_switch *ds, int port,
> -				    struct phylink_config *config);
> +				    struct phylink_config *config,
> +				    phy_interface_t *default_interface);

I would prefer having a dedicated void (*port_max_speed_interface),
because the post-phylink DSA drivers (which are not few) will generally
not need to concern themselves with implementing this, and I don't want
driver writers to think they need to populate every parameter they see
in phylink_get_caps. So the new function needs to be documented
appropriately (specify who needs and who does not need to implement it,
on which ports it will be called, etc).

In addition, if we have a dedicated ds->ops->port_max_speed_interface(),
we can do a better job of avoiding breakage with this patch set, since
if DSA cannot find a valid phylink fwnode, AND there is no
port_max_speed_interface() callback for this driver, DSA can still
preserve the current logic of not putting the port down, and not
registering it with phylink. That can be accompanied by a dev_warn() to
state that the CPU/DSA port isn't registered with phylink, please
implement port_max_speed_interface() to address that.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ