[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fcb77cb3-e57d-4b66-bb55-63d3b1410e8f@lunn.ch>
Date: Tue, 21 Nov 2023 02:34:48 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Russell King <linux@...linux.org.uk>,
linux-arm-kernel@...ts.infradead.org,
Christophe Leroy <christophe.leroy@...roup.eu>,
Herve Codina <herve.codina@...tlin.com>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Vladimir Oltean <vladimir.oltean@....com>,
Köry Maincent <kory.maincent@...tlin.com>,
Jesse Brandeburg <jesse.brandeburg@...el.com>
Subject: Re: [RFC PATCH net-next v2 06/10] net: ethtool: Introduce a command
to list PHYs on an interface
> diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
> index 2540c70952ff..29ef675f45c0 100644
> --- a/Documentation/networking/ethtool-netlink.rst
> +++ b/Documentation/networking/ethtool-netlink.rst
> @@ -57,6 +57,7 @@ Structure of this header is
> ``ETHTOOL_A_HEADER_DEV_INDEX`` u32 device ifindex
> ``ETHTOOL_A_HEADER_DEV_NAME`` string device name
> ``ETHTOOL_A_HEADER_FLAGS`` u32 flags common for all requests
> + ``ETHTOOL_A_HEADER_PHY_INDEX`` u32 phy device index
> ============================== ====== =============================
>
> ``ETHTOOL_A_HEADER_DEV_INDEX`` and ``ETHTOOL_A_HEADER_DEV_NAME`` identify the
> @@ -81,6 +82,12 @@ the behaviour is backward compatible, i.e. requests from old clients not aware
> of the flag should be interpreted the way the client expects. A client must
> not set flags it does not understand.
>
> +``ETHTOOL_A_HEADER_PHY_INDEX`` identify the ethernet PHY the message relates to.
> +As there are numerous commands that are related to PHY configuration, and because
> +we can have more than one PHY on the link, the PHY index can be passed in the
> +request for the commands that needs it. It is however not mandatory, and if it
> +is not passed for commands that target a PHY, the net_device.phydev pointer
> +is used, as a fallback that keeps the legacy behaviour.
O.K, you did document it :-)
But i would make this part of the previous patch.
> +Kernel response contents:
> +
> + ================================= ====== ==========================
> + ``ETHTOOL_A_PHY_HEADER`` nested request header
> + ``ETHTOOL_A_PHY_INDEX`` u32 the phy's unique index, that can
> + be used for phy-specific requests
> + ``ETHTOOL_A_PHY_DRVNAME`` string the phy driver name
> + ``ETHTOOL_A_PHY_NAME`` string the phy device name
> + ``ETHTOOL_A_PHY_UPSTREAM_TYPE`` u32 the type of device this phy is
> + connected to
> + ``ETHTOOL_A_PHY_UPSTREAM_PHY`` nested if the phy is connected to another
> + phy, this nest contains info on
> + that connection
> + ``ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME`` string if the phy controls an sfp bus,
> + the name of the sfp bus
> + ``ETHTOOL_A_PHY_ID`` u32 the phy id if the phy is C22
Maybe a future extension. We could make phy_bus_match() set
phydev->phy_id to the ID it matched to the driver when doing C45. We
would then always have a value here.
> --- a/include/linux/ethtool_netlink.h
> +++ b/include/linux/ethtool_netlink.h
> @@ -118,5 +118,10 @@ static inline bool ethtool_dev_mm_supported(struct net_device *dev)
> return false;
> }
>
> +int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
> +{
> + return -EOPNOTSUPP;
> +}
This is a header file, so should probably be static inline.
Andrew
Powered by blists - more mailing lists