* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:29 UTC (permalink / raw)
To: Christian Marangi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <6a3007ce.73de60af.3a056d.d903@mx.google.com>
On 6/15/26 16:10, Christian Marangi wrote:
> On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
>> Hi Christian,
>>
>> On 6/15/26 14:29, Christian Marangi wrote:
>>> Add support for late PCS provider attachment to a phylink instance.
>>> This works by creating a global notifier for the PCS provider and
>>> making each phylink instance that makes use of fwnode subscribe to
>>> this notifier.
>>>
>>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
>>> a new PCS provider is added.
>>>
>>> phylink will then react to this event and will call the new function
>>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
>>> provided by the event is present in the pcs-handle property of the
>>> phylink instance.
>>>
>>> If a related PCS is found, then such PCS is added to the phylink
>>> instance PCS list.
>>>
>>> Then we link the PCS to the phylink instance and we refresh the supported
>>> interfaces of the phylink instance.
>>>
>>> Finally we check if we are in a major_config_failed scenario and trigger
>>> an interface reconfiguration in the next phylink resolve.
>>>
>>> In the example scenario where the link was previously torn down due to
>>> removal of PCS, the link will be established again as the PCS came back
>>> and is now available to phylink.
>>>
>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>> ---
>>
>> [...]
>>
>>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
>>> if (pl->link_gpio)
>>> gpiod_put(pl->link_gpio);
>>>
>>> + /* Unregister notifier for late PCS attach */
>>> + if (pl->fwnode_pcs_nb.notifier_call)
>>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>
>> I wanted to try this out, but I get :
>>
>> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
>> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> | register_fwnode_pcs_notifier
>>
>> I guess you either need to stub this, or there's a missing Kconfig
>> dependency somewhere
>>
>
> Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
> the static declaration for unregister_fwnode_pcs_notifier.
I'll give it a go with this yeah, I have a few devices here I'd like to
try this on.
Can you CC me for the next rounds ?
Maxime
>
^ permalink raw reply
* Re: [PATCH net-next v7 2/2] net: dsa: mv88e6xxx: add support for credit based shaper
From: Cedric Jehasse @ 2026-06-15 14:29 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Cedric Jehasse via B4 Relay, cedric.jehasse, Andrew Lunn,
Vladimir Oltean, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Russell King, netdev, linux-kernel, Luke Howard,
Marek Behún
In-Reply-To: <20260612153656.4c5b8c62@kernel.org>
O Fri, Jun 12, 2026 at 03:36:56PM -0700, Jakub Kicinski wrote:
> On Tue, 09 Jun 2026 14:10:51 +0200 Cedric Jehasse via B4 Relay wrote:
> > From: Cedric Jehasse <cedric.jehasse@luminex.be>
> >
> > Some of the chips supported by this driver have credit based shaper
> > support. Support is added for the 6341, 6352, 6390 and 6393 families.
> > This is configured using the Qav registers in the AVB register block.
> > There are small differences in the Qav registers between the chip
> > families (eg. the unit used for the rate and number of bits in the
> > registers). mv88e6xxx_qav_info is introduced to configure this per chip.
> >
> > Eg. setting up 20mbps credit based shaper on a 1GBit link:
> > tc qdisc add dev p8 parent root handle 100: mqprio \
> > num_tc 8 \
> > map 0 0 6 7 0 5 0 0 0 0 0 0 0 0 0 0 \
> > queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
> > hw 0
> >
> > tc qdisc replace dev p8 parent 100:8 cbs locredit -1470 hicredit 30 \
> > sendslope -980000 idleslope 20000 offload 1
>
> Are DSA ports multi-queue? I would have expected a DSA driver to
> offload PRIO not MQPRIO.
>
> I seem to recall other discussion on the ML on the topic.
> It'd be great to get some review tags from folks familiar with
> the device.
As mentioned by Luke, this patch adds offloading for CBS, not MQPIO. Other dsa
driver already do this (eg. microchip ksz driver).
>
> > Note: only idleslope and hicredit can be programmed in the switch
> > registers, other parameters won't affect settings.
>
> > +static int mv88e6xxx_setup_tc_cbs(struct dsa_switch *ds, int port,
> > + struct tc_cbs_qopt_offload *cbs)
>
> please stick an extack into struct tc_cbs_qopt_offload and use it to
> report the reason for rejection back to the user
>
Do you mean modifying cbs_enable_offload to report a driver specified reason isof
reportig the generic "Specified device failed to setup cbs hardware offload"?
What should be done for other drivers who handle TC_SETUP_QDISC_CBS, but don't
fill in extack? Should cbs_enable_offload fill in extack with "Specified device
failed to setup cbs hardware offload"?
Cedric
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Christian Marangi @ 2026-06-15 14:35 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <7702ac09-75fd-49de-8ad2-fceaa122b627@bootlin.com>
On Mon, Jun 15, 2026 at 04:29:04PM +0200, Maxime Chevallier wrote:
>
>
> On 6/15/26 16:10, Christian Marangi wrote:
> > On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
> >> Hi Christian,
> >>
> >> On 6/15/26 14:29, Christian Marangi wrote:
> >>> Add support for late PCS provider attachment to a phylink instance.
> >>> This works by creating a global notifier for the PCS provider and
> >>> making each phylink instance that makes use of fwnode subscribe to
> >>> this notifier.
> >>>
> >>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
> >>> a new PCS provider is added.
> >>>
> >>> phylink will then react to this event and will call the new function
> >>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
> >>> provided by the event is present in the pcs-handle property of the
> >>> phylink instance.
> >>>
> >>> If a related PCS is found, then such PCS is added to the phylink
> >>> instance PCS list.
> >>>
> >>> Then we link the PCS to the phylink instance and we refresh the supported
> >>> interfaces of the phylink instance.
> >>>
> >>> Finally we check if we are in a major_config_failed scenario and trigger
> >>> an interface reconfiguration in the next phylink resolve.
> >>>
> >>> In the example scenario where the link was previously torn down due to
> >>> removal of PCS, the link will be established again as the PCS came back
> >>> and is now available to phylink.
> >>>
> >>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
> >>> if (pl->link_gpio)
> >>> gpiod_put(pl->link_gpio);
> >>>
> >>> + /* Unregister notifier for late PCS attach */
> >>> + if (pl->fwnode_pcs_nb.notifier_call)
> >>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> >>
> >> I wanted to try this out, but I get :
> >>
> >> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
> >> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> | register_fwnode_pcs_notifier
> >>
> >> I guess you either need to stub this, or there's a missing Kconfig
> >> dependency somewhere
> >>
> >
> > Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
> > the static declaration for unregister_fwnode_pcs_notifier.
>
> I'll give it a go with this yeah, I have a few devices here I'd like to
> try this on.
>
> Can you CC me for the next rounds ?
>
Sure, if you can would be good to check also the other commit if everything
is logically correct.
BTW by checking test from patchwork I can see also another fix is needed if
you want to test this revision.
phylink_create()
-if (config->num_possible_pcs && pl->mac_ops->mac_select_pcs) {
+if (config->num_possible_pcs && mac_ops->mac_select_pcs) {
Aside from these change I expect the current legacy code to be not
affected by these change.
--
Ansuel
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Mark Brown @ 2026-06-15 14:42 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, Paolo Abeni, Networking
Cc: Aditya Garg, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/microsoft/mana/mana_en.c
between commit:
f8fd56977eeea ("net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check")
from the net tree and commit:
d07efe5a6e641 ("net: mana: Use per-queue allocation for tx_qp to reduce allocation size")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/net/ethernet/microsoft/mana/mana_en.c
index d7de4c4d25bbe,26aef21c6c2c8..0000000000000
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@@ -2332,14 -2399,15 +2399,16 @@@ static void mana_destroy_txq(struct man
napi_synchronize(napi);
napi_disable_locked(napi);
netif_napi_del_locked(napi);
- apc->tx_qp[i].txq.napi_initialized = false;
+ apc->tx_qp[i]->txq.napi_initialized = false;
}
- mana_destroy_wq_obj(apc, GDMA_SQ, apc->tx_qp[i]->tx_object);
- if (apc->tx_qp[i].tx_object != INVALID_MANA_HANDLE)
++ if (apc->tx_qp[i]->tx_object != INVALID_MANA_HANDLE)
- mana_destroy_wq_obj(apc, GDMA_SQ, apc->tx_qp[i].tx_object);
++ mana_destroy_wq_obj(apc, GDMA_SQ, apc->tx_qp[i]->tx_object);
- mana_deinit_cq(apc, &apc->tx_qp[i].tx_cq);
+ mana_deinit_cq(apc, &apc->tx_qp[i]->tx_cq);
- mana_deinit_txq(apc, &apc->tx_qp[i].txq);
+ mana_deinit_txq(apc, &apc->tx_qp[i]->txq);
+
+ kvfree(apc->tx_qp[i]);
}
kfree(apc->tx_qp);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:44 UTC (permalink / raw)
To: Christian Marangi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <6a300da0.d5af3cef.1ca29d.19c4@mx.google.com>
On 6/15/26 16:35, Christian Marangi wrote:
> On Mon, Jun 15, 2026 at 04:29:04PM +0200, Maxime Chevallier wrote:
>>
>>
>> On 6/15/26 16:10, Christian Marangi wrote:
>>> On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
>>>> Hi Christian,
>>>>
>>>> On 6/15/26 14:29, Christian Marangi wrote:
>>>>> Add support for late PCS provider attachment to a phylink instance.
>>>>> This works by creating a global notifier for the PCS provider and
>>>>> making each phylink instance that makes use of fwnode subscribe to
>>>>> this notifier.
>>>>>
>>>>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
>>>>> a new PCS provider is added.
>>>>>
>>>>> phylink will then react to this event and will call the new function
>>>>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
>>>>> provided by the event is present in the pcs-handle property of the
>>>>> phylink instance.
>>>>>
>>>>> If a related PCS is found, then such PCS is added to the phylink
>>>>> instance PCS list.
>>>>>
>>>>> Then we link the PCS to the phylink instance and we refresh the supported
>>>>> interfaces of the phylink instance.
>>>>>
>>>>> Finally we check if we are in a major_config_failed scenario and trigger
>>>>> an interface reconfiguration in the next phylink resolve.
>>>>>
>>>>> In the example scenario where the link was previously torn down due to
>>>>> removal of PCS, the link will be established again as the PCS came back
>>>>> and is now available to phylink.
>>>>>
>>>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
>>>>> if (pl->link_gpio)
>>>>> gpiod_put(pl->link_gpio);
>>>>>
>>>>> + /* Unregister notifier for late PCS attach */
>>>>> + if (pl->fwnode_pcs_nb.notifier_call)
>>>>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>>>
>>>> I wanted to try this out, but I get :
>>>>
>>>> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
>>>> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> | register_fwnode_pcs_notifier
>>>>
>>>> I guess you either need to stub this, or there's a missing Kconfig
>>>> dependency somewhere
>>>>
>>>
>>> Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
>>> the static declaration for unregister_fwnode_pcs_notifier.
>>
>> I'll give it a go with this yeah, I have a few devices here I'd like to
>> try this on.
>>
>> Can you CC me for the next rounds ?
>>
>
> Sure, if you can would be good to check also the other commit if everything
> is logically correct.
Absolutely, I'm planning on doing this :) This is quite the series though,
I'll try to give it some deeper look in the upcoming days, I expect net-next
to close soon anyways, so that's as good as it gets for reviewing this :)
Also, it's probably a good idea to have Sean in CC as well, I know a few people
interested in the Xilinx PCS his series brought, hopefully he can follow-up on
this series with the other new PCS drivers.
>
> BTW by checking test from patchwork I can see also another fix is needed if
> you want to test this revision.
>
> phylink_create()
>
> -if (config->num_possible_pcs && pl->mac_ops->mac_select_pcs) {
> +if (config->num_possible_pcs && mac_ops->mac_select_pcs) {
Ack, I'll test it with this change, thanks :)
Maxime
>
> Aside from these change I expect the current legacy code to be not
> affected by these change.
I'll probably have things to say about this "legacy" naming :)
Thanks for driving this work forwards anyway, that's
>
^ permalink raw reply
* Re: [PATCH v27 4/5] sfc: obtain and map cxl range using devm_cxl_probe_mem
From: Alejandro Lucero Palau @ 2026-06-15 14:47 UTC (permalink / raw)
To: Dan Williams (nvidia), alejandro.lucero-palau, linux-cxl, netdev,
edward.cree, davem, kuba, pabeni, edumazet, dave.jiang
In-Reply-To: <dcc502fa-1a06-465a-abab-9b039b9c2672@amd.com>
On 6/10/26 14:56, Alejandro Lucero Palau wrote:
>
> On 6/10/26 07:10, Alejandro Lucero Palau wrote:
>>
>> On 6/10/26 00:30, Dan Williams (nvidia) wrote:
>>> alejandro.lucero-palau@ wrote:
>>>> From: Alejandro Lucero <alucerop@amd.com>
>>>>
>>>> Use core API for safely obtain the CXL range linked to an HDM
>>>> committed
>>>> by the BIOS. Map such a range for being used as the ctpio buffer.
>>>>
>>>> A potential user space action through sysfs unbinding or core cxl
>>>> modules remove will trigger sfc driver device detachment, with that
>>>> case
>>>> not racing with this mapping as this is done during driver probe and
>>>> therefore protected with device lock against those user space actions.
>>>>
>>>> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
>>>> ---
>>>> drivers/net/ethernet/sfc/efx.c | 1 +
>>>> drivers/net/ethernet/sfc/efx_cxl.c | 24 ++++++++++++++++++++++++
>>>> drivers/net/ethernet/sfc/efx_cxl.h | 3 +++
>>>> 3 files changed, 28 insertions(+)
>>>>
>>>> diff --git a/drivers/net/ethernet/sfc/efx.c
>>>> b/drivers/net/ethernet/sfc/efx.c
>>>> index 90ccbe310386..578054c21e79 100644
>>>> --- a/drivers/net/ethernet/sfc/efx.c
>>>> +++ b/drivers/net/ethernet/sfc/efx.c
>>>> @@ -984,6 +984,7 @@ static void efx_pci_remove(struct pci_dev
>>>> *pci_dev)
>>>> efx_fini_io(efx);
>>>> probe_data = container_of(efx, struct efx_probe_data, efx);
>>>> + efx_cxl_exit(probe_data);
>>>> pci_dbg(efx->pci_dev, "shutdown successful\n");
>>>> diff --git a/drivers/net/ethernet/sfc/efx_cxl.c
>>>> b/drivers/net/ethernet/sfc/efx_cxl.c
>>>> index 4d55c08cf2a1..d5766a40e2cf 100644
>>>> --- a/drivers/net/ethernet/sfc/efx_cxl.c
>>>> +++ b/drivers/net/ethernet/sfc/efx_cxl.c
>>>> @@ -18,6 +18,7 @@ int efx_cxl_init(struct efx_probe_data *probe_data)
>>>> {
>>>> struct efx_nic *efx = &probe_data->efx;
>>>> struct pci_dev *pci_dev = efx->pci_dev;
>>>> + struct range cxl_pio_range;
>>>> struct efx_cxl *cxl;
>>>> u16 dvsec;
>>>> int rc;
>>>> @@ -75,9 +76,32 @@ int efx_cxl_init(struct efx_probe_data *probe_data)
>>>> return -ENODEV;
>>>> }
>>>> + cxl->cxlmd = devm_cxl_probe_mem(&cxl->cxlds, &cxl_pio_range);
>>>> + if (IS_ERR(cxl->cxlmd)) {
>>>> + pci_err(pci_dev, "CXL accel memdev creation failed\n");
>>>> + return PTR_ERR(cxl->cxlmd);
>>>> + }
>>>> +
>>>> + cxl->ctpio_cxl = ioremap_wc(cxl_pio_range.start,
>>>> + range_len(&cxl_pio_range));
>>>> + if (!cxl->ctpio_cxl) {
>>>> + pci_err(pci_dev, "CXL ioremap region (%pra) failed\n",
>>>> + &cxl_pio_range);
>>>> + return -ENOMEM;
>>> Dave caught the iounmap leak, but another concern is since you want to
>>> continue operation if efx_cxl_init() fails then you probably also want
>>> to release the successful attachment to the CXL domain if this happens.
>>
>>
>> I will do that.
>>
>
> Looking at this issue, I think an error when creating the memdev or
> during the region attach triggers the memdev removal, but ...
>
>
>>
>>> Minor since something else is likely to fail if ioremap is not
>>> reliable.
>
>
> .. if we want to specifically do that with an unlikely (but possible)
> ioremap error something else needs to be exported like
> cxl_memdev_unregister(). Are you happy with that approach?
>
I have just tested with this:
+void cxl_memdev_remove(void *_cxlmd)
+{
+ struct cxl_memdev *cxlmd = _cxlmd;
+ struct device *dev = &cxlmd->dev;
+
+ devm_remove_action_nowarn(cxlmd->cxlds->dev, cxl_memdev_unregister,
+ cxlmd);
+
+ cdev_device_del(&cxlmd->cdev, dev);
+ cxl_memdev_shutdown(dev);
+ put_device(dev);
+}
+EXPORT_SYMBOL_NS_GPL(cxl_memdev_remove, "CXL");
only called if the ioremap fails.
Please, let me know if you like this approach before sending another
version.
Thank you
>
>>>
>>> Otherwise this looks good and with those fixed up the Reviewed-by still
>>> stands.
>>
>>
>> No Reviewed-by yet ... this is a new patch after your series removing
>> previous functionality.
>>
>>
>> Thanks
>>
^ permalink raw reply
* Re: [PATCH net-next 2/5] tls: remove dead sockmap (psock) handling from the SW path
From: Jakub Sitnicki @ 2026-06-15 14:55 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, bpf,
john.fastabend, sd
In-Reply-To: <20260614014102.461064-3-kuba@kernel.org>
On Sat, Jun 13, 2026 at 06:40 PM -07, Jakub Kicinski wrote:
> TLS and sockmap are now mutually exclusive. Try to delete the code
> from sendmsg and recvmsg path which is now obviously dead.
>
> The main goal is to delete enough code for AI security scanners
> to no longer bother us with sockmap related bugs. At the same
> time retain the code in case someone has the cycles to fix
> all of this and make the integration work, again.
>
> If the integration does not get restored we can wipe the rest
> of the skmsg code from TLS in two or three releases.
>
> The changes on the Tx side are deeper since that's where most
> of the bugs are, Rx side simply takes the data from sockmap
> and gives it to the user. On Tx split record handling and
> rolling back the iterator were the two problem areas.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
Nice! This unlocks further cleanup in tcp_bpf and tcp_ulp.
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
^ permalink raw reply
* Re: [RESEND PATCH v1] net: dsa: motorcomm: add yt92xx dsa driver
From: Julian Braha @ 2026-06-15 15:01 UTC (permalink / raw)
To: Kyle Switch, mmyangfl, andrew, olteanv, davem, edumazet, kuba,
pabeni, horms, netdev, linux-kernel
Cc: ming.xu, xiaolin.xu, jianmin.wang, de.ge
In-Reply-To: <20260615111235.3544282-1-kyle.switch@motor-comm.com>
Hi Kyle,
On 6/15/26 12:12, Kyle Switch wrote:
> diff --git a/drivers/net/dsa/motorcomm/Kconfig b/drivers/net/dsa/motorcomm/Kconfig
> new file mode 100644
> index 000000000000..f40d75e2a3f2
> --- /dev/null
> +++ b/drivers/net/dsa/motorcomm/Kconfig
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +config MOTORCOMM
> + tristate "Motorcomm YT92XX switch family support"
> + depends on NET_DSA
> + select FIXED_PHY
> + help
> + This driver adds support for Motorcomm switch chips. It supports
> + YT921X and YT922X switch.
> +
> +choice
> + prompt "Motorcomm switch series selection"
> + depends on MOTORCOMM
> +
> +config MOTORCOMM_YT921X
> + bool "Motorcomm YT921X series."
> +
> +config MOTORCOMM_YT922X
> + bool "Motorcomm YT922X series."
> +endchoice
> +
> +config NET_DSA_MOTORCOMM
> + tristate "Motorcomm YT92XX switch DSA driver"
> + depends on MOTORCOMM
> + depends on (MOTORCOMM_YT921X || MOTORCOMM_YT922X)
> + select NET_DSA_TAG_MOTORCOMM
> + select NET_IEEE8021Q_HELPERS if DCB
> + help
> + Select to enable support for Motorcomm driver.
> +
> diff --git a/drivers/net/dsa/motorcomm/Makefile b/drivers/net/dsa/motorcomm/Makefile
NET_DSA_MOTORCOMM already depends on:
(MOTORCOMM_YT921X || MOTORCOMM_YT922X)
with both of those options depending on MOTORCOMM due to the 'choice'
that they're in, so this additional dependency on MOTORCOMM is
unnecessary.
You could also consider using a comment to document that this option is
depended on indirectly.
- Julian Braha
^ permalink raw reply
* [PATCH net] tipc: free bearer discoverer via RCU to fix tipc_disc_rcv UAF
From: Samuel Page @ 2026-06-15 15:00 UTC (permalink / raw)
To: Jon Maloy
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev, tipc-discussion, linux-kernel, Samuel Page,
stable
bearer_disable() tears down a bearer's discovery object with
tipc_disc_delete(), which frees the struct tipc_discoverer with a plain,
synchronous kfree(). The discovery receive path, however, still reads
that object under RCU in softirq context:
tipc_udp_recv() // udp_media.c, rcu_dereference(ub->bearer)
-> tipc_rcv() // node.c
-> tipc_disc_rcv() // discover.c
-> tipc_disc_addr_trial_msg(b->disc, ...) // reads d->net etc.
tipc_udp_recv() only gates this path on test_bit(0, &b->up), which is a
TOCTOU check: an RX softirq that observes b->up == 1 before
bearer_disable() does clear_bit_unlock(0, &b->up) can still be executing
inside tipc_disc_rcv() when bearer_disable() reaches
if (b->disc)
tipc_disc_delete(b->disc);
and kfree()s the discoverer. The reader then dereferences freed memory
(d->net, inlined into tipc_disc_rcv()) in softirq context [0].
The bearer itself is freed RCU-safely (tipc_bearer_put() ->
kfree_rcu(b, rcu)) because the RX path runs under RCU, but the discoverer
hanging off b->disc is freed synchronously. The same b->disc is also
touched under rcu_read_lock() by
tipc_disc_add_dest()/tipc_disc_remove_dest().
Free the discoverer with the same RCU lifetime as its bearer. Add an
rcu_head to struct tipc_discoverer and defer the kfree_skb()/kfree() to
an RCU callback so any in-flight reader that already loaded b->disc
completes before the memory is released. The timer is still shut down
synchronously up front with timer_shutdown_sync() (which can sleep and
must not run from the RCU callback), and shutting it down before the
grace period prevents the periodic LINK_REQUEST timer from rearming or
re-entering the object.
This mirrors the existing TIPC pattern of pairing call_rcu() with a
cleanup callback (see tipc_node_free()/tipc_aead_free()).
[0]: (trailing page/memory-state dump trimmed)
BUG: KASAN: slab-use-after-free in tipc_disc_addr_trial_msg net/tipc/discover.c:149 [inline]
BUG: KASAN: slab-use-after-free in tipc_disc_rcv+0xe7c/0x103c net/tipc/discover.c:236
Read of size 8 at addr ffff000028f07428 by task ksoftirqd/0/15
CPU: 0 UID: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 7.0.11 #3 PREEMPT
Hardware name: linux,dummy-virt (DT)
Call trace:
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C)
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0xb4/0xd4 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x118/0x5d8 mm/kasan/report.c:482
kasan_report+0xb0/0xf4 mm/kasan/report.c:595
__asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381
tipc_disc_addr_trial_msg net/tipc/discover.c:149 [inline]
tipc_disc_rcv+0xe7c/0x103c net/tipc/discover.c:236
tipc_rcv+0x1884/0x2b1c net/tipc/node.c:2126
tipc_udp_recv+0x22c/0x684 net/tipc/udp_media.c:393
udp_queue_rcv_one_skb+0x898/0x1798 net/ipv4/udp.c:2441
udp_queue_rcv_skb+0x1b0/0xa44 net/ipv4/udp.c:2518
udp_unicast_rcv_skb+0x13c/0x348 net/ipv4/udp.c:2678
__udp4_lib_rcv+0x1aec/0x246c net/ipv4/udp.c:2754
udp_rcv+0x78/0xa0 net/ipv4/udp.c:2936
ip_protocol_deliver_rcu+0x68/0x410 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x28c/0x4b4 net/ipv4/ip_input.c:241
NF_HOOK include/linux/netfilter.h:318 [inline]
NF_HOOK include/linux/netfilter.h:312 [inline]
ip_local_deliver+0x29c/0x2ec net/ipv4/ip_input.c:262
dst_input include/net/dst.h:480 [inline]
ip_rcv_finish net/ipv4/ip_input.c:453 [inline]
ip_rcv_finish net/ipv4/ip_input.c:439 [inline]
NF_HOOK include/linux/netfilter.h:318 [inline]
NF_HOOK include/linux/netfilter.h:312 [inline]
ip_rcv+0x21c/0x258 net/ipv4/ip_input.c:573
__netif_receive_skb_one_core+0x110/0x184 net/core/dev.c:6195
__netif_receive_skb+0x2c/0x170 net/core/dev.c:6308
process_backlog+0x178/0x488 net/core/dev.c:6659
__napi_poll+0xa8/0x540 net/core/dev.c:7726
napi_poll net/core/dev.c:7789 [inline]
net_rx_action+0x360/0x964 net/core/dev.c:7946
handle_softirqs+0x2f0/0x7b0 kernel/softirq.c:622
run_ksoftirqd kernel/softirq.c:1063 [inline]
run_ksoftirqd+0x6c/0x88 kernel/softirq.c:1055
smpboot_thread_fn+0x65c/0x958 kernel/smpboot.c:160
kthread+0x39c/0x444 kernel/kthread.c:436
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
Allocated by task 68873:
kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57
kasan_save_track+0x20/0x3c mm/kasan/common.c:78
kasan_save_alloc_info+0x40/0x54 mm/kasan/generic.c:570
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xd4/0xd8 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloc_cache_noprof+0x1b0/0x458 mm/slub.c:5385
kmalloc_noprof include/linux/slab.h:950 [inline]
tipc_disc_create+0xdc/0x5e0 net/tipc/discover.c:356
tipc_enable_bearer+0x8b8/0xf94 net/tipc/bearer.c:348
__tipc_nl_bearer_enable+0x2a8/0x398 net/tipc/bearer.c:1047
tipc_nl_bearer_enable+0x2c/0x48 net/tipc/bearer.c:1056
genl_family_rcv_msg_doit+0x1e4/0x2c0 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x4e8/0x750 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x204/0x3cc net/netlink/af_netlink.c:2550
genl_rcv+0x3c/0x54 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x638/0x930 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x798/0xc68 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg+0xe0/0x128 net/socket.c:742
__sys_sendto+0x230/0x2f4 net/socket.c:2206
__do_sys_sendto net/socket.c:2213 [inline]
__se_sys_sendto net/socket.c:2209 [inline]
__arm64_sys_sendto+0xc4/0x13c net/socket.c:2209
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c:49
el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c:132
do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c:151
el0_svc+0x38/0xac arch/arm64/kernel/entry-common.c:724
el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c:743
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596
Freed by task 60072:
kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57
kasan_save_track+0x20/0x3c mm/kasan/common.c:78
kasan_save_free_info+0x4c/0x74 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x88/0xb8 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6170 [inline]
kfree+0x14c/0x458 mm/slub.c:6488
tipc_disc_delete+0x50/0x68 net/tipc/discover.c:393
bearer_disable+0x18c/0x278 net/tipc/bearer.c:418
tipc_bearer_stop+0xe0/0x198 net/tipc/bearer.c:757
tipc_net_stop+0x110/0x178 net/tipc/net.c:159
tipc_exit_net+0x80/0x19c net/tipc/core.c:112
ops_exit_list net/core/net_namespace.c:199 [inline]
ops_undo_list+0x244/0x694 net/core/net_namespace.c:252
cleanup_net+0x3a0/0x830 net/core/net_namespace.c:702
process_one_work+0x628/0xd38 kernel/workqueue.c:3289
process_scheduled_works kernel/workqueue.c:3372 [inline]
worker_thread+0x7a8/0xac0 kernel/workqueue.c:3453
kthread+0x39c/0x444 kernel/kthread.c:436
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash values")
Cc: stable@vger.kernel.org
Assisted-by: Bynario AI
Signed-off-by: Samuel Page <sam@bynar.io>
---
net/tipc/discover.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index 3e54d2df5683..844975b691ef 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
@@ -49,6 +49,7 @@
/**
* struct tipc_discoverer - information about an ongoing link setup request
+ * @rcu: RCU head used to free the structure after a grace period
* @bearer_id: identity of bearer issuing requests
* @net: network namespace instance
* @dest: destination address for request messages
@@ -60,6 +61,7 @@
* @timer_intv: current interval between requests (in ms)
*/
struct tipc_discoverer {
+ struct rcu_head rcu;
u32 bearer_id;
struct tipc_media_addr dest;
struct net *net;
@@ -382,6 +384,17 @@ int tipc_disc_create(struct net *net, struct tipc_bearer *b,
return 0;
}
+/* RCU callback: free the discoverer only after any concurrent
+ * tipc_disc_rcv() softirq reader of bearer->disc has finished.
+ */
+static void tipc_disc_free_rcu(struct rcu_head *rp)
+{
+ struct tipc_discoverer *d = container_of(rp, struct tipc_discoverer, rcu);
+
+ kfree_skb(d->skb);
+ kfree(d);
+}
+
/**
* tipc_disc_delete - destroy object sending periodic link setup requests
* @d: ptr to link dest structure
@@ -389,8 +402,7 @@ int tipc_disc_create(struct net *net, struct tipc_bearer *b,
void tipc_disc_delete(struct tipc_discoverer *d)
{
timer_shutdown_sync(&d->timer);
- kfree_skb(d->skb);
- kfree(d);
+ call_rcu(&d->rcu, tipc_disc_free_rcu);
}
/**
base-commit: 47186409c092cd7dd70350999186c700233e854d
--
2.54.0
^ permalink raw reply related
* [PATCH net v3] octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF
From: Junrui Luo @ 2026-06-15 15:04 UTC (permalink / raw)
To: Sunil Goutham, Linu Cherian, Geetha sowjanya, hariprasad,
Subbaraya Sundeep, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: netdev, linux-kernel, Yuhao Jiang, stable, Junrui Luo
In-Reply-To: <SYBPR01MB788101745A9E36F6FD81CD7AAF152@SYBPR01MB7881.ausprd01.prod.outlook.com>
rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct
index into the LMT map table to read another function's LMTLINE
physical base address and copy it into the caller's own LMT map table
entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the
IRQ source, but req->base_pcifunc is a separate payload field and is
not sanitized.
Reject the request with -EPERM when a VF caller's base_pcifunc is not a
valid function under its own PF. is_pf_func_valid() bounds the FUNC field
to the PF's configured VF count, keeping the computed index inside the
caller's own slot block.
Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
Changes in v3:
- Validate base_pcifunc with is_pf_func_valid() in addition to the same-PF
check: it bounds the FUNC field to the PF's configured VF count and
rejects non-existent functions, closing the wrap. Thanks to the AI
review forwarded by Paolo Abeni for spotting this.
- Link to v2: https://lore.kernel.org/all/SYBPR01MB788101745A9E36F6FD81CD7AAF152@SYBPR01MB7881.ausprd01.prod.outlook.com
Changes in v2:
- Restrict the check to VF callers only. PF callers are trusted and may
still share LMTLINEs across PFs.
- Link to v1: https://lore.kernel.org/r/SYBPR01MB7881F8D11D2930BB84215253AF0D2@SYBPR01MB7881.ausprd01.prod.outlook.com
---
drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
index d2163da28d18..fa4ea1258d29 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
@@ -178,6 +178,15 @@ int rvu_mbox_handler_lmtst_tbl_setup(struct rvu *rvu,
* pcifunc (will be the one who is calling this mailbox).
*/
if (req->base_pcifunc) {
+ /* A VF is untrusted and must not redirect its LMTLINE to
+ * another PF's region, so confine VF callers to their own PF.
+ */
+ if (is_vf(req->hdr.pcifunc) &&
+ (!is_pf_func_valid(rvu, req->base_pcifunc) ||
+ rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
+ rvu_get_pf(rvu->pdev, req->base_pcifunc)))
+ return -EPERM;
+
/* Calculating the LMT table index equivalent to primary
* pcifunc.
*/
---
base-commit: 9716c086c8e8b141d35aa61f2e96a2e83de212a7
change-id: 20260615-fixes-239a59dc6012
Best regards,
--
Junrui Luo <moonafterrain@outlook.com>
^ permalink raw reply related
* [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: Christian Marangi @ 2026-06-15 15:11 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, Daniel Golle, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Christian Marangi
Everything configured in phylink_config it's assumed to be set before
calling phylink_create() to permit correct parsing of all the different
modes and capabilities.
Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
probably due to an auto-rebase, placed the configuration of the INTERNAL
interface mode for the supported_interfaces for phylink_config right after
phylink_create() introducing a possible problem with supported interfaces
parsing.
While this doesn't currently create any problem/bug, move setting this bit
before phylink_create() to prevent any possible regression in future code
change in phylink core.
Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 7d771168b990..5d291e50a47b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -4960,6 +4960,11 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
if (MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628))
mac_ops = &rt5350_phylink_ops;
+ if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_2P5GPHY) &&
+ id == MTK_GMAC2_ID)
+ __set_bit(PHY_INTERFACE_MODE_INTERNAL,
+ mac->phylink_config.supported_interfaces);
+
phylink = phylink_create(&mac->phylink_config,
of_fwnode_handle(mac->of_node),
phy_mode, mac_ops);
@@ -4970,11 +4975,6 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
mac->phylink = phylink;
- if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_2P5GPHY) &&
- id == MTK_GMAC2_ID)
- __set_bit(PHY_INTERFACE_MODE_INTERNAL,
- mac->phylink_config.supported_interfaces);
-
SET_NETDEV_DEV(eth->netdev[id], eth->dev);
eth->netdev[id]->watchdog_timeo = 5 * HZ;
eth->netdev[id]->netdev_ops = &mtk_netdev_ops;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] amt: don't read the IP source address from a reallocated skb header
From: Taehee Yoo @ 2026-06-15 15:13 UTC (permalink / raw)
To: Michael Bommarito; +Cc: netdev, linux-kernel
In-Reply-To: <20260614155539.3106537-1-michael.bommarito@gmail.com>
On Mon, Jun 15, 2026 at 12:56 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
Hi Michael,
Thanks a lot for your work!
> amt_update_handler() caches iph = ip_hdr(skb) and then calls
> pskb_may_pull(). pskb_may_pull() can reallocate the skb head: the new
> head is allocated and the old one is freed. The cached iph is not
> refreshed, so the following tunnel lookup reads iph->saddr from the
> freed head. On an AMT relay this lookup runs for every incoming
> membership update, before the update's nonce and response MAC are
> validated.
>
> The sibling handlers amt_multicast_data_handler() and
> amt_membership_query_handler() re-read ip_hdr() after the pull and are
> not affected; only amt_update_handler() keeps the pre-pull pointer.
>
> Snapshot the source address before the pulls and match against the
> snapshot.
>
> The stale read was confirmed by instrumentation rather than a sanitizer:
> after the head is reallocated the comparison reads from the freed old
> head. KASAN does not flag it because the skb head is released through
> the page-fragment free path, which is not poisoned on free.
>
> Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
> Cc: stable@vger.kernel.org # v5.16+
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Thanks for the fix.
Please tag this as [PATCH net] in the subject, since it's a bug fix:
[PATCH net] amt: don't read the IP source address from a reallocated skb header
You can drop the Cc: stable.
The Fixes: tag is enough for the stable backport process to pick it up.
Please send a v2 with the above changes. You can carry my ack:
Acked-by: Taehee Yoo <ap420073@gmail.com>
Thank you so much!
Taehee Yoo
> ---
> Confirmed on x86_64 by instrumenting the comparison: with the update
> packet built so the first pskb_may_pull() reallocates the head (it pulls
> bytes out of a page fragment with no tailroom), the read runs against
> the freed old head -- the head pointer moves and the old page's refcount
> is 0. Neither generic KASAN nor arm64 HW-tag KASAN reports it: page-
> fragment frees are not synchronously poisoned, and under MTE the freed
> page keeps a tag matching the stale pointer, so this class of stale-
> header read escapes the usual fuzzing oracles. On a live relay the freed
> head is also exposed to reuse by later skb allocations.
>
> amtdbg: cmp reads iph=...e000 (skb->head=...384380) stale_head=1 ref=0
>
> A KUnit covering the re-read can follow separately.
>
> drivers/net/amt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/amt.c b/drivers/net/amt.c
> index f2f3139..af6e28d 100644
> --- a/drivers/net/amt.c
> +++ b/drivers/net/amt.c
> @@ -2455,8 +2455,10 @@ static bool amt_update_handler(struct amt_dev *amt, struct sk_buff *skb)
> struct ethhdr *eth;
> struct iphdr *iph;
> int len, hdr_size;
> + __be32 saddr;
>
> iph = ip_hdr(skb);
> + saddr = iph->saddr;
>
> hdr_size = sizeof(*amtmu) + sizeof(struct udphdr);
> if (!pskb_may_pull(skb, hdr_size))
> @@ -2472,7 +2474,7 @@ static bool amt_update_handler(struct amt_dev *amt, struct sk_buff *skb)
> skb_reset_network_header(skb);
>
> list_for_each_entry_rcu(tunnel, &amt->tunnel_list, list) {
> - if (tunnel->ip4 == iph->saddr) {
> + if (tunnel->ip4 == saddr) {
> if ((amtmu->nonce == tunnel->nonce &&
> amtmu->response_mac == tunnel->mac)) {
> mod_delayed_work(amt_wq, &tunnel->gc_wq,
> base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v1 bpf-next 0/2] bpf: bpf_redirect_peer egress redirection
From: Paul Chaignon @ 2026-06-15 15:15 UTC (permalink / raw)
To: Jordan Rife
Cc: bpf, netdev, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Stanislav Fomichev
In-Reply-To: <20260613183424.1198073-1-jordan@jrife.io>
On Sat, Jun 13, 2026 at 11:34:04AM -0700, Jordan Rife wrote:
> We have several use cases where a pod injects traffic into the datapath
> of another so that the traffic appears to have originated from that
> pod. One such use case is a synthetic flow generator which injects
> synthetic traffic into a pod's datapath to enable dynamic probing and
> debugging. Another is a transparent proxy where connections originating
> from one pod are redirected towards another which proxies that
> connection. The new connection is bound to the IP of the original pod
> using IP_TRANSPARENT and its traffic is injected into that pod's
> datapath and handled as if it had originated there. This can be used for
> mTLS, etc.
>
> We use bpf_redirect(BPF_F_INGRESS) to direct traffic leaving the proxy,
> flow generator, etc. towards the target pod, ensuring that eBPF programs
> that are meant to intercept traffic leaving that pod are executed.
> However, this doesn't work with netkit.
>
> With netkit, an ingress redirection from proxy to workload skips eBPF
> programs that are meant to intercept traffic leaving the pod, since they
> reside on the netkit peer device. One workaround is to attach the
> same program to both the netkit peer device and the TCX ingress hook for
> the netkit pair's primary interface, but
>
> a) This seems hacky and we need to be careful not to run the same
> program twice for the same skb in cases where we want to pass that
> traffic to the host stack.
> b) We're trying to keep the proxy redirection / traffic injection
> systems as modular and separated from Cilium as possible, the system
> that manages netkit setup and core eBPF programming.
>
> It would be handy if instead we could redirect traffic directly from
> one netkit peer device to another. This patch proposes an extension
> to bpf_redirect_peer to allow us to do just that.
>
> With this patch, the BPF_F_INGRESS flag tells bpf_redirect_peer to emit
> the skb in the egress direction of the target interface's peer device
> While the main use case is netkit, I suppose you could also use this
> mode with veth as well if, e.g., there were some eBPF programs attached
> to that side of the veth pair that needed to intercept traffic.
>
> +---------------------------------------------------------------------+
> | +-------------------------+ 6. bpf_redirect_neigh(eth0) |
> | | pod (10.244.0.10) | ------------------------ |
> | | | | | |
> | | +--------+ | | +---------+ | |
> | | 1. packet -->| | | | | | | |
> | | leaves ^ | netkit |<===========|======| netkit | | |
> | | | | peer |=======(eBPF)=====>| primary | | |
> | | | | | | | | | | |
> | | | +--------+ | | +---------+ | |
> | | | | | 2. bpf_redirect v |
> | +-----------|-------------+ |___________________ +-------|
> | | | | eth0 |
> | | 5. bpf_redirect_peer(BPF_F_INGRESS) | +-------|
> | |________________________ | |
> | +-------------------------+ | | |
> | | proxy (10.244.0.11) | | | |
> | | IP_TRANSPARENT | | | |
> | | +--------+ | | +---------+ | |
> | | 3. packet <--| | | | | |<-- |
> | | enters | netkit |<===========|======| netkit | |
> | | [proxy] | peer |=======(eBPF)=====>| primary | |
> | | 4. packet -->| | | | | |
> | | leaves +--------+ | +---------+ |
> | | sip=10.244.0.10 | |
> | +-------------------------+ |
> +---------------------------------------------------------------------+
>
> Using the proxy use case as an example, in step 5 we would redirect
> traffic leaving the proxy towards the pod's peer device using
> bpf_redirect_peer(BPF_F_INGRESS).
>
> As a bonus, since the skb doesn't have to go through the backlog queue
> it can take full advantage of netkit's performance benefits. I set up a
The motivation makes sense. Cilium could probably use this as well to
avoid some of the hacks we have around proxy reinjection.
> test where outgoing iperf3 traffic is injected into the datapath of
> another pod using either bpf_redirect_peer(BPF_F_INGRESS) or
> bpf_redirect(BPF_F_INGRESS). I used Cilium's eBPF host routing mode
> which skips the host stack and uses BPF redirect helpers to do all the
> routing.
>
> (net.ipv4.tcp_congestion_control=cubic,mtu=1500,100GiB link,Cilium
> eBPF host routing mode)
>
> BASELINE [bpf_redirect(BPF_F_INGRESS)]
> 1. [iperf pod] ==bpf_redirect([pod b], BPF_F_INGRESS)==> [pod b]
> 2. [pod b] ==bpf_redirect_neigh([eth0])==> eth0
> 3. eth0 ==over network==> [host b]
>
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-60.00 sec 231 GBytes 33.0 Gbits/sec 12060 sender
> [ 5] 0.00-60.00 sec 230 GBytes 33.0 Gbits/sec receiver
>
> TEST [bpf_redirect_peer(BPF_F_INGRESS)]
> 1. [iperf pod] ==bpf_redirect_peer([pod b], BPF_F_INGRESS)==> [pod b]
> 2. [pod b] ==bpf_redirect_neigh([eth0])==> eth0
> 3. eth0 ==over network==> [host b]
>
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec 0 sender
> [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec receiver
>
> In this test, using bpf_redirect_peer(BPF_F_INGRESS) for the hop from
> [iperf pod] to [pod b] led to ~18% more throughput compared to
> bpf_redirect(BPF_F_INGRESS).
>
> Note: I wasn't sure about the flag name. I can see where BPF_F_INGRESS
> might be confusing, since technically it's an egress redirection
> from the perspective of the peer device's namespace. But, I didn't
> want to add a BPF_F_EGRESS flag just for this and convinced myself
> it makes sense, because from the perspective of the caller the skb
> will be flowing towards the current namespace.
IMO, calling it BPF_F_EGRESS would be less confusing. It's a shame we
can't have the same flag API between bpf_redirect() and
bpf_redirect_peer(), but this is creating inconsistent semantics for
the terms egress/ingress across the two helpers.
>
> Jordan Rife (2):
> bpf: Support BPF_F_INGRESS with bpf_redirect_peer
> selftests/bpf: Add tests for bpf_redirect_peer with BPF_F_INGRESS
>
> include/uapi/linux/bpf.h | 16 +++--
> net/core/filter.c | 14 ++--
> tools/include/uapi/linux/bpf.h | 16 +++--
> .../selftests/bpf/prog_tests/tc_redirect.c | 68 +++++++++++++++++++
> .../selftests/bpf/progs/test_tc_peer.c | 22 ++++++
> 5 files changed, 116 insertions(+), 20 deletions(-)
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: Maxime Chevallier @ 2026-06-15 15:27 UTC (permalink / raw)
To: Christian Marangi, Felix Fietkau, Lorenzo Bianconi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Russell King,
Daniel Golle, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260615151106.15438-1-ansuelsmth@gmail.com>
On 6/15/26 17:11, Christian Marangi wrote:
> Everything configured in phylink_config it's assumed to be set before
> calling phylink_create() to permit correct parsing of all the different
> modes and capabilities.
>
> Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
> internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
> probably due to an auto-rebase, placed the configuration of the INTERNAL
> interface mode for the supported_interfaces for phylink_config right after
> phylink_create() introducing a possible problem with supported interfaces
> parsing.
>
> While this doesn't currently create any problem/bug, move setting this bit
> before phylink_create() to prevent any possible regression in future code
> change in phylink core.
Agreed
>
> Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY")
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: Daniel Golle @ 2026-06-15 15:33 UTC (permalink / raw)
To: Christian Marangi
Cc: Felix Fietkau, Lorenzo Bianconi, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260615151106.15438-1-ansuelsmth@gmail.com>
On Mon, Jun 15, 2026 at 05:11:00PM +0200, Christian Marangi wrote:
> Everything configured in phylink_config it's assumed to be set before
> calling phylink_create() to permit correct parsing of all the different
> modes and capabilities.
>
> Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
> internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
> probably due to an auto-rebase, placed the configuration of the INTERNAL
> interface mode for the supported_interfaces for phylink_config right after
> phylink_create() introducing a possible problem with supported interfaces
> parsing.
>
> While this doesn't currently create any problem/bug, move setting this bit
> before phylink_create() to prevent any possible regression in future code
> change in phylink core.
>
> Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY")
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
As no user-visible bug surfaces because of that it is questionable though if
the Fixes:-tag is justified.
^ permalink raw reply
* Re: [PATCH v4 1/6] pds_core: add support for quiet devcmd failures
From: Simon Horman @ 2026-06-15 15:34 UTC (permalink / raw)
To: nikhil.rao
Cc: Simon Horman, netdev, brett.creeley, andrew+netdev, davem,
edumazet, kuba, pabeni, eric.joyner
In-Reply-To: <20260614050052.1048328-2-nikhil.rao@amd.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
pds_core: add support for quiet devcmd failures
This commit introduces support for suppressing error messages during device
commands by adding a boolean parameter to wait and lock functions. It changes
pdsc_devcmd_wait and pdsc_devcmd_locked into internal __pdsc_devcmd_wait and
__pdsc_devcmd_locked variants that handle the new messaging flag. This
functionality is intended for negotiating the PDS_CORE_IDENTITY_VERSION_2.
> diff --git a/drivers/net/ethernet/amd/pds_core/dev.c b/drivers/net/ethernet/amd/pds_core/dev.c
> index bded6b33289ce..dd9989cfe6b3f 100644
> --- a/drivers/net/ethernet/amd/pds_core/dev.c
> +++ b/drivers/net/ethernet/amd/pds_core/dev.c
[ ... ]
> -int pdsc_devcmd_locked(struct pdsc *pdsc, union pds_core_dev_cmd *cmd,
> - union pds_core_dev_comp *comp, int max_seconds)
> +static int __pdsc_devcmd_locked(struct pdsc *pdsc, union pds_core_dev_cmd *cmd,
> + union pds_core_dev_comp *comp, int max_seconds,
> + const bool do_msg)
> {
> int err;
>
> @@ -197,7 +199,7 @@ int pdsc_devcmd_locked(struct pdsc *pdsc, union pds_core_dev_cmd *cmd,
>
> memcpy_toio(&pdsc->cmd_regs->cmd, cmd, sizeof(*cmd));
> pdsc_devcmd_dbell(pdsc);
> - err = pdsc_devcmd_wait(pdsc, cmd->opcode, max_seconds);
> + err = __pdsc_devcmd_wait(pdsc, cmd->opcode, max_seconds, do_msg);
>
> if ((err == -ENXIO || err == -ETIMEDOUT) && pdsc->wq)
> queue_work(pdsc->wq, &pdsc->health_work);
[Severity: Critical]
This isn't a bug introduced by this patch, but it occurs in the function
modified here.
Can this queue_work() call trigger a use-after-free during driver removal?
Looking at pdsc_remove() in drivers/net/ethernet/amd/pds_core/main.c,
destroy_workqueue() is called but the pdsc->wq pointer is not cleared:
pdsc_remove() {
...
if (pdsc->wq)
destroy_workqueue(pdsc->wq);
mutex_lock(&pdsc->config_lock);
set_bit(PDSC_S_STOPPING_DRIVER, &pdsc->state);
pdsc_stop(pdsc);
pdsc_teardown(pdsc, PDSC_TEARDOWN_REMOVING);
...
}
Subsequently, pdsc_teardown() issues a RESET command to the firmware.
If the firmware is unresponsive and the command times out, we reach this
error path in __pdsc_devcmd_locked(). Since the pdsc->wq pointer was never
set to NULL, the check here succeeds, and it attempts to queue work to a
destroyed workqueue.
Should pdsc->wq be explicitly set to NULL immediately after being destroyed
in pdsc_remove() to prevent this?
> else
> memcpy_fromio(comp, &pdsc->cmd_regs->comp, sizeof(*comp));
>
^ permalink raw reply
* Re: [PATCH v4 3/6] pds_core: add PLDM firmware update support via devlink flash
From: Simon Horman @ 2026-06-15 15:36 UTC (permalink / raw)
To: nikhil.rao
Cc: Simon Horman, netdev, brett.creeley, andrew+netdev, davem,
edumazet, kuba, pabeni, eric.joyner
In-Reply-To: <20260614050052.1048328-4-nikhil.rao@amd.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
pds_core: add PLDM firmware update support via devlink flash
Implement PLDM FW Update in the pds_core driver using the upstream
pldmfw API. This allows updating an entire PLDM FW package at once
or updating specific firmware components by name.
> diff --git a/drivers/net/ethernet/amd/pds_core/fw.c b/drivers/net/ethernet/amd/pds_core/fw.c
> --- a/drivers/net/ethernet/amd/pds_core/fw.c
> +++ b/drivers/net/ethernet/amd/pds_core/fw.c
> [ ... ]
> @@ -195,3 +239,720 @@ int pdsc_firmware_update(struct pdsc *pdsc, const struct firmware *fw,
> [ ... ]
> +static int pdsc_flash_component_chunk(struct pdsc *pdsc, struct device *dev,
> [ ... ]
> + err = pdsc_devcmd_send_component(pdsc, info, info_sz, dma_addr,
> + copy_sz, offset, slot_id, comp);
> + if (err == -ETIMEDOUT || err == -EAGAIN) {
> + pdsc_deferred_dma_add(pdsc, deferred, dma_addr,
> + component_data, copy_sz, DMA_TO_DEVICE);
> + return err;
> + }
[Severity: High]
Can this lead to a race condition that leaks the DMA mapping and memory?
If pdsc_devcmd_send_component() encounters a timeout in the lower level
__pdsc_devcmd_locked() function, it will queue pdsc->health_work. The wrapper
function __pdsc_devcmd_with_data_nomsg() will then release the devcmd_lock
before returning the timeout error back here.
If the scheduled health_work runs and acquires devcmd_lock before this code
reaches pdsc_deferred_dma_add(), it could execute a recovery devcmd and
call pdsc_deferred_dma_free() on an empty list. When this thread resumes,
it adds the timed-out buffer to the deferred DMA list, but its cleanup
trigger has already fired, leaving the buffer leaked.
> [ ... ]
> +int pdsc_firmware_update(struct pdsc *pdsc,
> + struct devlink_flash_update_params *params,
> + struct netlink_ext_ack *extack)
> +{
> + int err;
> +
> + if (pdsc->dev_ident.version >= PDS_CORE_IDENTITY_VERSION_2 &&
> + pdsc->dev_ident.capabilities &
> + cpu_to_le64(PDS_CORE_DEV_CAP_PLDM_FW_UPDATE))
> + err = pdsc_pldm_firmware_update(pdsc, params, extack,
> + params->fw);
> + else
> + err = pdsc_legacy_firmware_update(pdsc, params->fw, extack);
[Severity: High]
Does this fallback path ignore the requested component name?
If the device does not support PLDM, the driver falls back to
pdsc_legacy_firmware_update() which only takes the params->fw pointer.
If a user requested a targeted component update using devlink, this would
ignore the component filter and flash the entire monolithic image onto
the device.
Should this explicitly check if params->component is set before falling
back, and return -EOPNOTSUPP if a component is specified on legacy
firmware?
^ permalink raw reply
* Re: [PATCH v4 1/6] pds_core: add support for quiet devcmd failures
From: Simon Horman @ 2026-06-15 15:37 UTC (permalink / raw)
To: nikhil.rao
Cc: netdev, brett.creeley, andrew+netdev, davem, edumazet, kuba,
pabeni, eric.joyner
In-Reply-To: <20260615153400.772876-3-horms@kernel.org>
On Mon, Jun 15, 2026 at 04:34:02PM +0100, Simon Horman wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
Apologies, I sent this by mistake.
I do not believe the AI-generated review for this patch
needs consideration in the context of this patchset.
I meant to forward the review for patch 3/6, which I have now done.
^ permalink raw reply
* [PATCH net-next v12 00/10] net: phy_port: SFP modules representation and phy_port listing
From: Maxime Chevallier @ 2026-06-15 15:38 UTC (permalink / raw)
To: davem, Andrew Lunn, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau, Frank Wunderlich
Hello everyone,
Here's V12 for the phy_port netlink interface.
V12 rebases on net-next, which includes some fixes for sashiko-reported
issues. It also fixes some typos here and there in the documentation.
This work extends 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.
Let's see what we can do with some examples of the new ethtool API :
- Get MII interfaces supported by an empty SFP cage :
# ethtool --show-ports eth3
Port for eth3:
Port id: 1
Supported MII interfaces : sgmii, 1000base-x, 2500base-x
Port type: sfp
- Get Combo-ports supported modes, on each port :
# ethtool --show-ports eth1
Port for eth1:
Port id: 1
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
10000baseT/Full
2500baseT/Full
5000baseT/Full
Port type: mdi
Port for eth1:
Port id: 2
Supported MII interfaces : 10gbase-r
Port type: sfp
- Get Achievable linkmodes on a SFP module (combo port with a DAC in the
SFP cage)
# ethtool --show-ports eth1
Port for eth1:
Port id: 1
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
10000baseT/Full
2500baseT/Full
5000baseT/Full
Port type: mdi
Port for eth1:
Port id: 2
Supported MII interfaces : 10gbase-r
Port type: sfp
Port for eth1:
Port id: 3
Upstream id: 2
Supported link modes: 10000baseCR/Full
Port type: mdi
Note that here, we have 3 ports :
- The Copper port
- The SFP Cage itself, marked as 'occupied'
- The SFP module
This series builds on top of phy_port and phy_link_topology to allow
tracking the ports of an interface. We maintain a list of supported
linkmodes/interfaces on each port, which allows for fine-grained
reporting of each port's capability.
What this series doesn't do :
- We don't support selecting which port is active. This is the next step.
- We only support PHY-driven combo ports. The end-goal of this whole
journey that started with phy_link_topology is to get support for MII
muxes, such as the one we have on the Turris Omnia. This will eventually
be upstreamed as well.
If you want to play around with it, here's [1] the patched ethtool that I've
been using to produce the outputs above.
Thanks !
Maxime
[1] : https://github.com/minimaxwell/ethtool/tree/mc/ethtool_port
Changelog :
Changes in V12:
- Rebased on net-next, including fixes on the phy probing and cleanup
paths
- Rebased on Jakub's netdev_ops_locked changes in phy_link_topology
- Fixed some typos reported by Andrew and sashiko in the documentation
Changes in v11:
V11:https://lore.kernel.org/r/20260521121040.1199622-1-maxime.chevallier@bootlin.com
- Aggregated Andrew's reviews :)
- Removed the "vacant" field, replaced it with "upstream_port"
Changes in V10:
V10: https://lore.kernel.org/r/20260513130521.1064094-1-maxime.chevallier@bootlin.com
- Rebase on net-next
- Rename phylink/phy_device sfp_bus_port to sfp_cage_port
- Sashiko's reviews were mostly unrealistic or wrong :(
Changes in V9:
V9: https://lore.kernel.org/r/20260403123755.175742-1-maxime.chevallier@bootlin.com
- Added missing netlink doc updates for u8->u32 conversion
- Removed dead code with a condition that can never be true in
phylink's mod_port code
- Fixed the error path in phy_sfp_connect_phy
Changes in v8:
V8: https://lore.kernel.org/r/20260325081937.571115-1-maxime.chevallier@bootlin.com
- Set the new phydev.has_sfp_mod_phy field when we're sure that no
errors occured
- Fix formatting of the copyright info in ethnl port
- Use a policy to validate the range of port_id
- Use GENL_REQ_ATTR_CHECK
- alpha-sort headers
- use u32 in netlink messages
- return better error codes
- don't check the skb len, the core does that
Changes in V7:
V7: https://lore.kernel.org/all/20260309152747.702373-1-maxime.chevallier@bootlin.com/
- Changed the port cleanup path to use list_for_each_entry_continue_reverse
- Adjusted the cleanup path in phylink for the port vacant state
- Pass the right cmd for the netlink dump message
Changes in V6:
V6: https://lore.kernel.org/r/20260304145444.442334-1-maxime.chevallier@bootlin.com
- Added some comments in th mod_port cleanup
- changed some kmalloc to kmalloc_obj
- Removed some phy_link_topo_del_port that wasn't needed
Changes in V5:
V5: https://lore.kernel.org/r/20260205092317.755906-1-maxime.chevallier@bootlin.com
- Fixed a check on a potentially un-initialized pointer, reported by
Simon
- Fixed a documentation formatting issue
- Remove a stray pr_info
- Rebased on net-next
Changes in V4:
V4 : https://lore.kernel.org/netdev/20260203172839.548524-1-maxime.chevallier@bootlin.com/
- Add a cleanup patch for the of port parsing
- Added a match to sync the port's linkmodes with the PHY's for OF
ports
- Added RTNL assert in the port_get topo helper
- nullify the bus port for phylink support
- Fix some typos
Changes in V3:
V3: https://lore.kernel.org/netdev/20260201151249.642015-1-maxime.chevallier@bootlin.com/
- Remove the sfp bus ops for nophy, and use .module_start() as
suggested by Russell
- Added missing cleanup for the topology, as per AI review
- Fixed a few typos as per Romain's review
- Changed "occupied" to "vacant" as per Romain's review
- Added missing checks for null ports, per AI review
Changes in V2:
V2: https://lore.kernel.org/netdev/20260128204526.170927-1-maxime.chevallier@bootlin.com/
- Fix the cleanup path of phy_link_topo_add_phy, as per AI review
- Fix the cleanup path of phy_sfp_probe, as per AI review
- Fix the call-site of the disconnect_nophy sfp bus ops, per AI review
- Fix the netdev-less case uin phylink, per AI review
- Fix the prototype of phy_link_topo_get_port for the stubs
- Dropped patch 11. It ended-up breaking 'allnoconfig', so instead we
built a phy_interface_names array in net/ethtool/netlink.c
- Fix an ethool-netlink spec discrepancy with the type of an attribute
- Fix the size computation in the netlink port API
- Fix the cleanup path in the netlink port API
V1: https://lore.kernel.org/netdev/20260127134202.8208-1-maxime.chevallier@bootlin.com/
Maxime Chevallier (10):
net: phy: phy_link_topology: Add a helper for opportunistic alloc
net: phy: phy_link_topology: Track ports in phy_link_topology
net: phylink: Register a phy_port for MAC-driven SFP cages
net: phy: Create SFP phy_port before registering upstream
net: phy: Represent PHY-less SFP modules with phy_port
net: phy: phy_port: Store information about a port's upstream
net: phy: phy_link_topology: Add a helper to retrieve ports
netlink: specs: Add ethernet port listing with ethtool
net: ethtool: Introduce ethtool command to list ports
Documentation: networking: Update the phy_port infrastructure
description
Documentation/netlink/specs/ethtool.yaml | 50 +++
Documentation/networking/ethtool-netlink.rst | 34 ++
Documentation/networking/phy-port.rst | 26 +-
MAINTAINERS | 1 +
drivers/net/phy/phy-caps.h | 2 +
drivers/net/phy/phy_caps.c | 26 ++
drivers/net/phy/phy_device.c | 183 ++++++++-
drivers/net/phy/phy_link_topology.c | 82 +++-
drivers/net/phy/phylink.c | 128 +++++-
include/linux/phy.h | 10 +
include/linux/phy_link_topology.h | 39 ++
include/linux/phy_port.h | 5 +
.../uapi/linux/ethtool_netlink_generated.h | 19 +
net/core/dev.c | 1 +
net/ethtool/Makefile | 2 +-
net/ethtool/netlink.c | 25 ++
net/ethtool/netlink.h | 9 +
net/ethtool/port.c | 373 ++++++++++++++++++
18 files changed, 981 insertions(+), 34 deletions(-)
create mode 100644 net/ethtool/port.c
--
2.54.0
^ permalink raw reply
* [PATCH net-next v12 01/10] net: phy: phy_link_topology: Add a helper for opportunistic alloc
From: Maxime Chevallier @ 2026-06-15 15:38 UTC (permalink / raw)
To: davem, Andrew Lunn, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau, Frank Wunderlich
In-Reply-To: <20260615153907.862987-1-maxime.chevallier@bootlin.com>
The phy_link_topology structure stores information about the PHY-related
components connected to a net_device. It is opportunistically allocated,
when we add the first item to the topology, as this is not relevant for
all kinds of net_devices.
In preparation for the addition of phy_port tracking in the topology,
let's make a dedicated helper for that allocation sequence.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/phy/phy_link_topology.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
index 4134de7ae313..99f1842afcbd 100644
--- a/drivers/net/phy/phy_link_topology.c
+++ b/drivers/net/phy/phy_link_topology.c
@@ -28,11 +28,28 @@ static int netdev_alloc_phy_link_topology(struct net_device *dev)
return 0;
}
+static struct phy_link_topology *phy_link_topo_get_or_alloc(struct net_device *dev)
+{
+ int ret;
+
+ if (dev->link_topo)
+ return dev->link_topo;
+
+ /* The topology is allocated the first time we add an object to it.
+ * It is freed alongside the netdev.
+ */
+ ret = netdev_alloc_phy_link_topology(dev);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return dev->link_topo;
+}
+
int phy_link_topo_add_phy(struct net_device *dev,
struct phy_device *phy,
enum phy_upstream upt, void *upstream)
{
- struct phy_link_topology *topo = dev->link_topo;
+ struct phy_link_topology *topo;
struct phy_device_node *pdn;
int ret;
@@ -45,13 +62,9 @@ int phy_link_topo_add_phy(struct net_device *dev,
if (WARN_ON_ONCE(netdev_need_ops_lock(dev)))
return -EOPNOTSUPP;
- if (!topo) {
- ret = netdev_alloc_phy_link_topology(dev);
- if (ret)
- return ret;
-
- topo = dev->link_topo;
- }
+ topo = phy_link_topo_get_or_alloc(dev);
+ if (IS_ERR(topo))
+ return PTR_ERR(topo);
pdn = kzalloc_obj(*pdn);
if (!pdn)
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v12 02/10] net: phy: phy_link_topology: Track ports in phy_link_topology
From: Maxime Chevallier @ 2026-06-15 15:38 UTC (permalink / raw)
To: davem, Andrew Lunn, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau, Frank Wunderlich
In-Reply-To: <20260615153907.862987-1-maxime.chevallier@bootlin.com>
phy_port is aimed at representing the various physical interfaces of a
net_device. They can be controlled by various components in the link,
such as the Ethernet PHY, the Ethernet MAC, and SFP module, etc.
Let's therefore make so we keep track of all the ports connected to a
netdev in phy_link_topology. The only ports added for now are phy-driven
ports.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/phy/phy_link_topology.c | 53 +++++++++++++++++++++++++++++
include/linux/phy_link_topology.h | 18 ++++++++++
include/linux/phy_port.h | 2 ++
net/core/dev.c | 1 +
4 files changed, 74 insertions(+)
diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
index 99f1842afcbd..a7ff36a12c4e 100644
--- a/drivers/net/phy/phy_link_topology.c
+++ b/drivers/net/phy/phy_link_topology.c
@@ -7,6 +7,7 @@
*/
#include <linux/phy_link_topology.h>
+#include <linux/phy_port.h>
#include <linux/phy.h>
#include <linux/rtnetlink.h>
#include <linux/xarray.h>
@@ -23,6 +24,9 @@ static int netdev_alloc_phy_link_topology(struct net_device *dev)
xa_init_flags(&topo->phys, XA_FLAGS_ALLOC1);
topo->next_phy_index = 1;
+ xa_init_flags(&topo->ports, XA_FLAGS_ALLOC1);
+ topo->next_port_index = 1;
+
dev->link_topo = topo;
return 0;
@@ -45,12 +49,45 @@ static struct phy_link_topology *phy_link_topo_get_or_alloc(struct net_device *d
return dev->link_topo;
}
+int phy_link_topo_add_port(struct net_device *dev, struct phy_port *port)
+{
+ struct phy_link_topology *topo;
+ int ret;
+
+ topo = phy_link_topo_get_or_alloc(dev);
+ if (IS_ERR(topo))
+ return PTR_ERR(topo);
+
+ /* Attempt to re-use a previously allocated port_id */
+ if (port->id)
+ ret = xa_insert(&topo->ports, port->id, port, GFP_KERNEL);
+ else
+ ret = xa_alloc_cyclic(&topo->ports, &port->id, port,
+ xa_limit_32b, &topo->next_port_index,
+ GFP_KERNEL);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_add_port);
+
+void phy_link_topo_del_port(struct net_device *dev, struct phy_port *port)
+{
+ struct phy_link_topology *topo = dev->link_topo;
+
+ if (!topo)
+ return;
+
+ xa_erase(&topo->ports, port->id);
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_del_port);
+
int phy_link_topo_add_phy(struct net_device *dev,
struct phy_device *phy,
enum phy_upstream upt, void *upstream)
{
struct phy_link_topology *topo;
struct phy_device_node *pdn;
+ struct phy_port *port;
int ret;
/* ethtool ops may run without rtnl_lock, and rtnl_lock is what
@@ -99,8 +136,20 @@ int phy_link_topo_add_phy(struct net_device *dev,
if (ret < 0)
goto err;
+ /* Add all the PHY's ports to the topology */
+ list_for_each_entry(port, &phy->ports, head) {
+ ret = phy_link_topo_add_port(dev, port);
+ if (ret)
+ goto del_ports;
+ }
+
return 0;
+del_ports:
+ list_for_each_entry_continue_reverse(port, &phy->ports, head)
+ phy_link_topo_del_port(dev, port);
+
+ xa_erase(&topo->phys, phy->phyindex);
err:
kfree(pdn);
return ret;
@@ -112,10 +161,14 @@ void phy_link_topo_del_phy(struct net_device *dev,
{
struct phy_link_topology *topo = dev->link_topo;
struct phy_device_node *pdn;
+ struct phy_port *port;
if (!topo)
return;
+ list_for_each_entry(port, &phy->ports, head)
+ phy_link_topo_del_port(dev, port);
+
pdn = xa_erase(&topo->phys, phy->phyindex);
/* We delete the PHY from the topology, however we don't re-set the
diff --git a/include/linux/phy_link_topology.h b/include/linux/phy_link_topology.h
index 95575f68d5bc..296ee514ba46 100644
--- a/include/linux/phy_link_topology.h
+++ b/include/linux/phy_link_topology.h
@@ -16,11 +16,15 @@
struct xarray;
struct phy_device;
+struct phy_port;
struct sfp_bus;
struct phy_link_topology {
struct xarray phys;
u32 next_phy_index;
+
+ struct xarray ports;
+ u32 next_port_index;
};
struct phy_device_node {
@@ -48,6 +52,9 @@ int phy_link_topo_add_phy(struct net_device *dev,
void phy_link_topo_del_phy(struct net_device *dev, struct phy_device *phy);
+int phy_link_topo_add_port(struct net_device *dev, struct phy_port *port);
+void phy_link_topo_del_port(struct net_device *dev, struct phy_port *port);
+
static inline struct phy_device *
phy_link_topo_get_phy(struct net_device *dev, u32 phyindex)
{
@@ -77,6 +84,17 @@ static inline void phy_link_topo_del_phy(struct net_device *dev,
{
}
+static inline int phy_link_topo_add_port(struct net_device *dev,
+ struct phy_port *port)
+{
+ return 0;
+}
+
+static inline void phy_link_topo_del_port(struct net_device *dev,
+ struct phy_port *port)
+{
+}
+
static inline struct phy_device *
phy_link_topo_get_phy(struct net_device *dev, u32 phyindex)
{
diff --git a/include/linux/phy_port.h b/include/linux/phy_port.h
index 0ef0f5ce4709..4e2a3fdd2f2e 100644
--- a/include/linux/phy_port.h
+++ b/include/linux/phy_port.h
@@ -36,6 +36,7 @@ struct phy_port_ops {
/**
* struct phy_port - A representation of a network device physical interface
*
+ * @id: Unique identifier for the port within the topology
* @head: Used by the port's parent to list ports
* @parent_type: The type of device this port is directly connected to
* @phy: If the parent is PHY_PORT_PHYDEV, the PHY controlling that port
@@ -52,6 +53,7 @@ struct phy_port_ops {
* @is_sfp: Indicates if this port drives an SFP cage.
*/
struct phy_port {
+ u32 id;
struct list_head head;
enum phy_port_parent parent_type;
union {
diff --git a/net/core/dev.c b/net/core/dev.c
index 202e35acb15b..3a91b8efa2bc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -11300,6 +11300,7 @@ static void netdev_free_phy_link_topology(struct net_device *dev)
if (IS_ENABLED(CONFIG_PHYLIB) && topo) {
xa_destroy(&topo->phys);
+ xa_destroy(&topo->ports);
kfree(topo);
dev->link_topo = NULL;
}
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v12 03/10] net: phylink: Register a phy_port for MAC-driven SFP cages
From: Maxime Chevallier @ 2026-06-15 15:38 UTC (permalink / raw)
To: davem, Andrew Lunn, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau, Frank Wunderlich
In-Reply-To: <20260615153907.862987-1-maxime.chevallier@bootlin.com>
phy_port tracks the interfaces that a netdevice feeds into. SFP cages are
such ports, but so far we are only tracking the ones that are driven by
PHYs acting as media-converters.
Let's populate a phy_port for MAC driver SFP cages, handled by phylink.
This phy_port represents the SFP cage itself, and not the module that
may be plugged into it. It's therefore not an MDI interface, so only the
'interfaces' field is relevant here.
The phy_port is only populated for 'NETDEV' phylink instances, as
otherwise we don't have any topology to attach the port to.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/phy/phylink.c | 53 +++++++++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 087ac63f9193..640b3f4f45f9 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -14,6 +14,8 @@
#include <linux/of_mdio.h>
#include <linux/phy.h>
#include <linux/phy_fixed.h>
+#include <linux/phy_link_topology.h>
+#include <linux/phy_port.h>
#include <linux/phylink.h>
#include <linux/rtnetlink.h>
#include <linux/spinlock.h>
@@ -93,6 +95,7 @@ struct phylink {
DECLARE_PHY_INTERFACE_MASK(sfp_interfaces);
__ETHTOOL_DECLARE_LINK_MODE_MASK(sfp_support);
u8 sfp_port;
+ struct phy_port *sfp_cage_port;
struct eee_config eee_cfg;
@@ -1765,6 +1768,46 @@ static void phylink_fixed_poll(struct timer_list *t)
static const struct sfp_upstream_ops sfp_phylink_ops;
+static int phylink_create_sfp_cage_port(struct phylink *pl)
+{
+ struct phy_port *port;
+ int ret = 0;
+
+ if (!pl->netdev || !pl->sfp_bus)
+ return 0;
+
+ port = phy_port_alloc();
+ if (!port)
+ return -ENOMEM;
+
+ port->is_sfp = true;
+ port->is_mii = true;
+ port->active = true;
+
+ phy_interface_and(port->interfaces, pl->config->supported_interfaces,
+ phylink_sfp_interfaces);
+ phy_port_update_supported(port);
+
+ ret = phy_link_topo_add_port(pl->netdev, port);
+ if (ret)
+ phy_port_destroy(port);
+ else
+ pl->sfp_cage_port = port;
+
+ return ret;
+}
+
+static void phylink_destroy_sfp_cage_port(struct phylink *pl)
+{
+ if (pl->netdev && pl->sfp_cage_port)
+ phy_link_topo_del_port(pl->netdev, pl->sfp_cage_port);
+
+ if (pl->sfp_cage_port)
+ phy_port_destroy(pl->sfp_cage_port);
+
+ pl->sfp_cage_port = NULL;
+}
+
static int phylink_register_sfp(struct phylink *pl,
const struct fwnode_handle *fwnode)
{
@@ -1782,9 +1825,18 @@ static int phylink_register_sfp(struct phylink *pl,
pl->sfp_bus = bus;
+ ret = phylink_create_sfp_cage_port(pl);
+ if (ret) {
+ sfp_bus_put(bus);
+ return ret;
+ }
+
ret = sfp_bus_add_upstream(bus, pl, &sfp_phylink_ops);
sfp_bus_put(bus);
+ if (ret)
+ phylink_destroy_sfp_cage_port(pl);
+
return ret;
}
@@ -1946,6 +1998,7 @@ EXPORT_SYMBOL_GPL(phylink_create);
void phylink_destroy(struct phylink *pl)
{
sfp_bus_del_upstream(pl->sfp_bus);
+ phylink_destroy_sfp_cage_port(pl);
if (pl->link_gpio)
gpiod_put(pl->link_gpio);
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v12 04/10] net: phy: Create SFP phy_port before registering upstream
From: Maxime Chevallier @ 2026-06-15 15:39 UTC (permalink / raw)
To: davem, Andrew Lunn, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau, Frank Wunderlich
In-Reply-To: <20260615153907.862987-1-maxime.chevallier@bootlin.com>
When dealing with PHY-driven SFP, we create a phy_port representing the
SFP bus when we know we have such a bus.
We can move the port creation before registering the sfp upstream ops,
as long as we know the SFP bus is there. This will allow passing the
phy_port along with the upstream information to the SFP bus.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/phy/phy_device.c | 55 +++++++++++++++++++++++++-----------
1 file changed, 39 insertions(+), 16 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0615228459ef..ad2546169360 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1673,13 +1673,13 @@ static void phy_del_port(struct phy_device *phydev, struct phy_port *port)
phydev->n_ports--;
}
-static int phy_setup_sfp_port(struct phy_device *phydev)
+static struct phy_port *phy_setup_sfp_port(struct phy_device *phydev)
{
struct phy_port *port = phy_port_alloc();
int ret;
if (!port)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
port->parent_type = PHY_PORT_PHY;
port->phy = phydev;
@@ -1694,10 +1694,12 @@ static int phy_setup_sfp_port(struct phy_device *phydev)
* when attaching the port to the phydev.
*/
ret = phy_add_port(phydev, port);
- if (ret)
+ if (ret) {
phy_port_destroy(port);
+ return ERR_PTR(ret);
+ }
- return ret;
+ return port;
}
/**
@@ -1706,25 +1708,46 @@ static int phy_setup_sfp_port(struct phy_device *phydev)
*/
static int phy_sfp_probe(struct phy_device *phydev)
{
+ struct phy_port *port = NULL;
struct sfp_bus *bus;
- int ret = 0;
+ int ret;
- if (phydev->mdio.dev.fwnode) {
- bus = sfp_bus_find_fwnode(phydev->mdio.dev.fwnode);
- if (IS_ERR(bus))
- return PTR_ERR(bus);
+ if (!phydev->mdio.dev.fwnode)
+ return 0;
- phydev->sfp_bus = bus;
+ bus = sfp_bus_find_fwnode(phydev->mdio.dev.fwnode);
+ if (IS_ERR(bus))
+ return PTR_ERR(bus);
- ret = sfp_bus_add_upstream(bus, phydev, &sfp_phydev_ops);
- sfp_bus_put(bus);
+ phydev->sfp_bus = bus;
- if (ret)
- phydev->sfp_bus = NULL;
+ if (bus) {
+ port = phy_setup_sfp_port(phydev);
+ if (IS_ERR(port)) {
+ ret = PTR_ERR(port);
+ goto out_sfp;
+ }
}
- if (!ret && phydev->sfp_bus)
- ret = phy_setup_sfp_port(phydev);
+ ret = sfp_bus_add_upstream(bus, phydev, &sfp_phydev_ops);
+ if (ret)
+ goto out_port;
+
+ /* sfp_bus_add_upstream() grabs a ref to the sfp bus on success, it's
+ * safe to release it now.
+ */
+ sfp_bus_put(bus);
+
+ return ret;
+
+out_port:
+ if (port) {
+ phy_del_port(phydev, port);
+ phy_port_destroy(port);
+ }
+out_sfp:
+ sfp_bus_put(bus);
+ phydev->sfp_bus = NULL;
return ret;
}
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v12 05/10] net: phy: Represent PHY-less SFP modules with phy_port
From: Maxime Chevallier @ 2026-06-15 15:39 UTC (permalink / raw)
To: davem, Andrew Lunn, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau, Frank Wunderlich
In-Reply-To: <20260615153907.862987-1-maxime.chevallier@bootlin.com>
Now that the SFP bus infrastructure notifies when PHY-less modules are
connected, we can create a phy_port to represent it. Instead of letting
the SFP subsystem handle that, the Bus' upstream is in charge of
maintaining that phy_port and register it to the topology, as the
upstream (in this case a phy device) is directly interacting with the
underlying net_device.
Add a phy_caps helper to get the achievable modes on this module based
on what the phy_port representing the bus supports.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/phy/phy-caps.h | 2 +
drivers/net/phy/phy_caps.c | 26 +++++++++
drivers/net/phy/phy_device.c | 101 +++++++++++++++++++++++++++++++++--
drivers/net/phy/phylink.c | 76 ++++++++++++++++++++++++--
include/linux/phy.h | 6 +++
5 files changed, 204 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/phy-caps.h b/drivers/net/phy/phy-caps.h
index 421088e6f6e8..ec3d39a0ae06 100644
--- a/drivers/net/phy/phy-caps.h
+++ b/drivers/net/phy/phy-caps.h
@@ -66,5 +66,7 @@ void phy_caps_medium_get_supported(unsigned long *supported,
enum ethtool_link_medium medium,
int lanes);
u32 phy_caps_mediums_from_linkmodes(unsigned long *linkmodes);
+void phy_caps_linkmode_filter_ifaces(unsigned long *to, const unsigned long *from,
+ const unsigned long *interfaces);
#endif /* __PHY_CAPS_H */
diff --git a/drivers/net/phy/phy_caps.c b/drivers/net/phy/phy_caps.c
index 942d43191561..558e4df4d63c 100644
--- a/drivers/net/phy/phy_caps.c
+++ b/drivers/net/phy/phy_caps.c
@@ -445,3 +445,29 @@ u32 phy_caps_mediums_from_linkmodes(unsigned long *linkmodes)
return mediums;
}
EXPORT_SYMBOL_GPL(phy_caps_mediums_from_linkmodes);
+
+/**
+ * phy_caps_linkmode_filter_ifaces() - Filter linkmodes with an interface list
+ * @to: Stores the filtered linkmodes
+ * @from: Linkmodes to filter
+ * @interfaces: Bitfield of phy_interface_t that we use for filtering
+ *
+ * Filter the provided linkmodes, only to keep the ones we can possibly achieve
+ * when using any of the provided MII interfaces.
+ */
+void phy_caps_linkmode_filter_ifaces(unsigned long *to,
+ const unsigned long *from,
+ const unsigned long *interfaces)
+{
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(ifaces_supported) = {};
+ unsigned int ifaces_caps = 0;
+ phy_interface_t interface;
+
+ for_each_set_bit(interface, interfaces, PHY_INTERFACE_MODE_MAX)
+ ifaces_caps |= phy_caps_from_interface(interface);
+
+ phy_caps_linkmodes(ifaces_caps, ifaces_supported);
+
+ linkmode_and(to, from, ifaces_supported);
+}
+EXPORT_SYMBOL_GPL(phy_caps_linkmode_filter_ifaces);
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ad2546169360..c72582701e66 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1490,11 +1490,21 @@ static int phy_sfp_connect_phy(void *upstream, struct phy_device *phy)
{
struct phy_device *phydev = upstream;
struct net_device *dev = phydev->attached_dev;
+ int ret;
- if (dev)
- return phy_link_topo_add_phy(dev, phy, PHY_UPSTREAM_PHY, phydev);
+ phydev->has_sfp_mod_phy = true;
- return 0;
+ /* If we aren't attached to a netdev, we can't add the SFP PHY to its
+ * topology.
+ */
+ if (!dev)
+ return 0;
+
+ ret = phy_link_topo_add_phy(dev, phy, PHY_UPSTREAM_PHY, phydev);
+ if (ret)
+ phydev->has_sfp_mod_phy = false;
+
+ return ret;
}
/**
@@ -1512,6 +1522,8 @@ static void phy_sfp_disconnect_phy(void *upstream, struct phy_device *phy)
struct phy_device *phydev = upstream;
struct net_device *dev = phydev->attached_dev;
+ phydev->has_sfp_mod_phy = false;
+
if (dev)
phy_link_topo_del_phy(dev, phy);
}
@@ -1617,6 +1629,75 @@ static void phy_sfp_link_down(void *upstream)
port->ops->link_down(port);
}
+static int phy_add_sfp_mod_port(struct phy_device *phydev)
+{
+ const struct sfp_module_caps *caps;
+ struct phy_port *port;
+ int ret = 0;
+
+ /* Create mod port */
+ port = phy_port_alloc();
+ if (!port)
+ return -ENOMEM;
+
+ port->active = true;
+
+ caps = sfp_get_module_caps(phydev->sfp_bus);
+
+ phy_caps_linkmode_filter_ifaces(port->supported, caps->link_modes,
+ phydev->sfp_cage_port->interfaces);
+
+ if (phydev->attached_dev) {
+ ret = phy_link_topo_add_port(phydev->attached_dev, port);
+ if (ret) {
+ phy_port_destroy(port);
+ return ret;
+ }
+ }
+
+ /* we don't use phy_add_port() here as the module port isn't a direct
+ * interface from the PHY, but rather an extension to the sfp-bus, that
+ * is already represented by its own phy_port
+ */
+ phydev->mod_port = port;
+
+ return 0;
+}
+
+static void phy_del_sfp_mod_port(struct phy_device *phydev)
+{
+ if (!phydev->mod_port)
+ return;
+
+ if (phydev->attached_dev)
+ phy_link_topo_del_port(phydev->attached_dev, phydev->mod_port);
+
+ phy_port_destroy(phydev->mod_port);
+ phydev->mod_port = NULL;
+}
+
+static int phy_sfp_module_start(void *upstream)
+{
+ struct phy_device *phydev = upstream;
+
+ /* If there's a downstream SFP module, and it doesn't contain a PHY
+ * device, let's create a phy_port to represent that module.
+ */
+ if (!phydev->has_sfp_mod_phy)
+ return phy_add_sfp_mod_port(phydev);
+
+ return 0;
+}
+
+static void phy_sfp_module_stop(void *upstream)
+{
+ struct phy_device *phydev = upstream;
+
+ /* Called upon module removal or upstream removal */
+ if (!phydev->has_sfp_mod_phy)
+ phy_del_sfp_mod_port(phydev);
+}
+
static const struct sfp_upstream_ops sfp_phydev_ops = {
.attach = phy_sfp_attach,
.detach = phy_sfp_detach,
@@ -1626,6 +1707,8 @@ static const struct sfp_upstream_ops sfp_phydev_ops = {
.link_down = phy_sfp_link_down,
.connect_phy = phy_sfp_connect_phy,
.disconnect_phy = phy_sfp_disconnect_phy,
+ .module_start = phy_sfp_module_start,
+ .module_stop = phy_sfp_module_stop,
};
static int phy_add_port(struct phy_device *phydev, struct phy_port *port)
@@ -1744,11 +1827,14 @@ static int phy_sfp_probe(struct phy_device *phydev)
if (port) {
phy_del_port(phydev, port);
phy_port_destroy(port);
+ port = NULL;
}
out_sfp:
sfp_bus_put(bus);
phydev->sfp_bus = NULL;
+ phydev->sfp_cage_port = port;
+
return ret;
}
@@ -1838,6 +1924,12 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
err = phy_link_topo_add_phy(dev, phydev, PHY_UPSTREAM_MAC, dev);
if (err)
goto error;
+
+ if (phydev->mod_port) {
+ err = phy_link_topo_add_port(dev, phydev->mod_port);
+ if (err)
+ goto error;
+ }
}
/* Some Ethernet drivers try to connect to a PHY device before
@@ -1974,6 +2066,8 @@ void phy_detach(struct phy_device *phydev)
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
phy_link_topo_del_phy(dev, phydev);
+ if (phydev->mod_port)
+ phy_link_topo_del_port(dev, phydev->mod_port);
}
phydev->phy_link_change = NULL;
@@ -3840,6 +3934,7 @@ static int phy_remove(struct device *dev)
sfp_bus_del_upstream(phydev->sfp_bus);
phydev->sfp_bus = NULL;
+ phydev->sfp_cage_port = NULL;
phy_cleanup_ports(phydev);
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 640b3f4f45f9..59ea3a2e5da4 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -96,6 +96,7 @@ struct phylink {
__ETHTOOL_DECLARE_LINK_MODE_MASK(sfp_support);
u8 sfp_port;
struct phy_port *sfp_cage_port;
+ struct phy_port *mod_port;
struct eee_config eee_cfg;
@@ -1790,10 +1791,15 @@ static int phylink_create_sfp_cage_port(struct phylink *pl)
ret = phy_link_topo_add_port(pl->netdev, port);
if (ret)
- phy_port_destroy(port);
- else
- pl->sfp_cage_port = port;
+ goto out_destroy_port;
+
+ pl->sfp_cage_port = port;
+
+ return 0;
+out_destroy_port:
+ phy_port_destroy(port);
+ pl->sfp_cage_port = NULL;
return ret;
}
@@ -3924,14 +3930,65 @@ static void phylink_sfp_module_remove(void *upstream)
phy_interface_zero(pl->sfp_interfaces);
}
+static int phylink_add_sfp_mod_port(struct phylink *pl)
+{
+ const struct sfp_module_caps *caps;
+ struct phy_port *port;
+ int ret = 0;
+
+ if (!pl->sfp_cage_port)
+ return 0;
+
+ /* Create mod port */
+ port = phy_port_alloc();
+ if (!port)
+ return -ENOMEM;
+
+ port->active = true;
+
+ caps = sfp_get_module_caps(pl->sfp_bus);
+
+ phy_caps_linkmode_filter_ifaces(port->supported, caps->link_modes,
+ pl->sfp_cage_port->interfaces);
+
+ if (pl->netdev) {
+ ret = phy_link_topo_add_port(pl->netdev, port);
+ if (ret) {
+ phy_port_destroy(port);
+ return ret;
+ }
+ }
+
+ pl->mod_port = port;
+
+ return 0;
+}
+
+static void phylink_del_sfp_mod_port(struct phylink *pl)
+{
+ if (!pl->mod_port)
+ return;
+
+ if (pl->netdev)
+ phy_link_topo_del_port(pl->netdev, pl->mod_port);
+
+ phy_port_destroy(pl->mod_port);
+ pl->mod_port = NULL;
+}
+
static int phylink_sfp_module_start(void *upstream)
{
struct phylink *pl = upstream;
+ int ret;
/* If this SFP module has a PHY, start the PHY now. */
if (pl->phydev) {
phy_start(pl->phydev);
return 0;
+ } else {
+ ret = phylink_add_sfp_mod_port(pl);
+ if (ret)
+ return ret;
}
/* If the module may have a PHY but we didn't detect one we
@@ -3940,7 +3997,16 @@ static int phylink_sfp_module_start(void *upstream)
if (!pl->sfp_may_have_phy)
return 0;
- return phylink_sfp_config_optical(pl);
+ ret = phylink_sfp_config_optical(pl);
+ if (ret)
+ goto del_mod_port;
+
+ return 0;
+
+del_mod_port:
+ phylink_del_sfp_mod_port(pl);
+
+ return ret;
}
static void phylink_sfp_module_stop(void *upstream)
@@ -3950,6 +4016,8 @@ static void phylink_sfp_module_stop(void *upstream)
/* If this SFP module has a PHY, stop it. */
if (pl->phydev)
phy_stop(pl->phydev);
+ else
+ phylink_del_sfp_mod_port(pl);
}
static void phylink_sfp_link_down(void *upstream)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 199a7aaa341b..59903257e978 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -582,6 +582,7 @@ struct phy_oatc14_sqi_capability {
* @wol_enabled: Set to true if the PHY or the attached MAC have Wake-on-LAN
* enabled.
* @is_genphy_driven: PHY is driven by one of the generic PHY drivers
+ * @has_sfp_mod_phy: Set true if downstream SFP bus's module contains a PHY
* @state: State of the PHY for management purposes
* @dev_flags: Device-specific flags used by the PHY driver.
*
@@ -594,6 +595,8 @@ struct phy_oatc14_sqi_capability {
* @phylink: Pointer to phylink instance for this PHY
* @sfp_bus_attached: Flag indicating whether the SFP bus has been attached
* @sfp_bus: SFP bus attached to this PHY's fiber port
+ * @sfp_cage_port: The phy_port connected to the downstream SFP cage
+ * @mod_port: phy_port representing the SFP module, if it is phy-less
* @attached_dev: The attached enet driver's device instance ptr
* @adjust_link: Callback for the enet controller to respond to changes: in the
* link state.
@@ -706,6 +709,7 @@ struct phy_device {
unsigned irq_rerun:1;
unsigned default_timestamp:1;
+ unsigned has_sfp_mod_phy:1;
int rate_matching;
@@ -785,6 +789,8 @@ struct phy_device {
/* This may be modified under the rtnl lock */
bool sfp_bus_attached;
struct sfp_bus *sfp_bus;
+ struct phy_port *sfp_cage_port;
+ struct phy_port *mod_port;
struct phylink *phylink;
struct net_device *attached_dev;
struct mii_timestamper *mii_ts;
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v12 06/10] net: phy: phy_port: Store information about a port's upstream
From: Maxime Chevallier @ 2026-06-15 15:39 UTC (permalink / raw)
To: davem, Andrew Lunn, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau, Frank Wunderlich
In-Reply-To: <20260615153907.862987-1-maxime.chevallier@bootlin.com>
MII phy_ports are not meant to be connected directly to a link partner.
They are meant to feed into some media converter devices that will
expose an MDI phy_port, so far we only support SFP modules for that.
In the case an MDI phy_port is backed by an MII port (e.g. a SFP
module's port, backed by the SFP cage port), let's keep track of the
port id of the MII port backing it.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/phy/phy_device.c | 27 +++++++++++++++++++++++++++
drivers/net/phy/phylink.c | 5 +++++
include/linux/phy.h | 4 ++++
include/linux/phy_port.h | 3 +++
4 files changed, 39 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index c72582701e66..b7cd152aaaa3 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1493,6 +1493,7 @@ static int phy_sfp_connect_phy(void *upstream, struct phy_device *phy)
int ret;
phydev->has_sfp_mod_phy = true;
+ phy_set_upstream_port(phy, phydev->sfp_cage_port);
/* If we aren't attached to a netdev, we can't add the SFP PHY to its
* topology.
@@ -1526,6 +1527,8 @@ static void phy_sfp_disconnect_phy(void *upstream, struct phy_device *phy)
if (dev)
phy_link_topo_del_phy(dev, phy);
+
+ phy_set_upstream_port(phy, NULL);
}
/**
@@ -1661,6 +1664,8 @@ static int phy_add_sfp_mod_port(struct phy_device *phydev)
*/
phydev->mod_port = port;
+ port->upstream_port = phydev->sfp_cage_port->id;
+
return 0;
}
@@ -3696,6 +3701,28 @@ struct phy_port *phy_get_sfp_port(struct phy_device *phydev)
}
EXPORT_SYMBOL_GPL(phy_get_sfp_port);
+/**
+ * phy_set_upstream_port() - Sets the phy_port controlling the MII this PHY is
+ * attached to.
+ * @phydev: pointer to the PHY device we set the upstream of.
+ * @port: The phy_port upstream of this PHY, can be NULL.
+ */
+void phy_set_upstream_port(struct phy_device *phydev, struct phy_port *port)
+{
+ struct phy_port *local_port;
+
+ ASSERT_RTNL();
+
+ phydev->upstream_port = port;
+
+ phy_for_each_port(phydev, local_port)
+ if (port)
+ local_port->upstream_port = port->id;
+ else
+ local_port->upstream_port = 0;
+}
+EXPORT_SYMBOL_GPL(phy_set_upstream_port);
+
/**
* fwnode_mdio_find_device - Given a fwnode, find the mdio_device
* @fwnode: pointer to the mdio_device's fwnode
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 59ea3a2e5da4..d069338e8e4d 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -3959,6 +3959,8 @@ static int phylink_add_sfp_mod_port(struct phylink *pl)
}
}
+ port->upstream_port = pl->sfp_cage_port->id;
+
pl->mod_port = port;
return 0;
@@ -4062,6 +4064,8 @@ static int phylink_sfp_connect_phy(void *upstream, struct phy_device *phy)
phy_interface_and(phy->host_interfaces, phylink_sfp_interfaces,
pl->config->supported_interfaces);
+ phy_set_upstream_port(phy, pl->sfp_cage_port);
+
/* Do the initial configuration */
return phylink_sfp_config_phy(pl, phy);
}
@@ -4070,6 +4074,7 @@ static void phylink_sfp_disconnect_phy(void *upstream,
struct phy_device *phydev)
{
phylink_disconnect_phy(upstream);
+ phy_set_upstream_port(phydev, NULL);
}
static const struct sfp_upstream_ops sfp_phylink_ops = {
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 59903257e978..33ed10d4502a 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -597,6 +597,7 @@ struct phy_oatc14_sqi_capability {
* @sfp_bus: SFP bus attached to this PHY's fiber port
* @sfp_cage_port: The phy_port connected to the downstream SFP cage
* @mod_port: phy_port representing the SFP module, if it is phy-less
+ * @upstream_port: phy_port this PHY's MII attaches to, if any
* @attached_dev: The attached enet driver's device instance ptr
* @adjust_link: Callback for the enet controller to respond to changes: in the
* link state.
@@ -791,6 +792,7 @@ struct phy_device {
struct sfp_bus *sfp_bus;
struct phy_port *sfp_cage_port;
struct phy_port *mod_port;
+ struct phy_port *upstream_port;
struct phylink *phylink;
struct net_device *attached_dev;
struct mii_timestamper *mii_ts;
@@ -2466,6 +2468,8 @@ int __phy_hwtstamp_set(struct phy_device *phydev,
struct phy_port *phy_get_sfp_port(struct phy_device *phydev);
+void phy_set_upstream_port(struct phy_device *phydev, struct phy_port *port);
+
/**
* phy_module_driver() - Helper macro for registering PHY drivers
* @__phy_drivers: array of PHY drivers to register
diff --git a/include/linux/phy_port.h b/include/linux/phy_port.h
index 4e2a3fdd2f2e..e3a41cedebdc 100644
--- a/include/linux/phy_port.h
+++ b/include/linux/phy_port.h
@@ -40,6 +40,8 @@ struct phy_port_ops {
* @head: Used by the port's parent to list ports
* @parent_type: The type of device this port is directly connected to
* @phy: If the parent is PHY_PORT_PHYDEV, the PHY controlling that port
+ * @upstream_port: For non-MII ports, indicates the MII port that feeds this
+ * port, e.g. the SFP cage port for a SFP module port.
* @ops: Callback ops implemented by the port controller
* @pairs: The number of pairs this port has, 0 if not applicable
* @mediums: Bitmask of the physical mediums this port provides access to
@@ -59,6 +61,7 @@ struct phy_port {
union {
struct phy_device *phy;
};
+ u32 upstream_port;
const struct phy_port_ops *ops;
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox