[PATCH net-next 10/13] net: phy: phy_link_topology: Add a helper to retrieve ports

Maxime Chevallier posted 13 patches 1 week, 5 days ago
There is a newer version of this series
[PATCH net-next 10/13] net: phy: phy_link_topology: Add a helper to retrieve ports
Posted by Maxime Chevallier 1 week, 5 days ago
In order to allow netlink access to phy_ports, let's add a helper to
retrieve them. When handling a port coming from phy_link_topology, the
caller must hold rtnl until it's done with it.

Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 include/linux/phy_link_topology.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/include/linux/phy_link_topology.h b/include/linux/phy_link_topology.h
index 66bceff72b19..d5f8f20c5d32 100644
--- a/include/linux/phy_link_topology.h
+++ b/include/linux/phy_link_topology.h
@@ -66,6 +66,17 @@ phy_link_topo_get_phy(struct net_device *dev, u32 phyindex)
 	return NULL;
 }
 
+static inline struct phy_port *
+phy_link_topo_get_port(struct net_device *dev, u32 port_id)
+{
+	struct phy_link_topology *topo = dev->link_topo;
+
+	if (!topo)
+		return NULL;
+
+	return xa_load(&topo->ports, port_id);
+}
+
 #else
 static inline int phy_link_topo_add_phy(struct net_device *dev,
 					struct phy_device *phy,
@@ -95,6 +106,11 @@ phy_link_topo_get_phy(struct net_device *dev, u32 phyindex)
 {
 	return NULL;
 }
+
+phy_link_topo_get_port(struct net_device *dev, u32 port_id)
+{
+	return NULL;
+}
 #endif
 
 #endif /* __PHY_LINK_TOPOLOGY_H */
-- 
2.49.0
Re: [PATCH net-next 10/13] net: phy: phy_link_topology: Add a helper to retrieve ports
Posted by kernel test robot 1 week, 4 days ago
Hi Maxime,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Maxime-Chevallier/net-phy-phy_port-Correctly-recompute-the-port-s-linkmodes/20260127-215318
base:   net-next/main
patch link:    https://lore.kernel.org/r/20260127134202.8208-11-maxime.chevallier%40bootlin.com
patch subject: [PATCH net-next 10/13] net: phy: phy_link_topology: Add a helper to retrieve ports
config: s390-randconfig-002-20260128 (https://download.01.org/0day-ci/archive/20260128/202601280624.F1IZ2yHm-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260128/202601280624.F1IZ2yHm-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601280624.F1IZ2yHm-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from net/ethtool/tsinfo.c:5:
   include/linux/phy_link_topology.h:110:1: error: return type defaults to 'int' [-Werror=implicit-int]
    phy_link_topo_get_port(struct net_device *dev, u32 port_id)
    ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/phy_link_topology.h:110:1: warning: no previous prototype for 'phy_link_topo_get_port' [-Wmissing-prototypes]
   In file included from include/uapi/linux/posix_types.h:5,
                    from include/uapi/linux/types.h:14,
                    from include/linux/types.h:6,
                    from include/uapi/linux/net_tstamp.h:13,
                    from include/linux/net_tstamp.h:6,
                    from net/ethtool/tsinfo.c:3:
   include/linux/phy_link_topology.h: In function 'phy_link_topo_get_port':
>> include/linux/stddef.h:8:14: warning: returning 'void *' from a function with return type 'int' makes integer from pointer without a cast [-Wint-conversion]
    #define NULL ((void *)0)
                 ^
   include/linux/phy_link_topology.h:112:9: note: in expansion of macro 'NULL'
     return NULL;
            ^~~~
   cc1: some warnings being treated as errors


vim +8 include/linux/stddef.h

^1da177e4c3f41 Linus Torvalds   2005-04-16  6  
^1da177e4c3f41 Linus Torvalds   2005-04-16  7  #undef NULL
^1da177e4c3f41 Linus Torvalds   2005-04-16 @8  #define NULL ((void *)0)
6e218287432472 Richard Knutsson 2006-09-30  9  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH net-next 10/13] net: phy: phy_link_topology: Add a helper to retrieve ports
Posted by kernel test robot 1 week, 4 days ago
Hi Maxime,

kernel test robot noticed the following build errors:

[auto build test ERROR on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Maxime-Chevallier/net-phy-phy_port-Correctly-recompute-the-port-s-linkmodes/20260127-215318
base:   net-next/main
patch link:    https://lore.kernel.org/r/20260127134202.8208-11-maxime.chevallier%40bootlin.com
patch subject: [PATCH net-next 10/13] net: phy: phy_link_topology: Add a helper to retrieve ports
config: i386-randconfig-141-20260128 (https://download.01.org/0day-ci/archive/20260128/202601280617.qlkBpNaP-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
smatch version: v0.5.0-8994-gd50c5a4c
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260128/202601280617.qlkBpNaP-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601280617.qlkBpNaP-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from net/core/dev.c:165:
>> include/linux/phy_link_topology.h:110:1: error: return type defaults to 'int' [-Wimplicit-int]
     110 | phy_link_topo_get_port(struct net_device *dev, u32 port_id)
         | ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/phy_link_topology.h:110:1: warning: no previous prototype for 'phy_link_topo_get_port' [-Wmissing-prototypes]
   In file included from include/uapi/linux/posix_types.h:5,
                    from include/uapi/linux/types.h:14,
                    from include/linux/types.h:6,
                    from include/linux/kasan-checks.h:5,
                    from include/asm-generic/rwonce.h:26,
                    from ./arch/x86/include/generated/asm/rwonce.h:1,
                    from include/linux/compiler.h:380,
                    from include/linux/cleanup.h:5,
                    from include/linux/uaccess.h:5,
                    from net/core/dev.c:71:
   include/linux/phy_link_topology.h: In function 'phy_link_topo_get_port':
>> include/linux/stddef.h:8:14: error: returning 'void *' from a function with return type 'int' makes integer from pointer without a cast [-Wint-conversion]
       8 | #define NULL ((void *)0)
         |              ^
   include/linux/phy_link_topology.h:112:16: note: in expansion of macro 'NULL'
     112 |         return NULL;
         |                ^~~~


vim +/int +110 include/linux/phy_link_topology.h

   109	
 > 110	phy_link_topo_get_port(struct net_device *dev, u32 port_id)
   111	{
   112		return NULL;
   113	}
   114	#endif
   115	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH net-next 10/13] net: phy: phy_link_topology: Add a helper to retrieve ports
Posted by Romain Gantois 1 week, 4 days ago
On Tuesday, 27 January 2026 14:41:58 CET Maxime Chevallier wrote:
> In order to allow netlink access to phy_ports, let's add a helper to
> retrieve them. When handling a port coming from phy_link_topology, the
> caller must hold rtnl until it's done with it.

Why not use rtnl-specific lockdep annotations to make this more explicit?

Thanks,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH net-next 10/13] net: phy: phy_link_topology: Add a helper to retrieve ports
Posted by Maxime Chevallier 1 week, 2 days ago

On 28/01/2026 17:10, Romain Gantois wrote:
> On Tuesday, 27 January 2026 14:41:58 CET Maxime Chevallier wrote:
>> In order to allow netlink access to phy_ports, let's add a helper to
>> retrieve them. When handling a port coming from phy_link_topology, the
>> caller must hold rtnl until it's done with it.
> 
> Why not use rtnl-specific lockdep annotations to make this more explicit?

While this makes sure the call-site holds the lock as it should, it
doesn't guarantee the caller won't release it too early.

Doesn't hurt to add it though :)

Maxime

> 
> Thanks,
>