[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5ead844d-8c9b-47e1-9950-3ff1428e1572@bootlin.com>
Date: Tue, 27 Jan 2026 22:18:38 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, Andrew Lunn <andrew@...n.ch>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Russell King <linux@...linux.org.uk>, Heiner Kallweit
<hkallweit1@...il.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
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>,
Marek Behún <kabel@...nel.org>,
Oleksij Rempel <o.rempel@...gutronix.de>,
Nicolò Veronese <nicveronese@...il.com>,
Simon Horman <horms@...nel.org>, mwojtas@...omium.org,
Romain Gantois <romain.gantois@...tlin.com>,
Daniel Golle <daniel@...rotopia.org>,
Dimitri Fedrau <dimitri.fedrau@...bherr.com>
Subject: Re: [PATCH net-next 00/13] net: phy_port: SFP modules representation
and phy_port listing
Hi,
On 27/01/2026 22:07, Jakub Kicinski wrote:
> On Tue, 27 Jan 2026 14:41:48 +0100 Maxime Chevallier wrote:
>> This series is another step towards dealing with multi-port interfaces.
>>
>> It build on the recent addition of phy_port representation to enable
>> listing the front-facing ports of an interface. For now, we don't control
>> these ports, we merely list their presence and their capabilities.
>>
>> As the most common use-case of multi-port interfaces is combo-ports that
>> provide both RJ45 and SFP connectors on a single MAC, there's a lot of
>> SFP stuff in this series.
>>
>> This series is in 2 main parts. The first one aims at representing the
>> SFP cages and modules using phy_port, as combo-ports with RJ45 + SFP are
>> by far the most common cases for multi-connector setups.
>>
>> The second part is the netlink interface to list those ports, now that
>> most use-cases are covered.
>
> Some config-related build unhappines here (kunit hits this):
>
> ../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/build_bug.h:5,
> from ../include/linux/bits.h:30,
> from ../include/linux/bitops.h:6,
> from ../include/linux/bitmap.h:8,
> from ../include/linux/ethtool.h:16,
> from ../include/uapi/linux/ethtool_netlink.h:12,
> from ../include/linux/ethtool_netlink.h:6,
> from ../net/ethtool/common.c:3:
> ../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;
> | ^~~~
Ah yes indeed, silly mistake from me but wasn't caught by running
./ingest_mdir.py locally, I'll increase my local coverage with a
defconfig that triggers this.
I was so focused making sure the various combinations of phylib et.al.
being built as modules or builtin that I didn't test with PHYLIB=n :/
Thanks for reporting, I'll address that :)
Maxime
Powered by blists - more mailing lists