[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <503a066b-e2be-48ad-91d5-15ea9fd5bb62@gmail.com>
Date: Fri, 12 Apr 2024 13:35:25 +0200
From: Heiner Kallweit <hkallweit1@...il.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>, davem@...emloft.net
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
thomas.petazzoni@...tlin.com, Andrew Lunn <andrew@...n.ch>,
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>,
Vladimir Oltean <vladimir.oltean@....com>,
Köry Maincent <kory.maincent@...tlin.com>,
Jesse Brandeburg <jesse.brandeburg@...el.com>, Marek Behún
<kabel@...nel.org>, Piergiorgio Beruto <piergiorgio.beruto@...il.com>,
Oleksij Rempel <o.rempel@...gutronix.de>,
Nicolò Veronese <nicveronese@...il.com>,
Simon Horman <horms@...nel.org>, mwojtas@...omium.org,
Nathan Chancellor <nathan@...nel.org>
Subject: Re: [PATCH net-next] net: phy: phy_link_topology: Handle NULL
topologies
On 12.04.2024 12:46, Maxime Chevallier wrote:
> In situations where phylib is a module, the topology can be NULL as it's
> not initialized at netdev creation.
>
> Allow passing a NULL topology pointer to phy_link_topo helpers.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@...tlin.com>
> Closes: https://lore.kernel.org/netdev/2e11b89d-100f-49e7-9c9a-834cc0b82f97@gmail.com/
> Closes: https://lore.kernel.org/netdev/20240409201553.GA4124869@dev-arch.thelio-3990X/
> ---
>
> Hi,
>
> This patch fixes a commit that is in net-next, hence the net-next tag and the
> lack of "Fixes" tag.
>
> Nathan, Heiner, can you confirm this solves what you're seeing ?
>
> I think we can improve on this solution by moving the topology init at
> the first PHY insertion and clearing it at netdev destruction.
>
Not on every system the topology extension is needed, it may just create
overhead on such systems. Would it make sense to hide it behind a config symbol?
> Maxime
>
> drivers/net/phy/phy_link_topology.c | 10 +++++++++-
> include/linux/phy_link_topology.h | 7 ++++++-
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
> index 985941c5c558..0f3973f07fac 100644
> --- a/drivers/net/phy/phy_link_topology.c
> +++ b/drivers/net/phy/phy_link_topology.c
> @@ -42,6 +42,9 @@ int phy_link_topo_add_phy(struct phy_link_topology *topo,
> struct phy_device_node *pdn;
> int ret;
>
> + if (!topo)
> + return 0;
> +
This one I added as temporary workaround already, it fixes the issue for me.
> pdn = kzalloc(sizeof(*pdn), GFP_KERNEL);
> if (!pdn)
> return -ENOMEM;
> @@ -93,7 +96,12 @@ EXPORT_SYMBOL_GPL(phy_link_topo_add_phy);
> void phy_link_topo_del_phy(struct phy_link_topology *topo,
> struct phy_device *phy)
> {
> - struct phy_device_node *pdn = xa_erase(&topo->phys, phy->phyindex);
> + struct phy_device_node *pdn;
> +
> + if (!topo)
> + return;
> +
> + pdn = xa_erase(&topo->phys, phy->phyindex);
>
> /* We delete the PHY from the topology, however we don't re-set the
> * phy->phyindex field. If the PHY isn't gone, we can re-assign it the
> diff --git a/include/linux/phy_link_topology.h b/include/linux/phy_link_topology.h
> index 6b79feb607e7..21ca78127d0f 100644
> --- a/include/linux/phy_link_topology.h
> +++ b/include/linux/phy_link_topology.h
> @@ -40,7 +40,12 @@ struct phy_link_topology {
> static inline struct phy_device *
> phy_link_topo_get_phy(struct phy_link_topology *topo, u32 phyindex)
> {
> - struct phy_device_node *pdn = xa_load(&topo->phys, phyindex);
> + struct phy_device_node *pdn;
> +
> + if (!topo)
> + return NULL;
> +
> + pdn = xa_load(&topo->phys, phyindex);
>
> if (pdn)
> return pdn->phy;
Powered by blists - more mailing lists