* [PATCH net-next v3 0/5] net/sched: netem: fixes and improvements
From: Stephen Hemminger @ 2026-05-05 17:38 UTC (permalink / raw)
To: netdev; +Cc: jhs, jiri, Stephen Hemminger
This is a collection of improvements to netem found while
investigating the fixes now in net tree.
V3 - fix the multi-skb corruption patch
- don't count ECN as dropped
- try and clarify to AI why statistics are ok
Stephen Hemminger (5):
net/sched: netem: reorder struct netem_sched_data
net/sched: netem: remove useless VERSION
net/sched: netem: replace pr_info with netlink extack error messages
net/sched: netem: handle multi-segment skb in corruption
net/sched: netem: add per-impairment extended statistics
include/uapi/linux/pkt_sched.h | 9 ++
net/sched/sch_netem.c | 206 +++++++++++++++++++--------------
2 files changed, 128 insertions(+), 87 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH net v3] net: phy: broadcom: Save PHY counters during suspend
From: Justin Chen @ 2026-05-05 17:39 UTC (permalink / raw)
To: netdev
Cc: pabeni, kuba, edumazet, davem, linux, hkallweit1, andrew,
bcm-kernel-feedback-list, florian.fainelli, Justin Chen
The PHY counters can be lost if the PHY is reset during suspend. We
need to save the values into the shadow counters or the accounting
will be incorrect over multiple suspend and resume cycles.
Fixes: 820ee17b8d3b ("net: phy: broadcom: Add support code for reading PHY counters")
Signed-off-by: Justin Chen <justin.chen@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
v3
- Added fixes tag and moved from net-next to net.
v2
- Removed hook into bcm7xxx_suspend(). We dont have phy stats for 40NM phys
nor shadow stats.
drivers/net/phy/bcm-phy-lib.c | 9 +++++++++
drivers/net/phy/bcm-phy-lib.h | 1 +
drivers/net/phy/bcm7xxx.c | 14 ++++++++++++++
drivers/net/phy/broadcom.c | 5 +++++
4 files changed, 29 insertions(+)
diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/bcm-phy-lib.c
index 5198d66dbbc0..b64beade8dd9 100644
--- a/drivers/net/phy/bcm-phy-lib.c
+++ b/drivers/net/phy/bcm-phy-lib.c
@@ -563,6 +563,15 @@ void bcm_phy_get_stats(struct phy_device *phydev, u64 *shadow,
}
EXPORT_SYMBOL_GPL(bcm_phy_get_stats);
+void bcm_phy_update_stats_shadow(struct phy_device *phydev, u64 *shadow)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(bcm_phy_hw_stats); i++)
+ bcm_phy_get_stat(phydev, shadow, i);
+}
+EXPORT_SYMBOL_GPL(bcm_phy_update_stats_shadow);
+
void bcm_phy_r_rc_cal_reset(struct phy_device *phydev)
{
/* Reset R_CAL/RC_CAL Engine */
diff --git a/drivers/net/phy/bcm-phy-lib.h b/drivers/net/phy/bcm-phy-lib.h
index bceddbc860eb..bba94ce96195 100644
--- a/drivers/net/phy/bcm-phy-lib.h
+++ b/drivers/net/phy/bcm-phy-lib.h
@@ -85,6 +85,7 @@ int bcm_phy_get_sset_count(struct phy_device *phydev);
void bcm_phy_get_strings(struct phy_device *phydev, u8 *data);
void bcm_phy_get_stats(struct phy_device *phydev, u64 *shadow,
struct ethtool_stats *stats, u64 *data);
+void bcm_phy_update_stats_shadow(struct phy_device *phydev, u64 *shadow);
void bcm_phy_r_rc_cal_reset(struct phy_device *phydev);
int bcm_phy_28nm_a0b0_afe_config_init(struct phy_device *phydev);
int bcm_phy_enable_jumbo(struct phy_device *phydev);
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index 00e8fa14aa77..71a163f62c0e 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -807,6 +807,17 @@ static void bcm7xxx_28nm_get_phy_stats(struct phy_device *phydev,
bcm_phy_get_stats(phydev, priv->stats, stats, data);
}
+static int bcm7xxx_28nm_suspend(struct phy_device *phydev)
+{
+ struct bcm7xxx_phy_priv *priv = phydev->priv;
+
+ mutex_lock(&phydev->lock);
+ bcm_phy_update_stats_shadow(phydev, priv->stats);
+ mutex_unlock(&phydev->lock);
+
+ return genphy_suspend(phydev);
+}
+
static int bcm7xxx_28nm_probe(struct phy_device *phydev)
{
struct bcm7xxx_phy_priv *priv;
@@ -849,6 +860,7 @@ static int bcm7xxx_28nm_probe(struct phy_device *phydev)
.flags = PHY_IS_INTERNAL, \
.config_init = bcm7xxx_28nm_config_init, \
.resume = bcm7xxx_28nm_resume, \
+ .suspend = bcm7xxx_28nm_suspend, \
.get_tunable = bcm7xxx_28nm_get_tunable, \
.set_tunable = bcm7xxx_28nm_set_tunable, \
.get_sset_count = bcm_phy_get_sset_count, \
@@ -866,6 +878,7 @@ static int bcm7xxx_28nm_probe(struct phy_device *phydev)
.flags = PHY_IS_INTERNAL, \
.config_init = bcm7xxx_28nm_ephy_config_init, \
.resume = bcm7xxx_28nm_ephy_resume, \
+ .suspend = bcm7xxx_28nm_suspend, \
.get_sset_count = bcm_phy_get_sset_count, \
.get_strings = bcm_phy_get_strings, \
.get_stats = bcm7xxx_28nm_get_phy_stats, \
@@ -902,6 +915,7 @@ static int bcm7xxx_28nm_probe(struct phy_device *phydev)
.config_aneg = genphy_config_aneg, \
.read_status = genphy_read_status, \
.resume = bcm7xxx_16nm_ephy_resume, \
+ .suspend = bcm7xxx_28nm_suspend, \
}
static struct phy_driver bcm7xxx_driver[] = {
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index bf0c6a04481e..d1a4edb34ad2 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -592,8 +592,13 @@ static int bcm54xx_set_wakeup_irq(struct phy_device *phydev, bool state)
static int bcm54xx_suspend(struct phy_device *phydev)
{
+ struct bcm54xx_phy_priv *priv = phydev->priv;
int ret = 0;
+ mutex_lock(&phydev->lock);
+ bcm_phy_update_stats_shadow(phydev, priv->stats);
+ mutex_unlock(&phydev->lock);
+
bcm54xx_ptp_stop(phydev);
/* Acknowledge any Wake-on-LAN interrupt prior to suspend */
--
2.34.1
^ permalink raw reply related
* RE: [PATCH net-next 1/5] dt-bindings: net: add onsemi's TS2500/NCN26010 10BASE-T1S MACPHY
From: Selvamani Rajagopal @ 2026-05-05 17:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Piergiorgio Beruto, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, krzk+dt@kernel.org, conor+dt@kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <7fad56ee-88c8-4e0a-8411-eeb5c0ab4a38@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Tuesday, May 5, 2026 10:28 AM
> To: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> Cc: Rob Herring <robh@kernel.org>; Piergiorgio Beruto <Pier.Beruto@onsemi.com>;
> andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com;
> kuba@kernel.org; pabeni@redhat.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> netdev@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 1/5] dt-bindings: net: add onsemi's TS2500/NCN26010
> 10BASE-T1S MACPHY
>
>
> This Message Is From an External Sender
> This message came from outside your organization.
>
> > Had the same question in internal review. Datasheet says the minimum
> > speed 15 MHz is needed. That's why we had placed.
>
> Could you try it at lower speeds. What happens?
>
> Since it is a 10Mbps media, if the SPI speed is lower than 15MHz,
> maybe it cannot keep up with the media? But this clock speed on its
> own is not the deciding factor, there could be other users of the SPI
> bus. I would expect the driver and device to keep working if the SPI
> bus is saturated, just not give the full 10Mbps. And it would also be
> a good test the device and driver do work correctly when the bus is
> saturated.
I should have given more information. If we configure SPI at lower speed, it may start losing frames as it can't sustain the PHY's speed. Please let me know If I should remove it.
>
> Andrew
^ permalink raw reply
* Re: [PATCH v5 02/16] firmware: qcom: Add a generic PAS service
From: Mukesh Ojha @ 2026-05-05 17:32 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, robh, krzk+dt, conor+dt, robin.clark, sean,
akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg,
Harshal Dev
In-Reply-To: <20260504130603.1474043-3-sumit.garg@kernel.org>
On Mon, May 04, 2026 at 06:35:49PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
> OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
> support these non-standard SCM calls. And even for newer architectures
> using S-EL2 with Hafnium support, QTEE won't be able to support SCM
> calls either with FF-A requirements coming in. And with both OP-TEE
> and QTEE drivers well integrated in the TEE subsystem, it makes further
> sense to reuse the TEE bus client drivers infrastructure.
>
> The added benefit of TEE bus infrastructure is that there is support
> for discoverable/enumerable services. With that client drivers don't
> have to manually invoke a special SCM call to know the service status.
>
> So enable the generic Peripheral Authentication Service (PAS) provided
> by the firmware. It acts as the common layer with different TZ
> backends plugged in whether it's an SCM implementation or a proper
> TEE bus based PAS service implementation.
>
> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
> drivers/firmware/qcom/Kconfig | 8 +
> drivers/firmware/qcom/Makefile | 1 +
> drivers/firmware/qcom/qcom_pas.c | 291 +++++++++++++++++++++++++
> drivers/firmware/qcom/qcom_pas.h | 50 +++++
> include/linux/firmware/qcom/qcom_pas.h | 43 ++++
> 5 files changed, 393 insertions(+)
> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
>
> diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
> index b477d54b495a..8653639d06db 100644
> --- a/drivers/firmware/qcom/Kconfig
> +++ b/drivers/firmware/qcom/Kconfig
> @@ -6,6 +6,14 @@
>
> menu "Qualcomm firmware drivers"
>
> +config QCOM_PAS
> + tristate
> + help
> + Enable the generic Peripheral Authentication Service (PAS) provided
> + by the firmware. It acts as the common layer with different TZ
> + backends plugged in whether it's an SCM implementation or a proper
> + TEE bus based PAS service implementation.
> +
> config QCOM_SCM
> select QCOM_TZMEM
> tristate
> diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qcom/Makefile
> index 0be40a1abc13..dc5ab45f906a 100644
> --- a/drivers/firmware/qcom/Makefile
> +++ b/drivers/firmware/qcom/Makefile
> @@ -8,3 +8,4 @@ qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
> obj-$(CONFIG_QCOM_TZMEM) += qcom_tzmem.o
> obj-$(CONFIG_QCOM_QSEECOM) += qcom_qseecom.o
> obj-$(CONFIG_QCOM_QSEECOM_UEFISECAPP) += qcom_qseecom_uefisecapp.o
> +obj-$(CONFIG_QCOM_PAS) += qcom_pas.o
> diff --git a/drivers/firmware/qcom/qcom_pas.c b/drivers/firmware/qcom/qcom_pas.c
> new file mode 100644
> index 000000000000..025308adf553
> --- /dev/null
> +++ b/drivers/firmware/qcom/qcom_pas.c
> @@ -0,0 +1,291 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2010,2015,2019 The Linux Foundation. All rights reserved.
> + * Copyright (C) 2015 Linaro Ltd.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/device/devres.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +
> +#include "qcom_pas.h"
> +
> +static struct qcom_pas_ops *ops_ptr;
> +
> +/**
> + * devm_qcom_pas_context_alloc() - Allocate peripheral authentication service
> + * context for a given peripheral
> + *
> + * PAS context is device-resource managed, so the caller does not need
> + * to worry about freeing the context memory.
> + *
> + * @dev: PAS firmware device
> + * @pas_id: peripheral authentication service id
> + * @mem_phys: Subsystem reserve memory start address
> + * @mem_size: Subsystem reserve memory size
> + *
> + * Return: The new PAS context, or ERR_PTR() on failure.
> + */
> +struct qcom_pas_context *devm_qcom_pas_context_alloc(struct device *dev,
> + u32 pas_id,
> + phys_addr_t mem_phys,
> + size_t mem_size)
> +{
> + struct qcom_pas_context *ctx;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return ERR_PTR(-ENOMEM);
> +
> + ctx->dev = dev;
> + ctx->pas_id = pas_id;
> + ctx->mem_phys = mem_phys;
> + ctx->mem_size = mem_size;
> +
> + return ctx;
> +}
> +EXPORT_SYMBOL_GPL(devm_qcom_pas_context_alloc);
> +
> +/**
> + * qcom_pas_init_image() - Initialize peripheral authentication service state
> + * machine for a given peripheral, using the metadata
> + * @pas_id: peripheral authentication service id
> + * @metadata: pointer to memory containing ELF header, program header table
> + * and optional blob of data used for authenticating the metadata
> + * and the rest of the firmware
> + * @size: size of the metadata
> + * @ctx: optional pas context
> + *
> + * Return: 0 on success.
> + *
> + * Upon successful return, the PAS metadata context (@ctx) will be used to
> + * track the metadata allocation, this needs to be released by invoking
> + * qcom_pas_metadata_release() by the caller.
> + */
> +int qcom_pas_init_image(u32 pas_id, const void *metadata, size_t size,
> + struct qcom_pas_context *ctx)
> +{
> + if (!ops_ptr)
> + return -ENODEV;
> +
> + return ops_ptr->init_image(ops_ptr->dev, pas_id, metadata, size, ctx);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_init_image);
> +
> +/**
> + * qcom_pas_metadata_release() - release metadata context
> + * @ctx: pas context
> + */
> +void qcom_pas_metadata_release(struct qcom_pas_context *ctx)
> +{
> + if (!ops_ptr || !ctx || !ctx->ptr)
> + return;
> +
> + ops_ptr->metadata_release(ops_ptr->dev, ctx);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_metadata_release);
> +
> +/**
> + * qcom_pas_mem_setup() - Prepare the memory related to a given peripheral
> + * for firmware loading
> + * @pas_id: peripheral authentication service id
> + * @addr: start address of memory area to prepare
> + * @size: size of the memory area to prepare
> + *
> + * Return: 0 on success.
> + */
> +int qcom_pas_mem_setup(u32 pas_id, phys_addr_t addr, phys_addr_t size)
> +{
> + if (!ops_ptr)
> + return -ENODEV;
> +
> + return ops_ptr->mem_setup(ops_ptr->dev, pas_id, addr, size);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_mem_setup);
> +
> +/**
> + * qcom_pas_get_rsc_table() - Retrieve the resource table in passed output buffer
> + * for a given peripheral.
> + *
> + * Qualcomm remote processor may rely on both static and dynamic resources for
> + * its functionality. Static resources typically refer to memory-mapped
> + * addresses required by the subsystem and are often embedded within the
> + * firmware binary and dynamic resources, such as shared memory in DDR etc.,
> + * are determined at runtime during the boot process.
> + *
> + * On Qualcomm Technologies devices, it's possible that static resources are
> + * not embedded in the firmware binary and instead are provided by TrustZone.
> + * However, dynamic resources are always expected to come from TrustZone. This
> + * indicates that for Qualcomm devices, all resources (static and dynamic) will
> + * be provided by TrustZone PAS service.
> + *
> + * If the remote processor firmware binary does contain static resources, they
> + * should be passed in input_rt. These will be forwarded to TrustZone for
> + * authentication. TrustZone will then append the dynamic resources and return
> + * the complete resource table in output_rt_tzm.
> + *
> + * If the remote processor firmware binary does not include a resource table,
> + * the caller of this function should set input_rt as NULL and input_rt_size
> + * as zero respectively.
> + *
> + * More about documentation on resource table data structures can be found in
> + * include/linux/remoteproc.h
> + *
> + * @ctx: PAS context
> + * @pas_id: peripheral authentication service id
> + * @input_rt: resource table buffer which is present in firmware binary
> + * @input_rt_size: size of the resource table present in firmware binary
> + * @output_rt_size: TrustZone expects caller should pass worst case size for
> + * the output_rt_tzm.
> + *
> + * Return:
> + * On success, returns a pointer to the allocated buffer containing the final
> + * resource table and output_rt_size will have actual resource table size from
> + * TrustZone. The caller is responsible for freeing the buffer. On failure,
> + * returns ERR_PTR(-errno).
> + */
> +struct resource_table *qcom_pas_get_rsc_table(struct qcom_pas_context *ctx,
> + void *input_rt,
> + size_t input_rt_size,
> + size_t *output_rt_size)
> +{
> + if (!ops_ptr)
> + return ERR_PTR(-ENODEV);
> + if (!ctx)
> + return ERR_PTR(-EINVAL);
> +
> + return ops_ptr->get_rsc_table(ops_ptr->dev, ctx, input_rt,
> + input_rt_size, output_rt_size);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_get_rsc_table);
> +
> +/**
> + * qcom_pas_auth_and_reset() - Authenticate the given peripheral firmware
> + * and reset the remote processor
> + * @pas_id: peripheral authentication service id
> + *
> + * Return: 0 on success.
> + */
> +int qcom_pas_auth_and_reset(u32 pas_id)
> +{
> + if (!ops_ptr)
> + return -ENODEV;
> +
> + return ops_ptr->auth_and_reset(ops_ptr->dev, pas_id);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_auth_and_reset);
> +
> +/**
> + * qcom_pas_prepare_and_auth_reset() - Prepare, authenticate, and reset the
> + * remote processor
> + *
> + * @ctx: Context saved during call to qcom_scm_pas_context_init()
devm_qcom_pas_context_alloc()
> + *
> + * This function performs the necessary steps to prepare a PAS subsystem,
> + * authenticate it using the provided metadata, and initiate a reset sequence.
> + *
> + * It should be used when Linux is in control setting up the IOMMU hardware
> + * for remote subsystem during secure firmware loading processes. The
> + * preparation step sets up a shmbridge over the firmware memory before
> + * TrustZone accesses the firmware memory region for authentication. The
> + * authentication step verifies the integrity and authenticity of the firmware
> + * or configuration using secure metadata. Finally, the reset step ensures the
> + * subsystem starts in a clean and sane state.
> + *
> + * Return: 0 on success, negative errno on failure.
> + */
> +int qcom_pas_prepare_and_auth_reset(struct qcom_pas_context *ctx)
> +{
> + if (!ops_ptr)
> + return -ENODEV;
> + if (!ctx)
> + return -EINVAL;
> +
> + return ops_ptr->prepare_and_auth_reset(ops_ptr->dev, ctx);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_prepare_and_auth_reset);
> +
> +/**
> + * qcom_pas_set_remote_state() - Set the remote processor state
> + * @state: peripheral state
> + * @pas_id: peripheral authentication service id
> + *
> + * Return: 0 on success.
> + */
> +int qcom_pas_set_remote_state(u32 state, u32 pas_id)
> +{
> + if (!ops_ptr)
> + return -ENODEV;
> +
> + return ops_ptr->set_remote_state(ops_ptr->dev, state, pas_id);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_set_remote_state);
> +
> +/**
> + * qcom_pas_shutdown() - Shut down the remote processor
> + * @pas_id: peripheral authentication service id
> + *
> + * Return: 0 on success.
> + */
> +int qcom_pas_shutdown(u32 pas_id)
> +{
> + if (!ops_ptr)
> + return -ENODEV;
> +
> + return ops_ptr->shutdown(ops_ptr->dev, pas_id);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_shutdown);
> +
> +/**
> + * qcom_pas_supported() - Check if the peripheral authentication service is
> + * available for the given peripheral
> + * @pas_id: peripheral authentication service id
> + *
> + * Return: true if PAS is supported for this peripheral, otherwise false.
> + */
> +bool qcom_pas_supported(u32 pas_id)
> +{
> + if (!ops_ptr)
> + return false;
> +
> + return ops_ptr->supported(ops_ptr->dev, pas_id);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_supported);
> +
> +bool qcom_pas_is_available(void)
> +{
> + /*
> + * The barrier for ops_ptr is intended to synchronize the data stores
> + * for the ops data structure when client drivers are in parallel
> + * checking for PAS service availability.
> + *
> + * Once the PAS backend becomes available, it is allowed for multiple
> + * threads to enter TZ for parallel bringup of co-processors during
> + * boot.
> + */
> + return !!smp_load_acquire(&ops_ptr);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_is_available);
> +
> +void qcom_pas_ops_register(struct qcom_pas_ops *ops)
> +{
> + if (!qcom_pas_is_available())
> + /* Paired with smp_load_acquire() in qcom_pas_is_available() */
> + smp_store_release(&ops_ptr, ops);
> + else
> + pr_err("qcom_pas: ops already registered by %s\n",
> + ops_ptr->drv_name);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_ops_register);
> +
> +void qcom_pas_ops_unregister(void)
> +{
> + /* Paired with smp_load_acquire() in qcom_pas_is_available() */
> + smp_store_release(&ops_ptr, NULL);
> +}
> +EXPORT_SYMBOL_GPL(qcom_pas_ops_unregister);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Qualcomm generic TZ PAS driver");
> diff --git a/drivers/firmware/qcom/qcom_pas.h b/drivers/firmware/qcom/qcom_pas.h
> new file mode 100644
> index 000000000000..8643e2760602
> --- /dev/null
> +++ b/drivers/firmware/qcom/qcom_pas.h
> @@ -0,0 +1,50 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef __QCOM_PAS_INT_H
> +#define __QCOM_PAS_INT_H
> +
> +struct device;
> +
> +/**
> + * struct qcom_pas_ops - Qcom Peripheral Authentication Service (PAS) ops
> + * @drv_name: PAS driver name.
> + * @dev: PAS device pointer.
> + * @supported: Peripheral supported callback.
> + * @init_image: Peripheral image initialization callback.
> + * @mem_setup: Peripheral memory setup callback.
> + * @get_rsc_table: Peripheral get resource table callback.
> + * @prepare_and_auth_reset: Peripheral prepare firmware authentication and
> + * reset callback.
> + * @auth_and_reset: Peripheral firmware authentication and reset
> + * callback.
> + * @set_remote_state: Peripheral set remote state callback.
> + * @shutdown: Peripheral shutdown callback.
> + * @metadata_release: Image metadata release callback.
> + */
> +struct qcom_pas_ops {
> + const char *drv_name;
> + struct device *dev;
> + bool (*supported)(struct device *dev, u32 pas_id);
> + int (*init_image)(struct device *dev, u32 pas_id, const void *metadata,
> + size_t size, struct qcom_pas_context *ctx);
> + int (*mem_setup)(struct device *dev, u32 pas_id, phys_addr_t addr,
> + phys_addr_t size);
> + void *(*get_rsc_table)(struct device *dev, struct qcom_pas_context *ctx,
> + void *input_rt, size_t input_rt_size,
> + size_t *output_rt_size);
> + int (*prepare_and_auth_reset)(struct device *dev,
> + struct qcom_pas_context *ctx);
> + int (*auth_and_reset)(struct device *dev, u32 pas_id);
> + int (*set_remote_state)(struct device *dev, u32 state, u32 pas_id);
> + int (*shutdown)(struct device *dev, u32 pas_id);
> + void (*metadata_release)(struct device *dev,
> + struct qcom_pas_context *ctx);
> +};
> +
> +void qcom_pas_ops_register(struct qcom_pas_ops *ops);
> +void qcom_pas_ops_unregister(void);
> +
> +#endif /* __QCOM_PAS_INT_H */
> diff --git a/include/linux/firmware/qcom/qcom_pas.h b/include/linux/firmware/qcom/qcom_pas.h
> new file mode 100644
> index 000000000000..65b1c9564458
> --- /dev/null
> +++ b/include/linux/firmware/qcom/qcom_pas.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2010-2015, 2018-2019 The Linux Foundation. All rights reserved.
> + * Copyright (C) 2015 Linaro Ltd.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef __QCOM_PAS_H
> +#define __QCOM_PAS_H
> +
> +#include <linux/err.h>
> +#include <linux/types.h>
> +
> +struct qcom_pas_context {
> + struct device *dev;
> + u32 pas_id;
> + phys_addr_t mem_phys;
> + size_t mem_size;
> + void *ptr;
> + dma_addr_t phys;
> + ssize_t size;
> + bool use_tzmem;
> +};
> +
> +bool qcom_pas_is_available(void);
> +struct qcom_pas_context *devm_qcom_pas_context_alloc(struct device *dev,
> + u32 pas_id,
> + phys_addr_t mem_phys,
> + size_t mem_size);
> +int qcom_pas_init_image(u32 pas_id, const void *metadata, size_t size,
> + struct qcom_pas_context *ctx);
> +struct resource_table *qcom_pas_get_rsc_table(struct qcom_pas_context *ctx,
> + void *input_rt, size_t input_rt_size,
> + size_t *output_rt_size);
> +int qcom_pas_mem_setup(u32 pas_id, phys_addr_t addr, phys_addr_t size);
> +int qcom_pas_auth_and_reset(u32 pas_id);
> +int qcom_pas_prepare_and_auth_reset(struct qcom_pas_context *ctx);
> +int qcom_pas_set_remote_state(u32 state, u32 pas_id);
> +int qcom_pas_shutdown(u32 pas_id);
> +bool qcom_pas_supported(u32 pas_id);
> +void qcom_pas_metadata_release(struct qcom_pas_context *ctx);
> +
> +#endif /* __QCOM_PAS_H */
> --
> 2.51.0
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v1] gve: Use generic power management
From: Harshitha Ramamurthy @ 2026-05-05 17:28 UTC (permalink / raw)
To: Vaibhav Gupta
Cc: Joshua Washington, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Willem de Bruijn, Ankit Garg,
Tim Hostetler, Alok Tiwari, John Fraker, Matt Olson,
Praveen Kaligineedi, netdev, linux-kernel
In-Reply-To: <20260504182139.604925-1-vaibhavgupta40@gmail.com>
On Mon, May 4, 2026 at 11:21 AM Vaibhav Gupta <vaibhavgupta40@gmail.com> wrote:
>
> Switch to the generic power management and remove the usage of legacy
> (pci_driver) hooks.
>
> Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
> ---
> drivers/net/ethernet/google/gve/gve_main.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
> index 424d973c97f2..b7bac6bf89e2 100644
> --- a/drivers/net/ethernet/google/gve/gve_main.c
> +++ b/drivers/net/ethernet/google/gve/gve_main.c
> @@ -2967,9 +2967,9 @@ static void gve_shutdown(struct pci_dev *pdev)
> rtnl_unlock();
> }
>
> -#ifdef CONFIG_PM
> -static int gve_suspend(struct pci_dev *pdev, pm_message_t state)
> +static int gve_suspend(struct device *dev)
> {
> + struct pci_dev *pdev = to_pci_dev(dev);
> struct net_device *netdev = pci_get_drvdata(pdev);
> struct gve_priv *priv = netdev_priv(netdev);
> bool was_up = netif_running(priv->dev);
> @@ -2990,8 +2990,9 @@ static int gve_suspend(struct pci_dev *pdev, pm_message_t state)
> return 0;
> }
>
> -static int gve_resume(struct pci_dev *pdev)
> +static int gve_resume(struct device *dev)
> {
> + struct pci_dev *pdev = to_pci_dev(dev);
> struct net_device *netdev = pci_get_drvdata(pdev);
> struct gve_priv *priv = netdev_priv(netdev);
> int err;
> @@ -3004,7 +3005,8 @@ static int gve_resume(struct pci_dev *pdev)
> rtnl_unlock();
> return err;
> }
> -#endif /* CONFIG_PM */
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(gve_pm_ops, gve_suspend, gve_resume);
>
> static const struct pci_device_id gve_id_table[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_GOOGLE, PCI_DEV_ID_GVNIC) },
> @@ -3017,10 +3019,7 @@ static struct pci_driver gve_driver = {
> .probe = gve_probe,
> .remove = gve_remove,
> .shutdown = gve_shutdown,
> -#ifdef CONFIG_PM
> - .suspend = gve_suspend,
> - .resume = gve_resume,
> -#endif
> + .driver.pm = &gve_pm_ops,
Thanks for the patch! A minor suggestion: could you wrap this in pm_sleep_ptr()?
Also, please include the net-next prefix in the subject line when posting v2.
With those changes, feel free to add:
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Thanks,
Harshitha
> };
>
> module_pci_driver(gve_driver);
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH net-next 1/5] dt-bindings: net: add onsemi's TS2500/NCN26010 10BASE-T1S MACPHY
From: Andrew Lunn @ 2026-05-05 17:27 UTC (permalink / raw)
To: Selvamani Rajagopal
Cc: Rob Herring, Piergiorgio Beruto, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, krzk+dt@kernel.org, conor+dt@kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CY8PR02MB924915930E62AE03DF05C2DC833E2@CY8PR02MB9249.namprd02.prod.outlook.com>
> Had the same question in internal review. Datasheet says the minimum
> speed 15 MHz is needed. That's why we had placed.
Could you try it at lower speeds. What happens?
Since it is a 10Mbps media, if the SPI speed is lower than 15MHz,
maybe it cannot keep up with the media? But this clock speed on its
own is not the deciding factor, there could be other users of the SPI
bus. I would expect the driver and device to keep working if the SPI
bus is saturated, just not give the full 10Mbps. And it would also be
a good test the device and driver do work correctly when the bus is
saturated.
Andrew
^ permalink raw reply
* Re: [PATCH net v2] xfrm: esp: avoid in-place decrypt on shared skb frags
From: Hex Rabbit @ 2026-05-05 17:26 UTC (permalink / raw)
To: Steffen Klassert
Cc: Hyunwoo Kim, netdev, Greg Kroah-Hartman, Herbert Xu, Simon Horman,
David S . Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ido Schimmel, linux-kernel
In-Reply-To: <afmDOrObXxUC7eDt@secunet.com>
> You reported it, so you can have the tag.
>
> This is now applied to the ipsec tree, thanks a lot everybody!
Thanks for applying it, and thanks everyone for the review and testing.
Best regards,
Kuan-Ting
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: eth: fbnic: Add pma read and write access
From: Mike Marciniszyn @ 2026-05-05 17:23 UTC (permalink / raw)
To: Paolo Abeni
Cc: Alexander Duyck, Jakub Kicinski, kernel-team, Andrew Lunn,
David S. Miller, Eric Dumazet, Heiner Kallweit, Russell King,
Jacob Keller, Mohsin Bashir, Lee Trager, Andrew Lunn, netdev,
linux-kernel
In-Reply-To: <7d657e09-1037-4f0d-b0f6-70228a4acccd@redhat.com>
On Tue, May 05, 2026 at 02:40:18PM +0200, Paolo Abeni wrote:
> On 4/30/26 5:08 PM, mike.marciniszyn@gmail.com wrote:
> > From: "Mike Marciniszyn (Meta)" <mike.marciniszyn@gmail.com>
> >
> > Document the MDIO interface topology with an ASCII diagram
> > showing the MAC, PCS (MMD 3), FEC, Separated PMA (MMD 8), and PMD
> > (MMD 1) blocks and their interconnects. The diagram illustrates how
> > 4 lanes connect the MAC through PCS, FEC, and PMA, then narrow to
> > 2 lanes at the PMD.
> >
> > The c45 read and write routines are enhanced to support
> > read and write of the separated PMA for the fbnic.
> >
> > Co-developed-by: Alexander Duyck <alexanderduyck@fb.com>
> > Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
> > Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com>
> > ---
> > v2:
> > - no changes
> > v1: https://lore.kernel.org/all/20260428172810.175077-5-mike.marciniszyn@gmail.com/
> >
> > drivers/net/ethernet/meta/fbnic/fbnic_csr.h | 1 +
> > drivers/net/ethernet/meta/fbnic/fbnic_mdio.c | 71 ++++++++++++++++++++
> > 2 files changed, 72 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_csr.h b/drivers/net/ethernet/meta/fbnic/fbnic_csr.h
> > index 81794bd326e1..64b958df7774 100644
> > --- a/drivers/net/ethernet/meta/fbnic/fbnic_csr.h
> > +++ b/drivers/net/ethernet/meta/fbnic/fbnic_csr.h
> > @@ -805,6 +805,7 @@ enum {
> > #define FBNIC_CSR_END_PCS 0x10668 /* CSR section delimiter */
> >
> > #define FBNIC_CSR_START_RSFEC 0x10800 /* CSR section delimiter */
> > +#define FBNIC_RSFEC_CONTROL(n) (0x10800 + 8 * (n)) /* 0x42000 + 32*n */
>
> Sashiko says:
>
> ---
> With the introduction of the RSFEC memory space at 0x10800, does the bounds
> check in fbnic_mdio_write_pcs() need to be updated to prevent clobbering
> these new registers?
> While not introduced by this patch, fbnic_mdio_write_pcs() currently
> contains:
> /* Allow access to both halves of PCS for 50R2 config */
> if (addr > 2)
> return;
> When addr is 2, FBNIC_PCS_PAGE(2) evaluates to 0x10000 + 0x400 * 2, which
> is 0x10800.
> Since this overlaps with FBNIC_CSR_START_RSFEC, an MDIO write to MMD 3
> (PCS) at address 2 could silently overwrite the newly managed RSFEC
> control registers.
> The read function fbnic_mdio_read_pcs() correctly uses if (addr >= 2) to
> prevent this. Should the write function be updated to match?
> ---
>
> Does not look blocking to me, but a follow-up could be needed.
>
> /P
>
The patch that fixes this issue should have preceded the three patches.
Here is the patchwork link: https://patchwork.kernel.org/project/netdevbpf/patch/20260504135815.44226-2-mike.marciniszyn@gmail.com/
I don't see that you actually pulled that patch or that it has been
accepted?
Mike
^ permalink raw reply
* Re: [PATCH net-next v10 00/10] ipv6: Address ext hdr DoS vulnerabilities
From: Justin Iurman @ 2026-05-05 17:11 UTC (permalink / raw)
To: Tom Herbert, davem, kuba, netdev, willemdebruijn.kernel, pabeni,
horms
Cc: Tom Herbert
In-Reply-To: <20260504185122.50642-1-tom@xdpnet.ai>
On 5/4/26 20:51, Tom Herbert wrote:
> IPv6 extension headers are defined to be quite open ended with few
> limits. For instance, RFC8200 requires a receiver to process any
> number of extension headers in a packet in any order. This flexibility
> comes at the cost of a potential Denial of Service attack. The only
> thing that might mitigate the DoS attacks is the fact that packets
> with extension headers experience high drop rates on the Internet so
> that a DoS attack based on extension wouldn't be very effective at
> Internet scale.
>
> This patch set addresses some of the more egregious vulnerabilities
> of extension headers to DoS attack.
>
> - If sysctl.max_dst_opts_cnt or hbh_opts_cnt are set to 0 then that
> disallows packets with Destination Options or Hop-by-Hop Options even
> if the packet contain zero non-padding options
>
> - Add a case for IPV6_TLV_TNL_ENCAP_LIMIT in the switch on TLV type
> in ip6_parse_tlv function. This TLV is handled in tunnel processing,
> however it needs to be detected in ip6_parse_tlv to properly account
> for it as recognized non-padding option
>
> - Move IPV6_TLV_TNL_ENCAP_LIMIT to uapi/linux/in6.h so that all the
> TLV definitions are in one place
>
> - Set the default limits of non-padding Hop-by-Hop and Destination
> options to 2. This means that if a packet contains more then two
> non-padding options then it will be dropped. The previous limit
> was 8, but that was too liberal considering that the stack only
> support two Destination Options and the most Hop-by-Hop options
> likely to ever be in the same packet are IOAM and JUMBO. The limit
> can be increased via sysctl for private use and experimentation
>
> - Enforce RFC8200 recommended ordering of Extension Headers. This
> also enforces that any Extension Header occurs at most once
> in a packet except for Destination Options that may appear
> twice. The enforce_ext_hdr_order sysctl controls enforcement. If
> it's set to true then order is enforced, if it's set to false then
> neither order nor number of occurrences are enforced.
>
> The enforced ordering is:
>
> IPv6 header
> Hop-by-Hop Options header
> Destination Options before the Routing header
> Routing header
> Fragment header
> Authentication header
> Encapsulating Security Payload header
> Destination Options header
> Upper-Layer header
>
> --- Background
>
> We selected the default value of eight in RFC8504 based on an
> expectation that there might be new options defined and that the
> Internet would be fixed to reliably support extension headers
> including those with options. I do not believe either of those are
> going to happen.
>
> Hop-by-Hop Options are ostensibly the right way to do network to host
> and host to network signaling.The only HBH options that might get any
> substantial deployment are Router Alert option and IOAM. The Router
> Alert option is being deprecated and IOAM is at best a "nice to
> have". The best use case of Hop-by-Hop options is congestion
> signaling, unfortunately the die was cast when CSIG authors decided to
> place the information in VLANs at L2 and cajole the information to be
> routable through a switch. IMO, the miss on CSIG pretty much is the
> nail in the coffin for Hop-by-Hop options to ever be widely deployed
> (https://www.ietf.org/archive/id/draft-ravi-ippm-csig-01.txt).
>
> Destination Options have proven even less useful than Hop-by-Hop
> Options. The only Destination Options supported by the stack is the
> Tunnel Encap Limit option and Home Address Options. The Tunnel Encap
> Option was buried in the v6 tunnel code which is why it wasn't obvious
> it was supported in the first version of the patch set. I'll assume
> that might be useful, so this patch set cleans up the code for it. I
> don't believe there's any use of Home Address Option.
>
> A major problem with DestOpts, HBH, Routing Header, and Fragment
> header is that they have no inherent security. Their use presents a
> security risk especially when sent over untrusted networks including
> the Internet. Given that and that the high drop rates of extension
> headers on the Internet, I am proposing that Extension header except
> for ESP being deprecated on the Internet
> (https://www.ietf.org/archive/id/draft-herbert-deprecate-eh-01.txt).
>
> An update to RFC8200 is being proposed in IETF to allow enforcement of
> extension header ordering and number of occurences. An I-D is in
> https://www.ietf.org/archive/id/draft-iurman-6man-eh-occurrences-00.txt
>
> --- Testing
>
> Add selftest eh_limits.sh. Tested by running:
>
> $ sudo ./eh_limits.sh
> TEST: EH-limits - default sysctls [ OK ]
> TEST: EH-limits - modified sysctls [ OK ]
>
> Tests passed: 2
> Tests failed: 0
>
> $ sudo ./eh_limits.sh -v
>>>>>> Default
> TEST: Two non-padding options in HBH and DestOpts: Received as expected
> TEST: Big destination option: Received as expected
> TEST: Almost Big HBH option: Received as expected
> TEST: Big HBH option: Received as expected
> TEST: Too much HBH padding: Didn't receive as expected
> TEST: Too much DestOpt padding: Didn't receive as expected
> TEST: Too much DestOpt padding #2: Didn't receive as expected
> TEST: Too much DestOpt padding #3: Didn't receive as expected
> TEST: Almost too much DestOpt padding #2: Received as expected
> TEST: Two Dest Ops: Didn't receive as expected
> TEST: OOO Routing header: Didn't receive as expected
> TEST: Two Routing headers: Didn't receive as expected
> TEST: Two Destination options okay: Received as expected
> TEST: Two Destination options: Didn't receive as expected
> TEST: Two Destination options after RH: Didn't receive as expected
> TEST: Many EH OOO: Didn't receive as expected
> TEST: Two fragment Headers: Didn't receive as expected
>
> TEST: EH-limits - default sysctls [ OK ]
>>>>>> No order enforce, 8 options, 66 length limit
> TEST: Two non-padding options in HBH and DestOpts: Received as expected
> TEST: Big destination option: Didn't receive as expected
> TEST: Almost Big HBH option: Received as expected
> TEST: Big HBH option: Didn't receive as expected
> TEST: Too much HBH padding: Didn't receive as expected
> TEST: Too much DestOpt padding: Didn't receive as expected
> TEST: Too much DestOpt padding #2: Didn't receive as expected
> TEST: Too much DestOpt padding #3: Didn't receive as expected
> TEST: Almost too much DestOpt padding #2: Received as expected
> TEST: Two Dest Ops: Received as expected
> TEST: OOO Routing header: Received as expected
> TEST: Two Routing headers: Received as expected
> TEST: Two Destination options okay: Received as expected
> TEST: Two Destination options: Received as expected
> TEST: Two Destination options after RH: Received as expected
> TEST: Many EH OOO: Received as expected
> TEST: Two fragment Headers: Didn't receive as expected
>
> TEST: EH-limits - modified sysctls [ OK ]
>
> Tests passed: 2
> Tests failed: 0
>
> V4: Switch order of patches to avoid transient build failure
> V5: Allow Destination Options before the Routing header, fixes
> suggested by Justin Iurman
> v6: Fix a bug and create a test for extension header limits
> v7: Run pylint on new Python file, run shellcheck on new bash file,
> Make fixes as needed
> v8: Repost
> v9: Fix subject prefix
> v10: Lint fixes in selftest scripts suggested by Simon Horman
>
> Tom Herbert (10):
> ipv6: Check of max HBH or DestOp sysctl is zero and drop if it is
> ipv6: Cleanup IPv6 TLV definitions
> ipv6: Add case for IPV6_TLV_TNL_ENCAP_LIMIT in EH TLV switch
> ipv6: Set HBH and DestOpt limits to 2
> ipv6: Document defaults for max_{dst|hbh}_opts_number sysctls
> ipv6: Enforce Extension Header ordering
> ipv6: Document enforce_ext_hdr_order sysctl
> test: Add proto_nums.py in networking selftests
> test: Add ext_hdr.py in networking selftests
> test: Add networking selftest for eh limits
>
> Documentation/networking/ip-sysctl.rst | 52 ++-
> include/net/ipv6.h | 9 +-
> include/net/netns/ipv6.h | 1 +
> include/net/protocol.h | 14 +
> include/uapi/linux/in6.h | 21 +-
> include/uapi/linux/ip6_tunnel.h | 1 -
> net/ipv6/af_inet6.c | 1 +
> net/ipv6/exthdrs.c | 32 +-
> net/ipv6/ip6_input.c | 42 +++
> net/ipv6/reassembly.c | 1 +
> net/ipv6/sysctl_net_ipv6.c | 7 +
> net/ipv6/xfrm6_protocol.c | 2 +
> tools/testing/selftests/net/Makefile | 4 +
> tools/testing/selftests/net/eh_limits.py | 349 ++++++++++++++++++++
> tools/testing/selftests/net/eh_limits.sh | 210 ++++++++++++
> tools/testing/selftests/net/ext_hdr.py | 385 ++++++++++++++++++++++
> tools/testing/selftests/net/proto_nums.py | 231 +++++++++++++
> 17 files changed, 1334 insertions(+), 28 deletions(-)
> create mode 100755 tools/testing/selftests/net/eh_limits.py
> create mode 100755 tools/testing/selftests/net/eh_limits.sh
> create mode 100755 tools/testing/selftests/net/ext_hdr.py
> create mode 100644 tools/testing/selftests/net/proto_nums.py
>
Hi Tom,
While at it, should we also take care of ip6_tnl_parse_tlv_enc_lim(),
ipv6_skip_exthdr(), and ipv6_find_hdr(), so that we remain consistent
with recent merged fixes 3744b0964d52 and 076b8cad77aa ?
Cheers,
Justin
^ permalink raw reply
* [PATCH v7] nfc: hci: fix out-of-bounds read in HCP header parsing
From: Ashutosh Desai @ 2026-05-05 17:07 UTC (permalink / raw)
To: netdev
Cc: kuba, edumazet, davem, pabeni, horms, stable, linux-kernel,
david+nfc, Ashutosh Desai
Both nfc_hci_recv_from_llc() and nci_hci_data_received_cb() read
packet->header from skb->data at function entry without first checking
that the buffer holds at least one byte. A malicious NFC peer can send
a 0-byte HCP frame that passes through the SHDLC layer and reaches
these functions, causing an out-of-bounds heap read of packet->header.
The same 0-byte frame, if queued as a non-final fragment, also causes
the reassembly loop to underflow msg_len to UINT_MAX, triggering
skb_over_panic() when the reassembled skb is written.
Fix this by adding a pskb_may_pull() check at the entry of each
function before packet->header is first accessed. The existing
pskb_may_pull() checks before the reassembled hcp_skb is cast to
struct hcp_packet remain in place to guard the 2-byte HCP message
header.
Fixes: 8b8d2e08bf0d ("NFC: HCI support")
Fixes: 11f54f228643 ("NFC: nci: Add HCI over NCI protocol support")
Cc: stable@vger.kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
---
Changes in v7:
- Add David Heidelberg <david+nfc@ixit.cz> to CC (NFC subsystem maintainer)
Changes in v6:
- Add pskb_may_pull(skb, 1) at function entry in both functions before
packet->header is first accessed, to fix OOB read on 0-byte frames
and prevent integer underflow in the fragment reassembly path
(Paolo Abeni)
V6 -> V7: add NFC subsystem maintainer to CC
V5 -> V6: add entry-point length checks per Paolo Abeni's review
V4 -> V5: fix whitespace damage
V3 -> V4: add Fixes tags
V2 -> V3: drop redundant checks from nfc_hci_msg_rx_work/nci_hci_msg_rx_work;
remove incorrect Suggested-by tag
V1 -> V2: use pskb_may_pull() instead of skb->len check
v6: https://lore.kernel.org/netdev/20260502163116.3409687-1-ashutoshdesai993@gmail.com/
v5: https://lore.kernel.org/netdev/20260416051522.4154698-1-ashutoshdesai993@gmail.com/
v4: https://lore.kernel.org/netdev/177614425081.3600288.2536320552978506086@gmail.com/
v3: https://lore.kernel.org/netdev/20260413024329.3293075-1-ashutoshdesai993@gmail.com/
v2: https://lore.kernel.org/netdev/20260409150825.2217133-1-ashutoshdesai993@gmail.com/
v1: https://lore.kernel.org/netdev/20260408223113.2009304-1-ashutoshdesai993@gmail.com/
net/nfc/hci/core.c | 10 ++++++++++
net/nfc/nci/hci.c | 10 ++++++++++
2 files changed, 20 insertions(+)
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index 0d33c81a15fe..ba6f0310ffd7 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -861,6 +861,11 @@ static void nfc_hci_recv_from_llc(struct nfc_hci_dev *hdev, struct sk_buff *skb)
struct sk_buff *frag_skb;
int msg_len;
+ if (!pskb_may_pull(skb, NFC_HCI_HCP_PACKET_HEADER_LEN)) {
+ kfree_skb(skb);
+ return;
+ }
+
packet = (struct hcp_packet *)skb->data;
if ((packet->header & ~NFC_HCI_FRAGMENT) == 0) {
skb_queue_tail(&hdev->rx_hcp_frags, skb);
@@ -904,6 +909,11 @@ static void nfc_hci_recv_from_llc(struct nfc_hci_dev *hdev, struct sk_buff *skb)
* unblock waiting cmd context. Otherwise, enqueue to dispatch
* in separate context where handler can also execute command.
*/
+ if (!pskb_may_pull(hcp_skb, NFC_HCI_HCP_HEADER_LEN)) {
+ kfree_skb(hcp_skb);
+ return;
+ }
+
packet = (struct hcp_packet *)hcp_skb->data;
type = HCP_MSG_GET_TYPE(packet->message.header);
if (type == NFC_HCI_HCP_RESPONSE) {
diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
index 40ae8e5a7ec7..c03e8a0bd3bd 100644
--- a/net/nfc/nci/hci.c
+++ b/net/nfc/nci/hci.c
@@ -439,6 +439,11 @@ void nci_hci_data_received_cb(void *context,
return;
}
+ if (!pskb_may_pull(skb, NCI_HCI_HCP_PACKET_HEADER_LEN)) {
+ kfree_skb(skb);
+ return;
+ }
+
packet = (struct nci_hcp_packet *)skb->data;
if ((packet->header & ~NCI_HCI_FRAGMENT) == 0) {
skb_queue_tail(&ndev->hci_dev->rx_hcp_frags, skb);
@@ -482,6 +487,11 @@ void nci_hci_data_received_cb(void *context,
* unblock waiting cmd context. Otherwise, enqueue to dispatch
* in separate context where handler can also execute command.
*/
+ if (!pskb_may_pull(hcp_skb, NCI_HCI_HCP_HEADER_LEN)) {
+ kfree_skb(hcp_skb);
+ return;
+ }
+
packet = (struct nci_hcp_packet *)hcp_skb->data;
type = NCI_HCP_MSG_GET_TYPE(packet->message.header);
if (type == NCI_HCI_HCP_RESPONSE) {
--
2.34.1
^ permalink raw reply related
* Exclusive Notice: Invoice #18546-3674
From: Geek Squad Service @ 2026-05-05 17:06 UTC (permalink / raw)
To: netdev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Hi admin,
Thank you for your continued trust in Geek Squad Service! We've successfully processed your membership renewal (Order #4596-ZF-3710) and are excited to continue serving you.
Renewal Details:
📅 Renewal Date: Today
👤 Member: admin
📧 Email: netdev@vger.kernel.org
💳 Transaction: #92039160892
🛡 Service: Sound system installation
⏳ Term: 1 Year
💰 Amount: 261.6 USD
Your membership benefits are now active for another year. As always, our team is here to help at +18082104827.
Warm regards,
The Geek Squad Service Team
+18082104827
Po Box 282 Stonewall MS 39363 United States
© 2025 Geek Squad Service LLC. All rights reserved.
^ permalink raw reply
* Re: [PATCH net] ixgbe: fix X550 AQ PHY identification returning ixgbe_phy_unknown
From: Simon Horman @ 2026-05-05 16:53 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260430123154.132072-1-aleksandr.loktionov@intel.com>
On Thu, Apr 30, 2026 at 02:31:53PM +0200, Aleksandr Loktionov wrote:
> ixgbe_get_phy_id() reads the two MII_PHYSID registers and combines them
> into hw->phy.id with the lower 4 revision bits masked out by
> IXGBE_PHY_REVISION_MASK (0xFFFFFFF0).
>
> Commit 5f1c3589b0f0 ("ixgbe: Correct X550 phy ID") replaced
> X550_PHY_ID (0x01540220) with X550_PHY_ID2 (0x01540223) and
> X550_PHY_ID3 (0x01540221). These are the raw values read directly off
> hardware, but after revision-bit masking both reduce to 0x01540220.
> The switch cases in ixgbe_get_phy_type_from_id() therefore never match,
> and X550 AQ PHY devices always fall through to ixgbe_phy_unknown. A
> wrong PHY type means the wrong ops vector is selected, resulting in
> failed PHY initialization and no link.
>
> Restore X550_PHY_ID (0x01540220) as the match value -- the
> revision-stripped ID that the driver actually stores. Keep X550_PHY_ID2
> and X550_PHY_ID3 as documentation of the hardware-reported values.
>
> Fixes: 5f1c3589b0f0 ("ixgbe: Correct X550 phy ID")
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 net-next 3/3] selftests:net: Implement ptp4l sync test using netdevsim
From: Andrew Lunn @ 2026-05-05 16:53 UTC (permalink / raw)
To: Maciek Machnikowski
Cc: Jakub Kicinski, netdev, richardcochran, milena.olech,
willemdebruijn.kernel, vadim.fedorenko, horms
In-Reply-To: <aa5798db-51b1-4d44-abec-c55b0560ec21@machnikowski.net>
> >>> Anything we need to do?
> >>
> >> Can you share the config file you used? Seems the PTP clock was not
> >> found which may lead to PTP_1588_CLOCK_MOCK not being enabled?
> >
> > Shouldn't the configuration file be part of the test?
> >
> > Andrew
>
> I meant the kernel config.
Ah. O.K.
> The PTP emulation requires PTP Mock to be
> enabled, as that's the backbone for generating timestamps. If it's
> disabled - netdevsim netdevs will report no timestamping support, as in
> the example above.
Maybe a Kconfig selects or depends should be added to netdevsim to
ensure the needed parts are enabled?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 12/12] arm64: dts: qcom: qcs6490-rb3gen2: enable TC9564 with a single QCS8081 phy
From: Alex Elder @ 2026-05-05 16:46 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, Daniel Thompson, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <afod8ot7xb+g0wzN@oss.qualcomm.com>
On 5/5/26 11:42 AM, Mohd Ayaan Anwar wrote:
> Hi Alex,
> On Fri, May 01, 2026 at 10:54:20AM -0500, Alex Elder wrote:
>> From: Daniel Thompson <daniel@riscstar.com>
>>
>> The QCS6490 RB3Gen2 includes a Toshiba TC9564 (a.k.a. Qualcomm QPS615).
>> TC9564 is an twin Ethernet-AVB/TSN bridge with an integrated PCIe switch.
>>
>> There are multiple builds of RB3Gen2 with components included/excluded.
>> That means whether or not there is a phy attached to eMAC0 depends on
>> the exact board. However all versions include a TC9564 combined with a
>> single QCS8081 attached to eMAC1.
>>
>> Add properties to the existing PCI nodes to describe how the TC9564 and
>> QCS8081 are connected to each other (and to the host SoC).
>>
>> (Note: "pci1179,0220" is documented in the "net/toshiba,tc956x-dwmac.yaml"
>> binding, but checkpatch.pl doesn't recognize that.)
>>
>> Co-developed-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>
> There's a minor typo in the PHY name - QCS8081 instead of QCA8081.
OK, I'll fix that too. Thanks a lot Ayaan.
-Alex
>
> Ayaan
^ permalink raw reply
* Re: [PATCH net-next 10/12] net: stmmac: tc956x: add TC956x/QPS615 support
From: Alex Elder @ 2026-05-05 16:46 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, Daniel Thompson, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <afodG9uuopgfvSmu@oss.qualcomm.com>
On 5/5/26 11:38 AM, Mohd Ayaan Anwar wrote:
> Hi Alex,
> On Fri, May 01, 2026 at 10:54:18AM -0500, Alex Elder wrote:
>
>> + /*
>> + * TX956x has 8 TX queues but only #0 to #3 work for general IP traffic.
>
> Minor typo in the comment: I think you meant TC956X instead of TX956X?
Yes, I'll fix that.
>> + for (i = 0; i < td->plat->rx_queues_to_use; i++) {
>> + res->rx_irq[i] = irq_create_mapping(irq_domain, HWIRQ_RX0 + i);
>> + if (!res->tx_irq[i])
>
> Typo: res->rx_irq instead of res->tx_irq.
Wow, that's important... Fortunately we haven't been getting errors.
This will be fixed.
> PS: I was able to successfully test this series out on a Rb3Gen2 board.
Great! Thank you.
-Alex
> Ayaan
^ permalink raw reply
* Re: [PATCH net-next 12/12] arm64: dts: qcom: qcs6490-rb3gen2: enable TC9564 with a single QCS8081 phy
From: Mohd Ayaan Anwar @ 2026-05-05 16:42 UTC (permalink / raw)
To: Alex Elder
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, Daniel Thompson, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260501155421.3329862-13-elder@riscstar.com>
Hi Alex,
On Fri, May 01, 2026 at 10:54:20AM -0500, Alex Elder wrote:
> From: Daniel Thompson <daniel@riscstar.com>
>
> The QCS6490 RB3Gen2 includes a Toshiba TC9564 (a.k.a. Qualcomm QPS615).
> TC9564 is an twin Ethernet-AVB/TSN bridge with an integrated PCIe switch.
>
> There are multiple builds of RB3Gen2 with components included/excluded.
> That means whether or not there is a phy attached to eMAC0 depends on
> the exact board. However all versions include a TC9564 combined with a
> single QCS8081 attached to eMAC1.
>
> Add properties to the existing PCI nodes to describe how the TC9564 and
> QCS8081 are connected to each other (and to the host SoC).
>
> (Note: "pci1179,0220" is documented in the "net/toshiba,tc956x-dwmac.yaml"
> binding, but checkpatch.pl doesn't recognize that.)
>
> Co-developed-by: Alex Elder <elder@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
There's a minor typo in the PHY name - QCS8081 instead of QCA8081.
Ayaan
^ permalink raw reply
* Re: [PATCH net-next 10/12] net: stmmac: tc956x: add TC956x/QPS615 support
From: Mohd Ayaan Anwar @ 2026-05-05 16:38 UTC (permalink / raw)
To: Alex Elder
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, Daniel Thompson, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260501155421.3329862-11-elder@riscstar.com>
Hi Alex,
On Fri, May 01, 2026 at 10:54:18AM -0500, Alex Elder wrote:
> + /*
> + * TX956x has 8 TX queues but only #0 to #3 work for general IP traffic.
Minor typo in the comment: I think you meant TC956X instead of TX956X?
> +
> + for (i = 0; i < td->plat->rx_queues_to_use; i++) {
> + res->rx_irq[i] = irq_create_mapping(irq_domain, HWIRQ_RX0 + i);
> + if (!res->tx_irq[i])
Typo: res->rx_irq instead of res->tx_irq.
PS: I was able to successfully test this series out on a Rb3Gen2 board.
Ayaan
^ permalink raw reply
* Re: [PATCH v5 net-next 3/3] selftests:net: Implement ptp4l sync test using netdevsim
From: Vadim Fedorenko @ 2026-05-05 16:38 UTC (permalink / raw)
To: Maciek Machnikowski, Andrew Lunn
Cc: Jakub Kicinski, netdev, richardcochran, milena.olech,
willemdebruijn.kernel, horms
In-Reply-To: <aa5798db-51b1-4d44-abec-c55b0560ec21@machnikowski.net>
On 05/05/2026 17:22, Maciek Machnikowski wrote:
>
>
> On 05/05/2026 14:22, Andrew Lunn wrote:
>> On Tue, May 05, 2026 at 09:36:30AM +0200, Maciek Machnikowski wrote:
>>>
>>>
>>> On 04/05/2026 19:07, Jakub Kicinski wrote:
>>>> On Sun, 3 May 2026 09:47:47 +0200 Maciek Machnikowski wrote:
>>>>> Add PTP synchronization test using ptp4l and netdevsim.
>>>>>
>>>>> The test creates two netdevsim adapters, links them together
>>>>> and runs the ptp4l leader and ptp4l follower on two ends
>>>>> of the netdevsim link and waits for the follower to report the
>>>>> synchronized state (s2) in its output log.
>>>>>
>>>>> This implementation runs the test runs over IPv4 link.
>>>>
>>>> Doesn't seem to pass on netdevsim for us:
>>>>
>>>> # 41.13 [+40.95] # ptp4l follower did not reach locked state (s2) within 40s
>>>> # 41.13 [+0.00] # Follower log (last 10 lines): ptp4l[2179.605]: ioctl SIOCETHTOOL failed: Operation not supported | ptp4l[2179.607]: interface 'eth0' does not support requested timestamping mode | failed to create a clock
>>>> # 41.15 [+0.02] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 173, in ptp_sync_test:
>>>> # 41.15 [+0.01] # Check| _run_ptp4l_wait_sync(nsimsv.ifname, nsimcl.ifname, nssv.name, nscl.name)
>>>> # 41.16 [+0.01] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 99, in _run_ptp4l_wait_sync:
>>>> # 41.17 [+0.01] # Check| ksft_true(False, "PTP sync timeout")
>>>> # 41.17 [+0.00] # Check failed False does not eval to True PTP sync timeout
>>>> # 41.32 [+0.16] not ok 1 ptp.ptp_sync_test
>>>> # 41.33 [+0.00] # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
>>>>
>>>> Anything we need to do?
>>>
>>> Can you share the config file you used? Seems the PTP clock was not
>>> found which may lead to PTP_1588_CLOCK_MOCK not being enabled?
>>
>> Shouldn't the configuration file be part of the test?
>>
>> Andrew
>
> I meant the kernel config. The PTP emulation requires PTP Mock to be
> enabled, as that's the backbone for generating timestamps. If it's
> disabled - netdevsim netdevs will report no timestamping support, as in
> the example above.
> - Maciek
tools/testing/selftests/drivers/net/netdevsim/config has
CONFIG_PTP_1588_CLOCK_MOCK=y
but maybe no CONFIG_PTP_1588_CLOCK ?
^ permalink raw reply
* Re: [PATCH net] vsock/virtio: fix potential unbounded skb queue
From: Bobby Eshleman @ 2026-05-05 16:37 UTC (permalink / raw)
To: Stefano Garzarella
Cc: Eric Dumazet, Arseniy Krasnov, Bobby Eshleman, Stefan Hajnoczi,
Michael S. Tsirkin, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev, eric.dumazet, Arseniy Krasnov, Jason Wang,
Xuan Zhuo, Eugenio Pérez, kvm, virtualization
In-Reply-To: <afoF_cHfl6ygcupM@sgarzare-redhat>
On Tue, May 05, 2026 at 06:11:13PM +0200, Stefano Garzarella wrote:
> On Tue, May 05, 2026 at 07:14:36AM -0700, Eric Dumazet wrote:
> > On Tue, May 5, 2026 at 6:52 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
> > >
> > > On Thu, Apr 30, 2026 at 12:26:52PM +0000, Eric Dumazet wrote:
> > > >virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
> > > >
> > > >virtio_transport_recv_enqueue() skips coalescing for packets
> > > >with VIRTIO_VSOCK_SEQ_EOM.
> > > >
> > > >If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
> > > >a very large number of packets can be queued
> > > >because vvs->rx_bytes stays at 0.
> > > >
> > > >Fix this by estimating the skb metadata size:
> > > >
> > > > (Number of skbs in the queue) * SKB_TRUESIZE(0)
> > > >
> > > >Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
> > > >Signed-off-by: Eric Dumazet <edumazet@google.com>
> > > >Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
> > > >Cc: Stefan Hajnoczi <stefanha@redhat.com>
> > > >Cc: Stefano Garzarella <sgarzare@redhat.com>
> > > >Cc: "Michael S. Tsirkin" <mst@redhat.com>
> > > >Cc: Jason Wang <jasowang@redhat.com>
> > > >Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > >Cc: "Eugenio Pérez" <eperezma@redhat.com>
> > > >Cc: kvm@vger.kernel.org
> > > >Cc: virtualization@lists.linux.dev
> > > >---
> > > > net/vmw_vsock/virtio_transport_common.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> > > >index 416d533f493d7b07e9c77c43f741d28cfcd0953e..9b8014516f4fb1130ae184635fbba4dfee58bd64 100644
> > > >--- a/net/vmw_vsock/virtio_transport_common.c
> > > >+++ b/net/vmw_vsock/virtio_transport_common.c
> > > >@@ -447,7 +447,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> > > > static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
> > > > u32 len)
> > > > {
> > > >- if (vvs->buf_used + len > vvs->buf_alloc)
> > > >+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
> > > >+
> > > >+ if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
> > > > return false;
> > >
> > > I'm not sure about this fix, I mean that maybe this is incomplete.
> > > In virtio-vsock, there is a credit mechanism between the two peers:
> > > https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-4850003
> > >
> > > This takes only the payload into account, so it’s true that this problem
> > > exists; however, perhaps we should also inform the other peer of a lower
> > > credit balance, otherwise the other peer will believe it has much more
> > > credit than it actually does, send a large payload, and then the packet
> > > will be discarded and the data lost (there are no retransmissions,
> > > etc.).
> >
> > I dunno, perhaps revert 077706165717 ("virtio/vsock: don't use skbuff
> > state to account credit")
> > and find a better fix then?
>
> IIRC the same issue was there before the commit fixed by that one (commit
> 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")), so
> not sure about reverting it TBH.
>
> CCing Arseniy and Bobby.
>
> >
> > There is always a discrepancy between skb->len and skb->truesize.
> > You will not be able to announce a 1MB window, and accept one milliion
> > skb of 1-byte each.
> >
> > This kind of contract is broken.
> >
>
> Yep, I agree, but before we start discarding data (and losing it), IMHO we
> should at least inform the other peer that we're out of space.
>
> @Stefan, @Michael, do you think we can do something in the spec to avoid
> this issue and in some way take into account also the metadata in the
> credit. I mean to avoid the 1-byte packets flooding.
>
> Thanks,
> Stefano
>
>
Indeed the old pre-fix skb code would have the same issue.
I can't think of any way around this without extending the spec.
Best,
Bobby
^ permalink raw reply
* [PATCH] net: iphc: fix offset errors in multicast context compression
From: Quan Sun @ 2026-05-05 16:31 UTC (permalink / raw)
To: linux-wpan, netdev; +Cc: alex.aring, davem, edumazet, andrew, Quan Sun
The function lowpan_iphc_mcast_ctx_addr_compress() contains two offset
errors that break context-based multicast address compression
(LOWPAN_IPHC_DAM_00).
When compressing the multicast address, the compressed format expects
exactly 6 bytes:
- Bytes 0-1: Flags, scope, and reserved bits (from s6_addr[1..2])
- Bytes 2-5: The 4-byte Group ID (from s6_addr[12..15])
Currently, the memcpy() operations use incorrect offsets:
1. The destination offset for the Group ID is &data[1] instead of
&data[2]. This overwrites the previously copied scope byte.
2. The source offset for the Group ID is &ipaddr->s6_addr[11] instead
of &ipaddr->s6_addr[12].
This mismatch results in a corrupted compressed address being
transmitted. Consequently, the receiving side fails to reconstruct the
original IPv6 address via lowpan_uncompress_multicast_ctx_daddr() since
it expects the Group ID to start at data[2].
Fix the logic by correcting both the destination and source offsets
so that the 6-byte compressed representation is assembled correctly.
Signed-off-by: Quan Sun <2022090917019@std.uestc.edu.cn>
---
net/6lowpan/iphc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index e116d308a8df6..29ae68ca3ec15 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -1091,7 +1091,7 @@ static u8 lowpan_iphc_mcast_ctx_addr_compress(u8 **hc_ptr,
/* flags/scope, reserved (RIID) */
memcpy(data, &ipaddr->s6_addr[1], 2);
/* group ID */
- memcpy(&data[1], &ipaddr->s6_addr[11], 4);
+ memcpy(&data[2], &ipaddr->s6_addr[12], 4);
lowpan_push_hc_data(hc_ptr, data, 6);
return LOWPAN_IPHC_DAM_00;
base-commit: 95084f1883a760e0d4290698346759d58e2b944a
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net, v3] net: mana: Fix crash from unvalidated SHM offset read from BAR0 during FLR
From: Dipayaan Roy @ 2026-05-05 16:28 UTC (permalink / raw)
To: Paolo Abeni
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, dipayanroy, leitao, kees,
john.fastabend, hawk, bpf, daniel, ast, sdf, yury.norov
In-Reply-To: <30f588ad-cf80-432b-bde3-13b3c0d5a124@redhat.com>
On Tue, May 05, 2026 at 03:42:46PM +0200, Paolo Abeni wrote:
> On 5/1/26 4:47 AM, Dipayaan Roy wrote:
> > @@ -73,10 +74,28 @@ static int mana_gd_init_pf_regs(struct pci_dev *pdev)
> > gc->phys_db_page_base = gc->bar0_pa + gc->db_page_off;
> >
> > sriov_base_off = mana_gd_r64(gc, GDMA_SRIOV_REG_CFG_BASE_OFF);
> > + if (sriov_base_off >= gc->bar0_size ||
> > + gc->bar0_size - sriov_base_off <
> > + GDMA_PF_REG_SHM_OFF + sizeof(u64) ||
> > + !IS_ALIGNED(sriov_base_off, sizeof(u64))) {
> > + dev_err(gc->dev,
> > + "SRIOV base offset 0x%llx out of range or unaligned (BAR0 size 0x%llx)\n",
> > + sriov_base_off, (u64)gc->bar0_size);
> > + return -EPROTO;
> > + }
>
> I think that the additional fix suggested by sashiko is really worthy,
> but should go in a separate patch. @Dipayaan: please follow-up on that
> one, thanks!
>
> Paolo
>
Hi Paolo,
Thanks for reviewing, and I will cross check and send out a separate patch for
issue pointed out by Sashiko(un-related to the current issue).
Regards
Dipayaan Roy
^ permalink raw reply
* Re: [PATCH net v1] net/mlx5: Fix HWS L2-to-L3 tunnel reformat release
From: Alexander Lobakin @ 2026-05-05 16:26 UTC (permalink / raw)
To: Prathamesh Deshpande
Cc: Saeed Mahameed, Leon Romanovsky, Moshe Shemesh, Mark Bloch,
Tariq Toukan, Yevgeny Kliteynik, Jakub Kicinski, netdev,
linux-rdma, linux-kernel
In-Reply-To: <20260504221920.48685-1-prathameshdeshpande7@gmail.com>
From: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
Date: Mon, 4 May 2026 23:19:17 +0100
> mlx5_cmd_hws_packet_reformat_alloc() allocates
> MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL objects from el2tol3tnl_pools with
> MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L3.
>
> The deallocation path uses el2tol2tnl_pools with
> MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L2 instead. This releases the
> packet-reformat entry through the wrong pool, corrupting pool accounting
> and potentially moving the bulk entry onto the wrong pool list.
>
> Use the matching L2-to-L3 tunnel pool and action type when releasing the
> object.
>
> Fixes: aecd9d1020e3 ("net/mlx5: fs, add HWS packet reformat API function")
> Signed-off-by: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH v8 phy-next 01/31] PCI: cadence: Preserve all error codes in cdns_plat_pcie_probe()
From: Bjorn Helgaas @ 2026-05-05 16:26 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, Bjorn Helgaas, Krzysztof Wilczyński,
Lorenzo Pieralisi, Manikandan K Pillai, Manivannan Sadhasivam,
Rob Herring, Tom Joseph
In-Reply-To: <20260505100523.1922388-2-vladimir.oltean@nxp.com>
[+cc Tom, author of bd22885aa188 in case there's something subtle here]
On Tue, May 05, 2026 at 01:04:53PM +0300, Vladimir Oltean wrote:
> The blamed commit functionally changed the error path of
> cdns_pcie_host_probe(), now cdns_plat_pcie_probe().
>
> When the old code path executed "goto err_get_sync", the PCIe controller
> probe function propagated the pm_runtime_get_sync() error code. The new
> code doesn't, and returns 0.
>
> Similarly for the "goto err_init" previously triggered by
> cdns_pcie_host_init() errors, and now triggered by
> cdns_pcie_host_setup() and cdns_pcie_ep_setup() errors. These are not
> propagated and will result in probing success, which is incorrect.
>
> Fixes: bd22885aa188 ("PCI: cadence: Refactor driver to use as a core library")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manikandan K Pillai <mpillai@cadence.com>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
I guess this driver is orphaned.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> v7->v8: patch is new, issue was flagged by Sashiko
> https://sashiko.dev/#/patchset/20260430110652.558622-1-vladimir.oltean@nxp.com
> ---
> drivers/pci/controller/cadence/pcie-cadence-plat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-plat.c b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> index b067a3296dd3..8b12a46b5601 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-plat.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> @@ -126,7 +126,7 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)
> while (phy_count--)
> device_link_del(cdns_plat_pcie->pcie->link[phy_count]);
>
> - return 0;
> + return ret;
This affects cases where pm_runtime_get_sync(),
cdns_pcie_host_setup(), or cdns_pcie_ep_setup() return failure.
Seems right to me to fail the probe when these fail.
Not all users of pm_runtime_get_sync() check for failure, but I think
all the other controller drivers that do check return failures from
the .probe().
> }
>
> static void cdns_plat_pcie_shutdown(struct platform_device *pdev)
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next 12/12] arm64: dts: qcom: qcs6490-rb3gen2: enable TC9564 with a single QCS8081 phy
From: Daniel Thompson @ 2026-05-05 16:25 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alex Elder, andrew+netdev, davem, edumazet, kuba, pabeni,
maxime.chevallier, rmk+kernel, andersson, konradybcio, robh,
krzk+dt, conor+dt, linusw, brgl, arnd, gregkh, mohd.anwar,
a0987203069, alexandre.torgue, ast, boon.khai.ng, chenchuangyu,
chenhuacai, daniel, hawk, hkallweit1, inochiama, john.fastabend,
julianbraha, livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <d29621c3-07fc-4720-abff-d8901a0d791c@lunn.ch>
On Fri, May 01, 2026 at 11:09:42PM +0200, Andrew Lunn wrote:
> > + tc956x_emac1_phy: ethernet-phy@1c {
> > + compatible = "ethernet-phy-id004d.d101";
> > + reg = <0x1c>;
> > + reset-gpios = <&tc956x_emac0 1 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <20>;
> > + reset-deassert-us = <20>;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&qep_irq_pin>;
> > + interrupts-extended = <&tlmm 101 IRQ_TYPE_EDGE_FALLING>;
>
> What is probably wrong. PHY interrupts are level, not edge.
Thanks (and agree). Will fix.
Daniel.
^ permalink raw reply
* Re: [PATCH v5 net-next 3/3] selftests:net: Implement ptp4l sync test using netdevsim
From: Maciek Machnikowski @ 2026-05-05 16:22 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jakub Kicinski, netdev, richardcochran, milena.olech,
willemdebruijn.kernel, vadim.fedorenko, horms
In-Reply-To: <9c7eecee-f0c2-4ee3-95cf-ae9965191902@lunn.ch>
On 05/05/2026 14:22, Andrew Lunn wrote:
> On Tue, May 05, 2026 at 09:36:30AM +0200, Maciek Machnikowski wrote:
>>
>>
>> On 04/05/2026 19:07, Jakub Kicinski wrote:
>>> On Sun, 3 May 2026 09:47:47 +0200 Maciek Machnikowski wrote:
>>>> Add PTP synchronization test using ptp4l and netdevsim.
>>>>
>>>> The test creates two netdevsim adapters, links them together
>>>> and runs the ptp4l leader and ptp4l follower on two ends
>>>> of the netdevsim link and waits for the follower to report the
>>>> synchronized state (s2) in its output log.
>>>>
>>>> This implementation runs the test runs over IPv4 link.
>>>
>>> Doesn't seem to pass on netdevsim for us:
>>>
>>> # 41.13 [+40.95] # ptp4l follower did not reach locked state (s2) within 40s
>>> # 41.13 [+0.00] # Follower log (last 10 lines): ptp4l[2179.605]: ioctl SIOCETHTOOL failed: Operation not supported | ptp4l[2179.607]: interface 'eth0' does not support requested timestamping mode | failed to create a clock
>>> # 41.15 [+0.02] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 173, in ptp_sync_test:
>>> # 41.15 [+0.01] # Check| _run_ptp4l_wait_sync(nsimsv.ifname, nsimcl.ifname, nssv.name, nscl.name)
>>> # 41.16 [+0.01] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 99, in _run_ptp4l_wait_sync:
>>> # 41.17 [+0.01] # Check| ksft_true(False, "PTP sync timeout")
>>> # 41.17 [+0.00] # Check failed False does not eval to True PTP sync timeout
>>> # 41.32 [+0.16] not ok 1 ptp.ptp_sync_test
>>> # 41.33 [+0.00] # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
>>>
>>> Anything we need to do?
>>
>> Can you share the config file you used? Seems the PTP clock was not
>> found which may lead to PTP_1588_CLOCK_MOCK not being enabled?
>
> Shouldn't the configuration file be part of the test?
>
> Andrew
I meant the kernel config. The PTP emulation requires PTP Mock to be
enabled, as that's the backbone for generating timestamps. If it's
disabled - netdevsim netdevs will report no timestamping support, as in
the example above.
- Maciek
^ permalink raw reply
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